1. Temporal Reasoning and Planning in Medicine The Asgaard Project: A Task-Specific Framework for the Application and Critiquing of Time-Oriented Clinical Guidelines Yuval Shahar, M.D., Ph.D.

2. The Asgaard* Project: The Outline
The Basic Model
Guideline-Related Tasks
Overview of Architecture
The Asbru* Language
Example: Gestational Diabetes
The Asbru-based guideline-acquisition tool
Conclusions and future Steps
* In Norse mythology, Asgaard was the home and citadel of the gods, corresponding to
Mount Olympus in Greek mythology. It was located in the heavens and was accessible
only over the rainbow bridge, called Asbru (or Bifrost)

3. Design Time Versus Execution Time
At design time:
An author designs a clinical guideline
The author has in mind prescribed actions, an intended overall plan, and intended patient states
During execution time:
A care provider performs actions, which are recorded, observed, and abstracted over time
The state of the patient is recorded, observed, and abstracted over time

4. An Intention-Oriented Critiquing Model
Execution time
Design time
Patient state
Care-provider state intentions
Guideline intended state
Care-provider abstracted plan
Guideline intended plan
Care-provider observed actions
Guideline prescribed actions

5. Intention-Based Critiquing
Guideline prescribed actions <—> executed (observed) actions
Guideline intended plan <—> pattern of executed actions
State intentions of guideline <—> state intentions of provider
State intentions of guideline <—> abstracted patient state
State intentions of provider <—> abstracted patient state
=> A comparison (critiquing) vector is a behavior

6. Example behaviors + + + + + Everything goes according to plan
The guideline does not work
Plan intention achieved by other actions
State intention achieved by another plan
Plan and state intentions not achieved

7. A Plan-Recognition and Critiquing Example (I)
—Patient state:
2 weeks of severe anemia
—Protocol intention:
Avoid more than 2 weeks of severe anemia
—Protocol recommendation:
Decrease dose of drug toxic to bone marrow
—Physician's action:
Transfusion of two units of packed red blood cells

8. A Plan-Recognition and Critiquing Example (II)
• Analysis:
Both methods compatible with elevating hemoglobin level:
1. Decrease a plan argument inversely related to it
2. Initialize a plan that increases it directly
• Conclusions:
a. The protocol’s state intention followed by another plan
b. Next therapy session, monitor transfusion complications

9. Plan Recognition and Critiquing: Data and Knowledge Requirements
Plan recognition is a prerequisite for effective plan critiquing
Required input data:
care provider’s executed actions
patient’s clinical states
action and state intentions of the guideline
Additional knowledge requirements:
plan effects (overall and argument-specific)
revision strategies (generic and domain-specific)

10. Guideline-Based–Care Support Tasks
At design time:
verification of plan intentions given actions
validation of state intentions given actions and plans
At execution time:
determination of guideline applicability
execution of the guideline
recognition of providers intentions from their actions
critiquing of providers actions
modification of guideline or provider plans
evaluation of guideline effectiveness

11. Knowledge Requirements of the Tasks
Each task requires different knowledge roles
Execution requires knowledge of prescribed actions; preconditions and termination conditions; patient states
Plan recognition, critiquing, and modification require also knowledge of executed actions and patient states; various types of plan preconditions; action and state intentions; intervention effects; revision strategies

12. The Asgaard Guideline-Support Architecture
Care
provider
Guideline-
acquisition
tool
Patient database
Temporal-mediation
module
Execution interpreter
Guideline-
specification
library
Task-specific
reasoning
modules
Domain-specific
knowledge bases
Plan recognition
Temporal abstraction
Applicability
Revision strategies
Critiquing
Intervention effects

13. Asbru: An Intention-Based Guideline Language
Expressive, time-oriented specification language
sequential plans
parallel plans
cyclical plans
task-specific annotations
preferences
conditions
intentions
effects

14. The Asbru Ontology of Plan-Body Types
DO-IN-SEQUENCE
SEQUENTIAL
PLANS
DO-ALL-TOGETHER
CONCURRENT
PLANS
DO-SOME-TOGETHER
Plan types
PARALLEL
PLANS
DO-ALL-ANY-ORDER
ANY-ORDER
PLANS
DO-SOME-ANY-ORDER
CYCLICAL
PLANS
DO-EVERY

15. Guideline Annotations in AsbruY P R E F E R E N C E S U T I L I T Y S E L C T - M H O D N S R A I R E S O U C - N T A I I N T E O NS
INTERMEDIATE-STATE
INTERMEDIATE-ACTION S E T U P - P R E C O N D I T I O N
OVERALL-STATE C O N D I T S F I L T E R - P R E C O N D I T I ON
OVERALL-ACTION
SUSPEND-CONDITION
ABORT-CONDITION
PLAN EFFECTS
COMPLETE-CONDITION
OVERALL-EFFECTS
RESTART-CONDITION
ARGUMENT-EFFECTS

16. State Transitions of a Generic Guideline Plan
Ignored
Considered f i l t e r - p r e c o n d i t i o n
false filter
precondition
false setup
precondition
Possible
false setup
precondition s e t u p - p r e c o n d i t i o n
Ready
false setup
precondition
Rejected

17. State-Transition Criteria for Guideline-Plan Instances
reactivate
Suspended s u s p e n d
Activated a b o r t a b o r t c o m p l e t e
Aborted
Completed

