Upload
marco-montali
View
34
Download
0
Embed Size (px)
Citation preview
Stefano Bragaglia1, Federico Chesani1, Paola Mello1, Marco Montali2
1DISI, University of Bologna2KRDB, Free University of Bozen-Bolzano
Workshop on Foundations of Biomedical Knowledge Representation01/11/2012 Lorentz Centre, Leiden
��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
��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
�� 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
��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
��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
�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
�� 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?
�� Interplay between CGs and BMK
� Complex interaction: they can 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
�Conformance: overview
Conformance module
Events
Deviations
CG model
�Conformance: overview
Conformance module
Events
Deviations
CG model
Conformance module
State of affairs
(fluents)
ExpectationsEvents
Deviations
CG model
Eventsemantics Constraints
�Procedural Knowledge
�� Activities are
connected to an expected lifecycle� Internal states of
activities� Transitions
triggered by atomic events
Intra-Activity Perspective
active
completed
startend
candidate
�� Correlation of
events to the corresponding lifecycle
� “Next-transition” expectation
� Generation of corresponding “activity state” fluent
Intra-Activity Conformance
active
completed
startend
candidate
�Inter-Activity Perspective11
Table 1. Basic workflow patterns in GLARE, and their corresponding enabling con-ditions
Pattern Representation Enabling conditions
SequenceA B
When A is completed, B becomes candidate
Exclusive choiceA
B
C
cond
else
When A is completed and cond holds, B becomescandidateWhen A is completed and cond does not hold, Cbecomes candidate
Simple merge B
C
D
When B is completed, D becomes candidateWhen C is completed, D becomes candidate
Parallel split
A B
C When A is completed, B and C become candidate
Synchronization
DB
CWhen B and C are completed, D becomes candi-date
– Properly handle the computation of candidate activities, applying the control-flow patterns semantics to the current state of a�airs (which includes infor-mation about the currently completed activities).
– Impose and verify the negative expectation about non-candidate activities:only candidate activities can be activated by means of a start event.
– Ensure the proper termination of the CG execution when the trace of eventsis finished; the proper termination is in turn formalized by the followingexpectations:• every active activity instance is expected to be completed before the
termination;• when the execution terminates, no activity can be candidate for execu-
tion.
We observe that, considering the conformance characterization provided sofar, the CG procedural knowledge gives raise to a “closed” notion of confor-mance, where every event that is not explicitly expected is considered as forbid-den, and no unforeseen activity can be executed. To partially open the workflowspecification, more sophisticated forms of activity lifecycle can be introduced.For example, Figure 2 (right) presents an improved version of the basic lifecycle.The new version contains an additional state and transition, to explicitly accountfor exceptional situations that require the prompt interruption of the runningactivity instance. This exceptional transition is associated to a failure eventthat leads the instance to an aborted terminal state. In this way, it is possibleto “cancel” the execution of an activity instance under critical and exceptional
�� 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
�Semi-openness
active
completed
aborted
startend
failurecandidate
� Failure situations allow to skip activities
� Exceptional flows can be managed with rules/workflows� By “enabling”
additional activities� By default:
robustness principle
�
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[with Terenziani’s group]
�� 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.
Electrocardiographicstudy
Echocardiographicstudy
Coronaryangiorgraphy
�� 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
�� BMK
� Eligibility checks (preconditions)
� Abnormality checks to identify exceptional cases� Before the
activity execution � During the
activity execution
Revised Lifecycle
ready
candidate
active
completed
discarded aborted
preconditions∧ ¬abnormal
else
start
end
failure∨ abnormal
�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
�� 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
�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
�An example…
17
Fig. 4. EC-based conformance evaluation of a CG execution.
timestamps, we use natural numbers (N0) to represent time values. The mappingof a real timestamp to a corresponding number depends on the chosen time gran-ularity (such as ms or day). E.g., by choosing ms as the time granularity, eachtimestamp t could be mapped to the number of milliseconds between 1/1/197000:00 and t.
The combination of the domain knowledge and a concrete execution traceleads to infer “what is true when”, i.e., the intervals during which fluents hold.The holds at(f , t) predicate of the EC ontology is specifically used to test whetherf holds at time t.
Continuation of this section: formalization of the concepts described in Section3 using the Event Calculus. The formalization is ongoing and will be included in thefinal version, discussing at the workshop to which level of details. Figure 4 shows ascreenshot of conformance checking using our EC reasoner.
5 Generating and Matching Expectations with ECERules
In several previous works we have explored the notion of expectations, and wehave defined several di�erent languages for defining rules that support the defi-nition of expectation. Here we will refer only to two recent works, that providea good starting point for presenting our approach.
In [4] we have introduced the Event-Condition-Expectations (ECE-) rules.Based on the rule framework Drools6, ECE-Rules allow to link current systemstatus (properties, and also Event Calculus fluents) and the dynamic happeningof events to the generation of expectations.
6 http://www.jboss.org/drools/
• Reification of deviations as special fluents• Expectations not explicitly represented
�� Events� Something happened (what)� At a time point (when)
� Fluents� Properties/status of the system� Affected by events
� Expectations� About events� About fluents
� Achievement properties (existentially quantified)� Maintenance properties (universally quantified)
� Only positive vs. positive/negative expectations
Declarative Conformance:few concepts
�� 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 matching negative expectation has happened� Achievement/maintenance properties are treated almost
similarly…
Events, fluents, expectations and…
�� 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…
�� 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"
thenexpect InitiateTreatment( $pat , $disease , this after[0,1hour] $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].
An example of a rule is shown in Figure 5. When a patient $pat is evaluatedto be at risk of a disease $disease, with a factor judged as to be “high” and witha confidence equal or greater to the “medium” grade, then it is expected that aproper treatment is initiated within one hour from the evaluation.
This simple rule already shows the power of the ECE-Rules: this rule in par-ticular triggers when the evaluation of the disease risk is inserted as a event andconditions are met. As a consequence, dynamically an expectation is generated.The expectation then can be satisfied by an event representing the start of propertreatment. Note that the formalism allows to defines also proper actions in caseof satisfaction of the expectations (rewards) and in case of violations (possiblyexpected countermeasures).
In [5] instead we focuses on the possibility of extending Drools rules withfuzzy ontologies: in particular, the work present a first attempt to extend thenative matching mechanism supported by Drools with reasoning capabilitiesderived 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")
thenprintln("Degree of Delivery Conformance: " +
Drools.degree);end
Fig. 6. A rule that checks the conformance of a delivery with respect to a fuzzy ontol-ogy. Taken from [5].
�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"
thenexpect InitiateTreatment( $pat , $disease , this after[0,1hour] $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].
An example of a rule is shown in Figure 5. When a patient $pat is evaluatedto be at risk of a disease $disease, with a factor judged as to be “high” and witha confidence equal or greater to the “medium” grade, then it is expected that aproper treatment is initiated within one hour from the evaluation.
This simple rule already shows the power of the ECE-Rules: this rule in par-ticular triggers when the evaluation of the disease risk is inserted as a event andconditions are met. As a consequence, dynamically an expectation is generated.The expectation then can be satisfied by an event representing the start of propertreatment. Note that the formalism allows to defines also proper actions in caseof satisfaction of the expectations (rewards) and in case of violations (possiblyexpected countermeasures).
In [5] instead we focuses on the possibility of extending Drools rules withfuzzy ontologies: in particular, the work present a first attempt to extend thenative matching mechanism supported by Drools with reasoning capabilitiesderived 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")
thenprintln("Degree of Delivery Conformance: " +
Drools.degree);end
Fig. 6. A rule that checks the conformance of a delivery with respect to a fuzzy ontol-ogy. Taken from [5].
candidate
now
Answer questions