Temporal Mediators: Integration of Temporal Reasoning and Temporal-Data Maintenance

1. Temporal Reasoning and Planning in Medicine Temporal Mediators:Integration of Temporal Reasoning and Temporal-Data Maintenance Yuval Shahar MD, PhD

2. Temporal Reasoning and Temporal Maintenance • Temporal reasoning supports inference tasks involving time-oriented data; often connected with artificial-intelligence methods • Temporal data maintenance deals with storage and retrieval of data that has multiple temporal dimensions; often connected with database systems • Both require temporal data modelling

3. Examples of Temporal-Maintenance Systems • TSQL2, a bitemporal-database query language (Snodgrass et al., Arizona) • TNET and the TQuery language (Kahn, Stanford/UCSF) • The Chronus/Chronus2 projects (Stanford)

4. Examples of Temporal-Reasoning Systems • RÉSUMÉ • M-HTP • TOPAZ • TrenDx

5. A Typical TM and TR Application:Automated Support to Therapy by Clinical Guidelines/Protocols • Clinical guidelines/protocols contain recommendations for medical interventions that are predicated on the observation of: • relevant temporal patterns of these states • relevant patient states

6. CCTG-522 Recommendation Modify the standard dose of AZT for a patient if, during treatment with the protocol, the patient experiences a second episode of moderate anemia that has persisted for more than two weeks

7. Protocol-Based Decision Support System • Presents patient-specific recommendations • Needs a method for verifying the presence of time-oriented patient conditions in a database

8. Information Mismatch

9. Temporal Abstraction • Defined as the creation of high-level summaries of time-oriented data • Necessary because • clinical databases usually store raw, time-stamped data • protocols often require information in high-level terms

10. Temporal Patterns

11. Temporal Maintenance • Defined as the storage of time-oriented data and the selective retrieval of that data based on some time-oriented constraint • Necessary because clinical conditions may be defined as temporal patterns • temporal order • temporal duration • temporal context

12. Temporal Data Manager • Performs • temporal abstraction of time-oriented data • temporal maintenance • Used for tasks such as finding in a patient database which patients fulfil eligibility conditions (expressed as temporal patterns), assessing the quality of care by comparison to predefined time-oriented goals, or visualization temporal patterns in the patient data

13. Embedding A Temporal Data Manager Within a Guideline-Support System • Can be embedded within a larger decision support framework, e.g., EON • Mediates all access to the external clinical database

14. Two Implementation Strategies 1) Extend DBMS 2) Extend Application

15. Problems Extending DBMS Temporal data management methods implemented in DBMS: • are limited to producing very simple abstractions • are often database-specific

16. Problems Extending Applications Temporal data management methods implemented in applications: • duplicate some functions of the DBMS • are application-specific

17. Our Strategy • Separates data management methods from the application and the database • Decomposes temporal data management into two general tasks: • temporal abstraction • temporal maintenance

18. The Tzolkin Temporal Mediator Architecture

19. RÉSUMÉ: Temporal Abstraction • Creates summaries of time-oriented data • Clinical data is usually stored as “low-level” data • Protocols often specify conditions as “high-level”, interval-based concepts • Is domain-independent • Has a tool that facilitates knowledge acquisition and maintenance

20. Temporal Abstraction of Hb

21. Chronus: Temporal Maintenance • Provides temporal extensions to SQL • Historical relational model • Each tuple has two time stamps • Time stamps conferred special status • Temporal algebra that supports temporal manipulations • Closed algebra • Complete for the temporal conditions found in protocols

22. Chronus TimeLine SQL (TL-SQL) GRAIN WEEK SELECT2ND problem_name FROM problems_table WHERE problem_name = ‘Hb’ WHENSTART_TIME BEFORE 1/1/99

23. Coupling RÉSUMÉ and Chronus • Integrates temporal abstraction and temporal query processing • Allows retrieval of summaries of clinical data using time-oriented conditions Modify the standard dose of AZT for a patient if, during treatment with the protocol, the patient experiences a second episode of moderate anemia that has persisted for more than two weeks

24. SQLA Interface Language • Based on SQL • Supports temporal queries • Detects when abstractions are requested and computes them on the fly GRAIN WEEK CONTEXT CCTG-522 SELECT2ND problem_name FROM problems_table WHERE problem_name = ‘HbState’ and value = ‘moderate anemia’ WHENDURATION (start, stop) > 2

25. Query-Evaluation Algorithm

26. A Detailed Example GRAIN WEEK CONTEXT CCTG-522 SELECT2ND problem_name FROM problems_table WHERE problem_name = ‘HbState’ and value = ‘moderate anemia’ WHENDURATION (start, stop) > 2

27. Loading the Domain Knowledge • Examine the context clause of the SQLA statement, which contains a reference to a knowledge base • Use the reference to locate and load the appropriate knowledge base

28. Blood State HbState WBCState PltState Hb WBC Plt Detecting the Need for Abstractions • Find non-SQLA terms in WHERE clause (“HbState” and “moderate anemia”) • Look up terms in RESUME KB • If look-up succeeds, Tzolkin needs to compute abstractions (“HbState”)

29. Blood State HbState WBCState PltState Hb WBC Plt Loading the Data Primitives • Locate the requested abstraction in the RESUME KB (“HbState”) • Find the primitive parameters (leaves of the tree) below it (“Hb”) • Load all patient data of these parameter types into RESUME

30. Generating the Interpretation Contexts within RÉSUMÉ • Find the types of events and abstractions that can induce a context (via a dynamic induction relation of contexts) (context CCTG522 can be induced by event: “enroll-CCTG 522”) • Locate patient-specific instances of these events (patient enrolled in CCTG 522 on 10/10/1999) • Compute all abstractions that can induce a context (recursive process) • RESUME will then generate the appropriate contexts

31. Invoking RÉSUMÉ and Chronus • Execute RESUME to compute the requested abstractions • The computed abstractions are stored in the database • RESUME signals Tzolkin when it is done • Then execute Chronus to retrieve the results

32. Future Research Directions • Enhancement of the query language • Addition of truth-maintenance capabilities to the database • Addition of “what-if” query support • Provision of complete dynamic (goal-directed) query computation