A General Framework for the Distributed Management of Exceptions

and Comorbidities

Alessio Bottrighi, Luca Piovesan and Paolo Terenziani

DISIT, Computer Science Institute, Universit

a del Piemonte Orientale, Italy

Keywords:

Computer Interpretable Guideline (CIG), Concurrent Execution of Multiple CIGs, CIG-exception Handler,

System Architecture.

Abstract:

In the last decades, many different computer-assisted management systems for Computer Interpretable Guide-

lines (CIGs) have been developed. While CIGs propose a “standard” evidence-based treatments of “typical”

patients, exceptions may arise, as well the need to cope with comorbidities. The treatment of deviation from

“standard” execution has attracted a lot of attention in the recent literature, but the approaches proposed are

focused on the treatment either of exceptions or of comorbities. However, this is a clear limitation, since du-

ring a CIG execution, both these issues can occur. In this paper, we propose the ﬁrst approach which supports

the integrated treatment of both exceptions and comorbidities. To achieve such a goal, we propose a modular

client-server architecture supporting the concurrent execution of multiple guidelines. The architecture propo-

sed has been designed as a further layer building upon “traditional” execution engines for a single CIG. Thus,

our methodology is general and can be used to extend the CIG systems in the literature. Finally, we describe

our approach in action on a case study, in which a comorbid patient is treated for Peptic Ulcer and for deep

Venous Thrombosis and, during the treatment, she manifests a heart failure.

1 INTRODUCTION

Clinical Practice Guidelines (CPGs) represent the cur-

rent understanding of the best clinical practice. CPGs

are gaining a major role to improve the quality and to

reduce the cost of health care. The ICT technology

can further enhance the impact of CPGs. Many dif-

ferent systems have been developed to manage Com-

puter Interpretable clinical practice Guidelines (CIGs

for short). Such approaches are characterized by a

specifc formalism to represent CPGs. CIG forma-

lisms are usually based on a Task Network Model: a

(hierarchical) model of the CPG control ﬂow as a net-

work of speciﬁc tasks. Such formalisms are “formal”

and allow one to unambiguously represent guideline

procedures and recommendations. Besides suppor-

ting formal languages to acquire and represent CPGs,

CIG systems usually also provide execution engines

that allow user physicians to “instantiate” general gui-

delines on speciﬁc patients: by accessing the patient

clinical data, the execution engine shows to the user

physicians only those paths of actions that are ap-

plicable to the patient at hand. In such a way, they

provide patient-oriented recommendations to physici-

ans, allowing them to fulﬁll the gap between the CPG

generality and the speciﬁcity of the patient at hand.

A survey and/or a comparative analysis of these sys-

tems is outside the goals of this paper, but a compari-

son of Asbru, EON, GLIF, Guide, PROforma, PRO-

DIGY can be found in (Peleg et al., 2003). Bottrighi

et al. (Bottrighi et al., 2009) extends it to consider

also GLARE and GPROVE. (Peleg, 2013; Anselma

et al., 2015) are recent surveys of the state-of-the-art.

One of the main goals of CPGs and CIGs is to cap-

ture medical evidence and to put it into practice. Ho-

wever, from one side, evidence is essentially a form

of statistical knowledge, and it is used to capture the

generalities of classes of patients, rather than the pe-

culiarities of a speciﬁc patient. From the other side,

demanding to expert committees the elicitation of all

possible executions of a CPG on any possible speciﬁc

patient in any possible clinical condition is an infea-

sible task. Thus, several conditions are usually impli-

citly assumed by experts building a CPG: (i) ideal pa-

tients, i.e., patients that have only the disease conside-

red in the CPG (thus excluding the concurrent appli-

cation of more than one CIG), and (ii) “statistically re-

levant” patients not presenting rare peculiarities/side-

effects; (iii) ideal context of execution, so that all ne-

cessary resources are available. However, when a spe-

ciﬁc physician applies a given CIG to a speciﬁc pa-

tient, unexpected conditions may show up. Such si-

Bottrighi, A., Piovesan, L. and Terenziani, P.

A General Framework for the Distributed Management of Exceptions and Comorbidities.

DOI: 10.5220/0006552800660076

In Proceedings of the 11th Inter national Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2018) - Volume 5: HEALTHINF, pages 66-76

ISBN: 978-989-758-281-3

tuations are unexpected, and, as such, cannot be spe-

ciﬁed a priory in the CIGs. However, especially in

case of unexpected life threatening problems, the phy-

sician must start soon to cope with the new problems

(possibly suspending or ending the “standard” execu-

tion of the current CIG, or concurrently with it). Such

problems have been usually indicated with the term

“exceptions” within the CIG community, since they

are exceptions with respect to the “standard” execu-

tion of a CIG.

Another challenging problem that might involve

deviations from the “standard” execution of a CIG is

the treatment of comorbid patients. The problem is

that, by deﬁnition, CIGs address speciﬁc clinical ci-

rcumstances (i.e., speciﬁc pathologies), and, unfortu-

nately, in comorbid patients the treatments of single

pathologies may dangerously interact with each ot-

her. Also, the approach of proposing an ad-hoc “com-

bined” CIG to cope with each possible comorbidity

does not scale up (Michalowski et al., 2013). For

these reasons, new methodologies have been recently

introduced to manage multiple CIGs on comorbid pa-

tients (see, e.g., the survey in (Fraccaro et al., 2015)).

1.1 Related Work

Within the CIG community, the “exceptions” and co-

morbidities have been always managed in isolation.

Several frameworks have been already proposed

to cope with “exceptions” (see, e.g. (Fox et al., 1998;

Leonardi et al., 2012; Tu and Musen, 1999; Grando

et al., 2010; Quaglini et al., 2001; Peleg et al., 2009)).