18. Types of Plan Conditions
All conditions are (optional) temporal patterns
Filter preconditions need to be true at start of a guideline
Setup preconditions need to be achieved to enable a guideline
Suspend conditions cause suspension if true during execution
Restart conditions enable reactivation of a suspended execution
Completion conditions specify when the execution is completed
Abort conditions specify when the execution is aborted

19. Types of Plan Intentions
Intentions: temporal patterns to maintain, achieve, or avoid
Four (optional) categories of intentions can annotate each plan:
Intermediate state (during plan execution)
Overall state pattern (after plan execution)
Intermediate action (during plan execution)
Overall action pattern (after plan execution)

20. Plan Preferences Bias or constrain the selection of actions or plans
Explicit preferences include
Method selection: a matching measure of plan applicability
Utility measures of the overall plan (e.g., minimize cost)
Resource constraints (e.g., use -blockers)
Start conditions when preconditions hold (manual, automatic)

21. Plan Effects
Describe a functional relationship between the plan and measurable clinical parameters
Include a measure of likelihood
Include a temporal annotation
Two types of effects can be represented:
Overall effect of plan
Effect of each argument of the plan

22. A Graphical Representation of a Guideline
Plans P L A N A 1 P L A N A 2 P R E F E R E N C E S I N T E N T I O N S C O N D I T I O N S C O N D I T I O N S E F F E C T S E F F E C T S A G B C D H I E E E E F
Time

23. An Asbru Syntax Example: GDM
(PLAN observing-GDM-Type-II
(INTENTION:INTERMEDIATE-STATE (MAINTAIN STATE(blood-glucose) (NORMAL | SLIGHTLY-HIGH) GDM-Type-II [[24 G-WEEKS, 24 G-WEEKS], [DELIVERY, DELIVERY],
[_,_]] CONCEPTION) (FILTER-PRECONDITION (one-hour-GTT (140, 200) pregnancy [[24 G-WEEKS, 24 G-WEEKS], [26 G-WEEKS, 26 G-WEEKS],
[_,_]] CONCEPTION) (SUSPEND-CONDITION (STATE(blood-glucose) HIGH GDM-Type-II [[24,24], [DELIVERY,DELIVERY], [_,_]] CONCEPTION [[G-WEEK,G-WEEK], [G-WEEK,G-WEEK], [_,_]])
(DO-ALL-TOGETHER (glucose-monitoring) (nutrition-management) (observe-insulin-indicators)) )

24. The Asbru Knowledge-Acquisition Tool
Expert physicians need not have familiarity with the syntax of the Asbru language to author clinical guidelines
Graphic knowledge-acquisition tools can be generated automatically by systems such as PROTÉGÉ
Once the ontology underlying the Asbru language is defined, a knowledge-acquisition tool can be generated automatically from it using the PROTÉGÉ suite of tools

25. The Knowledge-Acquisition Tool Ontology

26. The Knowledge-Acquisition Tool Interface

27. The AsbruView Visualization Tool

28. The Local Aspect The BGU/Vienna/Stanford Asgaard Project
Computational modules for verification, application, quality assessment
The BGU/Ness-ISI guideline-server and guideline-services project
Web-based tools for specification, visualization, search & retrieval, eligibility determination, application, quality assessment
Integration with the Ness Web-based clinical data repository architecture
Uses a new hybrid representation to facilitate markup of existing guidelines and creation of new guidelines:
Free text (HTML)
Structured text (XML)
Formal executable language (Asbru)
The guideline is converted to structured text by a medical expert using a markup (HTML-to-XML) editor, then to formal Asbru by a knowledge engineer using an XML-to-Abru editor
Each of the application tools is designed to handle all three representations

29. The BGU Guideline Mark-Up Tool

30. The BGU Guideline Search & Retrieval Tool

31. The BGU/Ness-ISI guideline-services project
Knowledge engineer
Medical expert
Structured-to-Formal (Asbru) conversion tool
Guideline markup tool
BGU Clinical- guideline server
Clinical data
repository
mediator
Guideline library interface
Phase II Tools
Phase I Tools
GL eligibility determination
GL Search & retrieval
GL Application
Quality assessment of GL application
GL Visualization

32. The Importance of Infrastructure and Intelligent Data Abstraction for Automated Support of Guideline-Based Care
The effectiveness of automated tools depends on the quality of the electronic clinical-data repositories
Meaningful clinical data repositories integrate multiple, heterogeneous, distributed data sources
Computing the answer to complex queries to support the multiple guideline-based care tasks, such as therapy and quality assessment (“Did the patient have more than 3 weeks of moderate anemia during the past 6 months of the current treatment?”), requires sophisticated methodologies for abstraction of time-oriented clinical data

33. Current and Future Work in The Asgaard Project
The syntax of the Asbru language is being stabilized
Guidelines are modeled in several domains (diabetes, asthma)
The knowledge-acquisition tool for intention-oriented guidelines is developed using tools from the PROTÉGÉ project
XML mark-up tools are developed to annotate and retrieve existing text-based guidelines using semi-formal representations
Development focuses on the core computational reasoning modules, in particular execution and critiquing
Verification and visualization tasks have been investigated in depth by colleagues in Vienna

34. Summary: The Asgaard Project
Automated support of clinical guidelines involves a dialog
Full support requires explicit representation of intentions
Plan critiquing involves plan recognition; both require knowledge of domain-specific plan-effects and revision strategies
the Asbru language enables representation of the knowledge roles
Intentions are temporal patterns to maintain, achieve, or avoid
Intentions support validation, verification, execution, critiquing, recognition, modification, reuse, and evaluation of guidelines