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.
Stefano Bragaglia1, Federico Chesani1,
Paola Mello1, Marco Montali2
1DISI, University of Bologna
2KRDB, Free University of...
–
™CGs developed by applying evidence-based
medicine to large classes of abstract patients
™Assumptions
– Ideal patients
™...
–
™Context and patients are not ideal
– Resources may be missing
– Each patient has her own story, condition, preferences
...
–
™ Compliance The act of conforming as requested by the CG
™ Flexibility The ability of accommodating and promptly
adapti...
–
™CGs propose a recommended behavior
™Many factors could lead healthcare professionals
in taking a different behavior
™We...
–
™Not to be intended as a normative component
™“Global” usage (totality of cases): CGs
understanding and improvement
– Im...
–
Conformance Checking
Conformance module
Events
Deviations
CG model
™ Nature of deviations depends on when conformance is...
–
™ Definitions and terminology, to describe terms and
applicability conditions of the CG
™ Workflows, characterizing the ...
–
™ Interplay between CGs and BMK
– Complex interaction:theycan defeat each other depending
on the specific situation
– “C...
–
Conformance: overview
Conformance module
Events
Deviations
CG model
–
Conformance: overview
Conformance module
Events
Deviations
CG model
Conformance module
State of
affairs
(fluents)
Expecta...
–
Procedural Knowledge
–
™ Activities are
connected to an
expected lifecycle
– Internal states of
activities
– Transitions
triggered by
atomic ev...
–
™ Correlation of
events to the
corresponding
lifecycle
™ “Next-transition”
expectation
™ Generation of
corresponding
“ac...
–
Inter-Activity Perspective11
Table 1. Basic workflow patterns in GLARE, and their corresponding enabling con-
ditions
Pat...
–
™ Generation of “candidate” activity instances
– Todo list
™ Progression principle
– Every candidate activity is expecte...
–
Semi-openness
active
completed
aborted
start
end
failurecandidate
™ Failure situations
allow to skip
activities
™ Except...
–
Formalize the refinedmodel towards conformance checking
Refine CGs (GLARE) to accommodate BMK
Understand how CGs are int...
–
™ Both BMK and CG may involve declarative and
procedural knowledge
™ Procedural knowledge fixes the sequencing of
action...
–
™ The interplay between the two kinds of knowledge
occurs at execution time
™ Brainstorming with physicians led to a spe...
–
™ BMK
– Eligibility checks
(preconditions)
– Abnormality
checks to identify
exceptional cases
™ Before the
activityexecu...
–
Conformance with CG+BMK
™ Ready and candidate states collapsed
™ Expected life cycle à triggered by logical conditions
™...
–
™ Proposed in 1986 by Kowalsky and Sergot
™ Events
™ Fluents, i.e. properties whose truth value can change
along time
™ ...
–
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)
d...
–
An example…
17
Fig. 4. EC-based conformance evaluation of a CG execution.
• Reification of deviations as special fluents...
–™ Events
– Somethinghappened (what)
– At a time point (when)
™ Fluents
– Properties/status of the system
– Affectedby eve...
–
™ Matching function: return a score if an observed event
matches any (positive/negative) expectation
™ Should support di...
–
™ Violation
– an event matching a positive expectation did not
happen
– An event matching negative expectation has happe...
–™ Work in progress!!!
™ Based on Drools/Java and Drools Chance
CG representation and
expectations: ECE rules
18
rule "Ris...
–
ECE rules…
native matching mechanism supported by Drools
derived by fuzzy ontologies.
rule "Fuzzy evaluation of conforma...
candidate
now
Answer questions
Upcoming SlideShare
Loading in …5
×

FBKR 2012 - Montali - Conformance Verification when Dealing with Computerized and Human-Enhanced Processes

110 views

Published on

Invited presentation on "Conformance Verification when Dealing with Computerized and Human-Enhanced Processes" at the Workshop on Foundations of Biomedical Knowledge Representation (FBKR 2012), Lorentz Centre, the Netherlands.

  • Be the first to comment

  • Be the first to like this