In most of such approaches, the “standard” executor

of a CIG is extended with some mechanism to trig-

ger exceptions (on the basis of the patient’s data) and

to activate their treatment, synchronizing such a treat-

ment with the execution of the current CIG. Different

mechanisms of synchronization have been proposed.

On the other hand, a range of different techni-

cal solutions have been proposed to cope with co-

morbidities, spanning from the use of constraint lo-

gic programming (Michalowski et al., 2013; Wilk

et al., 2017) to answer set programming (Merhej et al.,

2016), from rules (L

opez-Vallverd

u et al., 2013) to

agents (S

anchez-Garz

on et al., 2013). Notably, some

of such approaches focus on the automatic genera-

tion of a unique “merged” CIG avoiding the undesi-

red CIG interactions (consider, e.g. (L

opez-Vallverd

et al., 2013; S

anchez-Garz

on et al., 2013)). In such a

way, a “standard” CIG executor can be used to enact

the “merged” CIG. However, in the clinical practice,

(1) there are usually different ways to manage inte-

ractions, and physicians want and must (for ethical

reasons) be the protagonists of such a decision. And,

more importantly for the current work, (2) though

in clinical practice the interactions between CIGs are

managed, physicians do not look at the solution as a

single “merged” CIG: they still look at the treatment

of a comorbid patient as the concurrent execution of

multiple CIGs.

In conclusion, there are several approaches mana-

ging either “exceptions” or comorbidities, but no one

provides a integrated support of them. This is a ma-

jor and clear limitation to their application in practice,

also given the occurrence frequency of the above phe-

nomena. For instance, several studies demonstrate a

prevalence of comorbidities on an average of 25% of

the population, ranging from 10% (in younger people)

to 78% (in older people) (van den Akker et al., 1998;

Barnett et al., 2012). Thus, we aim at fulﬁlling the

gap between the support provided by the current CIG

systems and real world requirements.

1.2 Goals and Original Contributions

Until now, within the CIG literature, exceptions and

comorbidities have been treated as separate pheno-

mena

, so that current approaches cope either with

exceptions, or with comorbidities. This is a clear li-

mitation of the state of the art, since both phenomena

may co-occur on speciﬁc patients. In this paper, we

ﬁrst propose a CIG approach facing both phenomena,

thus overcoming such a relevant limitation of the cur-

rent literature. Additionally, unlike (L

opez-Vallverd

et al., 2013; S

anchez-Garz

on et al., 2013), we aim at

maintaining the distinction between CIGs, even in the

case of comorbid patients.

Our goal is to propose the ﬁrst general framework

that copes with both exceptions and comorbidities.

The starting point of our approach is that the mana-

gement of patients affected by multiple problems re-

quires

(i) A support for the concurrent and distributed

(i.e., carried on by different agents) execution of

CIGs, and to synchronize them. In the case of

comorbid patients, it will support the execution

of one CIG for each one of the patient’s disea-

ses; in the case of an “exception”, it will support

the execution of the original CIG plus the plan

This choice is, in our opinion, quite surprising, since

there does not seem to be a clear cut between the two pheno-

mena. Just as one prototypical example, in (Leonardi et al.,

2012) heart failure is considered as an “exception” for a pa-

tient treated with a CIG for trauma. But, when a patient with

a trauma manifests a heart failure, s/he becomes a comorbid

patient, and attention must be paid to avoid dangerous inte-

ractions between the treatment (CIG) for the trauma and the

treatment (CIG) for the hearth failure.

A General Framework for the Distributed Management of Exceptions and Comorbidities

(which can be formalized as a CIG) to manage

the exception.

(ii) A support for detecting the possible interacti-

ons between such concurrent CIGs, and for ma-

naging them (avoiding dangerous interactions)

(iii) A support for detecting new patient’s problems

(i.e., changes in the status of the patient that re-

quire new treatments – thus, new CIGs).

In the rest of the paper, we propose the ﬁrst CIG

framework providing all such supports in an integra-

ted way. While (1)-(3) are the main goals of our

approach, we also take into account a further, more

“technical” goal. The specialized literature proposes

several “consolidated” execution engines, to execute a

CIG for a speciﬁc patient. Many of such approaches

