GLARE (GuideLine Acquisition Representation and Execution)

1. GLARE(GuideLine Acquisition Representation and Execution) Paolo Terenziani Dipartimento di Informatica, Universita’ del Piemonte Orientale “Amedeo Avogadro”, Alessandria, Italy - Introduction - Representation formalism - Kernel Architecture: acquisition and execution modules - General Architecture (advanced features of GLARE) - Decision making - Temporal reasoning - Verification

2. Introduction Clinical guidelines are a means for specifying the “best” clinical procedures and for standardizing them Adopting (computer-based) clinical guidelines is advantageous Different roles: - support - critique - evaluation - education - …... Many different computer systems managing clinical guidelines (e.g., Asgaard, GEM, Gliff, Guide, PROforma,…)

3. GLARE(GuideLine Acquisition Representation and Execution) -Joint project with: Gianpaolo Molino, Mauro Torchio Laboratorio di Informatica Clinica, Azienda Ospedaliera S. Giovanni Battista, Molinette, Torino, Italy Stefania Montani, Alessio Bottrighi, Luca Anselma, Gianluca Correndo - Domain independent (e.g., bladder cancer, reflux esophagitis, heart failure) - User-friendly (limited number of primitives)

4. CG D A B C B B1 B2 B1 B2.3 B1.2 B2.1 B1.1 B2.2 B2 GLARE (Guideline Acquisition, Representation and Execution)Representation Formalism Tree of graphs

5. CG D A B C B B1 B2 B1 B2.3 B1.2 B2.1 B1.1 B2.2 B2 Representation Formalism Tree of graphs Atomic actions

6. CG D A B C B B1 B2 B1 B2.3 B1.2 B2.1 B1.1 B2.2 B2 Representation Formalism Tree of graphs Atomic actions Composite actions (plans)

7. CG D A B C B B1 B2 B1 B2.3 B1.2 B2.1 B1.1 B2.2 B2 Representation Formalism Tree of graphs Atomic actions Composite actions (plans) Control relations between actions: - sequence

8. CG D A B C B B1 B2 B1 B2.3 B1.2 B2.1 B1.1 B2.2 B2 Representation Formalism Tree of graphs Atomic actions Composite actions (plans) Control relations between actions: - sequence - “controlled” (e.g., during)

9. CG D A B C B B1 B2 B1 B2.3 B1.2 B2.1 B1.1 B2.2 B2 Representation Formalism Tree of graphs Atomic actions Composite actions (plans) Control relations between actions: - sequence - “controlled” - alternative

10. CG D A B C B B1 B2 B1 B2.3 B1.2 B2.1 B1.1 B2.2 B2 Representation Formalism Tree of graphs Atomic actions Composite actions (plans) Control relations between actions: - sequence - “controlled” - alternative - repetition (e.g. “3 times each 2 days for a month”)

11. Representation Formalism Temporal constraint associated with atomic actions and control relations (see below)

12. Representation FormalismHierarchy of Action Types Action Plan Work action Query Decision Conclusion Clinical action Pharmacol. prescription Diagnostic decision Therapeutic decision

13. Representation Formalismdescription of a clinical action

14. Surgical treatment Treatment choice Expectant management Litholitic therapy Therapeutic decisions Fixed set of parameters (effectiveness, cost, side-effects, compliance, duration) Treatment choice for symptomless gallbladder stones

15. Local information associated with treatment choice (in the symptomless gallbladder stones guideline)

16. Diagnostic Decisions * Decision parameters <finding, attribute, value> * Decision criteria score-based mechanism For each alternative For each parameter  score  (additive) threshold range

17. Diagnostic Decisions(Gastro Esophageal Reflux Disease) PARAMETERS: heartburn absent (“no-hb”), heartburn lasted not more than 3 months (“hb=<3”), heartburn r lasted more than 3 months (“hb>3m”); dysphagia absent (“no-dys”); dysphagia present (“dys”); occurrence of weight loss (“wl”) or non-occurrence (“no-wl”); hemathemesis absence (“no-hem”); hemathemesis presence (“hem”); postural reflux absent (“no-ref”), postural reflux lasted not more than 3 months (“ref=<3”); postural reflux lasted more than three months (“ref>3m”). THRESHOLD:>9. (One should conclude “no GERD” only if heartburn, dysphagia, weight loss, hematemesis and postural reflux are all absent.)

