=Paper=
{{Paper
|id=Vol-2237/medracer-paper-4
|storemode=property
|title=Filtering Clinical Guideline Interactions with Pre-Conditions: A Case Study on Diabetes
Guideline
|pdfUrl=https://ceur-ws.org/Vol-2237/medracer-paper-4.pdf
|volume=Vol-2237
|authors=Veruska Zamborlini,Roelof van der Heijden,Annette ten Teije
|dblpUrl=https://dblp.org/rec/conf/kr/ZamborliniHT18
}}
==Filtering Clinical Guideline Interactions with Pre-Conditions: A Case Study on Diabetes
Guideline==
https://ceur-ws.org/Vol-2237/medracer-paper-4.pdf
Filtering Clinical Guideline Interactions with Pre-conditions:
A Case study on Diabetes Guideline∗
Veruska Zamborlini Roelof van der Heijden Annette ten Teije
Institute for Logic, Lang. and Computation Graduate School of Informatics Computer Science Department
Universiteit van Amsterdam Universiteit van Amsterdam Vrije Universiteit Amsterdam
v.zamborlini@uva.nl annette.ten.teije@vu.nl
Abstract recommendations might contradict or in other ways interact
with each other. It might even be the case that within a single
Clinical Guidelines are meant to support healthcare guideline, some recommendations interact with some other
providers to offer a better service via evidence-based
recommendations. These interactions might result in errors
recommendations that apply according to certain cir-
cumstances given a certain disease or condition. How- in the treatment of patients.
ever, the high number of recommendations in a single The TMR model (Transition-based Medical Recommen-
guideline makes it humanly impossible to verify for all dation), designed by Zamborlini et al. (Zamborlini et al.
possible interactions. The goal of this work is twofold: 2014) is another approach to describe clinical guideline rec-
(i) to analyse pros and cons of formalising a real guide-
line using the TMR model and then (ii) to infer inter-
ommendations. It is designed to detect conflicts between rec-
action among (some of) the recommendations from the ommendations. It has been used in this regard for a con-
the Scottish Guideline on Diabetes. To this end we ex- structed set of recommendations already. However, the TMR
tend the TMR Model to formalize the pre-conditions model is also limited, for example in its ability to handle
that define in which circumstances a recommendations preconditions of recommendations. This research tests the
may apply and we implemented the reasoning in SWI- expressiveness of the TMR model for formalizing recom-
Prolog. The results show that (i) properly formalising mendations from a real life clinical guideline and detecting
the diabetes guideline is a cross-disciplinary task that possible interactions among the guideline recommendations.
requires both the formalisation know-how and the med- The proposed case study uses the Scottish diabetes guide-
ical background; and (ii) indeed the diabetes guideline line SIGN116 (Network 2013). Furthermore, we extend the
presents conflicting recommendations which can be au-
tomatically detected provided the suitable modeling and
TMR model and implement some logic to allow the TMR
background knowledge. It is reasonable to conclude that model to handle preconditions.
these conclusions hold for other guidelines too. The adopted methodology comprises of three steps further
described in the next section. The first step consists of ver-
Introduction ifying if the information available in guidelines is sufficient
to allow formal representation and detecting interactions in
Clinical guidelines are a standard in the medical field. There the TMR model. Is the help of a medical expert required?
is a separate clinical guideline available for almost every ma- Are the recommendations clear and unambiguous? The next
jor disease. They serve as a framework for the treating doc- step is to look into the limitations of the TMR model. Which
tor, to put his actions in perspective and point him in new recommendations can be described using the TMR model
directions. Of course, they are only guidelines and doctors and what choices need to be made in doing so? Are there rec-
can deviate from them when they deem it necessary when ommendations that can not be described by the TMR model
creating a treatment plan for a patient. and what extensions would be required to be able to? The
Guidelines are often long and complex documents, there- third step consists of improving one particular aspect of the
fore tools have been developed to help with this developing TMR model, namely the representation of pre-conditions.
process of clinical guidelines. One of these tools is the mod- How can we implement them and what new insights does
eling language Asbru (Shahar, Miksch, and Johnson 1998), this bring to our previous results? Does the handling of pre-
which allows practitioners to precisely formulate each step conditions improve the detection of true interactions?
in a treatment plan and the conditions that need to be satis-
fied in order to perform the next step. One feature that Asbru In the sequel we present the core concepts of the TMR
does not support however, is conflict detection between rec- model and how they are used to detect interactions, followed
ommendations in the guideline. When a patient suffers from by the proposed extension to use pre-conditions for identi-
multiple diseases, multiple guidelines might apply, whose fying what interactions can avoided. Then we present the
experiment of formalising the Diabetes Guideline in TMR
∗ This paper is based on the master thesis of van der Heijden, and detecting interactions. Finally we discuss some related
available in https://tinyurl.com/heijdenMScThesis work and present the conclusions of this work.
Methodology TMR Extension
This section describes the steps of the methodology, results TMR Model - Background
and contributions as presented in (van der Heijden 2017). In this section we present the core concepts of the TMR
Step 1: Guideline selection model in order to provide the necessary information to un-
derstand our modeling decisions (Zamborlini et al. 2014;
To test the abilities of the TMR model to describe recom- Zamborlini et al. 2017a). Besides actions and recommenda-
mendations from real life guidelines, we first chose a real tions, the TMR-model accounts for transitions and the rea-
life guideline. We were looking for a guideline that based sons for performing an action, the so called causation be-
its statement on verifiable scientific research. It also needed liefs. An UML class diagram of the TMR model can be
to be written in English, so that the international scientific found in Figure 1 and its components.
community can take part in the discussion. It would have Each component is described as follows and illustrated us-
our preference if the guideline was also recently updated. ing the following recommendation taken from the Diabetes
The chosen guideline was the Scottish diabetes guideline Guideline: “People with type 1 diabetes should be encour-
SIGN116 (Network 2013). Next, we went through the guide- aged to participate in physical activity or structured exercise
line and identified several recommendations that could pos- to improve cardiovascular risk factors”. Its representation
sibly interact with each other. Only if we know that inter- according to the TMR model is illustrated in Figure 2.
actions are supposed to exist between the recommendations,
can we verify any results the TMR model might give us. Clinical Guideline Each recommendation is part of a clin-
After that, we examined the recommendations closely, to ical guideline object. In our case study, since all our recom-
determine if there is any missing or ambiguous data in the mendations come from the same guideline, we only have to
selected set. It is important to note these problems already, define a single guideline object for diabetes and can refer-
for it might influence the choices we will make during the ence it in each recommendation.
modeling. Furthermore, clinical guidelines are written with
Recommendation Each recommendation references an
a target audience of medical experts in mind. We need to
action and a causation belief that justifies the recommenda-
determine if we are able to understand the guideline before
tion, besides specifies its strength and which clinical guide-
starting to model the recommendations.
line it is a part of. In Figure 2 the recommendation is labeled
Results Selection of recommendations, their analysis and
as “Type 1 should exercise regularly” and recommends that
expected interactions.
an action should be performed for a reason.
Contribution Discussion about the ambiguities and miss-
ing information found in the guideline. Action Types An action object can represent the adminis-
tration of drugs, but can also be some other medical action.
Step 2: Modeling and interaction detection In our example the action describes exercising, so we label
The next step was to model the recommendations in TMR. it as “Perform exercise.”
Any problems we encountered or decisions we had to make
Transition Types A transition has two objects associated
are discussed in this section. With our models of the rec-
with it: the transformable situation and the expected situa-
ommendation in hand, we executed the algorithm to detect
tion. These describe the beginning and ending state of a tran-
the interactions. We compared these results with our initial
sition respectively. If we perform exercise, we reduce our
expectations and analysed any differences.
risk of cardiovascular diseases. So in our example the trans-
Results Recommendations modeled in TMR, calculated
formable situation is “increased cardiovascular risk factors”
interactions.
and the expected situation is “reduced cardiovascular risk
Contribution Discussion about (i) the benefits and diffi-
factors.”
culties faced while modeling, (ii) analysis of the computed
interactions compared against the expected ones, and (iii) Situation types Both transformable and expected situa-
how could the TMR model be improved. tions are instances of situation types. They are used to de-
scribe states of the patient. It allows for example to describe
Step 3: Extension of TMR model when two actions promote the same transition or as well the
Subsequently, we extend the TMR model to allow for the opposite effect of each other. In a situation we always talk
handling of preconditions. To do this we have identified a about a specific property that is some value, for example
common structure of preconditions and designed an imple- “cardiovascular risk factor is reduced.”
mentation for it. Using these observations, we performed the
actual encoding of the preconditions. We ran the detection Causation Belief A causation belief object is used to de-
algorithm with the extended TMR models and discuss the scribe what transition is caused by a specific action. It an-
results compared to our manual expectations as well as the swers the question: why do we perform this action? For
previous results to determine whether we have been success- example, we perform exercise to reduce the cardiovascular
ful in extending the TMR model. risk factors. Each causation belief has a probability and a
Results The TMR model extended with preconditions, strength, which is defined by the quality of the evidence of
new calculated interactions. the recommendation. 1
Contribution Discussion about the proposed solution, 1 The probability information as well as the strength are cur-
advantages & limitations. rently not used by the implementation of the TMR model to com-
Figure 1: UML class diagram of the TMR model.
Figure 2: Example of instance of the TMR model.
Interaction Types An interaction relates two recommen- Definition 3 (Repeating) Recommendations R1 , R2 , ..., Rn
dations. Each interaction is of a specific type, e.g. contradic- are considered repeating when they all recommend the ac-
tion or repetition. tion A.
One of the goals of the TMR model is to allow for detec-
Definition 4 (Alternative) Recommendations R1 , R2 , ..., Rn
tion of interactions among recommendations, as described
are considered alternatives to each other when their causa-
in the next section.
tion beliefs C1 ,C2 reference the same transition T , while the
actions A1 , A2 are different.
Detection of several interaction types
Definition 5 (Repairable) Two recommendations are con-
In the current implementation of the TMR model, four types sidered repairable when one recommends and the other does
of interactions that can be detected. These are: contradic- not recommend actions whose transitions are inverse.
tion, repetition, alternative actions and repairable transi-
tions. In particular, some interactions may be defined in A recommendation is considered repairable when it is
terms of counteracting effects, which requires us to define meant to prevent a transition while another recommendation
also inverse transitions. Other types of interactions, such as recommends an action that promotes an inverse transition,
interactions in time or dosage are not yet supported. Hereby i.e. it indicates that the undesired effect could be repaired.
we provide their informal descriptions based on the formal All those rules are implemented in SWI-Prolog and the
definitions provided in (Zamborlini et al. 2017a). interactions are automatically calculated. The implementa-
tion of these rules is discussed in details in (Zamborlini et
Definition 1 (Inverse) Two transitions T1 and T1 are in- al. 2017b), where they are generically applied to (parts of)
verse if the expected end state of T1 is the initial state of Hypertension, Osteoarthritis and Diabetes II guideline also
T2 and the initial state of T1 is the expected end state of T2 . using existing medical knowledge available as Linked Open
Data.
Definition 2 (Contradiction) Two recommendations
R1 , R2 are considered contradicting if one of the following
is true:
Pre-Condition Extension and Implementation
One of our contribution of this paper is the extension of
• Recommendation R1 recommends action A1 , whereas R2 TMR model with pre-conditions, i.e. the conditions in which
recommends not performing A1 . a recommendation would apply (van der Heijden 2017). Our
• Recommendation R1 recommends action A1 to achieve extension is described in UML as pictured in Figure 3. It
transition T , whereas R2 recommends performing action comprises two modifications: (i) introduction of a relation
A2 in order to prevent T from occurring. hasFilterSituation between the Recommendation and a Situ-
• The recommendations R1 , R2 recommend actions A1 , A2 ation Type; and (ii) specialization of the class Situation Type
that promote transitions T1 , T2 that are inverse to each into two sub-classes: Atomic and Complex Situation Types.
other. The latter is a combination of other situation types using one
of the logic operators: and, or and negation (neg).
pute interactions. Therefore, we have used a probability value of Since the TMR model is implemented in RDF format, it
“always” for all our causation beliefs. requires to represent the preconditions in RDF as well. This
icate, or an intermediate object. For each argument of each
operator, a new RDF triple needs to be defined.
: orABC a tmr : SituationType ;
2 rdf : or :A , :B , :C.
4 : negB a tmr : SituationType ;
rdf : neg :B.
6
: negA a tmr : SituationType ;
8 rdf : neg :A.
Figure 3: UML class diagram of the extension to the TMR 10 : orNegAC a tmr : SituationType ;
model. rdf : or : negA , :C.
12
: final a tmr : SituationType ;
is not straightforward since a statement in RDF is a triple 14 rdf : and : orABC , : negB , : orNegAC .
that consists of a subject, predicate (verb) and object. Each Listing 2: Intermediate RDF resources to define logic for-
triple can be viewed as a directed arrow from the subject mulas.
to the object, that is annotated with the verb. A formula in The final formula object :final is referenced by the
predicate logic consists of boolean operators, predicates and recommendation. Using this representation we are able to
literals. Each operator takes two (or one, in case of nega- uniquely describe any logic formula in RDF.
tion) objects, applies some operation on them and produces There are a couple things to note here.
a result. We need a way to represent the one using the other.
Our representation uses intermediate objects to represent • There is nothing preventing a user from defining relations
the logic formulas. Let’s say we want to represent the fol- that use different verbs to a single intermediate object,
lowing formula in RDF. e.g. defining both an and relation and an or relation for
a single intermediate object. However, the resulting struc-
(A ∨ B ∨C) ∧ ¬B ∧ (¬A ∨C) (1) ture can not be translated back into predicate logic. This
Here we are using the n-ary extensions of the binary boolean should therefore never be done.
operators. Using prescript notation this can be written as • Because in RDF a subject can be related to any number
of objects, we can define multiple relations for a single
∧(∨(A, B,C), ¬B, ∨(¬A,C)). (2) intermediate object. This allows us to use n-ary boolean
We can write this formula as a directed graph where each operators instead of binary boolean operators.
node is either a literal or an operator. If an edge points from • We only support the boolean operations conjunction, dis-
an operator to a node, then it means that this node is an argu- junction and negation. All other operations have to be ex-
ment for this operator. The graph corresponding to the for- pressed using these three.
mula of Equation 2 can be found in Figure 4a.
Figure 4b pictures the graph representation of the RDF file Finally, the reasoning task is implemented in SWI-
that encodes this same formula. Here, we use boxed nodes Prolog2 . It first extracts Prolog rules from the above de-
to denote intermediate objects. Each arrow is labeled with scribed RDF representation. Then it verifies their satisfiabil-
its operation. ity by using the SAT-solver CLP(B) (Triska 2016). In other
In RDF, let’s first define the literals. The only requirement words, it determines if the conditions imposed by a set of
we have for literals is that we want to be able to refer to them. interacting recommendations are satisfiable. If it is not, it
So we only need to define a subject and type. We also give means the interaction will never occur since no patient can
them a label. Listing 1 shows how we can do that. satisfy all the conditions at the same time.
Experiment and Results
1 :A a tmr : SituationType ;
rdfs : label " Situation A" . Selecting and analysing recommendations
3
:B a tmr : SituationType ;
From SIGN116 (Network 2013) 21 recommendations were
5 rdfs : label " Situation B" . selected for which interactions were expected to be found.
The following list presents a subset of the recommendations
7 :C a tmr : SituationType ; selected in (van der Heijden 2017):3
rdfs : label " Situation C" .
2 The main code can be found in guidelines-tmr.github.
Listing 1: Predicates defined in RDF. io/tmr-precond-code and a notebook showing the results can be
founf in guidelines-tmr.github.io/tmr-precond-notebook
Now we use intermediate objects as subjects and the oper- 3 The code associated to each recommendation is kept as in the
ators as verbs. The object of each statement is either a pred- original work, except for a small correction for B1, B2, D1 and D2.
Figure 4: Different representations of the same formula.
B1 People with type 1 diabetes should be encouraged to par- operators; (ii) implicit knowledge about causation or precon-
ticipate in physical activity or structured exercise to im- ditions is also common since either it is considered common
prove cardiovascular risk factors. medical knowledge, or it is omitted by relying on the con-
B2 People with type 2 diabetes should be encouraged to par- text of the the document section in which the recommenda-
ticipate in physical activity or structured exercise to im- tion appears, or it is provided in an accompanying text which
prove glycaemic control and cardiovascular risk factors. describes the evidence for the recommendation and or often
not very clear, specially for non-domain-experts.
B3 Patients with existing complications of diabetes should For example, consider recommendation C3. It ambigu-
seek medical review before embarking on exercise pro- ously suggests to add pioglitazone to metformin AND
grammes. sulphonylurea therapy. However, it is not clear whether this
C1 Metformin should be considered as the first line oral treat- means adding to both metformin and sulphonylurea, or to ei-
ment option for overweight patients with type 2 diabetes. ther metformin or sulphonylurea therapy. In this case, if we
look into C1 and C2 then we can conclude that the latter is
C2 Sulphonylureas should be considered as first line oral correct. Moreover, neither of them clearly mention the effect
agents in patients who are not overweight, who are in- expected to be achieved by any of the therapies. It actually
tolerant of, or have contraindications to, metformin. is meant to lower the average blood glucose level.
C3 Pioglitazone can be added to metformin and sulphony-
lurea therapy, or substituted for either in cases of intoler- Formalizing the Diabetes guideline
ance. The expressiveness of the TMR model can also pose some
D1 Examination of the retina prior to conception and during difficulties in the modeling process: it may require informa-
each trimester is advised in women with type 1 and type 2 tion that is missing in the guideline (see previous section)
diabetes. More frequent assessment may be required in or it may not offer means to formalise all knowledge within
those with poor glycaemic control, hypertension or pre- a recommendation, such as time and quantity, since it is a
existing retinopathy. work in progress.
D2 Patients’ retinas should be screened at least annually. Surpassed those difficulties/limitations, the recommenda-
tions are formalized4 according to the TMR model.
F1 Patients with type 1 diabetes should be screened from age Listing 3 describes the formalisation of the recommenda-
12 years. tion B1 according to the RDF implementation of the TMR
F2 Patients with type 2 diabetes should be screened from di- model. Note that lines 23 to 26 describe the TMR extension
agnosis. of pre-conditions as discussed earlier.
G1 Lipid-lowering drug therapy with simvastatin 40 mg
Calculating Interactions
should be considered for primary prevention in patients
with type 1 diabetes aged > 40 years. The system detects interactions for the all the formalised
recommendations, which included all the expected ones but
G2 Patients under 40 years with type 1 or type 2 dia-
another two that were not foreseen. For the list of recom-
betes and other important risk factors, e.g. microalbumin-
mendations of previous section, Table 1 presents a subset
uria, should be considered for primary prevention lipid-
of the detected interactions, without taking into account the
lowering drug therapy with simvastatin 40 mg.
pre-conditions.
We have found issues that make the modeling of recom- The interactions marked with * are the ones expected to
mendations difficult, among them: (i) ambiguity is common be avoided by taking the preconditions into account. For ex-
due to imprecise nature of natural language descriptions, for ample, because B1 and B2 recommend the same action type,
example the use of ‘and’ and ‘or’ often do not correspond to
how it would be formalised using the corresponding logical 4 https://github.com/l0ft3r/SIGN116Model
# DM Guideline
Recommendations Detected interaction
2 :CIG - DB a tmr : Guideline ; * B1–B2 repetition
rdfs : label " CIG for Diabetes Mellitus " @en . B1–B3 contradiction
4 B2–B3 contradiction
# Recommendation B1 C1–C2–C3 alternative
6 : RecDB - ExercB1 a tmr : ClinicalRecommendation ; D1a–D1b–D2 repetition
rdfs : label * F1–F2 repetition
8 " Type 1 should exercise regularly " @en ; * G1–G2 repetition
tmr : partOf :CIG - DB ;
10 tmr : basedOn : CBExercise1 ; Table 1: Recommendations with detected interactions.
tmr : strength " should "ˆˆ xsd : string ;
12 tmr : aboutExecutionOf : ActExercise ;
tmr : hasFilterSituation : PredDM1 .
14 betes type 1 or type 2) or can be calculated when they are
# Causation Belief of a numeric nature (a patient cannot be below and above a
16 : CBExercise1 # named graph with a causation certain age). For the case study presented in this paper, the
{ : CBExercise1 a tmr : CausationBelief ; following knowledge is added:
18 tmr : probability " always "ˆˆ xsd : string ;
tmr : strength " L2 "ˆˆ xsd : string . • not(and(DM1, DM2))
20 : ActExercise • not(and(Age40+, Age40-))
tmr : causes : TrExerciseType1 . }
22 This means the patient cannot be suffering from diabetes
# Situation Pre - condition type 1 and type 2 at the same time, and also cannot be below
24 : PredDM1 a tmr : SituationType , and above 40 years old.
rdfs : label " DM 1" @en . By running the satisfiability checker, we found three un-
26 satisfiable cases, presented in Table 2 together with another
# Transition two satisfiable results out of several. This shows that our
28 : TrExerciseType1 a tmr : TransitionType ; implementation can automatically find the groups of inter-
tmr : promotedBy : ActPerformExercise ;
30 tmr : hasTransformableSituation
actions that can be avoided. In other words we are able to
: SitIncrCardiovRisks ; improve the precision of our interaction detection method
32 tmr : hasExpectedSituation by extending the TMR model with pre-conditions.
: SitRedCardiovRisks .
34 Rec Precondition Sat?
# Situation Types pre and pos state B2 DM1
36 : SitIncrCardiovRisks a tmr : SituationType ; False
B1 DM2
rdfs : label " Cardiov . risk is increased " @en . C1 and(DM2, Overweight)
38 : SitRedCardiovRisks a tmr : SituationType ;
C2 or(not(Overweight),
rdfs : label " Cardiov . risk is reduced " @en . True
40
IntolerantForMetformin,
# Action type ContraindForMetformin)
42 : ActExercise a tmr : CareActionType ; D1a or(Pregnant,
rdfs : label " Perform exercise " @en . WantsToBecomePregnant) True
Listing 3: Excerpt of the TMR-based representation of the D2 or(DM1, DM2)
recommendation B1 F1 and(DM1, Age12+)
False
F2 DM2
namely to perform exercises, the system will detect an inter- G2 and(or(DM1, DM2),
action of type repetition. However, looking into their pre- OtherRiskFactors, Age40-) False
conditions, we can expect this interaction not to occur since G1 and(DM1, Age40+)
the first is applicable for patients with diabetes type 1 and
the second for diabetes type 2. The same happens for other Table 2: A subset of our findings. For each recommendation
two pairs of recommendations, namely F1-F2 and G1-G2. pair that make up an interaction, it details their preconditions
By chance they are all involved in interactions of type repe- and the satisfiability of the conjunction of preconditions.
tition, but it could have been the case for any other type.
Calculating Avoidable Interactions Related Work
In order to re-evaluate the applicability of interactions based Riano and Ortega (Riao and Ortega 2017) have performed a
on the pre-conditions some background knowledge is also literature survey on computer systems that deal with multi-
required. For the moment, we have manually added the re- morbidity. They classify the recent research in this area ac-
quired background knowledge, but we hope such informa- cording to several systems, one of them being a classification
tion can be either extracted from existing medical knowl- system developed Abidi et al. (Abidi 2010) and extended
edge bases or ontologies (e.g. a patient can either have dia- by Jafarpour (Jafarpour and Abidi 2013), where the catego-
rization is based upon the combination point of the differ- and a guideline execution module. The acquisition module
ent guidelines. Five distinct categories are defined: guide- provides a user friendly interface to load a clinical guide-
lines can be combined and then computerized, the comput- line. While the doctor is entering the guideline, it already
erized guidelines can be combined, combination can occur detects many forms of semantic or syntactic inconsistencies
of the individual treatment plans, or during the process of : name and range checking, to ensure standard nomencla-
computerization. Finally the knowledge from guidelines can ture is being used; logical consistency, to ensure that each
be combined based on the stored records of patients that set of alternatives is preceded by a decision and each de-
match the multi-morbid criteria. Riano and Ortega identify cision is preceded by a data query and to prevent circular
the work of Zamborlini et al. as belonging to the category dependencies; and temporal consistency, to ensure the en-
where guidelines are computerized and then combined. The tered guideline is still executable. This process ensures only
extension we describe in this work does not change this cat- high quality guidelines are entered into the system. How-
egorization. ever, these consistency checking apply to a single guideline.
Riano and Ortega also mention the strengths and weak- When multiple guidelines are relevant for a single patient, as
nesses of the used techniques. They identify “reusable is the case for multi-morbid patients, their simultaneous exe-
knowledge, conceptual simplicity, decremental costs” as the cution could lead to conflicts. Furthermore, as preconditions
strengths of transition fitting, the technique used by the TMR in GLARE are stored as plain text, it is not possible to per-
model. Decremental costs in this context means that the form an automated analysis of excluding preconditions for
required effort of adding more guidelines to the system’s the calculation of interactions between recommendations.
knowledge base diminishes with each additional guideline, In (Anselma, Piovesan, and Terenziani 2017), Anselma et
since the concepts shared between guidelines can be reused. al. describe their extensions to the GLARE system as the
The weaknesses are identified as follows: “not completely first to focus on the temporal interactions between actions
automatic, premature, only suitable for short-term treat- guideline actions with the intent to detect conflicts that actu-
ments.” The TMR model is indeed underdevelopment and ally occur, rather than conflicts that might occur when their
its implementation is a proof of concept rather than a fully effects happen to be active simultaneously. They construct
functional system ready to be used by the doctors. It is also a constraint satisfaction problem based on three sources of
not completely automatic in the sense that it does not pro- information: a user-provided log that describes when certain
vide a user with a treatment plan for a specific patient. In- actions have been executed, temporal constraints extracted
deed, this was never part of the design goals of the TMR from the guidelines as they are expressed in GLARE, and
model: it focuses on detection of interactions rather than on information present in their knowledge base. Once solved
conflict resolution. The decision is expected to be taken by using a standard STP constraint propagation network frame-
the medical doctor taking into account the guidelines and work, they interpret the results and provide the user with
the patient. In the future we might consider also the patient “YES,” “NO” or “MAYBE” to indicate whether an interac-
data to identify relevant guideline interactions for a particu- tion occurs. Although their work is a nice contribution to
lar case. conflict detection between clinical guidelines, a user is still
The study from Peleg et al. (Peleg et al. 2003) gives a required to select the recommendations from the guidelines
comparison between five CIG modeling languages: Asbru, for the system to analyze. This means the user needs to be
Eon, GLIF, GUIDE, PRODIGY and Proforma. It asked ex- aware of possible interactions before using the system. In its
perienced modelers of each language to model two guide- turn, the TMR method present these possible interactions to
lines and compared the resulting models syntactically and a user, requiring only a selection of clinical guidelines to an-
semantically. Their aim was to identify common compo- alyze, rather than the actual recommendations. Both studies
nents between the different languages to try and establish use a form of constraint satisfaction programming to sup-
some standards, as well as providing a starting point for dis- port the detection of conflicts. In this paper we use SAT,
cussions on comparing CG modeling languages. They have which is a special kind of constraint satisfaction program-
concluded that there are indeed major components that are ming, but different than the one used in (Anselma, Piovesan,
very similar between the languages. The dimensions that Pe- and Terenziani 2017), which includes time constraints. This
leg et al. (Peleg et al. 2003) took into account were: 1) or- suggests the possibility of combining both works in a simi-
ganization of guideline plan components, 2) specification of lar fashion, i.e. using the initial calculation of interactions to
goals/intentions, 3) model of guideline actions, 4) decision reduce the search space for the satisfiability problem.
models, 5) expression/criterion language used to specify de-
cision criteria, 6) data interpretations/abstractions, 7) repre- Conclusion and Future Work
sentation of a medical concept model and its use, and 8) pa- In our study on guideline interactions in diabetes we ob-
tient information model. However they note that these are served that there are many ambiguous recommendations,
implemented in different ways because of the different goals missing information on the motivation of recommendations
of each language. They find that it is important to allow each and implicit information in the preconditions of the recom-
research group behind a language to pursue their own goals mendations. This indicates that it is very difficult to accu-
rather than try to constrain them by imposing a standard. rately model these recommendations in a formal language,
GLARE (Terenziani, Molino, and Torchio 2001) is an- regardless of which language is chosen. In many cases a
other structured language for describing clinical guidelines. medical expert is required to resolve these issues on a case
It consists of two modules: a guideline acquisition module, by case basis. Another possible solution, but less realistic in
the current guideline development process, would lie in the et al. 2003. Comparing computer-interpretable guide-
migration from a ”paper-based” guideline paradigm (recom- line models: a case-study approach. Journal of the
mendation and evidence are mere texts to be interpreted) to American Medical Informatics Association 10(1):52–
a well supported computerized paradigm that would account 68.
for those problems at the authoring phase, i.e. making sure Riao, D., and Ortega, W. 2017. Computer technologies to
the meaning and purpose of recommendations are clear from integrate medical treatments to manage multimorbidity.
the beginning. Journal of Biomedical Informatics 75:1 – 13.
Overall we were able to model the selected diabetes rec-
ommendations in TMR. The concepts in the TMR model Shahar, Y.; Miksch, S.; and Johnson, P. 1998. The asgaard
match closely with the information present in the recom- project: a task-specific framework for the application
mendations, although there is a need for less strict causal and critiquing of time-oriented clinical guidelines. Ar-
relations, like maybe, possibly and might be that has been tificial intelligence in medicine 14(1):29–51.
addressed conceptually in (Zamborlini et al. 2017a) but not Terenziani, P.; Molino, G.; and Torchio, M. 2001. A modular
yet implemented. approach for representing and executing clinical guide-
The interaction detection algorithm computes all possible lines. Artificial Intelligence in Medicine 23(3):249 –
interactions. With our extension to the TMR model of pre- 276.
conditions, we were able to reduce the number of identified Triska, M. 2016. The boolean constraint solver of swi-
possible interactions. More importantly, the initial calcula- prolog: System description. In FLOPS, volume 9613
tion of interactions are a mean to reduce the search space of LNCS, 45–61.
for the satisfiability problem between preconditions. In our
case-study from 52 interactions to 49 interactions. Further van der Heijden, R. 2017. Modeling a Diabetes Guideline
reduction of interaction would be possible by entering some using the TMR model for interaction detection. Techni-
characteristics of the patient, like has type 1 diabetes, then cal report, Universiteit van Amsterdam. Master Thesis.
many recommendations and, by extension, many interac- Zamborlini, V.; Hoekstra, R.; da Silveira, M.; Pruski, C.; ten
tions can be ruled out. In in (Zamborlini et al. 2017a) we also Teije, A.; and van Harmelen, F. 2014. A conceptual
propose other way to filter out or rank interactions based on model for detecting interactions among medical rec-
some characteristics of the recommendation, action or tran- ommendations in clinical guidelines: A case-study on
sitions involved, e.g. the deontic strength of the recommen- multimorbidity, volume 8876 of Lecture Notes in Com-
dations involved. puter Science. Springer. 591–606.
Finally, an important characteristic of clinical guidelines
Zamborlini, V.; da Silveira, M.; Pruski, C.; ten Teije, A.;
and of systems that implement them is to provide advice
Geleijn, E.; van der Leeden, M.; Stuiver, M.; and van
that addresses the general public, which means it supports
Harmelen, F. 2017a. Analyzing interactions on com-
mainly the majorities, for example, patients that have either
bining multiple clinical guidelines. Artificial Intelli-
diabetes 1 or 2. Although this is an understandable limita-
gence in Medicine.
tion of the ”paper-based” clinical guideline system, we be-
lieve that computer-based systems should allow for support- Zamborlini, V.; Hoekstra, R.; da Silveira, M.; Pruski, C.;
ing also minorities, such as patients that have both diabetes ten Teije, A.; and van Harmelen, F. 2017b. General-
1 and 2. Therefore, as future work the system should be flex- izing the Detection of Clinical Guideline Interactions
ible enough to account for both situations. Enhanced with LOD. In Biomedical Engineering Sys-
tems and Technologies. Springer International Publish-
References ing. 360–386.
Abidi, S. 2010. A Knowledge Management Framework
to Develop, Model, Align and Operationalize Clinical
Pathways to Provide Decision Support for Comorbid
Diseases.
Anselma, L.; Piovesan, L.; and Terenziani, P. 2017. Tem-
poral detection and analysis of guideline interactions.
Artificial Intelligence in Medicine.
Jafarpour, B., and Abidi, S. S. R. 2013. Merging Disease-
Specific Clinical Guidelines to Handle Comorbidities
in a Clinical Decision Support Setting. Berlin, Heidel-
berg: Springer Berlin Heidelberg. 28–32.
Network, S. I. G. 2013. Management of Diabetes. Gyle
Square, 1 South Gyle Crescent Edinburgh EH12 9EB:
Healthcare Improvement Scotland.
Peleg, M.; Tu, S.; Bury, J.; Ciccarese, P.; Fox, J.; Greenes,
R. A.; Hall, R.; Johnson, P. D.; Jones, N.; Kumar, A.;