Temporal Data Management for Protocol

Download Report

Transcript Temporal Data Management for Protocol

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



DB
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
TM
Clinical
decision-support
application
TR
Examples of TemporalMaintenance Systems
TSQL2, a bitemporal-database query
language (Snodgrass et al., Arizona)
 TNET and the TQuery language (Kahn,
Stanford/UCSF)
 The Chronus/Chronus2 projects (Stanford)

Examples of
Temporal-Reasoning Systems

RÉSUMÉ
M-HTP
 TOPAZ
 TrenDx

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
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
Protocol-Based Decision Support System


Presents patient-specific recommendations
Needs a method for verifying the presence of
time-oriented patient conditions in a database
Information Mismatch
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
Temporal Patterns
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
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 timeoriented goals, or visualization temporal patterns
in the patient data
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
Two Implementation Strategies
Application
Application
Temporal Data Management
Temporal Data Management
Database
1) Extend DBMS
Database
2) Extend Application
Problems Extending DBMS
Application
Temporal data
management methods
implemented in
DBMS:
 are
Temporal Data Management
Database
limited to
producing very simple
abstractions
 are often databasespecific
Problems Extending Applications
Temporal data
management methods
implemented in
applications:
some
functions of the DBMS
 are application-specific
Application
Temporal Data Management
 duplicate
Database
Our Strategy


Separates data
management methods
from the application
and the database
Decomposes temporal
data management into
two general tasks:
abstraction
 temporal maintenance
Application
Temporal Abstraction
Temporal Querying
 temporal
Database
The Tzolkin Temporal Mediator
Architecture
Application
Query
Results
Tzolkin
Knowledge
Base
Temporal
Abstraction
Module
TemporalQuerying
Module
Abstraction
Knowledge
Database
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
Temporal Abstraction of Hb
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
Chronus TimeLine SQL (TL-SQL)
GRAIN
SELECT
FROM
WHERE
WHEN
WEEK
2ND problem_name
problems_table
problem_name = ‘Hb’
START_TIME BEFORE 1/1/99
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
SQLA Interface Language



Based on SQL
Supports temporal queries
Detects when abstractions are requested and computes
them on the fly
GRAIN
CONTEXT
SELECT
FROM
WHERE
WHEN
WEEK
CCTG-522
2ND problem_name
problems_table
problem_name = ‘HbState’
and value = ‘moderate anemia’
DURATION (start, stop) > 2
Query-Evaluation Algorithm
A Detailed Example
GRAIN
CONTEXT
SELECT
FROM
WHERE
WHEN
WEEK
CCTG-522
2ND problem_name
problems_table
problem_name = ‘HbState’
and value = ‘moderate anemia’
DURATION (start, stop) > 2
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
Detecting the Need for Abstractions

Find non-SQLA terms in
WHERE clause
Blood State
(“HbState” and
“moderate anemia”)


Look up terms in
RESUME KB
If look-up succeeds,
Tzolkin needs to compute
abstractions
(“HbState”)
HbState
Hb
WBCState
WBC
PltState
Plt
Loading the Data Primitives

Locate the requested
abstraction in the
RESUME KB
Blood State
(“HbState”)

Find the primitive
parameters (leaves of the
tree) below it
(“Hb”)

Load all patient data of
these parameter types into
RESUME
HbState
Hb
WBCState
WBC
PltState
Plt
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
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
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