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.

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. –
™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. –
™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. –
™ 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. –
™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. –
™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. –
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. –
™ 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. –
™ 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. –
Conformance: overview
Conformance module
Events
Deviations
CG model

11. –
Conformance: overview
Conformance module
Events
Deviations
CG model
Conformance module
State of
affairs
(fluents)
ExpectationsEvents
Deviations
CG model
Event
semantics
Constraints

12. –
Procedural Knowledge

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. –
™ 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. –
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. –
™ 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. –
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. –
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. –
™ 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. –
™ 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. –
™ 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. –
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. –
™ 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. –
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. –
An example…
17
Fig. 4. EC-based conformance evaluation of a CG execution.
• Reification of deviations as special fluents
• Expectations not explicitly represented

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. –
™ 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. –
™ 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. –™ 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. –
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. candidate
now
Answer questions