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

1. ­ Dipartimento di Informatica Applying formal methods to clinical guidelines: the case of temporal information Via Bellini 25/G, 15100 Alessandria, Italy Tel. (+39) 0131 360312, Fax. (+39) 0131 360198, http://www.di.unipmn.it ­ ­ ­ Paolo Terenziani Dipartimento di Informatica, Univ. del Piemonte Orientale “Amedeo Avogadro”, Via Bellini 25\g, 15100 Alessandria, Italy paolo.terenziani@mfn.unipmn.it Aberdeen, June 4th, 2008

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

3. 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

4. GLARE(GuideLine Acquisition Representation and Execution) - Joint project (started in 1997): Dept. Comp. Sci., Univ. Alessandria (It): P. Terenziani, S.Montani, A.Bottrighi Dept. Comp. Sci., Univ. Torino (It): L.Anselma,G.Correndo Az. Osp. S. Giovanni Battista, Torino (It): G.Molino, M.Torchio Koinè Sistemi S.p.A, Torino (It) (from 2005) - Domain independent (e.g., bladder cancer, reflux esophagitis, heart failure, ichemic stroke) - Phisician-oriented & User-friendly

5. GLARE Representation Formalism In GLARE, a clinical guideline is a hierarchical graphs of actions

6. Clinical DB Expert Physician User Physician Pharmac. DB Acquisition Interface Execution Interface Resource DB Knowledge Manager Execution Module ICD DB Guidelines DB Guidelines Instantiation DB Patient DB GLARE: Architecture of the KERNEL

7. Temporal Reasoning Module Contextualization Module GLARE KERNEL SPIN Update Module Decision-Making Module Model-Checking Module GLARE: Architecture of the system

8. 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 constraints • conclusions

9. 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)

10. (1) Need for coping with temporal data in patients’ clinical records The 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 patient’s clinical record on Jan 3rd NOTICE: major problems even with valid time alone!

11. 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)

12. Ad-hoc approaches are complex and are not likely to work Example 1. Projection (and temporal coalescing) Question: salary history of Andrea “Intuitive” SQL query: SELECT Salary,VT_start,VT_end FROM Employee WHERE Name=“Andrea”

13. Ad-hoc approaches are complex and are not likely to work Result obtained: Desired result:

14. Ad-hoc approaches are complex and are not likely to work How to get the desired result using SQL92: CREATE TABLE Temp(Salary, VT_start,VT_end) AS SELECT Salary, VT_start, VT_end FROM Employee WHERE Name = “Andrea”; Repeat UPDATE Temp T1 SET (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_end WHERE EXISTS (SELECT * FROM Temp AS T2 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_end) Until no tuples updated

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

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

17. Ad-hoc approaches are complex and are not likely to work How to get the desired result using a Temporal DB (ex. TSQL2) SELECT Salary FROM Employee WHERE Name = “Andrea”

18. Ad-hoc approaches are complex and are not likely to work Example 2. Join (and temporal intersection) Employee1 Employee2 Query: “combined” history of both Andrea’s salary and title

19. Ad-hoc approaches are complex and are not likely to work “Intuitive” SQL query: SELECT Salary, Title, Emp1.VT_start, Emp1.VT_end Emp2.VT_start, Emp2.VT_end FROM Employee1, Employee2 WHERE Employee1.Name=“Andrea” AND Employee1.Name=“Andrea”

20. Ad-hoc approaches are complex and are not likely to work Result obtained:

21. Ad-hoc approaches are complex and are not likely to work Result desired:

22. Ad-hoc approaches are complex and are not likely to work How to get the desired result using SQL92: SELECT Employee1.Name,Salary,Dept,Employee1.VT_start,Employee1.VT_end FROM Employee1, Employee2 WHERE Employee1.Name=Employee2.Name AND Employee2.VT_start <= Employee1.VT_start AND Employee1.VT_end < Employee2.VT_end UNION SELECT Employee1.Name,Salary,Dept,Employee1.VT_start,Employee2.VT_end FROM Employee1, Employee2 WHERE Employee1.Name=Employee2.Name AND Employee1.VT_start >= Employee2.VT_start AND Employee2.VT_end < Employee1.VT_end AND Employye1.VT_start < Employee2.VT_end UNION SELECT Employee1.Name,Salary,Dept,Employee2.VT_start,Employee1.VT_end FROM Employee1, Employee2 WHERE Employee1.Name=Employee2.Name AND Employee2.VT_start > Employee2.VT_start AND Employee1.VT_end < Employee2.VT_end AND Employye2.VT_start < Employee1.VT_end UNION SELECT Employee1.Name,Salary,Dept,Employee2.VT_start,Employee2.VT_end FROM Employee1, Employee2 WHERE Employee1.Name=Employee2.Name AND Employee2.VT_start > Employee1.VT_start AND Employee2.VT_end < Employee1.VT_end

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

24. Ad-hoc approaches are complex and are not likely to work How to get the desired result using a Temporal DB (ex. TSQL2) SELECT Salary, Title FROM Employee1, Employee2 WHERE Employee1.Name=“Andrea” AND Employee1.Name=“Andrea”

25. Ad-hoc approaches are complex and are not likely to work • 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) • And 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 ?