18. Acquisition Strict interaction with DB’s Clinical DB  hierarchically organized vocabulary  Standardization  Data sharing  Support for semantic checks (e.g., legal attribute values) NOTE: the organization (schema) of Patients DB is equal to the one of the Clinical DB  During acquisition, GLARE gets the information used at execution-time to retrieve automatically the patient’s data (via automatically generated dynamic-SQL queries)

19. Acquisition“Intelligent” helps (syntactic & semantic checks) - “legal” names & “legal” values for attributes - “logical” design criteria (no unstructured cycles, well-formed alternatives & decisions) - “semantic” checks: consistency of temporal constraints

20. Each block (including cycles) has just one entry and one exit a crucial step in order to enforce the semantic clearness of a representation formalism, and, thus, its understandability and practical usefulness (see the discussion about programming languages in the 60’) Digression 1We only allow “structured” guidelines

21. Clinical DB Expert Physician Pharmac. DB Acquisition Interface Resource DB Knowledge Manager ICD-9-CM DB Guidelines DB Architecture of the system(Acquisition part)

22. AcquisitionGraphical Interface

23. Clinical Guidelines Execution Module “Instantiate” a general guideline on a specific patient Basic Requirements  Independent of the guideline  Independent of the task (general purpose)  Providing support to decisions

24. Clinical DB Expert Physician User Physician Pharmac. DB Acquisition Interface Execution Interface Resource DB Knowledge Manager Execution Module ICD DB Guidelines DB Guidelines Instantiation DB Patient DB Architecture of the system

25. Agenda-based execution In the agenda - next actions to be executed - execution time (earliest and latest e.t.)  “On-line” execution: wait until the next e.t. (support physician in clinical activity)  “Simulated” execution: jump to the next e.t. (education, critique, evaluation)

26. Executing atomic actions Work actions: - evaluate pre-conditions - execute action within its range of time - delete from the agenda Query actions: - retrieve data from patient’s DB - wait for data not already in the DB, or for the update of “expired” data Conclusion actions: - insert conclusion into the patient’s DB Decision actions: (see alternatives)

27. Executing composite actions Sequence: - evaluate next action e.t. (given current time and delay) - execute it Concurrent actions: - execute actions according with the temporal constraints Decision + alternative actions (e.g., diagnostic decision): - evaluate parameter values for each alternative, using patient’s DB - determine the score for each alternative - compare the score with the threshold - show the alternatives to the user-physician (distinguishing between “suggested” and “not suggested” ones, and showing parameters and scores) - execute the alternative chosen by the physician (warning available)

28. Executing Clinical Guidelines: other issues  Repeated actions and user-defined periodicities - expressive language for user-defined periodicities [IEEE TKDE, 97] - computing next execution time  Exits  Failures return to previous decisions (chronological vs. guided backtracking)  A user-friendly graphical interface

29. Temporal Reasoning Module Contextualization Module GLARE KERNEL SPIN Update Module Decision-Making Module Model-Checking Module GLARE: Architecture of the system

30. GLARE KERNEL GLARE: Contextualization Temporal Reasoning Module Contextualization Module SPIN Update Module Decision-Making Module Model-Checking Module

31. GLARE: Contextualization Gap between GL generality and the peculiarity of specific contexts of execution is one of the major obstacles to GL dissemination & exploitation In GLARE: software module to automatically adapting (general) GL considering locally available resources * INPUT: a “general” GL + a list of locally available resources * OUTPUT: a “locally-adapted” GL: only paths for which resources are locally available are retained

32. GLARE KERNEL GLARE: Model Checking Temporal Reasoning Module Contextualization Module SPIN Update Module Decision-Making Module Model-Checking Module

33. GLARE: Model Checking After the acquisition of a GL, it is important to verify its properties (e.g., correctness, patient class eligibility, patient applicability) GLARE is loosely coupled with the model-checker SPIN General-purpose solution! Given any GLARE GL, any property that can be expressed in LTL can be checked!

34. GLARE KERNEL GLARE: Update Temporal Reasoning Module Contextualization Module SPIN Update Module Decision-Making Module Model-Checking Module