FBKR 2012 - Montali - Conformance Verification when Dealing with Computerized and Human-Enhanced Processes

  1. 1. Stefano Bragaglia1, Federico Chesani1, Paola Mello1, Marco Montali2 1DISI, University of Bologna 2KRDB, Free University of Bozen-Bolzano Workshop on Foundations of Biomedical Knowledge Representation 01/11/2012 Lorentz Centre, Leiden
  2. 2. – ™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
  3. 3. – ™Context and patients are not ideal – Resources may be missing – Each patient has her own story, condition, preferences à Unforeseen situations are common ™CGs routinely adapted on a per-patient basis, using the Basic Medical Knowledge (BMK) ™CGs enacted together with many additional (local) rules and processes ™Physicians are not ideal (maybe, they would need computerized support J ) Real World
  4. 4. – ™ 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
  5. 5. – ™CGs propose a recommended behavior ™Many factors could lead healthcare professionals in taking a different behavior ™We need to sort this discrepancy out! ™Goal of conformance checking: detect deviations between the expected and the actual behavior –I.e., provide to domain experts all useful information to understand and explain these deviations Conformance
  6. 6. – ™Not to be intended as a normative component ™“Global” usage (totality of cases): CGs understanding and improvement – Improvement of the organization – Improvement of the CG model ™“Local” usage (single patient): decision support – Track the state of affairs (where is the patient located wrt the CG?) – Report deviations – Run-time and offline perspective Usages of Conformance
  7. 7. – Conformance Checking Conformance module Events Deviations CG model ™ Nature of deviations depends on when conformance is checked – Run-time à open-time window – Offline à closed-time window
  8. 8. – ™ Definitions and terminology, to describe terms and applicability conditions of the CG ™ Workflows, characterizing the allowed courses of execution ™ Rules, to handle particular cases and exceptions, and declarative fragments ™ Linguistic labels to explain features, conditions, criteria – “Low”, “high”, “risky”, … ™ Temporal constraints (metric, repetitions, …) – In addition to the ones imposed by workflows What is a CG Model?
  9. 9. – ™ Interplay between CGs and BMK – Complex interaction:theycan defeat each other depending on the specific situation – “Closed” vs “open” fragments of the CG – Doctors always have the last word! ™ Interplay between workflows and rules – Workflows: procedural knowledge – Rules: declarative knowledge ™ Humans in the loop – They are not web services! – Missing a deadline for 50 ms is actually a deviation? à “Grades” of conformance Criticalities
  10. 10. – Conformance: overview Conformance module Events Deviations CG model
  11. 11. – Conformance: overview Conformance module Events Deviations CG model Conformance module State of affairs (fluents) ExpectationsEvents Deviations CG model Event semantics Constraints
  12. 12. – Procedural Knowledge
  13. 13. – ™ Activities are connected to an expected lifecycle – Internal states of activities – Transitions triggered by atomic events Intra-Activity Perspective active completed start end candidate
  14. 14. – ™ Correlation of events to the corresponding lifecycle ™ “Next-transition” expectation ™ Generation of corresponding “activity state” fluent Intra-Activity Conformance active completed start end candidate
  15. 15. – Inter-Activity Perspective11 Table 1. Basic workflow patterns in GLARE, and their corresponding enabling con- ditions Pattern Representation Enabling conditions Sequence A B When A is completed, B becomes candidate Exclusive choice A B C cond else When A is completed and cond holds, B becomes candidate When A is completed and cond does not hold, C becomes candidate Simple merge B C D When B is completed, D becomes candidate When C is completed, D becomes candidate Parallel split A B C When A is completed, B and C become candidate Synchronization DB C When B and C are completed, D becomes candi- date
  16. 16. – ™ Generation of “candidate” activity instances – Todo list ™ Progression principle – Every candidate activity is expected to be started ™ Enforcement of “closed” procedural knowledge – Every non-candidate activity is expected not to be started – What about exceptions? (see next slide) ™ Closed time-window: every executed activity must be completed before the end of the trace Inter-Activity Conformance
  17. 17. – Semi-openness active completed aborted start end failurecandidate ™ Failure situations allow to skip activities ™ Exceptional flows can be managed with rules/workflows – By “enabling” additional activities ™ By default: robustness principle
  18. 18. – Formalize the refinedmodel towards conformance checking Refine CGs (GLARE) to accommodate BMK Understand how CGs are interpretedby healthcare professionals Collectingreal examples about BMK+CGs Research agenda [with Terenziani’s group]
  19. 19. – ™ 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” CG+BMK: Example 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
  20. 20. – ™ The interplay between the two kinds of knowledge occurs at execution time ™ 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 as the process Binding CG with BMK
  21. 21. – ™ BMK – Eligibility checks (preconditions) – Abnormality checks to identify exceptional cases ™ Before the activityexecution ™ During the activityexecution Revised Lifecycle ready candidate active completed discarded aborted preconditions ∧ ¬abnormal else start end failure ∨ abnormal
  22. 22. – Conformance with CG+BMK ™ 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 active completed discarded aborted start end failure ∨ abort abort ready candidate active completed discarded aborted preconditions ∧ ¬abnormal else start end failure ∨ abnormal
  23. 23. – ™ Proposed in 1986 by Kowalsky and Sergot ™ Events ™ Fluents, i.e. properties whose truth value can change along time ™ Domain axioms: link the happening of events with the change of truth value of fluents Representing the current state: Event Calculus
  24. 24. – 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
  25. 25. – An example… 17 Fig. 4. EC-based conformance evaluation of a CG execution. • Reification of deviations as special fluents • Expectations not explicitly represented
  26. 26. –™ Events – Somethinghappened (what) – At a time point (when) ™ Fluents – Properties/status of the system – Affectedby events ™ Expectations – About events – About fluents ™ Achievement properties (existentially quantified) ™ Maintenance properties (universally quantified) – Only positive vs. positive/negative expectations Declarative Conformance: few concepts
  27. 27. – ™ Matching function: return a score if an observed event matches any (positive/negative) expectation ™ Should support different semantics – Ontologies – Fuzzy concepts – Temporal reasoning ™ Fulfillment – an event matching a positive expectation has happened – No event matchingnegative expectation has happened – Achievement/maintenance propertiesare treated almost similarly… Events, fluents, expectations and…
  28. 28. – ™ Violation – an event matching a positive expectation did not happen – An event matching negative expectation has happened – Fluents: strong negation vs. weak negation, in case of maintenance properties Events, fluents, expectations and…
  29. 29. –™ Work in progress!!! ™ Based on Drools/Java and Drools Chance CG representation and expectations: ECE rules 18 rule "Risk factor evaluation " when $pat : Patient( ... ) // patient identifier // evaluation of risk factor and confidence degree $risk : EvaluatedRisk ( $phys , $pat , $disease , $factor , $conf ) $factor == "high" $conf >= "medium" then expect InitiateTreatment ( $pat , $disease , this after [0,1 hour] $risk ) on fulfillment { // if the treatment is initiated /* some increase in patient health */ } on violation { // if the treatment is not initiated alert( ... ); } end Fig. 5. An example of ECE-Rule [4].
  30. 30. – ECE rules… native matching mechanism supported by Drools derived by fuzzy ontologies. rule "Fuzzy evaluation of conformance " when Order ($e: expectedInDays ) DeliveryLog ( $d: delay ~InTime $e , @imperfect(kind =="userOp") $p: packaging nec ~isA " GoodPackaging ") then println("Degree of Delivery Conformance : " + Drools.degree); end Fig. 6. A rule that checks the conformance of a delivery
  31. 31. candidate now Answer questions

×