Methods for Computer-Aided Design and Execution of Clinical Protocols

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 • Formulation of models of clinical tasks and application areas • Representation of those models in machine-understandable form • Development of new algorithms that process domain models • Implementation of computer programs that use models to automate clinically important tasks

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

4. Some basic beliefs • Computer-based patient records eventually will become ubiquitous • Clinical protocols can—and should—be authored from the beginning as machine-interpretable documents • 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 • ONCOCIN (1979–1988) • Clinical trials in oncology • Therapy Helper (1989–1995) • Clinical trials for HIV infection • EON (1989–) • Reusable components for automation of protocols and guidelines in a variety of domains

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

7. EON: Components for automation of clinical protocols • Models of protocol concepts • Programs to plan patient therapy in accordance with protocol requirements • 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 Knowledge-base authors create protocol descriptions EON Protocol knowledge base Therapy- planning program Eligibility- determination program Clinicians receive expert advice

9. Model (ontology) of protocol concepts

10. Components of the protocol model (ontology) • Guideline ontology • Defines abstract structure of clinical protocols and guidelines • Is independent of any medical specialty • 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 • Provides a domain of discourse for talking about some application area • Defines concepts, attributes of concepts, and relationships among concepts • 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 Knowledge-base authors create protocol descriptions EON Protocol knowledge base Therapy- planning program Eligibility- determination program Clinicians receive expert advice

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

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

21. EON is “middleware” • 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 Therapy- planning component RÉSUMÉtemporal- abstraction system Chronus temporal database query system Eligibility- determination component Clinical information system Patient database Tzolkin database mediator Protocol knowledge base Domain model

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

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

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 • Are reusable, domain-independent software components that solve abstract tasks (e.g., planning, classification, constraint satisfaction) • 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 Method Method Output Ontology Input Ontology Domain Ontology (e.g., clinical protocols)

29. Problem-solving methods can automate a variety of tasks • 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) • Each application entails mapping a different domain ontology to the same, reusable problem-solving method

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

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

32. EON eligibility-determination component (Yenta) • Takes as input • Computer-based patient record data • Knowledge of eligibility criteria of applicable protocols • 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 • Stable (e.g., having received prior therapy) • Variable (e.g., routine lab data) • Controllable (e.g., use of a given drug) • Subjective (e.g., likelihood of compliance) • Special (e.g., lab data requiring invasive or expensive tests)

34. Qualitative eligibility scores For each eligibility criterion, for each point in time, the computer assigns a score: • P meets the criterion • PP probably meets the criterion • N no assumption can be made • FP probably fails the criterion • F fails the criterion

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 Knowledge-base authors create protocol descriptions EON Protocol knowledge base Therapy- planning program Eligibility- determination program Clinicians receive expert advice

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

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

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

41. The temporal-abstraction task

42. Knowledge required for temporal abstraction • Structural knowledge(e.g., definitional relationships among lab tests and clinical states) • Classification knowledge (e.g., how numeric values map into qualitative ranges) • Temporal-semantic knowledge(e.g., whether intervals are concatenable or downward heriditary) • 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 Knowledge-base authors enter knowledge required for temporal abstraction TZOLKIN Parameter knowledge base RÉSUMÉ temporal-abstraction system Abstractions of relevant clinical parameters

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

45. A protocol model shared among all components • Makes explicit relevant assumptions about the application domain—we know what our programs know • 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 • Hypertension guidelines at Palo Alto VA Health Care System • Fast Track Systems, Inc., plans to develop systems for automation of clinical trials

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

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