Transcript Notes-8-guideline-execution

Notes 8
Guideline Execution Models
and Systems
1
Major efforts to produce
guideline execution schemes
• Arden Syntax/Medical Logic Modules – MLMs
– Structure
» Simple “triggers”
– History
» Derived from HELP
– Strength
» Simplicity
– Use
» Widespread in hospital and drug information systems for
warnings and monitors
– Problems
» The “Curly bracket problem”
2
Protégé/Eon
• Structure
– A general knowledge acquisition system based on a frame based ontology
(Protégé)
– An execution model for a specific model of guidelines which can be
expressed in Protégé (EON)
– ‘Standard’ reasoning mode: “Skeletal plan refinement”
• History
– Derived from Oncocin via Opal (Stanford)
• Problems
– Little re-use of ontologies – “curly bracket” variant
– No standard reasoner
– Steep learning curve to integrate pieces before you can start
• Strengths
– Flexibility
– Ease of use of ontology driven knowledge acquisition
– Many “Plug ins” – large community
• Use
– An international user community for expressing complex protocols
– AIDS treatment (THelper)
– Becoming a de facto standard for knowledge acquisition and interchange 3
• Web site: www.smi.stanford.org
Pro Forma/Tallis Publets
• Structure (Publets)
– Integrated reasoning strategy and hierarchical decomposition of tasks
– “Argumentation”
– Web based architecture
• History
– Derived from work on “argumentation” and safety critical systems (RED),
and “Oxford System of Medicine” (ICRF ACL John Fox)
• Strengths
– Unified view; Built in structure; Web orientation; User interface
• Weaknesses
– Lack of ontology, link to medical records
– Dependence on a single mode of reasoning
• Use
–
–
–
–
Commercial version available from InferMed
Open Web version just released
Goal of creating an open process in formal guideline development
Collaborative project with BMJ Evidence
• Web site: www.openclinical.org/tallis
4
ASBRU
• History
– Out of Stanford but now Ben Gurion and Vienna
• Structure
– Integrated structure aimed at definitive solution
– A language plus an execution model
– Emphasises “Abstraction”
• Strengths
– Ambition, completeness, rigour
• Weaknesses
– Complexity, lack of good implementations (yet)|
• Use
– Largely limited to a few users
– Highly influential on standards community
– Web site:
5
Tallis - Plan with 4 Operations
Plan
Decision
Action
Enquiry
6
The Tasks
• Plans
– Gather operations together into hierarchical units
• Operations
– Enquiry
» Define variables and questions to ask
(Can also be linked to procedures, e.g. to enquire of EHR)
– Decision
» Weigh up evidence for and against
• Or confirming or excluding
» Set threshold for success
• Support level if no confirmers or exluders
– What happens if both?
– (I don’t know – can you find out?)
7
The components (2)
• Actions
– Do something
» In simple cases make a recommendation
8
The model
• Things happened when triggered
• Subject to sequencing constraints
– Represented by arrows in flow diagram
• Can have several ‘threads’ at once
9
Other Tallis Vocabulary
• “Source”
– A source of information, normally a variable
• “Argument”
– A way of using sources in a decision
• “Candidates” the options for a decision
• “Parameters”
– Tasks can be “parameterised” by variables, but we will
ignore this for now.
10
The expression editor
• Invoked by clicking ‘…’
• Works by ‘highlight
and replace
• Really an assisted text
editor
– But if you use it you
can’t make spelling
mistakes
– Follow demonstration in
tutorial
11
The Execution Model
• Create/Edit a Publet
• Check it with the checker
• Submit it for execution to a web engine
someplace
12
Top Down Development
“Keystones”
• Keystones
– Mutable elements that can stand in for something you
haven’t decided how to do yet
» Get basic shape, sequence, preconditions in place
» Then decide if it can be a simple task or requires a plan
– Keystones can be executed.
13
Your task for Friday and next
week
• Work through the tutorial on your own
• Bring in a simple protocol but with more than
one level on paper
• Build a simple two-level protocol and test it.
• Build the same protocol both bottom up and
top down
• Keep a Log of queries/problems for the Tallis
group
– Good software development practice
– ‘Payment’ for use of software and training
14
Protégé
• Main differences
– Definable frames
» Tallis are fixed
– Information stored in frame structure
» Tallis assumes information will come from elsewhere
• Defined ad hoc
– Plug and Play
» Widgets
» Tabs
» Examples
• Graphics
– Pro-forma like graphical formalism
– Or usable for other graphical presentations
• UMLS
• …
– No Execution Engine / Pluggable execution engine
» A knowledge acquisition tool
» Requires separate execution engine for each application
15