1. Methods for Computer-Aided Design and Execution of Clinical Protocols Mark A. Musen, M.D., Ph.D. Stanford Medical Informatics Stanford University

2. Research problems in medical informatics involve n Formulation of models of clinical tasks and application areas n Representation of those models in machine-understandable form n Development of new algorithms that process domain models n Implementation of computer programs that use models to automate clinically important tasks

3. Protocol-based care is everywhere n Algorithms for mid-level practitioners n Clinical-trial protocols n Clinical alerts and reminders n Clinical practice guidelines

4. Some basic beliefs n Computer-based patient records eventually will become ubiquitous n Clinical protocols can—and should—be authored from the beginning as machine-interpretable documents n Electronic protocol knowledge bases will allow computer-based patient records to enhance all components of patient care and clinical research

5. Work in protocol-based care n ONCOCIN (1979–1988) ä Clinical trials in oncology n Therapy Helper (1989–1995) ä Clinical trials for HIV infection n EON (1989–) ä Reusable components for automation of protocols and guidelines in a variety of domains

6. Our research addresses n Development of computational models of ä Planning medical therapy ä Determining when therapy is applicable ä Reasoning about time-ordered data n New approaches for acquisition, representation, and use of medical knowledge within computers

7. EON: Components for automation of clinical protocols n Models of protocol concepts n Programs to plan patient therapy in accordance with protocol requirements n Programs to match patients to potentially applicable protocols and guidelines

8. Use of an explicit model to guide knowledge entry Model of protocol concepts Custom- tailored protocol-entry tool Protocol knowledge base Therapy- planning program Eligibility- determination program Knowledge-base authors create protocol descriptions Clinicians receive expert advice EON

9. Model (ontology) of protocol concepts

10. Components of the protocol model (ontology) n Guideline ontology ä Defines abstract structure of clinical protocols and guidelines ä Is independent of any medical specialty n Medical-specialty ontology ä Defines clinical interventions, patient findings, and patient problems relevant in a given specialty ä Provides primitive concepts used to construct specialty-specific protocols

11. An ontology n Provides a domain of discourse for talking about some application area n Defines concepts, attributes of concepts, and relationships among concepts n Defines constraints on values of attributes of concepts

12. Model (ontology) of protocol concepts

13. Custom-tailored protocol-entry tool

14. Details of CAF chemotherapy

15. Details of CTX prescription

16. Custom-tailored protocol-entry tool: Top level

17. Specifying eligibility criteria

18. Use of an explicit model to guide knowledge entry Model of protocol concepts Custom- tailored protocol-entry tool Protocol knowledge base Therapy- planning program Eligibility- determination program Knowledge-base authors create protocol descriptions Clinicians receive expert advice EON

19. Automation of protocol-based care requires n Ability to deal with complexity of patient data (e.g., time dependencies, abstractions, missing data) n Ability to deal with complexity of protocol actions (e.g., actions which are themselves protocols) n A scalable and maintainable computational architecture

20. The EON Architecture comprises n Problem-solving components that have task-specific functions (e.g., planning, classification) n A central database system for queries of both ä Primitive patient data ä Temporal abstractions of patient data n A shared knowledge base of protocols and general medical concepts

21. EON is “middleware” n Software components designed for ä incorporation within other software systems (e.g., hospital information systems) ä reuse in different applications of protocol- based care

22. Components of the EON architecture Tzolkin database mediator RÉSUMÉ temporal- abstraction system Chronus temporal database query system Patient database Therapy- planning component Eligibility- determination component Protocol knowledge base Domain model Clinical information system

23. Therapy-planning component n Takes as input ä Data from computer-based patient record ä Knowledge of clinical protocol n Generates as output ä Therapeutic interventions to make ä Laboratory tests to order ä Time for next patient visit

24. Episodic skeletal-plan refinement ProtocolDrug 2Drug 1 Regimen B Regimen A Protocol Drug 2Drug 1 Regimen B 1. Flesh out standard plan from skeletal plan elements 3. Revise plan based on problems identified 2. Query database for presence of relevant patient problems ?

25. Domain knowledge derives from knowledge base

26. Problem-solving knowledge automates specific tasks Domain knowledge + Problem-solving method Intelligent behavior

27. Problem-solving methods n Are reusable, domain-independent software components that solve abstract tasks (e.g., planning, classification, constraint satisfaction) n Represent data on which they operate as a method ontology (model), which must be mapped to the domain ontology that characterizes the application area

