applying formal methods to clinical guidelines: the case of temporal information

Applying formal methods to clinical guidelines: the case of temporal information

Paolo TerenzianiDipartimento di Informatica, Univ. del Piemonte Orientale Amedeo Avogadro, Via Bellini 25\g, 15100 Alessandria, [email protected] Aberdeen, June 4th, 2008

My favourite research topic: Dealing with time-related phenomena Knowl. Repr. Constraints PeriodicityTDB Semantics Constraints DB Periodicity DB Medical Info.

Overview of the presentation experience in the GL context: the GLARE project (sketch)temporal information in clinical records temporal databases temporal information in the guidelines reasoning about temporal constraints conclusions

GLARE(GuideLine Acquisition Representation and Execution)-Joint project (started in 1997):Dept. Comp. Sci., Univ. Alessandria (It): P. Terenziani, S.Montani, A.BottrighiDept. Comp. Sci., Univ. Torino (It): L.Anselma,G.CorrendoAz. Osp. S. Giovanni Battista, Torino (It): G.Molino, M.TorchioKoin Sistemi S.p.A, Torino (It) (from 2005)-Domain independent (e.g., bladder cancer, reflux esophagitis, heart failure, ichemic stroke)

-Phisician-oriented & User-friendly

GLARE Representation FormalismIn GLARE, a clinical guideline is a hierarchical graphs of actions

GLARE: Architecture of the KERNEL

GLARE: Architecture of the system

Overview of the presentation experience in the GL context: the GLARE project (sketch) temporal information in clinical records temporal databases (TDBs) temporal information in the guidelines reasoning about temporal constraintsconclusions

Coping with temporal information in patients records: the need for Temporal Databases(1)Need for coping with temporal data (both VT and TT)(2)Just adding 1 (or 2, or 4) temporal attributes (and maybe some ad-hoc procedures) does not work!(3)First, a rigorous semantic framework is needed, to give formal specification to the implementation. Properties: clearness, expressiveness, upward compatibiliy. Ex. BCDM(4)Second, the implementation must be proven to respect the semantics. Core issue here: efficient (1-NF) implementations hardly grant uniqueness of representation. Ex TSQL2(5)Other issues (my work in the area)

(1) Need for coping with temporal data in patients clinical recordsThe time when patients symptoms hold, laboratory examinations and clinical actions are performed, etc. are core pieces of information valid time

The time when data are inserted\deleted into the DB is important (e.g., justification of actions, legal purposes) transaction time

Ex. Lab test X has been executed on Jan 1st , 2008, and results have been inserted in the patients clinical record on Jan 3rdNOTICE: major problems even with valid time alone!

Ad-hoc approaches are complex and are not likely to workExample 1. Projection (and temporal coalescing)Question: salary history of Andrea

Intuitive SQL query:SELECT Salary,VT_start,VT_endFROM EmployeeWHERE Name=Andrea

NameSalaryTitleVT_startVT_endAndrea60000Ass. Provost1/1/199330/5/1993Andrea70000Ass. Provost1/6/199330/9/1993Andrea70000Provost1/10/199331/1/1994Andrea70000Professor1/2/199431/12/1994

Ad-hoc approaches are complex and are not likely to workResult obtained:Desired result:

SalaryVT_startVT_end600001/1/199330/5/1993700001/6/199330/9/1993700001/10/199331/1/1994700001/2/199431/12/1994

SalaryVT_startVT_end600001/1/199330/5/1993700001/6/199331/12/1994

Ad-hoc approaches are complex and are not likely to workHow to get the desired result using SQL92:CREATE TABLE Temp(Salary, VT_start,VT_end)AS SELECT Salary, VT_start, VT_endFROM EmployeeWHERE Name = Andrea;

RepeatUPDATE Temp T1SET (T1.VT_end)=SELECT MAX(T2.VT_end)WHERE T1.Salary=T2.Salary AND T1.VT_start < T2.VT_Start AND T1.VT_end >= T2.VT_start AND T1.VT_end < T2.VT_endWHERE EXISTS (SELECT *FROM Temp AS T2WHERE T1.Salary=T2.Salary AND T1.VT_start < T2.VT_Start AND T1.VT_end >= T2.VT_start AND T1.VT_end < T2.VT_end)Until no tuples updated