(including GLARE and its recent extension META-

GLARE (Terenziani et al., 2014; Bottrighi and Te-

renziani, 2016) have achieved good results, provi-

ding physicians with friendly environments to execute

CIGs. We think that it would really be a pity to waste

such an amount of good work, building from scratch

a new concurrent execution engine. Thus, an addi-

tional main goal of our approach is that of devising

a modular approach for the concurrent execution, in

which the execution engine of a CIG in isolation is

maintained, and it is extended and integrated in a ge-

neral framework supporting synchronization and con-

currency. Notably, although we are building our fra-

mework on top of META-GLARE (in the sense that

each “Exec” module - see Fig.3 below - is an instanti-

ation of META-GLARE execution module), our met-

hodology is general and can be adapted for similar

CIG systems (such as, e.g., (Fox et al., 1998; Shahar

et al., 1998)).

Furthermore, notice that the framework we have

developed also supports the fact that multiple healt-

hcare agents may be involved in the execution of each

single CIG for a speciﬁc patient. We cope with multi-

ple agents using the methodology in (Bottrighi et al.,

2013) and generalizing it to the context of multiple

CIGs. For the sake of brevity, such a topic is no furt-

her discussed within this paper.

Notably, the main contribution of this paper is

the deﬁnition of (the architecture of) a system-

independent framework for the distributed manage-

ment of exceptions and comorbidities. We are cur-

rently implementing a prototype of the framework on

top of META-GLARE and of its module for mana-

ging the interactions (Anselma et al., 2017).

2 A GENERAL VIEW OF THE

BEHAVIOR OF OUR

FRAMEWORK

While the architecture of our framework is proposed

in Section 3, here we informally discuss the basic

data/knowledge sources (ovals in Fig. 1) managed by

our framework, and its general behavior (see Fig. 1).

First, though in the literature (see, e.g., (Fox et al.,

1998; Grando et al., 2010; Leonardi et al., 2012; Pe-

leg et al., 2009; Quaglini et al., 2001; Tu and Musen,

1999)) different types of exceptions have been identi-

ﬁed, for the sake of brevity in this paper we focus only

on the most “common” ones, i.e., on the exceptions

arising because of unexpected changes in the status

of the patient, requiring a (new) treatment (i.e., with

CIG-independent patient-exceptions, in the termino-

logy in (Leonardi et al., 2012)).

Second, it is important to clarify that there is a

main “practical” difference between the management

of exceptions and the one of interactions (e.g., the in-

teractions that may arise between actions of different

CIGs operating on the same patient). Exceptions can-

not be avoided: the status of the patient has already

changed, and an exception arises because of such a

change (i.e., it is triggered by the new status of the

patient). Moreover, of course, the exception must be

managed, usually by starting a new treatment (which,

indeed, may be represented by a CIG) for it.

In our approach, the treatment of exceptions is

modeled by a KB (called “Exception KB”; see

Fig. 1) consisting of triggering rules of the form

hCondition, Managi, where “Condition” indicates a

Boolean condition (called “triggering” conditions) on

the status of the patient, and “Manag” represents the

actions to cope with such a condition (representable

as a new CIG) plus constraints about how such new

actions have to be synchronized with (the execution

of) the current CIG(s). Notably, in our approach, the

“Exception KB” is static, in the sense that the rules

it contains are patient-independent, and are perma-

nently stored.

On the contrary, undesired interactions should be

detected a-priori and avoided (through some manage-

ment operation). META-GLARE, for instance, is pro-

vided with a framework (see the Interaction Analysis

module in Fig. 1; rectangles represent computatio-

nal modules) for (i) supporting physicians in the fo-

cusing on speciﬁc parts of the CIGs

(Piovesan et al.,

CIGs may consist of hundreds of actions and/or alter-

native paths. An extensive check of all interactions could

provide a combinatorial number of cases, most of which

are not interesting for the patient at hand. Physician-driven

focusing is an essential step to avoid an unnecessary com-

HEALTHINF 2018 - 11th International Conference on Health Informatics

Figure 1: Graphical representation of our treatment of exceptions and interactions.

2015), (ii) automatically detecting (based on CIG-

independent ontological knowledge) the interactions

between the focused action (Piovesan et al., 2014), as

well as a suite of management options (derived from

the medical literature) to manage them (e.g., avoiding

them by delaying some actions, or managing them

through local modiﬁcations of the involved CIGs (Pi-

ovesan and Terenziani, 2015); see the Management

Deﬁnition module in Fig. 1). Although the analysis

of interaction should be performed a priori, generally

the management option chosen by physicians has not

to be enacted soon. Indeed, it had to be enacted only if

and when, during the execution of the CIGs, the con-

ditions identifying the onset of the interactions arise

As a consequence, the treatment of interactions may

be modelled by a KB (called “Interaction KB”; see

Fig. 1) containing hCondition, Managi pairs. Howe-

ver, differently from the rules for exceptions discus-

sed above, here:

(i) triggering conditions have as input the status of

execution of the CIGs

(ii) “Manag” indicates the operations to implement

binatorial explosion of the computation and of the number

of the identiﬁed interactions.

As an example, a possible undesired interaction bet-

ween the actions Act1 in CIG

and Act2 in CIG

can be

detected and physician can choose to manage it via the sub-

stitution of Act2 with a set of actions achieving the goal of

Act2, but non-interacting with Act1. However, such a sub-

stitution must be performed only in case the execution of

the two CIGs enforces the execution of both Act1 and Act2

(at times such that their effects may overlap in time). In-

deed, if in CIG

a path of actions not including Act1 has

been selected for execution, there is no need to substitute

Act2.

the management option chosen to cope with an

interaction (e.g., operations to locally modify a

CIG)

The “Interaction KB” is dynamic: the system dyna-

mically add rules into it whenever a new interaction

has been detected and a management for it has been

chosen, and it deletes such rules when they are not

useful any more. Indeed, there would be no reason to

permanently store such rules, since they are speciﬁc

to the execution of a set of CIGs for a speciﬁc patient.

In Fig. 1, we show that a unique manager, the

“Trigger Manager” can uniformly operate on both

types of rules. Fig. 1 also shows that the output of

the execution of an “Exception” rule may be the acti-

vation of a new CIG, while the result of the execution

of an “Interaction” rule may usually be a modiﬁca-

tion of some CIGs. It also shows that, when multiple

CIGs are active, the Interaction Analysis module may

be used to analyse possible interactions, and the Ma-

nagement Deﬁnition module can support the manage-

ment of such interactions. The output of the Manage-

ment Deﬁnition module is a new hCondition, Managi

rule, dynamically stored in the Interaction KB.

While Fig. 1 graphically illustrates the behaviour

of our framework, in Section 3 we discuss the archi-

tecture we have identiﬁed to achieve it, and conside-

ring the fact that the management of exceptions and

interactions may involve forms of synchronizations

between the different CIGs (possible synchronizati-

ons between CIGs have been omitted, for the sake of

clarity, from Fig. 1).

A General Framework for the Distributed Management of Exceptions and Comorbidities

Figure 2: Part of PU and VT original CIGs (above) and the updated version of VT after the managing of the interaction

(below).

2.1 Case Study

In this section, we present a “synthesized” case study,

which has been created with the help of some phy-

sicians of Azienda Ospedaliera “San Giovanni Bat-

tista” in Turin in order to be able to exemplify the

main features of our approach. We consider a comor-

bid patient, who is treated for Peptic Ulcer (PU) and

for deep Venous Thrombosis (VT) and has a heart fai-

lure (i.e., an “exception” arises) during the execution

of these CIGs. The two diseases are managed by two

speciﬁc CIGs (the upper part of Fig. 2 shows simpli-

ﬁed parts of the CIGs). Besides the CIGs, additional

medical knowledge is available, including the trigger

for exceptions. In our example, among them, we con-

sider the exception for heart failure (notably, in this

context, heart failure can be considered an exception:

it is not statistically recurrent in PU and VT, thus its

treatment is not contained into the original CIGs).

In our example, the CIGs for PU and VT are

executed concurrently by two different physicians:

Physician

manages PU, and Physician

manages VT.

We consider a sample working section articulated as

follows.

Step 1. We suppose that Physician

, at a certain point

of execution of PU and VT (e.g., at the beginning),

decides to analyze the possible interactions between

the two CIGs. To do so, Physician

exploits the Inte-

raction Manager module (see Fig. 1) focusing on re-

levant parts of PU and of VT, and the Interaction Ma-

nager module detects an interaction between warfarin

therapy (WT) in VT and amoxicillin therapy (AT) in

PU.

Step 2. Physician

chooses to manage such an inte-

raction replacing the action WT with an alternative

plan, having the same goal. For instance, the new

therapeutic plan may be the combination of acetylsa-

licylic acid (AA) therapy and omeprazole (OT) ther-

apy. As we will see in the Section 4, the Interaction

Manager module creates a trigger rule to implement

such a management (if/when required).

Step 3. Physician

and Physician

go on with the

independent executions of the CIGs. We suppose

that in PU “PU start”, “H.Pylori test”, “HPev” with

exit “positive” has been executed; in the meanwhile,

in VT “VT start”, “intervention decision”, with exit

“pharm”, and “AntiD” with exit “a” has been execu-

ted.

Step 4. At this point, the chosen management of the

interaction is required, and is executed (i.e. the trig-

ger rule created at step 2 above is executed, thus mo-

difying the CIG as shown in the lower part of Fig. 2).

Step 5. The execution continues on the modiﬁed

CIGs.

Step 6. To exemplify all the main features of our ap-

proach, we further suppose that at this point the pa-

tient has a heart failure, and we show how our frame-

work supports its treatment.

HEALTHINF 2018 - 11th International Conference on Health Informatics

3 ARCHITECTURE FOR THE

CONCURRENT EXECUTION

OF MULTIPLE CIGS

3.1 The Architecture

Our approach is based on the client-server model.

This choice is motivated by the need (i) to support a

distributed execution of the patient treatments, since

different CIGs can be managed by different physici-

ans (i.e. each physician needs a client to manage her

CIGs) and (ii) to have a global vision of patient treat-

ments, and to “synchronize” them (such a vision will

be stored and managed in the server). Notably, from

an abstract point of view our approach can be descri-

bed as an agent based system (i.e. each module can

be seen as an agent).

For sake of simplicity, in this paper we assume

that all the CIGs are related to the same patient. The

extension to cope with more than one patient is obvi-

ous. We propose a server model (see Fig. 3) compo-

sed by the following modules:

• a “General Manager” (in the middle of the “Ser-

ver” in Fig.3): it maintains the global vision of

the patient and of her treatments (i.e. global data

structures). It interacts with the other modules to

update such a vision and to synchronize them (the

functionalities of such a module are described in

more detail in subsection 3.2);

• the “Executor Modules”(“Exec CIG1”, “Exec

CIG2”, and “Exec CIG3”, in the left part of the

“Server” in Fig.3; notably, there is one “Exec”

module for each CIG under execution for the pa-

tient). Each Executor manages the execution of a

CIG for a speciﬁc patient (Bottrighi et al., 2015)

(see subsection 3.3);

• the “Interaction Manager” (top right part of the

“Server” in Fig.3): it supports the study of the

interactions between CIGs and deﬁnes how they

should be managed (see subsection 3.4);

• the “Trigger Manager” (bottom right part of the

“Server” in Fig.3): it manages the triggers in KBs

(see subsection 3.5).

Notably, the architecture of our framework is open.

It is possible to add the new modules to provide new

facilities, by specifying their communication API (i.e.

how they communicate with the other modules, the

patient’s DB and the client).

The client provides physicians with a GUI to sup-

port the execution of one or more CIGs (e.g. in Fig. 3

Client

allows to manage the execution of CIG

and

CIG

, while Client

supports the execution of CIG

Each client sends/receives messages to/from the exe-

cutor module to manage the execution of the CIGs.

Moreover, physicians can activate the interaction mo-

dule to study possible interactions between two or

more CIGs (e.g. in Fig. 3, Client

activates it).

3.2 The General Manager Module

The General Manager is the core of the system, since

it supports the concurrent execution of CIGs on a gi-

ven patient. To achieve such a goal, it manages the

interplay between the other modules in the server by

(i) sending/receiving messages, and (ii) maintaining

two data structures to provide a “global vision” of the

execution of the CIGs: (i) the graph of CIG depen-

dencies and (ii) the yellow pages of CIGs. Such data

structures work as a shared memory, where all the

modules have the read permissions, while the General

Manager has also the write permission.

The graph of CIG dependencies has two compo-

nents: nodes and arcs. Each node represents one CIG

under execution (for the given patient). The arcs re-

present the dependencies between such CIGs. An arc

starting from a node A and ending into a node B me-

ans that B must be suspended by the execution of A.

Thus, the graph represents the synchronization bet-

ween CIGs: CIGs without entering arcs are active,

while CIGs reached by an arc are temporarily sus-

pended. We provide a set of primitives to update the

graph: creation/deletion of a node, creation/deletion

of an arc.

The yellow pages of CIGs store all the instances of

CIGs currently in execution. The operations provided

to update the yellow pages are: add a CIG, remove a

CIG, update a pharmacological dosage, update a tem-

poral constraint, add a node to a CIG, add an arc to a

CIG (assuming that CIGs are represented as a Task-

Network Model).

The updates to the data structures are triggered

by messages sent by the other modules in the server.

A message represents a list of instructions expressed

using the primitives described above. The General

Manager manages messages as transactions, i.e. units

of work performed in an atomic way. It performs all

the updates required and then it notiﬁes such upda-

tes to the modules to maintain the synchronization.

The General Manager manages the message of upda-

tes using a FIFO policy.

A General Framework for the Distributed Management of Exceptions and Comorbidities

Figure 3: General Architecture of our framework. The arrows show the ﬂow of information between the different modules.

3.3 The Executor Module

The Executor module manages the execution of a

CIG instance for a speciﬁc patient. In our appro-

ach, there is an instance of Executor for each CIG

under execution. The Executor of a CIG can be

active or suspended depending on the current state

(i.e. active/suspended) of the CIG represented in the

graph of dependencies. Each instance of Executor re-

ads (i) the instance of the CIG that it has to execute

from the yellow pages, and (ii) the patient data from

the Patient DB. The Executor interacts with a speci-

ﬁc client to execute the current actions in the CIG.

In case the CIG is terminated, the Executor sends a

message to the General Manager, to remove the node

(representing the CIG) from the graph, and remove

the CIG from the yellow pages. Speciﬁcally, we use

the executor of META-GLARE (Bottrighi and Teren-

ziani, 2016), but our methodology is mostly system-

independent, and it can be adapted for use any CIG

executor (such as, e.g., (Fox et al., 1998)) or Asbru

(Shahar et al., 1998)).

3.4 The Interaction Manager Module

The Interaction Manager module supports the de-

tection and the deﬁnition of management for CIG in-

teractions. It is composed by two modules (see Fig.

3): the Interaction Analysis and the Management

Deﬁnition. The Interaction Analysis module (see (Pi-

ovesan et al., 2014)) operates in two steps. First,

it provides physicians with a navigation tool (opera-

ting at the different abstraction levels supported by

the given CIGs) supporting the choice of a speciﬁc

part (called “focus”) of the CIGs, the part currently of

interest for the treatment of the current patient. Se-

cond, it provides a knowledge-based tool that auto-

matically detects all the possible interactions between

the actions in the “focus”. Moreover, this module has

been recently extended with a set of facilities to tem-

porally analyze interactions (Anselma et al., 2017),

distinguishing among temporally certain, possible or

impossible interactions and performing hypothetical

reasoning. Once detected an interaction, the Mana-

gement Deﬁnition module (Piovesan and Terenziani,

2015) supports physicians in the selection of a ma-

nagement, choosing among different modalities (i.e.,

the management options (Piovesan and Terenziani,

2015)). Notably, in our approach, managements are

not applied immediately to CIGs, but through the cre-

ation of dynamic trigger rules (see the discussion in

Section 2). The triggers have the form hCondition,

Managi where “Condition” indicates a Boolean con-

dition on the execution of speciﬁc CIG action(s) or

decision result(s), and “Manag” represents the acti-

ons to cope with such a situation. These actions can

be described using a subset of primitives to operate on

the global data structures (see Section 3.2). Such trig-

ger rules are automatically generated by the by a spe-

ciﬁc component of the Management Deﬁnition mo-

dule (the “Trigger Generator”, not detailed in Fig.3

for the sake of brevity and clarity). The “Trigger Ge-

HEALTHINF 2018 - 11th International Conference on Health Informatics

nerator” takes as input from the other modules the de-

tected interacting actions, and the management opti-

ons chosen to manage such an interaction, plus addi-

tional parameters. The Trigger Generator consists of

a set of parametric procedures, one for each manage-

ment option, to automatically generate a trigger, on

the basis of the input parameters. Then, the trigger is

sent as a message to the Trigger Manager.

For instance in Section 4 we show the trigger crea-

ted by the Interaction Manager module to manage the

interaction between WT and AT (see section 2.1).

3.5 The Trigger Manager

The Trigger Manager module manages the triggers.

To achieve such a goal, it has (i) to check whether the

triggers stored in the KBs ﬁre and then to notify that

the management had to be applied and (ii) to maintain

up-to-date the Interaction KB, since it is a dynamic

KB (see details in Section 2).

To cope with (i), the Trigger Manager evaluates

whether a rule in the KBs had be executed. The form

of rules is hCondition, Managi (see Section 2) and the

Trigger Manager checks whether Condition is true or

not (i.e. the patient status retrieved in the Patient DB

or the execution status of the CIGs retrieved in the

yellow pages satisfy Condition). If Condition is true,

the Trigger Manager sends a message to the General

Manager. Such a message contains Manag (i.e. the

set of instructions to cope with the situation described

in Condition).

To cope with (ii), the Trigger Manager adds a

trigger to the Interaction KB, when it receives a mes-

sage from the Interaction Manager module. Each

message contains a trigger that has to be added. The

Trigger Manager manages the messages using a FIFO

policy.

The triggers in the Interaction KB are not perma-

nent, since they are context and patient dependent.

Thus, the Interaction Manager removes a trigger: (i)

when it is used (in the case that it is not reusable,

e.g. in the case it is applied to a repeatable part of

the CIGs, it is removed when the repetitions of such

a part is ended) or (ii) when one of the CIGs in its

Condition ends.

4 OUR SYSTEM IN ACTION:

MANAGING THE CASE STUDY

We describe how our framework works on the case

study described in subsection 2.1. The patient is af-

fected by both Peptic Ulcer (PU) and deep Venous

Thrombosis (VT) and two CIGs are executed to

treat such diseases. Two physicians are involved:

Physician

, managing PU, and Physician

, mana-

ging VT. In our framework, each physician interacts

with the system via a client: (1) Physician

uses

Client

to execute the CIG PU via the executor in-

stance Executor

, and (2) Physician

uses Client

V T

to execute the CIG VT via the executor instance

Executor

V T

. Suppose that both physicians are ma-

naging the ﬁrst action in the CIG (but this is not re-

strictive at all). In such a context, the graph of de-

pendencies contains two independent nodes (one for

PU and one for VT), while the yellow pages contain

the current instances of the CIGs. The Interaction KB

is empty and Exception KB contains the triggers to

manage the exceptions. In our example, among the

others, the trigger TR-HF (i.e. the trigger for heart

failure) is stored in the Exception KB:

TR-HF:

(1) h(Heart Failure = TRUE),

(2) (ADD_NODE HF-PLAN TO GRAPH;

(3) ADD HF-PLAN TO YELLOW PAGES;

(4) ADD_ARC from HF-PLAN to VT;

(5) ADD_ARC from HF-PLAN to PU;)i

In TR-HF, the Condition (line 1) captures that the

patient has a heart failure, the Manag (lines 2-5) des-

cribes the instructions that must be executed to ma-

nage it. In short, (2)-(5) encode the commands to

activate a new CIG “HF-PLAN” suspending the exe-

cution of VT and PU.

To analyze the possible interactions between the

two CIGs, Physician

(through Client

) calls the In-

teraction Manager module and selects the relevant

part of CIGs that the module has to analyse (i.e., the

“focus”). The Interaction Manager identiﬁes all the

interaction between the actions in the “focus” via the

Interaction Analysis module. In this speciﬁc example,

the Interaction Manager module ﬁnds an interaction

between warfarin therapy (WT) and amoxicillin ther-

apy (AT). Such an interaction increases the anticoagu-

lant effect of warfarin and raises the risk of bleedings.

As described in subsection 2.1, Physician

decides to

apply the replanning management option (Piovesan

and Terenziani, 2015), substituting WT with an alter-

native new plan. Such a new plan is automatically

generated by the Management Deﬁnition module (as

described in (Bottrighi et al., 2016)). In our example,

the new therapeutic plan is the combination of ace-

tylsalicylic acid (AA) therapy and omeprazole (OT)

therapy.

Then the Trigger Generator is invoked. It takes

as input the PU and VT CIGs, the management op-

tion chosen by Physician

(i.e., the replanning option)

and the new alternative plan, and (automatically) pro-

duces as output the trigger rule TR-WTAT described

A General Framework for the Distributed Management of Exceptions and Comorbidities

below. The Condition part of TR-WTAT represents

the conditions under which the interaction can occur.

In particular, in our example, AT and WT interacts in

case (line 1): (i) the decision AntiD has been taken,

having as result to execute the path “a” which con-

tains WT, and (ii) either the decision HPev has been

taken with result “positive” (i.e. choosing the path

containing AT), or HPev has not been already exe-

cuted (in this last situation, the system preventively

applies the management, avoiding the cases in which

decision HPev is taken with “positive” result only af-

ter WT has been executed, impeding the application

of the management). Notably, such a condition is au-

tomatically built by the Trigger Generator, through a

navigation throughout the PU and VT CIGs. The Ma-

nag part of TR-WTAT is automatically built by the

Trigger Generator on the basis of the management

option chosen by Physician

and the new alternative

plan. Speciﬁcally, the Manag part of TR-WTAT pres-

cribes to (line 2) remove WT, and (lines 3-4) to add

AA, OT and (lines 5-6) the corresponding arcs in the

CIG VT (the result of the execution of TR-WTAT is

shown in Fig. 2).

TR-WTAT:

(1) h(Exec(AntiD)=a AND (Exec(HPev)=positive

OR NOT Exec(HPev)),

(2) (remove action WT in VT;

(3) ADD_ACTION AA to VT;

(4) ADD_ACTION OT to VT;

(5) ADD_ARC in VT from AntiD to AA;

(6) ADD_ARC in VT from AA to OT;)i

Then, the Interaction Manager module sends a

message containing the TR-WTAT rule to the Trigger

Manager.

As a consequence, the Trigger Manager adds it to

the Interaction KB (see Fig. 2). Then, the two physi-

cians can independently go on with the execution of

the CIGs.

For instance, suppose that Physician

(through

Client

) has executed the actions “PU start”,

“H.Pylori test”, and “HPev”, which results positive; in

the meanwhile, Physician

(through client Client

V T

)

has executed “VT start”, “intervention decision”, with

exit “pharm”, and “AntiD” with exit “a”. This si-

tuation triggers TR-WTAT (i.e. Condition in TR-

WTAT is satisﬁed). Thus, the Trigger Manager sends

a message to the General Manager containing the in-

struction to manage such an interaction (i.e. the Ma-

nag component in TR-WTAT, i.e. lines 2-6) and re-

moves TR-WTAT from the Interaction KB, since it is

not reusable during the patient treatment.

Then, the General Manager executes as a unique

transaction the instructions in the message, updating

the global vision. In our example, the instance of VT

in the yellow pages is updated by replacing WT with

the alternative plan (see lines 2-6 in TR-WTAT), as

shown in the lower part of Fig. 2. Thus, the General

Manager notiﬁes to Executor

V T

that the instance of

VT in the yellow pages has been updated. As conse-

quence, Executor

V T

sends a message to Client

V T

refresh the visualization of VT, and let Physician

on with the execution of the updated CIG.

Moreover, let us suppose that, during the execu-

tion of such CIGs, the patient has a heart failure. As a

consequence TR-HF is triggered by the Trigger Ma-

nager. Then the Trigger Manager sends a message to

General Manager with the instructions to manage the

heart failure (lines 2-5 in TR-HF). The General Ma-

nager executes these instructions. The ﬁrst two in-

structions (lines 2-3 in TR-HF) generate (both in the

graph of CIG dependencies and in the yellow pages

of CIGs) the node corresponding to the CIG to treat

heart failure. As a result of such a generation, our

framework supports the search for a physician accep-

ting the responsibility of executing the new CIG (fol-

lowing the approach in (Bottrighi et al., 2013)), and

generates a new instance of Executor module to ma-

nage the Heart Failure CIG. The selected physician

can manage the execution of the CIG trough a client.

In case s/he is already executing a CIG for the speci-

ﬁc patient, the Heart Failure CIG is added to its client,

otherwise a new client is initialized for her/him. Mo-

reover, the interpretation of lines 4-5 in TR-HF adds

two (suspension) arcs in the graph of CIGs dependen-

cies, then the General Manager notiﬁes the suspen-

sion to Executor

V T

and to Executor

. Consequently,

the two executors notify the suspension to the corre-

sponding clients.

5 CONCLUSIONS

Traditional CIG execution engines provide physicians

with consolidated support for the execution of a sin-

gle CIG on a single patient. However, the treatment of

“exceptions” and of comorbidities demands for more

extended supports. Indeed, the management of such

phenomena requires also a support for the concurrent

execution of multiple CIGs on the same patient. The

approaches proposed in the literature manage either

“exceptions” or comorbidities, and do not provide fa-

cilities to cope with the coordination between such a

concurrent executions, which is an essential issue.

In this paper, we provide the ﬁrst homogene-

ous framework for the management of both “excepti-

ons” and interactions dealing with the concurrent and

coordinate execution of multiple CIGs. Our appro-

ach is modular, in that it adds a further layer buil-

ding upon “traditional” execution engines for a sin-

HEALTHINF 2018 - 11th International Conference on Health Informatics

gle CIG. Though our framework is being built on top

of META-GLARE, our methodology is general, and

can be adapted for similar CIG systems (such as, e.g.,

PROforma (Fox et al., 1998) or Asbru (Shahar et al.,

1998)).

We are currently implementing our approach

using Java (Java-based prototypes of META-GLARE

and its extensions to cope with comorbid patients are

available). As soon as the implementation will be

completed, we plan to develop an extensive experi-

mentation of our framework, especially in the context

of comorbidity treatment. Moreover, we plan to ex-

tend our approach to provide a more comprehensive

support for distributed execution of CIGs to grant tre-

atment continuity, contextualization, and responsibi-

lity assignment and delegation.

ACKNOWLEDGMENTS

This research is original and has a ﬁnancial support of

the Universit

a del Piemonte Orientale.

REFERENCES

Anselma, L., Bottrighi, A., Hommersom, A., Terenziani,

P., and Hunter, A. (2015). Supporting physicians

and patients through recommendation: Guidelines and

beyond. In Hommersom, A. and Lucas, P. J. F., edi-

tors, Foundations of Biomedical Knowledge Repre-

sentation - Methods and Applications, volume 9521 of

Lecture Notes in Computer Science, pages 281–286.

Springer.

Anselma, L., Piovesan, L., and Terenziani, P. (2017). Tem-

poral detection and analysis of guideline interactions.

Artiﬁcial Intelligence in Medicine, 76:40–62.

Barnett, K., Mercer, S. W., Norbury, M., Watt, G., Wyke,

S., and Guthrie, B. (2012). Epidemiology of multi-

morbidity and implications for health care, research,

and medical education: a cross-sectional study. The

Lancet, 380(9836):37–43.

Bottrighi, A., Chesani, F., Mello, P., Montali, M., Montani,

S., Storari, S., and Terenziani, P. (2009). Analysis

of the GLARE and GPROVE Approaches to Clinical

Guidelines. In KR4HC, volume 5943 of Lecture Notes

in Computer Science, pages 76–87. Springer.

Bottrighi, A., Leonardi, G., Piovesan, L., and Terenziani, P.

(2016). Knowledge-Based Support to the Treatment

of Exceptions in Computer Interpretable Clinical Gui-

delines:. International Journal of Knowledge-Based

Organizations, 6(3):1–27.

Bottrighi, A., Molino, G., Montani, S., Terenziani, P., and

Torchio, M. (2013). Supporting a distributed execu-

tion of clinical guidelines. Computer Methods and

Programs in Biomedicine, 112(1):200–210.

Bottrighi, A., Rubrichi, S., and Terenziani, P. (2015).

META-GLARE: A meta-engine for executing com-

puter interpretable guidelines. In Ria

no, D., Lenz,

R., Miksch, S., Peleg, M., Reichert, M., and ten

Teije, A., editors, Knowledge Representation for He-

alth Care - AIME 2015 International Joint Workshop,

KR4HC/ProHealth 2015, Pavia, Italy, June 20, 2015,

Revised Selected Papers, volume 9485 of Lecture No-

tes in Computer Science, pages 37–50. Springer.

Bottrighi, A. and Terenziani, P. (2016). META-GLARE: A

meta-system for deﬁning your own computer interpre-

table guideline system—Architecture and acquisition.

Artiﬁcial Intelligence in Medicine, 72:22–41.

Fox, J., Johns, N., and Rahmanzadeh, A. (1998). Dissemi-

nating medical knowledge: the PROforma approach.

Artiﬁcial Intelligence in Medicine, 14(1-2):157–181.

Fraccaro, P., Arguello Castelerio, M., Ainsworth, J., and

Buchan, I. (2015). Adoption of Clinical Decision Sup-

port in Multimorbidity: A Systematic Review. JMIR

Medical Informatics, 3(1):e4.

Grando, A., Peleg, M., and Glasspool, D. (2010). A goal-

oriented framework for specifying clinical guidelines

and handling medical errors. Journal of Biomedical

Informatics, 43(2):287–299.

Leonardi, G., Bottrighi, A., Galliani, G., Terenziani, P.,

Messina, A., and Corte, F. D. (2012). Exceptions

Handling within GLARE Clinical Guideline Frame-

work. In AMIA.

opez-Vallverd

u, J. A., Ria

no, D., and Collado, A. (2013).

Rule-Based Combination of Comorbid Treatments for

Chronic Diseases Applied to Hypertension, Diabetes

Mellitus and Heart Failure. In Process Support and

Knowledge Representation in Health Care, volume

7738, pages 30–41. Springer Berlin Heidelberg, Ber-

lin, Heidelberg.

Merhej, E., Schockaert, S., McKelvey, T. G., and De Cock,

M. (2016). Generating conﬂict-free treatments for pa-

tients with comorbidity using ASP. In KR4HC 2016,

Lecture Notes in Computer Science, pages 93–100.

Michalowski, M., Wilk, S., Michalowski, W., Lin, D., Fa-

rion, K., and Mohapatra, S. (2013). Using Constraint

Logic Programming to Implement Iterative Actions

and Numerical Measures during Mitigation of Con-

currently Applied Clinical Practice Guidelines. In

Proceedings of AIME, number 7885 in Lecture Notes

in Computer Science, pages 17–22. Springer Berlin

Heidelberg.

Peleg, M. (2013). Computer-interpretable clinical guideli-

nes: A methodological review. Journal of Biomedical

Informatics, 46(4):744–763.

Peleg, M., Somekh, J., and Dori, D. (2009). A methodo-

logy for eliciting and modeling exceptions. Journal of

Biomedical Informatics, 42(4):736–747.

Peleg, M., Tu, S. W., Bury, J., Ciccarese, P., Fox, J.,

Greenes, R. A., Hall, R. W., Johnson, P. D., Jones,

N., Kumar, A., Miksch, S., Quaglini, S., Seyfang, A.,

Shortliffe, E. H., and Stefanelli, M. (2003). Com-

paring Computer-interpretable Guideline Models: A

Case-study Approach. JAMIA, 10(1):52–68.

Piovesan, L., Molino, G., and Terenziani, P. (2014). Sup-

porting Physicians in the Detection of the Interactions

A General Framework for the Distributed Management of Exceptions and Comorbidities

between Treatments of Co-Morbid Patients. In He-

althcare Informatics and Analytics: Emerging Issues

and Trends, pages 165–193. IGI Global.

Piovesan, L., Molino, G., and Terenziani, P. (2015). Suppor-

ting Multi-Level User-Driven Detection of Guideline

Interactions. In Proceedings of the International Con-

ference on Health Informatics (HEALTHINF-2015),

pages 413–422. Scitepress.

Piovesan, L. and Terenziani, P. (2015). A Mixed-Initiative

approach to the conciliation of Clinical Guidelines for

comorbid patients. In KR4HC 2015, volume 9485 of

Lecture Notes in Artiﬁcial Intelligence, pages 95–108.

Springer International Publishing, Pavia.

Quaglini, S., Stefanelli, M., Lanzola, G., Caporusso, V., and

Panzarasa, S. (2001). Flexible guideline-based patient

careﬂow systems. Artiﬁcial Intelligence in Medicine,

22(1):65–80.

Shahar, Y., Miksch, S., and Johnson, P. (1998). The Asgaard

project: a task-speciﬁc framework for the application

and critiquing of time-oriented clinical guidelines. Ar-

tiﬁcial Intelligence in Medicine, 14(1-2):29–51.

anchez-Garz

on, I., Fern

andez-Olivares, J., Onaindia, E.,

Milla, G., Jord

an, J., and Castej

on, P. (2013). A Multi-

agent Planning Approach for the Generation of Per-

sonalized Treatment Plans of Comorbid Patients. In

AIME 2013, pages 23–27.

Terenziani, P., Bottrighi, A., and Rubrichi, S. (2014).

META-GLARE: a meta-system for deﬁning your

own CIG system: Architecture and Acquisition. In

KR4HC, pages 92–107.

Tu, S. W. and Musen, M. A. (1999). A ﬂexible approach to

guideline modeling. Proceedings of the AMIA Sympo-

sium, pages 420–424.

van den Akker, M., Buntinx, F., Metsemakers, J. F., Roos,

S., and Knottnerus, J. A. (1998). Multimorbidity in

general practice: prevalence, incidence, and determi-

nants of co-occurring chronic and recurrent diseases.

Journal of Clinical Epidemiology, 51(5):367–375.

Wilk, S., Michalowski, M., Michalowski, W., Rosu, D.,

Carrier, M., and Kezadri-Hamiaz, M. (2017). Com-

prehensive mitigation framework for concurrent appli-

cation of multiple clinical practice guidelines. Journal

of Biomedical Informatics, 66:52–71.

HEALTHINF 2018 - 11th International Conference on Health Informatics