28. Mapping domain ontologies to problem-solving methods Problem-Solving Method Domain Ontology (e.g., clinical protocols) Method Input Ontology Method Output Ontology

29. Problem-solving methods can automate a variety of tasks n Some skeletal planning tasks ä Therapy planning for protocol-based care (EON) ä Administration of digoxin in the presence of possible toxicity (Dig Advisor) ä Designing experiments in molecular genetics (MOLGEN) n Each application entails mapping a different domain ontology to the same, reusable problem-solving method

30. Components of the EON architecture Tzolkin database mediator RÉSUMÉ temporal- abstraction system Chronus temporal database query system Patient database Therapy- planning component Eligibility- determination component Protocol knowledge base Domain ontology Clinical information system

31. Our goals for eligibility determination n Automated clinical-trial screening from institutional and regional databases n Identification of specific actions that providers can take to enhance patient eligibility for guidelines and protocols n Minimization of inappropriate enrollment of patients who are not eligible

32. EON eligibility-determination component (Yenta) n Takes as input ä Computer-based patient record data ä Knowledge of eligibility criteria of applicable protocols n Generates as output ä List of patients potentially eligible for given protocols ä List of protocols for which given patients potentially are eligible

33. Classification of eligibility criteria for clinical trials n Stable (e.g., having received prior therapy) n Variable (e.g., routine lab data) n Controllable (e.g., use of a given drug) n Subjective (e.g., likelihood of compliance) n Special (e.g., lab data requiring invasive or expensive tests)

34. Qualitative eligibility scores n Pmeets the criterion n PPprobably meets the criterion n Nno assumption can be made n FPprobably fails the criterion n Ffails the criterion For each eligibility criterion, for each point in time, the computer assigns a score:

36. Eligibility criteria derive from the electronic knowledge base

37. Use of an explicit model to guide knowledge entry Model of protocol concepts Custom- tailored protocol-entry tool Protocol knowledge base Therapy- planning program Eligibility- determination program Knowledge-base authors create protocol descriptions Clinicians receive expert advice EON

38. Components of the EON architecture Tzolkin database mediator RÉSUMÉ temporal- abstraction system Chronus temporal database query system Patient database Therapy- planning component Eligibility- determination component Protocol knowledge base Domain model Clinical information system

39. Tzolkin database mediator n Serves as a common conduit for all problem solvers that must access patient data n Embodies components that address significant problems in temporal reasoning ä RÉSUMÉ—Temporal abstraction ä Chronus—Data query and manipulation

40. RÉSUMÉ temporal-abstraction method n Takes as input primary patient data and previously determined abstractions of those data n Generates as output further abstractions of the input n Requires a separate knowledge base of clinical parameters and their properties

41. The temporal-abstraction task

42. Knowledge required for temporal abstraction n Structural knowledge (e.g., definitional relationships among lab tests and clinical states) n Classification knowledge (e.g., how numeric values map into qualitative ranges) n Temporal-semantic knowledge (e.g., whether intervals are concatenable or downward heriditary) n Temporal-dynamic knowledge (e.g., minimal values for a significant change, functions to predict persistence of a value over time)

43. Acquiring temporal-abstraction knowledge for RÉSUMÉ Model of clinical parameters Tool for entry of temporal- abstraction knowledge Parameter knowledge base RÉSUMÉ temporal- abstraction system Knowledge-base authors enter knowledge required for temporal abstraction Abstractions of relevant clinical parameters TZOLKIN

44. The EON Architecture n Problem-solving components that have task-specific functions n A central database system for queries of both ä Primitive patient data ä Temporal abstractions of patient data n A shared knowledge base of protocols and general medical concepts

45. A protocol model shared among all components n Makes explicit relevant assumptions about the application domain— we know what our programs know n Consolidates the task of maintaining the domain knowledge— all the knowledge is in one place and can be examined in a coherent fashion

46. Planned applications of EON n Hypertension guidelines at Palo Alto VA Health Care System n Fast Track Systems, Inc., plans to develop systems for automation of clinical trials

47. EON’s component-based approach allows n Developers to create new problem- solving modules that “plug and play” n Clinicians to create new guideline knowledge bases that can interoperate immediately with existing components n System architects to integrate components with other software modules using standard communication methods

48. Some implications of our work n Enhanced authoring, maintenance, and execution of clinical protocols and guidelines n Incorporation of guideline-based practice into routine patient care n Increased participation of community- based practitioners in clinical research