26. Ad-hoc approaches are complex and are not likely to work • Key message: • Dealing with temporal data is a general problem in DB’s • Difficult problems (often “hidden” ones) have to be faced • From 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

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

28. 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)

29. BCDM(Bitemporal Conceptual Data Model)Snodgrass & Jensen, 1995 A 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)

30. 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 = {t’1,t’2, …, t’h}  {UC} (transaction time) DTT  DVT (bitemporal chronons)

31. BCDM • Data • Attribute names: DA={A1, A2, …, An} • Attribute domains DD={D1, D2, …, Dn} • Schema of a bitemporal relation: • R = Ai1, Ai2, …, Aij T • Domain of a bitemporal relation: • Di1 Di2 …  Dij DTT  DVT • Tuple of a relation r(R): • x = (a1, a2, …, aj | tB)

32. BCDM Example. Relation Employee with Schema: (name,salary,T) “Andrea was earning 60K at valid times 10, 11, 12 Such 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), ……}) VT 12 11 10 12 13 TT

33. BCDM Example. Relation Employee with Schema: (name,salary,T) “Andrea was earning 60K at valid times 10, 11, 12 Such 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)}) VT 12 11 10 12 13 UC TT

34. BCDM Bitemporal relation: set of bitemporal tuples. Constraint: Value equivalent tuples are not allowed. (Bitemporal) DB: set of (bitemporal) relations

35. BCDM Semantics (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)}

36. BCDM PROPERTIES Consistent 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)

37. BCDM Semantics of UC e.g., the DB’s clock thicks time 14

38. BCDM deletion (e.g., at time 15) delete(Employee, (Andrea,60K))

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

40. BCDM Algebraic Operators (Ex. Projection) πD(r)={z | ∃xr (z[D]=x[D]) ∧ ∀ yr (y[D]=z[D] ⇒ y[T] z[T]) ∧ ∀ tz[T] ∃yr (y[D]=z[D] ∧ ty[T])} • No value-equivalent tuple generated • (uniqueness of representation!) • Coalescing!

41. BCDM Algebraic Operators Properties BCDM algebraic operators are a consistent extension of SQL’s ones (reducibility and equivalence)

42. BCDM Reducibility ρtT rT ρtT (rT) opT op op(ρtT (rT)) ρtT = ρtT(opT (rT)) opT (rT)

43. BCDM Equivalence τt r τt(r) op opT τt op(r) τt(op(r))=opT (τt(r))

44. BCDM PROBLEM • Semantically 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!)

45. 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)

46. 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 tuples Notice: to retain the expressiveness of BCDM, value-equivalent tuples need to be allowed!

47. An example of implementation: TSQL2(Snodgrass et al., 1995) BCDM SEMANTICS TSQL2

48. An example of implementation: TSQL2(Snodgrass et al., 1995) • Efficient implementation (data model): • - 1-NF • UC managed efficiently • clear semantics (mapping onto BCDM) • BUT to get efficiency, we loose the uniqueness of representation property

49. Problem: no uniqueness of representation Example. 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. BCDM SEMANTICS TSQL2 (a) TSQL2 (b)

50. Problem: no uniqueness of representation VT 4 3 2 1 10 11 12 13 TT TSQL2 implementation: “covering” rectangles