35. GLARE: Update GL content has to be adapted to local contexts (e.g., country rules) and continuously revised to be up-to-date To grant for quality and EBM, a team of responsible has to evaluate update proposals • In GLARE (ongoing work): bitemporal Database support for managing: • proposals of update • acceptance\rejection

36. GLARE KERNEL GLARE: Temporal Reasoning Temporal Reasoning Module Contextualization Module SPIN Update Module Decision-Making Module Model-Checking Module

37. GLARE: Temporal Reasoning Temporal constraints (e.g., delays between actions) play a fundamental role within GL. • - A formalism to represent them is needed! • Correct & complete algorithms to propagate the constraints are also needed! • GLARE’s Temporal Reasoner can: • check the consistency of constraints (acquisition phase) • check whether actions are scheduled\executed accordingly to the GL constraints, and schedule next actions (execution phase)

38. GLARE KERNEL GLARE: Decision-making Temporal Reasoning Module Contextualization Module SPIN Update Module Decision-Making Module Model-Checking Module

39. GLARE: Decision-making Decision making is a core issue in the clinical practice. In particular, therapy selection is a critical issue. Different parameters (cost, effectiveness, expected utility) must be taken into account • In GLARE: a semi-automatic decision support system based on • simulation capabilities • Decision Theory

40. GLARE: current status • A Java prototype implements the kernel of the system • The prototype interacts with the (current) patient records (stored in Cache) during execution • All software developed by students: no “fully engineered” and “supported” sowtware available yet Different extensions of the prototype to demonstrate the feasibility of contextualization, decision making, model-checking, and temporal reasoning facilities Ready for the step towards a commercial product

41. Remarks • Computer-based approaches to GL can provide crucial adavntages for • Organizations (quality, service optimization, standardization) • Physicians (decision support, quality) • Patients (quality & standardization of the treatment, avoiding errors) A strict and long-term cooperation of Physicians and Computer Scientists has lead to the development of GLARE GLARE embodies advanced Artificial Intelligence techniques, providing automatic support forcontextualization, decision making, model-checking, update management, and temporal reasoning

42. GLARE: Decision-making “local information”: considering just the decision criteria associated with the specific decision at hand “global information”: information stemming from relevant alternative pathways in the guideline

43. “What if” facility Facility for gathering the chosen parameter (e.g, resources, costs, times) from the “relevant” alternative paths on the guideline It provides an idea of what could happen in the rest of the guideline if the physician selects a given alternative for the patient, and supports for comparisons of the alternatives

44. Laparoscopy Surgical treatment Laparoscopy Choice of surgical appr. Treatment choice Expectant management Laparotomy Laparotomy Litholitic therapy Litholitic treatment Syntomless gallbladder stonestreatment choice: “global information”

45. Laparoscopy Surgical treatment Laparoscopy Choice of surgical appr. Treatment choice Expectant management Laparotomy Laparotomy Litholitic therapy Litholitic treatment Syntomless gallbladder stonestreatment choice: “global information” Duration min:2 days Max:3 days

46. Laparoscopy Surgical treatment Laparoscopy Choice of surgical appr. Treatment choice Expectant management Laparotomy Litholitic therapy Litholitic treatment Syntomless gallbladder stonestreatment choice: “global information” Laparotomy Duration min:6 days Max:8 days

47. Laparoscopy Surgical treatment Laparoscopy Choice of surgical appr. Treatment choice Expectant management Laparotomy Laparotomy Litholitic therapy Litholitic treatment Syntomless gallbladder stonestreatment choice: “global information” Duration min:1 day Max: all life long

48. Laparoscopy Surgical treatment Laparoscopy Choice of surgical appr. Treatment choice Expectant management Laparotomy Laparotomy Litholitic therapy Litholitic treatment Syntomless gallbladder stonestreatment choice: “global information” Duration min:2 months Max:1 year

49. Local information associated with treatment choice (in the symptomless gallbladder stones guideline)

50. Digression 2Why don’t we put “global info (about paths)” locally in the decision actions? Given “local info” in each node, collecting & storing might be automatic HOWEVER: - exponential space in each node - data duplication (consistency after updates?) - not user friendly (too many data!) - not all aternatives are “relevant” - data not always necessary >> global data only at execution time, on request