1

Notes 8Guideline Execution Models

and Systems

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

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

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/tallis

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

Tallis - Plan with 4 OperationsPlan

Enquiry

Decision

Action

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

The components (2)

• Actions– Do something

» In simple cases make a recommendation

9

The model

• Things happened when triggered

• Subject to sequencing constraints– Represented by arrows in flow diagram

• Can have several ‘threads’ at once

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

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

The Execution Model

• Create/Edit a Publet

• Check it with the checker

• Submit it for execution to a web engine someplace

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

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

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