Ad-hoc approaches are complex and are not likely to workHow to get the desired result using SQL92 (continues!):DELETE FROM Temp T1WHERE EXISTS(SELECT *FROM Temp AS T2WHERE T1.Salary = T2.Salary AND ((T1.VT_start > T2.VT_Start) AND (T1.VT_end = T2.VT_Start) AND (T1.VT_end < T2.VT_end))

Ad-hoc approaches are complex and are not likely to workUnderlying semantic phenomenon:Projection on temporal relations involves temporal coalescing about value equivalent tuplesWhen it occurs (SQL):Whenever a proper subset of the attributes of the relations is chosen in the SELECT part of the query

Ad-hoc approaches are complex and are not likely to workHow to get the desired result using a Temporal DB (ex. TSQL2)SELECT SalaryFROM EmployeeWHERE Name = Andrea

Ad-hoc approaches are complex and are not likely to workExample 2. Join (and temporal intersection)Employee1Employee2Query: combined history of both Andreas salary and title

NameSalaryVT_startVT_endAndrea600001/1/199330/5/1993Andrea700001/6/199331/12/1994

NameTitleVT_startVT_endAndreaAss. Provost1/1/199330/9/1993AndreaProvost1/10/199331/1/1994AndreaProfessor1/2/199431/12/1994

Ad-hoc approaches are complex and are not likely to workIntuitive SQL query:SELECT Salary, Title, Emp1.VT_start, Emp1.VT_end Emp2.VT_start, Emp2.VT_end FROM Employee1, Employee2WHERE Employee1.Name=Andrea AND Employee1.Name=Andrea

Ad-hoc approaches are complex and are not likely to workResult obtained:

SalaryEmp1.VT_startEmp1.VT_endTitleEmp2.VT_startEmp2.VT_end600001/1/199330/5/1993Ass. Provost1/1/199330/9/1993600001/1/199330/5/1993Provost1/10/199331/1/1994600001/1/199330/5/1993Professor1/2/199431/12/1994700001/6/199331/12/1994Ass. Provost1/1/199330/9/1993700001/6/199331/12/1994Provost1/10/199331/1/1994700001/6/199331/12/1994Professor1/2/199431/12/1994

Ad-hoc approaches are complex and are not likely to workResult desired:

SalaryTitleVT_startVT_end60000Ass. Provost1/1/199330/5/199370000Ass. Provost1/6/199330/9/199370000Provost1/10/199331/1/199470000Professor1/2/199431/12/1994

Ad-hoc approaches are complex and are not likely to workHow to get the desired result using SQL92:SELECT Employee1.Name,Salary,Dept,Employee1.VT_start,Employee1.VT_endFROM Employee1, Employee2WHERE Employee1.Name=Employee2.Name AND Employee2.VT_start = Employee2.VT_start AND Employee2.VT_end < Employee1.VT_end AND Employye1.VT_start < Employee2.VT_endUNIONSELECT Employee1.Name,Salary,Dept,Employee2.VT_start,Employee1.VT_endFROM Employee1, Employee2WHERE Employee1.Name=Employee2.Name AND Employee2.VT_start > Employee2.VT_start AND Employee1.VT_end < Employee2.VT_end AND Employye2.VT_start < Employee1.VT_endUNIONSELECT Employee1.Name,Salary,Dept,Employee2.VT_start,Employee2.VT_endFROM Employee1, Employee2WHERE Employee1.Name=Employee2.Name AND Employee2.VT_start > Employee1.VT_start AND Employee2.VT_end < Employee1.VT_end

Ad-hoc approaches are complex and are not likely to workUnderlying semantic phenomenon:Join (Cartesian product) on temporal relations involves temporal intersectionWhen it occurs (SQL):Whenever more than one relation is used in the FROM part of the queryNote: the number of terms in the SQL union is 2n, where n is the number of relations in the FROM part

Ad-hoc approaches are complex and are not likely to workHow to get the desired result using a Temporal DB (ex. TSQL2)

SELECT Salary, TitleFROM Employee1, Employee2WHERE Employee1.Name=Andrea AND Employee1.Name=Andrea

Ad-hoc approaches are complex and are not likely to workAnd what about: Union, difference, , nested queries Temporal predicates Primary\secondary keys Aggregate functions Integrity constraints Multiple (user-defined!) granularities arbitrary combinations of all the above issues

Until now, just two simple examples concerning: SELECT a subset of attributes ( loop to do colaescing) FROM with >1 relations (exponential union to do intersection)?

Ad-hoc approaches are complex and are not likely to workKey message: Dealing with temporal data is a general problem in DBs Difficult problems (often hidden ones) have to be facedFrom a Software Engeneering point of view:Letting applications solve the problem in an ad-hoc way is: Both cost and time expensive Likely to lead to errors in the applications Likely to make integration (shared data) between applications impossible

Ad-hoc approaches are complex and are not likely to workTemporal DB: an area of research aiming at providing once-and-forall principled and integrated solution to the problem

BCDM(Bitemporal Conceptual Data Model)Snodgrass & Jensen, 1995A unifying consensus model, capturing the semantics of most approaches in the TDB literature Based on the relational model, and tuple timestamping A purely semantic model (efficiency issues are not taken into account)

BCDM

Temporal Domains

Time is linear and totally ordered Chronons are the basic time unit Time domains are isomorphic to subsets of the domain of Natural numbers

DVT = {t1,t2, , tk}(valid time) DTT = {t1,t2, , th} {UC} (transaction time)DTT DVT (bitemporal chronons)

BCDM

Data

Attribute names: DA={A1, A2, , An}Attribute domains DD={D1, D2, , Dn}

Schema of a bitemporal relation:R = Ai1, Ai2, , Aij TDomain of a bitemporal relation:Di1 Di2 Dij DTT DVT

Tuple of a relation r(R):x = (a1, a2, , aj | tB)

BCDM

Example.Relation Employee with Schema: (name,salary,T)

Andrea was earning 60K at valid times 10, 11, 12Such a tuple has been inserted into Employee at time 12, and is current now (say now=13)

(Andrea, 60k | {(12,10), (12,11), (12,12),(13,10), (13,11), (13,12), })

VTTT1012121311

BCDM

Example.Relation Employee with Schema: (name,salary,T)

Andrea was earning 60K at valid times 10, 11, 12Such a tuple has been inserted into Employee at time 12, and is current now (say now=13)

(Andrea, 60k | {(12,10), (12,11), (12,12),(13,10), (13,11), (13,12), (UC,10), (UC,11), (UC,12)})

VTTT1012121311UC

BCDMBitemporal relation: set of bitemporal tuples. Constraint: Value equivalent tuples are not allowed.

(Bitemporal) DB: set of (bitemporal) relations

BCDMSemantics (another viewpoint)(12,10) {Employee(Andrea,60K)}(12,11) {Employee(Andrea, 60K)}(12,12) {Employee(Andrea, 60K), Employee(John,50K)}(12,13) {Employee(John,50K)}(13,10) {Employee(Andrea,60K)}(13,11) {Employee(Andrea, 60K)}..(UC,12) {Employee(Andrea, 60K)}

NameSalaryTAndrea60K{(12,10), (12,11), (12,12),(13,10), (13,11), (13,12), (UC,10), (UC,11), (UC,12)}John50K{(12,12),(12, 13)}

BCDMPROPERTIESConsistent extension (of classical SQL DB)A temporal DB is a set of classical DBs, one for each bitemporal chronon

Uniqueness of representation(from the constraint about value equivalent tuples)

BCDMSemantics of UCe.g., the DBs clock thicks time 14

NameSalaryTAndrea60K{(12,10), (12,11), (12,12),(13,10), (13,11),(13,12), (UC,10), (UC,11), (UC,12)}John50K{(12,12),(12, 13)}

NameSalaryTAndrea60K{(12,10), (12,11), (12,12),(13,10), (13,11), (13,12), (14,10), (14,11), (14,12), (UC,10), (UC,11), (UC,12)}John50K{(12,12),(12, 13)}

BCDMdeletion (e.g., at time 15)delete(Employee, (Andrea,60K))



BCDMinsertion (e.g., at time 16)insert(Employee, (Andrea,60K|{12,13}))insert(Employee, (Mary,70K|{16}))


NameSalaryTAndrea60K{(12,10), (12,11), (12,12),(13,10), (13,11), (13,12), (14,10), (14,11), (14,12), (16,12),(16,13),(UC,12),(UC,13) }John50K{(12,12),(12, 13)}Mary70K{(16,16),(UC,16)}

BCDMD(r)={z | xr (z[D]=x[D]) yr (y[D]=z[D] y[T] z[T]) tz[T] yr (y[D]=z[D] ty[T])}

Algebraic Operators(Ex. Projection) No value-equivalent tuple generated(uniqueness of representation!) Coalescing!

BCDMBCDM algebraic operators are a consistent extension of SQLs ones(reducibility and equivalence)

Algebraic OperatorsProperties

BCDMReducibilityrT=

BCDMEquivalencertt(r)opTopop(r)tt(op(r))=opT (t(r))

BCDMPROBLEMSemantically clear but .. inefficient (not suitable for a direct implementation)

Not 1-NF

(2) UC (at each thick of the clock, all current tuples should be updated!)

An example of implementation: TSQL2(Snodgrass et al., 1995)Temporal attribute T four temporal attributes (TTS, TTE, VTS, VTE)

Attribute value: a timestamp or UC

Bitemporal tuple: A1,.An| TTS, TTE, VTS, VTE

Bitemporal relation: set of bitemporal tuplesNotice: to retain the expressiveness of BCDM, value-equivalent tuples need to be allowed!

An example of implementation: TSQL2(Snodgrass et al., 1995)SEMANTICSBCDMTSQL2

NameSalaryTAndrea60K{(12,10), (12,11), (12,12),(13,10), (13,11), (13,12), (UC,10), (UC,11), (UC,12)}John50K{(12,12),(12, 13)}

NameSalaryTTS TTE VTSVTEAndrea60K12UC1012John50K12121213

An example of implementation: TSQL2(Snodgrass et al., 1995)Efficient implementation (data model):- 1-NF UC managed efficiently clear semantics (mapping onto BCDM)

BUTto get efficiency, we loose the uniqueness of representation property

Problem: no uniqueness of representationBCDMExample. At time 10, the fact that Andrea earned 60K from 2 to 3 inserted in Employee. At time 12, such a tuple is updated: Andrea earned 60K from 1 to 4. At time 13, the tuple is (logically) deleted.

NameSalaryTAndrea60K{(10,2), (10,3), (11, 2),(11,3), (12,1), (12,2),(12,3),(12,4),(13,1),(13,2),(13,3),(13,4)}

NameSalaryTTSTTEVTSVTEAndrea60K101123Andrea60K12UC14

NameSalaryTTS TTE VTSVTEAndrea60K12UC11Andrea60K10UC23Andrea60K12UC44

Problem: no uniqueness of representationVTTT121213341011TSQL2 implementation: covering rectangles

Problem: no uniqueness of representationVTTT121213341011TSQL2 Representation (a)


Problem: no uniqueness of representationVTTT121213341011TSQL2 Representation (b)


Problem: no uniqueness of representationVTTT121213341011Other TSQL2 Representations!!

Problem: no uniqueness of representationPotentially, an enormous problem!

e.g., Return all employees earning more than 50K for at most 3 consecutive time chronons?



NameTTSTTEVTSVTEAndrea12UC14

Problem: no uniqueness of representationOne must grant that the temporal DB implementation respects its underlying semantics, independently of the representationDB1DB2op1, , opkDB1Given two semantically equivalent temporal DBs, and given any sequence of operations, the results are always semantic equivalent

Problem: no uniqueness of representationSolution. Step 1. Formal definition of semantic equivalence

Snapshot equivalence:Informally: two relations (Databases) are snapshot equivalent if they are identical at each bitemporal chronon

Problem: no uniqueness of representationSolution. Step 2. Definition of manipulation and algebraic operators that preserve snapshot equivalence

e.g., proofs given about TSQL2 (bitemporal) operatorsrB1rB2opBiopBiopBi(rB1)opBi(rB2)snapshotequivalentsnapshotequivalent

An example of implementation: TSQL2(Snodgrass et al., 1995)Last, but not least,

An high-level query and manipulation language (minimal extension to SQL to cope with time) is provided

An example of implementation: TSQL2(Snodgrass et al., 1995)Other properties proved for TSQL2

(Upward Compatibility)TSQL2 is a consistent extension of SQL

Personal considerationIn my opinion, ad-hoc approaches are not likely to Recognize Solve Prove the soundness of the solutionsthe above problems!

My past and current contribution to the area Treatment of temporal constraints in TDB(with V. Brusoni, L. Console, B. Pernici: IEEE Trans. Data and Knowledge Eng., 1998) Treatment of periodic data in TDB(IEEE Trans. Data and Knowledge Eng., 2003, and futher ongoing work with B.Stantic, G. Governatori, A. Sattar) Treatment of telic vs atelic data in TDB(with R.T. Snodgrass, IEEE Trans. Data and Knowledge Eng., 2004) Extension to BCDM to cope with proposal\evaluation of updates (with L. Anselma, A. Bottrighi, S. Montani, ongoing work) Extension to BCDM to cope with temporal indeterminacy(with R.T. Snodgrass, ongoing work)

Treatment of telic vs atelic data in TDB (joint work with R.T. Snodgrass)Distinction dates back to Aristotles Categories, used in Linguistics, Cognitive Science, and, recently, Artificial Intelligence

Core issue:Atelic facts (i.e., facts without a goal or culmination)e.g., (f1) Andrea earned 60K from 10 to 11(f2) Andrea earned 60K from 12 to 12can be represented\evaluated at each bitemporal chronon10 {earn(Andrea,60K)}11 {earn(Andrea,60K)}12 {earn(Andrea,60K)}

BCDM snapshot semantics is OK for atelic facts

Treatment of telic vs atelic data in TDBCore issue:Telic facts (i.e., facts with a goal or culmination)e.g., (f1) Andrea build a house from 10 to 11(f2) Andrea build a house from 12 to 12cannot be represented\evaluated at each bitemporal chronon10 {build_house(Andrea)}11 {build_house(Andrea)}12 {build_house(Andrea)}

BCDM snapshot semantics does not work for telic facts

Treatment of telic vs atelic data in TDB

Analysis of the impact of neglecting the telic\atelic distinction in TDBsSolution: (2.1)a two-sorted semantics-chronon-by-chronon for atelic facts-interval-based for telic facts(2.2)three sorted data model(2.3)three-sorted manipulation and algebraic operators(2.4)properties(2.5)high-level query language

Treatment of proposal\evaluation of updates(extension to BCDM) (joint work with L. Anselma, A. Bottrighi, S. Montani)Needed to cope with updates concerning GLs!

Important in several other applications, e.g., Wiki-based vocabularies (Citizendium)

Notice: TT needed to store the history of updates!

Main issues:Distinguishing between two level of users (proposers and evaluators)Delaying the effect of proposalsCoping with alternative tuples

Overview of the presentation experience in the GL context: the GLARE project (sketch) temporal information in clinical records temporal databases (TDB) temporal information in the guidelines reasoning about temporal constraintsconclusions

Temporal Constraints in Clinical GuidelinesTemporal constraints are an intrinsic part of clinical knowledge (e.g., ordering of the therapeutic actions)Different kinds of temporal constraints, e.g., -duration of actions (min / max) -qualitative constraints (e.g., before, during)-delays (min / max)-periodicity constraints on repeated actions

Temporal Constraints in Clinical GuidelinesrepetitionsThe therapy for multiple mieloma is made by six cycles of 5-day treatment, each one followed by a delay of 23 days (for a total time of 24 weeks). Within each cycle of 5 days, 2 inner cycles can be distinguished: the melphalan treatment, to be provided twice a day, for each of the 5 days, and the prednisone treatment, to be provided once a day, for each of the 5 days. These two treatments must be performed in parallel.

Managing Temporal Constraint: the ProblemTemporal Constraints without Temporal Reasoning (constraint propagation)-are useless-clash against users intuitions/expectations

Both representation and inference are NEEDED

Managing Temporal Constraints: the ProblemImplied constraint (temporal reasoning):(1.6) C ends between 30 and 60 m after the start of A

Correct (consistent) assertion:(1.7) C ends between 30 and 50 m after the start of A

Not correct (inconsistent) assertion:(1.8) C ends more than 70 m. after the start of A

However: Temporal Reasoning is NEEDED in order to support such an intended semantics!

(1.1) the end of A is equal to the start of B

(1.2) the end of B is equal to the start of C

(1.3) the duration of A is between 10 and 20 m

(1.4) the duration of B is between 10 and 20 m

(1.5) the duration of C is between 10 and 20 m

Managing Temporal Constraints: the ProblemDESIDERATA for Temporal Reasoning Algorithms- tractability reasonable response time - correctness no wrong inferences- completeness reliable answersDESIDERATA for the Representation formalism- expressiveness capture most temporal constraints in GLTRADE-OFF!SPECIALIZED APPROACHES (since 80 in AI literature)

Digression: Why Completeness is fundamental?Implied constraint (temporal reasoning):(1.6) C ends between 30 and 60 m after the start of A

Suppose that temporal reasoning is NOT complete, so that (1.6) is not inferred. One can add inconsistent info, e.g., C ends more than 70 m. after the start of Aand the system accept it! inconsistent GL!

Complete Temporal Reasoning is NEEDED in order to grant that GL is temporally consistent (executable!)

(1.1) the end of A is equal to the start of B

(1.2) the end of B is equal to the start of C

(1.3) the duration of A is between 10 and 20 m

(1.4) the duration of B is between 10 and 20 m

(1.5) the duration of C is between 10 and 20 m

Temporal Constraint TreatmentWHEN Temporal Reasoning is useful in Guidelines?ACQUISITION to check consistency (notice: an inconsistent GL cannot be executed!!!)EXECUTION-to compare the duration of paths, in hypothetical reasoning (simulation) facilities-to check that the time of execution of actions on patients is consistent with the constraints in the guideline -to schedule next actions

Temporal Representation and Temporal Reasoning for Clinical GuidelinesDifferent kinds of temporal constraintsNo current approach in the AI literature covers all of themOur proposal: an extension of the consensus STP approach [Dechter et al., 91]Our goal: expressiveness + correct, complete and tractable inferences

GLAREs approach (representation)Labeled tree of STPs (STPs-tree)Tree of STPs for the multiple mieloma chemotherapy guideline.The overall therapy (node N1) is composed by 6 cycles of 5 days plus a delay of 23 days . In each cycle (node N2), two therapies are executed in parallel: Alkeran (node N3: Sa and Ea are the starting and ending nodes), to be repeated twice a day, and Deltacorten (node N4: Sd and Ed are the starting and ending nodes), to be repeated once a day. Arcs between any two nodes X and Y in a STP (say N2) of the STP-tree are labeled by a pair [n,m] representing the minimal and maximal distance between X and Y.

Other formal approaches to temporal reasoning in clinical guidelinesMiksh et al.-an extension of STPs metric contraints-attention to constraint visualization

Shahar et al.-temporal reasoning oriented towards temporal abstraction (e.g., persistence phenomena)

ConclusionsFormal methods are necessary in order to properly cope with temporal phenomena related to GL management

Temporal information in patients records TDBs needed- ad-hoc solutions are complex, expensive, not likely to work-a clear semantics is needed an efficient (1-NF) implementation respecting the semantics is needed. (semantic equivalence must be preserved, otherwise, results cannot be trusted!)- any implementation should be a consistent extension of SQL (otherwise, previous work is lost!)

Temporal constraints in GLs Temporal reasoning needed-(temporally) inconsistent GL cannot be executed!-to detect which are the next candidate actions, and when they need to be executed

ConclusionsMore generally, I strongly believe that formal methods are recommended\necessary in order to properly cope with many other different phenomena related to GL management, including

- Decision support (e.g., Decision Theory) Verification (e.g., model-checking, theorem proving, Petri Nets) Simulation (e.g., Petri Nets) Formal semantics (Temporal logics, Operational semantics, Mapping techniques) !!!Thanks for your attention!

**************************************************************************

applying formal methods to clinical guidelines: the case of temporal information

Documents