1. 1 Notes 8 Guideline Execution Models and Systems

2. 2 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”

3. 3 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 Web site: www.smi.stanford.orgwww.smi.stanford.org

4. 4 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/talliswww.openclinical.org/tallis

5. 5 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:

6. 6 Tallis - Plan with 4 Operations Plan Enquiry Decision Action

7. 7 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?)

8. 8 The components (2) Actions –Do something »In simple cases make a recommendation

9. 9 The model Things happened when triggered Subject to sequencing constraints –Represented by arrows in flow diagram Can have several ‘threads’ at once

10. 10 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.

11. 11 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

12. 12 The Execution Model Create/Edit a Publet Check it with the checker Submit it for execution to a web engine someplace

13. 13 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.

14. 14 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

15. 15 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