Notes 8 Guideline Execution Models and Systems 1

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 Infer. Med 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