The EON Guideline Modeling System - Samson W. Tu Stanford Medical Informatics Stanford University School of Medicine
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
The EON Guideline Modeling System
Samson W. Tu
Stanford Medical Informatics
Stanford University School of Medicine
Stanford, CAOverview z Introduction to EON architecture for creating DSS for guideline-based care z Components of EON guideline modeling system uConcept model uPatient data model uExpression language uGuideline model z Questions
Genealogy of EON Guideline
Model
z Successive projects ...
...
to develop ONCOCIN
InterMed GLIF2
guideline-based
decision-support T-HELPER EON model
EON model'
GLIF
InterMed2
GLIF3
EON
PRODIGY EON Guideline
modelEON Research Problems z How to model clinical guidelines and protocols to provide patient-specific DS? z How to create a knowledge-engineering environment to facilitate encoding of guidelines and protocols? z How to represent, reason with, and visualize time-oriented patient data? z How to present and explain DS recommendations and conclusions?
EON 2.0
A Component-Based Architecture
Clients Yenta
Data-Display Servers
Yenta Temporal
Patient
Database
Client Mediator
Yenta
Eligibility
Yenta Eligibility
Client
Server
Explanation
Guideline
Yenta
Advisory
Yenta Advisory
Client Server
Guideline
Protégé Knowledge
BaseEON Modeling Approach
z Modeling, not programming
uEncoding guidelines is a modeling process requiring
training
uGuideline encoders tell the system appropriate
domain knowledge
z Allow alternative methods for performing a task
uGoal: plug in only those knowledge structures
needed to solve a particular problem
z Ease of use (by clinical collaborator) a design
criterion
uBut sometimes making something easy makes other
things hardOverview z Introduction to EON architecture for creating DSS for guideline-based care z Components of EON guideline modeling system uConcept model uPatient data model uExpression language uGuideline model z Questions
Guideline Modeling as Creation of
a Set of Interacting Models
4
Temporal- Organization
… Abstraction Guideline Model Model
Model
uses
3
Expression
Languages
depends on
1
Patient
Medical Concept 2
Data Model
Model
(VMR)1. EON Guideline Component:
Medical Concept Model
z Defines
uTaxonomic hierarchy of
concepts (e.g., ACE
inhibitor) used in
guidelines
uRelationships among
concepts (e.g.,
indications for ACE
inhibitor)
z Supplies
uControlled terminology
for guideline encodingWhy Not Use Standard
Vocabulary Directly?
z Need for strict is-a
classification hierarchy Diabetes
z Need to index medical and
DM type 1 DM not
guideline knowledge taking ARB
z Need for definition of
guideline-specific concepts
and axis of classification
DM not taking ARB:
Presence of DM and absence of
prescription for ARB
z Need to organize mappings
to host-system data
dictionary2. EON Guideline Component:
Patient Data Model
z Simplified model of
patient information
uFocus on clinical and
demographic
information needed for
clinical decision making
uFlat hierarchy for easier
mappings to relational
database
uData are time-stamped,
interval-based, or staticUse of Patient Data Model z Patient data model defines the types of assertions that can be made about patient situation z Patient data model allows alternative expression languages uTemplate-based uTemporal uLogic-based
3. EON Guideline Component:
Expression Language
z Template-Based Criterion Language
uFill-in-blank templates to encode relatively
simple expressions
Absence of
potassium lab result
within the last 7
days3. EON Guideline Component:
Expression Language
z Temporal Query and Criterion Language
uan episode of uncontrolled blood pressure
that overlaps with use of lisinopril and starts
within two weeks of initiating lisinopril
TEMPORAL SELECT domain_name
VALID INTERSECT(Condition, Medication)
FROM Condition, Medication
WHERE domain_name = “UNCONTROLLED_BP” AND
drug_name = “lisinopril”
WHEN start(Condition) AFTER start(Medication) AND
start(Condition) BEFORE
(start(Medication) + weeks(2))3. EON Guideline Component:
Expression Language
• Logic-Based Query and Criterion Language
• No current medication is contraindicated
(defrange ?current_med :FRAME Medication)
(defrange ?med_class :FRAME Drug_Class)
. . .
(not (exists ?current_med
(exists ?med_class
(and (subclass-of
(drug_name ?current_med) ?med_class)
(exists ?contraindication
(and (Absolute_Contraindications
?med_class ?contraindication)
(exists ?problem
(subclass-of
(domain_term ?problem)
?contraindication)))))))Why Three Expression
Languages?
z Knowledge-acquisition requirement
uClinicians feel comfortable encoding template criteria
with little training!
z Expressiveness requirement
uNeed to detect complex temporal patterns
uNeed to write general expressions that range over a
set of objects (forall, exists)
z Component-orientation
uTemporal query/abstraction engine made a
component usable by various applications
z Synergy with sister project
uUse Protégé constraint language as expression
language4. EON Guideline Component:
Guideline Model
z Task-oriented view
uMust contain concepts and relations for encoding
guideline knowledge needed to perform specific task
=Patient-specific decision support
z Domain-oriented view
uMust use domain-oriented abstractions sensible to
clinical collaborators
=e.g., model indications and contraindications as relations
among drugs and medical conditionsTask-Based Approach to Defining
Guideline DS Functionalities
Goal
High-level
Abstractions actions
Action1
Alternative1 Action2
Choice Alternative3 Action3 Action4
Alternative4 Action5
Specific
Data actions4.1 EON Guideline Model:
Setting Goals
For diabetic patients, the target blood pressure is
135/80 mm Hg
z Each guideline or subguideline has an AND/OR
goal tree
uOR subgoals modeled as a set of conditional goals
uConditional goal
=Selection criteria: “presence of diabetes”
=Goal criteria: “systolic BP < 130 mm Hg and diastolic BP
< 80 mm/Hg”
z Criteria language allows query of whether goals
are satisfied
z Satisfaction of goal as reason for making choice4.2 EON Guideline Model:
Interpreting Data
z Terminological abstraction:
Diabetes Mellitus
use is-a hierarchy of concept
model
DM type 1 DM type 2
z Non-temporal abstraction: use
concept-definition capability
“DM not ARB” := presence of EST 2190 Protocol
DM and absence of angiotensin
2 receptor blocker prescription
[G0] [G1] [G2] [G1]
z Temporal abstraction: use
Resume/RASTA 2000
Granulocyte
counts
Does there exists grade 2
granulocytopenia that lasts 1000
for more than 2 weeks?4.3 EON Guideline Model:
Sequencing Decisions and Actions
z A process model that organizes scenarios, decisions
and actions over time
uScenario: landmark patient states where
=real patient situation can be synchronized with process state
=context-specfic actions are specified
=decisions need to be made
uFlow-of-control: sequencing, repetition and
concurrency of actions and decisions
uNesting: Hierarchical decomposition of processes
z Represented as diagrammatical flowchartExample of Guideline
Management Process
Action
Concurrent step
actions
If-then-else
decision
Alternative
choices
Patient Subguideline
scenario4.4 EON Guideline Model: Action
Specification
z Specification of acts to be performed
uActions that change states of activities
=start, stop, change attributes (, abort, delay, suspend,
resume)
uSystem and medical actions
=e.g. send a message vs. order a test
uTemporal specification
=e.g. return appointment in 3 months
uUse of standard medical terminology
=e.g. ordering a specific lab test4.5 EON Guideline Model: Action
Refinement
Give ACEI
Preferred drug
Give lisinopril
Give dose4.6 EON Guideline Model:
Making Decisions
z Extensible decision
architecture
z Decision step rule-in:
BP
controlled
uChoice based on scenario action step
conditional rule rule-in:
BP not
uChoice based on controlled
for > 6 months
pros-and-cons
argumentation
u...Overview z Introduction to EON architecture for creating DSS for guideline-based care z Components of EON guideline modeling system uConcept model uPatient data model uExpression language uGuideline model z Questions
Questions
z How to represent and and use goals?
z Are there different “process” models?
uIs scenario necessary?
z Where do you draw the line
ubetween general medical knowledge and guideline
knowledge?
ubetween terminological ontology and knowledge
base?
z Are HL7 Act classes sufficient as the basis for action
specification?
z Why not model action refinement as subguidelines?
z Should expression language be declarative?
z How to use standard vocabularies?You can also read
