1 / 32

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

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

viola
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related