Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Prohealth 2011 - Montali - Conformance Checking of Executed Clinical Guidelines in presence of Basic Medical Knowledge


Published on

Presentation of the paper "Conformance Checking of Executed Clinical Guidelines in presence of Basic Medical Knowledge" at the 4th International Workshop on Process-Oriented Information Systems in Healthcare (ProHealth’11).

  • Be the first to comment

  • Be the first to like this

Prohealth 2011 - Montali - Conformance Checking of Executed Clinical Guidelines in presence of Basic Medical Knowledge

  1. 1. Alessio Bottrighi1, Federico Chesani2, Paola Mello2, Marco Montali3, Stefania Montani1, Paolo Terenziani1 1DI, University of Piemonte Orientale 2DEIS, University of Bologna 3KRDB, Free University of Bozen-Bolzano
  2. 2. – ™ Clinical Guidelines (CGs) in the ideal and real world ™ Real-life examples showing the interplay between CGs and medical knowledge ™ Specialized activity lifecycle as a connection point between them ™ Characterization of conformance and evaluation with the Event Calculus Outline
  3. 3. – ™ CGs developed by applying evidence-based medicine to large classes of abstract patients ™ Assumptions – Ideal patients ™ statistically relevant ™ with only the disease targeted by the CG – Ideal physicians – Ideal resources ™ ∞ resources Ideal world
  4. 4. – ™ Context and patients are not ideal – Resources may be missing – Each single patient has its own story, condition, preferences à Unforeseen situations are common à CGs are routinely adapted on a per patient basis, using the Basic Medical Knowledge (BMK) ™ Physicians are not ideal à they need (computerized) support Real World
  5. 5. – ™ Compliance The act of conforming as requested by the CG ™ Flexibility The ability of accommodating and promptly adapting to change and unforeseen situations Compliance vs Flexibility Universe of Traces Compliant Traces Compliance Flexibility
  6. 6. – ™ Conformance problem: adherence of a CG execution trace to the CG+BMK model – The doctor has always the last word! Big Question How do BMK and CGs interact?
  7. 7. – Formalize the refined model towards conformance checking Refine CGs (GLARE) to accommodate BMK Understand how CGs are interpreted by healthcare professionals Collecting real examples about BMK+CGs Research agenda
  8. 8. – Choice enforcement CG BMK Patients suffering from bacterial pneumonia caused by agents sensible to penicillin and to macrolid, must be treated one of them Don’t administer drugs to an allergic patient. ™ BMK reinforces the CG helping in the discrimination among possible alternatives … Administer penicillin Administer macrolid Patient allergic to penicillin
  9. 9. – Openness CG BMK Calcemia and glycemia are routinely performed for all patients admitted to the internal medicine ward of Italian hospitals. ™ BMK introduces further activities that can/must be executed alongside the ones of the CG ™ The CG cannot be interpreted as a closed specification –  Closed = everything not explicitly mentioned is forbidden
  10. 10. – Exceptions CG in GLARE [Terenziani et al.] BMK Threats to patient’s life must be addressed immediately. ™ (sometimes) CG’s prescriptions = standard behavior ™ BMK may introduce high-priority prescriptions used to deal with exceptional situations –  They override the CG Electrocardiographic" study" Echocardiographic" study" Coronary" angiorgraphy"
  11. 11. – Mandatory behaviors CG BMK In a patient affected by unstable angina and advanced predialytic renal failure, coronary angiography remains mandatory, even if the contrast media administration may cause a further final deterioration of the renal func- tions, leading the patient to dialysis. Don’t administer treatments to the patient when they are likely to be dangerous ™ (sometimes) BMK = default situation ™ CG introduces mandatory activities in order to handle special cases –  They override the BMK
  12. 12. – ™ BMK is used to fill the gap between the ideal world targeted by CGs and the real world ™ The interplay between CG and BMK is complex –  It is likely the case they seem to contradict each other ™ Contradiction is only apparent –  CG actions should not be interpreted as “must do” actions –  Both CG and BMK are “defeasible” ™  Parts of the CG are amended by the BMK ™  Parts of the BMK are overriden by the CG Lessons learnt 1/2
  13. 13. – ™ Both BMK and CG may involve declarative and procedural knowledge ™ Procedural knowledge fixes the sequencing of actions to be done ™ Declarative knowledge captures constraints and properties to be satisfied, without saying “how” Lessons learnt 2/2 CG in GLARE [Terenziani et al.] BMK Threats to patient’s life must be addressed immediately. An hearth failure is a life threat. Diuretic therapy is a possible immediate response for acute heart failure. Electrocardiographic" study" Echocardiographic" study" Coronary" angiorgraphy"
  14. 14. – ™ The interplay between the two kinds of knowledge occurs at execution time à when performing activities ™ Brainstorming with physicians led to a specialized activity life cycle –  Capturing the semantics of “executing activities” from the viewpoint of domain experts –  Pointing out where BMK-driven decision making comes into play –  Showing that data are as much as important than the process Binding CG with BMK
  15. 15. – Activity Lifecycle
  16. 16. – Activity Lifecycle candidate
  17. 17. – Activity Lifecycle candidate discarded ready NOT Precond ∨ Ab Precond ∧ NOT Ab Preconditions (CG) are applicability conditions over available patients data and execution context Abnormality conditions (BMK) point out when the patient/context is not ideal
  18. 18. – Activity Lifecycle candidate discarded ready active NOT Precond ∨ Ab Precond ∧ NOT Ab start
  19. 19. – Activity Lifecycle candidate discarded discarded completed ready active NOT Precond ∨ Ab Precond ∧ NOT Ab start end Ab∨ failure
  20. 20. – Robust Approach candidate discarded discarded completed ready active NOT Precond ∨ Ab Precond ∧ NOT Ab start end Ab∨ failure
  21. 21. – Conformance candidate discarded discarded completed active NOT Precond ∨ Ab Precond ∧ NOT Ab Ab ™  Ready and candidate states collapsed ™  Expected life cycle à triggered by logical conditions ™  Real life cycle à triggered by event occurrences ™  Conformance: detect and show deviations expected real candidate discarded discarded completed active start discard abort end
  22. 22. – ™ Ability to reason upon events, time and data –  Events characterizing the life cycle of activities ™  Glucose test completed at time … –  Events used to collect information about patient and context ™  At time …, the patient had an hearth failure ™ Ability to deal with declarative and procedural knowledge –  Rules –  States/milestones Reasoning - Requirements
  23. 23. – ™ A logic-based framework for reasoning upon events and their effects ™ Composed of –  EC ontology: a set of special predicates to represent how events manipulate fluents ™  Fluent = property that changes over time à states! –  A logic-based formalization capturing the semantics of the EC ontology ™ Can be axiomatized using logic programming with NAF –  Prolog! Event Calculus [Kowalski and Sergot, 1986]
  24. 24. – EC Framework Reasoning Facilities Logic-Based Framework Logic-based language Event Calculus Axiomatization EC ontology EC Specification Execution Trace Domain dependent Domain independent
  25. 25. – The Simple EC Ontology 1 2 3 4 5 6 7 8 9 10 11 12 13 14 initiates(a,f,3) terminates(b,f,12) happens(a,3) holds_at(f,7) declip clip 0 f f holds in (3,12] a b
  26. 26. – ™  Events –  Life cycle events: exec(event(start, A)) –  Patient-related events: heart_failure, glucose(91) ™  Status Fluents –  status(nextCGcandidate,As) indicates the next activity (set of activities) according to the CG ™  Control-flow dimension –  status(A,S) indicates the current state during the execution of A ™  Activity life cycle –  status(cg,nc) indicates the presence of a deviation ™  Other EC + Prolog rules to capture BMK ™  Facts to describe the structure of the CG and the preconditions of each activity Approach
  27. 27. – ™  Obviously, only relevant portions of the BMK can be considered ™  Threats to patient’s life must be addressed immediately –  Occurrence of a life threat gives raise to an abnormality situation –  The abnormality situation disappears only if a proper treatment is started initiates(exec(E),abnormality(E),T):- life_threat(E). terminates(exec(event(start,A)),abnormality(E),T):- treatment(E,A). ™  An hearth failure is a life threat ™  Diuretic therapy is a possible immediate response for acute heart failure life_threat(hearth_failure). treatment(hearth_failure,diuretic_therapy). Capturing BMK
  28. 28. – ™  Easy to include further cases by adding rules Capturing Deviations CG next activity is B Operator starts A initiates(exec(event(start,A)),status(cg,nc),T):- holds_at(status(nextCGcandidate,B),T), A ≠ B. CG A must be discarded Operator starts A initiates(exec(event(start,A)),status(cg,nc),T):- holds_at(status(A,candidate),T),¬preconditions(A,T). initiates(exec(event(start,A)),status(cg,nc),T):- holds_at(status(A,candidate),T),holds_at(abnormality(_),T). CG A must be started Operator discards A initiates(exec(event(discard,A)),status(cg,nc),T):- holds_at(status(A,candidate),T), preconditions(A,T),¬holds_at(abnormality(_),T).
  29. 29. –Running case with REC hearth failure REC
  30. 30. – ™ Healthcare professionals use BMK to put CGs into practice ™ Accommodating the BMK in CG modeling and execution has many implications –  Specialized activity life cycle –  Complex interplay between BMK and CG –  Conformance as a tool for highlighting deviations ™ Event Calculus is a suitable framework to formalize CG + BMK ™ Balancing between compliance and flexibility is, again, the main issue! Summary
  31. 31. – ™  Going on with our EC-based formalization ™  Combination with more declarative approaches such as DECLARE –  EC-based formalization of DECLARE constraints with temporal constraints already available (MOBUCON tool) ™  Connections with adaptive PAIS ™  Connections with artifact-centric business processes ™  Applying REC during the execution for clinical operational decision support ™  Investigating what happens if we only have “start” and “end” events Ongoing/Future Work
  32. 32. candidate now Answer questions