Inferring recommendation interactions in clinical guidelines 1

Abstract

The formal representation of clinical knowledge is still an open research topic. Classical representation languages for clinical guidelines are used to produce diagnostic and treatment plans. However, they have important limitations, e.g. when looking for ways to re-use, combine, and reason over existing clinical knowledge. These limitations are especially problematic in the context of multimorbidity; patients that suffer from multiple diseases. To overcome these limitations, this paper proposes a model for clinical guidelines (TMR4I) that allows the re-use and combination of knowledge from multiple guidelines. Semantic Web technology is applied to implement the model, allowing us to automatically infer interactions between recommendations, such as recommending the same drug more than once. It relies on an existing Linked Data set, DrugBank, for identifying drug-drug interactions. We evaluate the model by applying it to two realistic case studies on multimorbidity that combine guidelines for two (Duodenal Ulcer and Transient Ischemic Attack) and three diseases (Osteoarthritis, Hypertension and Diabetes) and compare the results with existing methods.

1. Introduction

Information and communication technologies are widely adopted in the clinical domain as Healthcare Information Systems. The primary foci of these systems are data management and visualization. Because of this, there is an increasing amount of patient data that can be used to study disease behavior and the effectiveness of certain treatments. The outcomes of such studies find their way into so-called “reference documents” for clinical practices, promoting the use of evidence-based medicine (EBM). Clinical guidelines (CGs) accumulate and reflect knowledge on how to best diagnose and treat diseases in the form of a list of recommendations. Guidelines have a formal status; they are sanctioned by national and international health care organizations. Relatively recently, the reference documents of EBM have started to be regrouped and published as CGs in their own right: evidence-based guidelines.

In the last decades, Computer Interpretable Guidelines (CIGs) emerged as formal representations of CGs. They can have distinct benefits over paper-based CGs in that they increase flexibility, minimize errors, and generalize the use of guidelines across institutions. CIGs are expressed in dedicated languages such as GLIF [11], Asbru [24] or PROforma [32]. They are mainly designed to promote the execution of guidelines, i.e. to apply them to patient data for supporting diagnostics or treatment plans. Hereafter we refer to CIGs as guidelines and to CGs as paper-based guidelines.

By definition, CGs address specific clinical situations, i.e. situations around a single disease. Following the same principle, guideline languages were defined to represent (and execute) one CG per time. They are not flexible enough to support cases where (parts of) multiple guidelines need to be combined. This is most problematic in the case of multimorbidity; situations where a patient suffers from multiple diseases at the same time. With demographic changes related to aging, and the increase of chronic diseases, multimorbidity is becoming more frequent. A Dutch study shows that not only the number of chronic diseases doubled in twenty years (1985–2005), the proportion of patients with four or more chronic diseases tripled in the same period [33]. Applying CGs for different diseases independently may lead to conflicting situations that can be detrimental to the health condition of the patient. For instance, Aspirin is recommended as anti-platelets to patients diagnosed with Transient Ischemic Attack. On the other hand, Aspirin is not recommended for Duodenal Ulcer patients because it increases the risk of bleeding.

A solution for this problem is considered as an important challenge for clinical decision support systems [31]. Some existing approaches for CIGs are unable to automatically detect conflicts for combinations of guidelines [20,23]. They also cannot propose alternative measures that would resolve the conflicts. Other approaches [34] require all the possible conflicts and their solutions to be available in a knowledge base. In general, the studied approaches do not properly address the combination of more than two guidelines.

In earlier work [38], we introduced the Transition-based Medical Recommendations (TMR) model; a conceptual model that uses the concepts of recommendation, transition, care action type and situation type to represent clinical guidelines in a more flexible and expressive way. We had selected a set of common conflicting situation to evaluate the capability of detecting and solving of several approaches and identify the opportunities to complement them.

The goal of the work presented in this paper is to pave the way towards an automatic identification of common potential conflicts or interactions that can happen when merging guidelines. We address the interactions that can be tackled independently of particular contexts of patients, taking into account the general context described in the guidelines and eventually complemented by Medical Background Knowledge (MBK) (Section 1 paragraph 6). This paper extends TMR to allow for the automatic inference of interactions between recommendations (TMR4I). The model allows us to classify different types of interactions (conflicts, duplicates, repetitions), and show possible alternative solutions. We implement the models using OWL, SWRL and SPARQL, and build a web application that allows for (semi)automatic detection of internal and external interactions between recommendations. This allows us to detect cases that require special attention from experts when two or more guidelines are combined for a multimorbidity patient; and provide suggestions for improvements.

The use of Semantic Web representation languages allows us not only to infer and detect these issues, they also allow us to tap into the enormous amount of relevant clinical information published as Linked Data, e.g. biomedical terminologies, drug databases, symptoms and side effect databases.

We evaluate TMR4I by applying it to two case studies of combined guidelines taken from alternative approaches in the literature [20,23,34]. The first is a merge of two guidelines, one on Duodenal Ulcer (DU) and the other on Transient Ischemic Attack (TIA). The second merges three guidelines on Osteoarthritis (OA), Hypertension (HT) and Diabetes (DB). These use cases also featured in our earlier work [38,40]. We show the added value of our model by comparing it to the existing approaches described in [20,23,34].

The contributions of this paper are:

• A formal representation of TMR4I, an extension of TMR [38] that allows for the detection of interactions between recommendations in multiple clinical guidelines.

• Definition of “guideline-independent” rules for detecting internal and external interactions that allows for a more reusable and scalable approach in the sense of number of interactions that can be semi-automatically detected and number of guidelines that can be combined.

• An implementation of TMR4I using Semantic Web languages (OWL, SWRL, SPARQL) that integrates with external knowledge from the Linked Data cloud (the Linked Data version of DrugBank [21,36]).

• A web application that allows for browsing (combined) guidelines and informs users about inferred interactions between recommendations, the type and source of each interaction, and offers potential solutions.

• An evaluation of the approach for two use cases, that compares the TMR4I model with existing approaches that target the same combination of guidelines [20,23,34].

This paper is structured as follows: Section 2 discusses related work. Section 3 introduces some preliminaries, including the concepts of the TMR model that underly TMR4I. Section 4 presents the TMR4I extension of TMR as a formal model. Section 5 describes our case studies for multimorbidity. Sections 6 and 7 present respectively the implementation and the obtained results. Finally, Section 8 discusses the results and outlines future work and Section 9 summarizes this work.

2. Related work

This section presents works related to Computer-based Representations of Clinical Guidelines in general, and Semantic Web-based ones in particular. Moreover, we present approaches for addressing multimorbidity and clinical knowledge available on the Semantic Web.

2.1. Computer-interpretable clinical guidelines

Several guideline description languages exist that are aimed at representing clinical knowledge: PROforma [32], GLIF [11], Asbru [24], etc. The main focus of these languages is on guideline execution, which makes them highly procedural and targeted to modeling a specific case. They are limited with respect to interoperability (guidelines cannot be combined), semantics (free text is often used to describe conditions and actions) and reasoning power (e.g. the inference of interactions and their solutions is not supported) [18,25].

At the same time clinical decision support systems (CDSS) fall short in assisting healthcare professionals in defining treatment plans for multimorbid patients [12]. There is a “lack of provision of integrated medical guidelines for multiple chronic diseases within current CDSS” [12]. Combined with the inflexibility of existing CIG languages, this indicates the necessity for new, more powerful and flexible formalisms or for adapting existing ones.

2.2. Semantic Web-based guideline representations

Semantic Web technologies have already been investigated for the representation of guidelines. In particular, OWL ontologies were used to enhance the representation of clinical knowledge of guidelines making it more comprehensible for computers. For instance, Pruski et al. [29] focused on the description of care actions usually expressed in natural language to better personalize treatment plans. Peleg et al. [26] proposed to reason with guideline action effects using OWL and abduction. Abidi et al. [10] introduced the COMET (Co-morbidity Ontological Modeling & ExecuTion) system that provides decision support to handle co-morbid chronic heart failure and a trial fibrillation. This framework relies on the capabilities of ontologies to represent guideline content and semantic alignment techniques to merge clinical pathways. The work of Isern et al. [19] stresses the use of ontologies to enable the execution of guidelines tailored to a well-identified clinical environment. In [37], Yao et al. derive SWRL rules from guidelines to dynamically adapt clinical pathways, represented in BPMN, according to clinical activities (contextual data and procedure actions). Hoekstra et al. [16] propose a lightweight ontology for annotating evidence-based clinical guidelines (adopting the W3C PROV and biomedical-related vocabularies), connecting recommendations to underlying evidence, and representing recommendations strength and evidence quality.

Still, these approaches are not designed for addressing multimorbidity. In this work we propose to use the Semantic Web for representing guideline content to enhance the reasoning capabilities of computer systems; allowing a better detection of interactions between guidelines in case of co-morbid patients. Secondly, it facilitates the integration of external knowledge sources expressed in RDF. This allows us to reuse clinical knowledge; thereby, in the end, improving the quality of medical decisions.

2.3. Multimorbidity

In [38], we reviewed existing approaches for merging treatments plans or guidelines and we categorized them into: (i) guideline-level verification, (ii) on-prescription verification, (iii) after-prescription verification and (iv) on-treatment-execution verification. As re-usability is one of our major concerns, in this section we discuss three approaches in the first level [20,23,34].

Constraint logic programming Wilk et al. [34] describe guidelines as an activity graph. They use constraint logic programming (CLP) to identify conflicts that result from applying two CGs to the same patient and propose mitigation alternatives. The temporal aspect is not considered, thus the approach can only be applied to specific situations (e.g. acute diseases diagnosed during a single patient-physician encounter). This approach also considers that all predicates use the same terminology and that they can have only two states (true or false). Although their approach allows the conflicts and solutions to be automatically identified, it relies on the availability of knowledge bases associated with each guideline. It means that both conflicts and solutions need to be previously defined in a Medical Background Knowledge (MBK) as guideline-dependent rules/constraints. Moreover, the solutions proposed to the conflicts are introduced using the same formalism of the original recommendations, which means that their approach would still be applicable to the resultant guideline (merge plus extra recommendations) in order to verify eventual new conflicts. However, they do not perform such verification to the proposed case study. Indeed, a considerable limitation for allowing this feature is that detecting new conflicts would require the introduction of new rules/constraints in the MBK. Finally, automatically retrieving clinical knowledge from existent repositories such as drug-drug and drug-disease interactions, as well as combining more than two guidelines are proposed as future work both in [34,35]. However, to the best of our knowledge these features were not yet addressed.

OntoMorph The OntoMorph approach by Jafarpour [20] defines a set of ontologies to represent: the guidelines (LKO – local knowledge ontology), the general domain (DKO – domain knowledge ontology), the mappings between LKO and DKO (KMO – knowledge mappings ontology), and the decision rules for concurrent execution of LKO, provided by domain experts (KPO – knowledge morphing ontology). The ultimate objective is to define a framework that can be used to merge heterogeneous knowledge from the same domain. However, using several ontologies can potentially rise some extra challenges, like decidability (having rules for all decision cases), maintenance (managing the consequences of changing the ontologies or mappings), and consistency (verifying contradictions between local or domain rules). This situation requires a laborious work from domain experts to map LKO to DKO following a rigorous and unambiguous process (all LKOs must be mapped in the exact same way). These experts are also required to identify all possible interactions between LKOs and to provide the correspondent consistent decision rules as solutions to the conflicts. Although these rules are necessary to generate conflict-free guidelines, they must be general enough to be applied to all combinations of LKOs. Some situations are hardly predictable, for instance, pairwise analysis of recommendations from guidelines will not allow detecting overdose of medication if it comes from the associations of three or more recommendations. Another challenge from this approach comes from the ontology alignment technique. The establishment of semantic relations (mappings) between heterogeneous data can require many complex techniques, for instance, natural language processing techniques would be necessary if textual information are provided describe concepts of the LKO (e.g. in one LKO there are the blood pressure “higvalue:120”, “lowvalue:80” and “unity:mmHg”, while in the other LKO there is “value: 120/80mmHg”).

Jafarpour uses OWL and SWRL to represent and merge the guidelines. The latter defines Constraints (rules) as entities that relates pairs of interacting Tasks (actions). These manually created rules are supposed to address cases where tasks (a) are identical, (b) should be executed simultaneously, (c) are conflicting, (d) can reuse each other’s results, (e) have a temporal or sequential constraint between them, (f) can be combined to a new task and (g) their execution schedule depends on operational constraints for their simultaneous execution.

Rule-based combinations Lopez-Vallverdu et al. [23] focus on Rules and Actions concerned with the administration of drugs. They use a standard terminology called ATC (Anatomical Therapeutic Chemical Classification System for drugs2

²

http://www.whocc.no/atc/.

). Based on knowledge available in clinical guidelines, they manually built “knowledge units” for pairwise combination of three diseases: Hypertension, Diabetes Mellitus and Heart Failure. Knowledge units can be about the co-existence of incompatible drugs (drug-drug interaction), the existence of a drug incompatible to a disease (drug-disease interaction) and the absence of a drug necessary for a combination of diseases. Based on these units, they manually built a minimal set of combination rules in the format pre-condition : condition → action. The pre-condition is a disease, the condition is the presence or absence of drug recommendations for each disease, and the action holds recommendations for adding, removing or replacing drugs. Although it is not clear from the knowledge format whether it is limited to two diseases, the strategy adopted by the authors for addressing the three aforementioned diseases is by pairwise combining them. Moreover, the manual identification of the interactions and their solutions is in itself a limiting factor for combining multiple guidelines. Their approach is implemented in a proprietary system for combining treatments.

In summary, these approaches are not sufficient to meet the objective of increasing the ability to handle multimorbidity, since they have important limitations such as manual definition of guideline-dependent rules/constraints for pairwise detecting conflicts. Therefore, we pursue an approach that allows us to evaluate a set of recommendations, originating from multiple guidelines, inferring and identifying the types of interactions amongst them; with minimal human interaction. In this context, the reuse of existing medical sources such as available in Linked Data is very attractive.

2.4. Ontologies and Linked Data

Since one of the long term goals of our work is to provide means to completely describe care actions in a computer-interpretable formalism, a primary problem to be considered is how to assure the normalization of the terminologies used to describe the actions and conditions. If a wide use of formalized care actions is expected, then their description need to be based on standard terminologies with an explicit semantic behind. Several standard terminologies exist (e.g. SNOMED-CT,3

³

http://www.ihtsdo.org/snomed-ct.

ATC, etc.) which can be used to describe care actions and conditions. In our approach, we assume that instances of the TMR model will be created based on existing standard terminologies or, when necessary, based on other publicly available Ontologies from the biomedical domain. For instance, one of the ∼390 ontologies (∼5 millions classes) published in BioPortal [6] or accessible via EHTOP [13]. Another assumption of our approach is that care action descriptions refer to the source of information that generates the related evidence. For instance, one transition can be associated to evidence from clinical trials (e.g. those published in [7]) which details the conditions where it was observed. The potential of Semantic Web technologies for making clinical guidelines and protocols more flexible is also recognised in [30]. Since a lot of life science information is available as Linked Data, it becomes an important resource for improving the quality of information generated by clinical decision support systems. According to Mannheim Linked Data Catalog [1] there are 85 datasets built based on Semantic Web technologies that can be used to provide large networks of Linked Data for the Life Science domain. Some platforms were created to regroup datasets and provide an unified way to query across resources using the W3C SPARQL query language (e.g. Bio2RDF [8] with more that ∼11 Billion RDF triples available and EBI-RDF [22]). In this work we selected one dataset relevant to evaluate the proposed approach: DrugBank [2,21,36] (∼3 milions RDF triples), but our approach is generic enough to use more datasets (e.g. Drugbank + Sider [5] (∼17 millions RDF triples), Clinical trials [4] (+25 milions RDF triples), Diseasome [3] (+9K RDF triples), etc.).

Fig. 1.

UML class diagram for the TMR Model.

3. Overview of the TMR model

This section briefly summarizes a slightly extended version of the TMR model, originally presented in [38] where we investigated the core concepts required for representing recommendations within CGs. Figure 1 shows a UML diagram of the TMR model. The concepts and relations presented as they were in the original version are depicted in gray shade to differ from the new concepts and relations changed or introduced in this work. Those that have a slash sign before their names are further defined by FOL (First Order Logics) formulas (e.g. /similarTo). We consider the concepts as being atomic, since its compositionality is out of scope of this work.

• A Guideline is an aggregation of Recommendations, whilst the latter is part of one Guideline. It can be a Single Disease Guideline, or it can be a Composed Guideline, which is derived from the combination of two or more Guidelines.

• A Recommendation either recommends to pursue or recommends to avoid (originally recommends and non-recommends) one Transition.

• A Transition is promoted by a single Care Action Type, which in turn can promote one or more Transitions. A Transition can be similar to or inverse to another one (definition is further provided).

• Situation Types can be Pre or Post-Situation Types in the context of different Transitions.

• Every Transition have:

For example, Table 1 presents the recommendation “If the patient’s temperature is over 37 degrees and he/she is over 10 years old then reduce the temperature by administering aspirin” decomposed into the TMR concepts.

Table 1

TMR Concepts Summary

Situation Type	Represents a property and its admissible values
Transformable Situation Type	Regards the situation that is expected to be changed	Patient’s temperature is over 37 degrees
Non-Transformable Situation Type	Regards the situation that holds as filter condition	Patient’s age is over 10 years old
Post-Situation Type	Regards the situation that is expected to be achieved	Patient’s temperature is below 37 degrees
Care Action Type	Represents the action types that can be performed by health care agents in order to change a situation	Administer aspirin
Transition	Represents the possibility of changing a situation regarding a patient by performing a care action type	Administering aspirin in patient over 10 years old reduces its temperature below 37 degrees
Recommendation	Represents a suggestion to either pursue or avoid a transition promoted by a care action type

We introduce the binary relations /similarTo and /inverseTo between Transitions, which are required for detecting Interactions. In this work we consider a simple approach of comparing equality among Pre and Post-Situation Types, though these definitions would benefit from a richer definition of Situation Types and possible matches among them. Therefore, similar transitions (def. 1.1) are those whose Pre-Situation Types are the same, as well as the Post-Situation Types, but that are promoted by different Care Action Types (otherwise they are the same transition). Two transitions are inverse (def. 2.1) if the Pre-Situation Type of one is equal to the Post-Situation Type of the other. Both relations similarTo and inverseTo are symmetric (def. 1.2 and 2.2).

1. $\forall \mathit{t}1\mathrm{,}\mathit{t}2\mathrm{,}\mathit{s}\mathit{a}\mathrm{,}\mathit{s}\mathit{b}\mathrm{,}\mathit{c}\mathit{a}1\mathrm{,}\mathit{c}\mathit{a}2\mathrm{(}\text{Transition(t1) }\wedge \text{Transition(t2) }\wedge \text{CareActionType(ca1) }\wedge \text{CareActionType(ca2) }\wedge \text{promotedBy(t1,ca1) }\wedge \text{promotedBy(t2,ca2) }\wedge \mathbf{\text{ca1}}\ne \mathbf{\text{ca2 }}\wedge \text{SituationType(sa) }\wedge \text{SituationType(sb) }\wedge \text{hasTransformableSituation(t1,sa) }\wedge \text{hasTransformableSituation(t2,sa) }\wedge \text{hasExpectedSituation(t1,sb) }\wedge \text{hasExpectedSituation(t2,sb) }\mathrm{)}\leftrightarrow \mathbf{\text{similarTo(t1,t2) }}$

2. $\forall \mathit{t}1\mathrm{,}\mathit{t}2\text{similarTo(t1,t2) }\leftrightarrow \text{similarTo(t2,t1) }$

3. $\forall \mathit{t}1\mathrm{,}\mathit{t}2\mathrm{,}\mathit{s}\mathit{a}\mathrm{,}\mathit{s}\mathit{b}\mathrm{(}\text{Transition(t1) }\wedge \text{Transition(t2) }\wedge \text{SituationType(sa) }\wedge \text{SituationType(sb) }\wedge \text{hasTransformableSituation(t1,sa) }\wedge \text{hasTransformableSituation(t2,sb) }\wedge \text{hasExpectedSituation(t1,sb) }\wedge \text{hasExpectedSituation(t2,sa) }\mathrm{)}\leftrightarrow \mathbf{\text{inverseTo(t1,t2) }}$

4. $\forall \mathit{t}1\mathrm{,}\mathit{t}2\text{inverseTo(t1,t2) }\leftrightarrow \text{inverseTo(t2,t1) }$

In [38] we illustrated the applicability of TMR by describing the possible interactions among recommendations. These interactions can be contradictory, optimizable or reflect alternative recommendations (redefined in Section 4). We advocated that the TMR concepts favor the detection of such interactions, which may require some attention from experts when combining CGs due to comorbidity. Moreover, we considered not all interactions are unwelcome (e.g. the recommendations to inverse transitions may be desirable and the alternative ones are useful to avoid conflicts) although they could still require attention (e.g. defining which alternative recommendation is preferred). In the following section we extend the TMR model for the specific task of representing and detecting interactions among recommendations.

4. The TMR4I model

The TMR4I (Transition-based Medical Recommendations for [detecting] Interactions) model is meant for detecting interactions among recommendations when addressing multimorbidity. In this case more than one disease, originally addressed in different guidelines, need to be taken into account. Therefore, the recommendations combined from the different guidelines may interact, e.g. presenting inconsistencies or being susceptible to optimization. The main concept in TMR4I is the interaction, which can be internal, among the recommendations themselves, or with some external knowledge base holding e.g. clinical knowledge (e.g. overdose). In Section 4.1 we focus on the internal interactions whilst the external ones are addressed in Section 4.2. Moreover, since the temporal/sequence aspects are still not addressed in this work, the interactions here defined are considered either time-independent or simultaneous.

Fig. 2.

Instance-schema for illustrating interactions among recommendations.

4.1. Internal interactions

Table 2

Interactions Summary

Contradiction Interactions	Two recommendations that would lead to a conflict if recommended together (i.e. they cannot be both followed at the same time)
Opposed recommendations to the same care action	– Do not administer aspirin to avoid increasing the risk of gastrointestinal bleeding– Administer aspirin to handle inflammation
Opposed recommendations to similar transitions	– Do not adm. beta-blockers to avoid lowering blood pressure – Administer ACE inhibitor to lower blood pressure
Recommendations to inverse transitions	– Administer ACE inhibitor to lower blood pressure – Administer midodrine to increase blood pressure
Repetition Interactions	Set of recommendations that are susceptible to optimization
Repeated recommendations to the same care action	– Administer aspirin to reduce the risk of thrombus– Administer aspirin to relief pain– Administer aspirin to handle inflammation
Alternative Interactions	Set of recommendations that hold as alternatives.
Repeated recommendations to the similar transitions promoted by different care action	– Administer aspirin to handle inflammation – Administer ibuprofen to handle inflammation – Administer naproxen to handle inflammation
Non-recommended transition whose inverse transition is recommended	– Do not administer aspirin to avoid increasing the risk of gastrointestinal bleeding – Adm PPI to decrease risk of gastrointestinal bleeding

Fig. 3.

UML class diagram for the TMR4I Model – Internal Interactions.

Figure 2 illustrates in a graphical notation the TMR4I representation for the examples discussed in Table 2. Arrows connecting Recommendations (on the left hand side) to Transitions (on the right hand side) mean that the former recommends the latter to be pursued or avoided. The blue arrow labeled “do” means the transition is to be pursued, while the red one labeled “do not” means the opposite. Each transition regards a property (e.g. gastrointestinal bleeding) and the pre and post situations are presented as small boxes connected by an arrow, where the box in the left hand side is the transformable pre-situation and the other one is the expected post-situation. If there is a dotted box in the left hand side, it represents a filter condition (non-transformable situation). Finally, a dotted ellipse on the arrow represents the care action type that could promote the transition. We depict the interactions named by their three main types (Repetition, Contradiction and Alternative) connecting the interacting recommendations. For example, the third interaction (from top to bottom) is a Repetition Interaction among three recommendations for different Transitions promoted by Administer Aspirin.

Figure 3 presents an UML class diagram for the TMR4I model. Elements presented in a gray-shade mean they were previously introduced. The concept Recommendation is specialized into /Internally Interacting Recommendation (def. 3) to denote the ones that internally interacts with other recommendations.

1. $\forall \mathit{r}\mathrm{,}\exists \mathit{i}\mathrm{(}\text{Recommendation(r) }\wedge \text{InternalRecommendationInteraction(i) }\wedge \text{relates(i,r) }\mathrm{)}\leftrightarrow \mathbf{\text{InternallyInteractingRecommendation(r) }}$

The interaction relation is reified as /Internal Recommendation Interaction and /relates two or more Recommendations in the context of a Guideline. The latter concept is specialized according to the classifications discussed in Table 2. They are further described and defined according FOL rules (def. 4 to 9). In particular some interaction types need an extra rule to capture their cumulative behaviour. For example, recommending 4 times Administer Aspirin for different purposes should not be considered as 6 different interactions between each pair of recommendations, but one interaction among 4 recommendations.

Repetition due to Same Action: when Transitions promoted by a same Care Action Type are recommended to be pursued (def. 4.1). This interaction is cumulative within a (merged) guideline, i.e. if a recommendation is related to two interactions of this type, they are the same interaction (def. 4.2)

1. $\forall \mathit{g}\mathrm{,}\mathit{r}1\mathrm{,}\mathit{r}2\mathrm{,}\mathit{t}1\mathrm{,}\mathit{t}2\mathrm{,}\mathit{c}\mathit{a}\mathrm{(}\text{Guideline(g) }\wedge \text{Recommendation(r1) }\wedge \text{Recommendation(r2) }\wedge \text{partOf(r1,g) }\wedge \text{partOf(r2,g) }\wedge \text{Transition(t1) }\wedge \text{Transition(t2) }\wedge \mathbf{\text{r1}}\ne \mathbf{\text{r2 }}\wedge \mathbf{\text{recommendsToPursue(r1,t1) }}\wedge \mathbf{\text{recommendsToPursue(r2,t2) }}\wedge \mathbf{\text{CareActionType(ca) }}\wedge \mathbf{\text{promotedBy(t1,ca) }}\wedge \mathbf{\text{promotedBy(t2,ca) }}\mathrm{)}\to \exists \mathit{i}\mathrm{(}\mathbf{\text{RepetitionDueToSameAction(i) }}\wedge \text{relates(i,r1) }\wedge \text{relates(i,r2) }\mathrm{)}$

2. $\forall \mathit{i}1\mathrm{,}\mathit{i}2\mathrm{,}\mathit{r}1\mathrm{,}\mathit{r}2\mathrm{,}\mathit{r}3\mathrm{(}\mathbf{\text{RepetitionDueToSameAction(i1) }}\wedge \mathbf{\text{RepetitionDueToSameAction(i2) }}\wedge \text{Recommendation(r1) }\wedge \text{Recommendation(r2) }\wedge \text{Recommendation(r3) }\wedge \text{r1}\ne \text{r3}\wedge \text{r1}\ne \text{r2}\wedge \text{r2}\ne \text{r3}\wedge \text{relates(i1,r1) }\wedge \text{relates(i1,r2) }\wedge \text{relates(i2,r2) }\wedge \text{relates(i2,r3) }\mathrm{)}\to \mathbf{\text{i1 = i2 }}$

Contradiction Interaction due to Inverse Transitions: when two inverse Transitions are (simultaneously) recommended to be pursued (def. 5);

1. $\forall \mathit{g}\mathrm{,}\mathit{r}1\mathrm{,}\mathit{r}2\mathrm{,}\mathit{t}1\mathrm{,}\mathit{t}2\mathrm{(}\text{Guideline(g) }\wedge \text{Recommendation(r1) }\wedge \text{Recommendation(r2) }\wedge \text{partOf(r1,g) }\wedge \text{partOf(r2,g) }\wedge \text{Transition(t1) }\wedge \mathbf{\text{recommendstoPursue(r1,t1) }}\wedge \text{Transition(t2) }\wedge \mathbf{\text{recommendstoPursue(r2,t2) }}\wedge \mathbf{\text{inverseTo(t1, t2) }}\mathrm{)}\to \exists \mathit{i}\mathrm{(}\mathbf{\text{ContradictionDueToInverseTransition(i) }}\wedge \text{relates(i,r1) }\wedge \text{relates(i,r2) }\mathrm{)}$

Contradiction Interaction due to Same Action: when two Transitions promoted by the same Care Actions Type are recommended to be pursued and the other recommended to be avoided (def. 6);

1. $\forall \mathit{g}\mathrm{,}\mathit{r}1\mathrm{,}\mathit{r}2\mathrm{,}\mathit{t}1\mathrm{,}\mathit{t}2\mathrm{,}\mathit{c}\mathit{a}\mathrm{(}\text{Guideline(g) }\wedge \text{Recommendation(r1) }\wedge \text{Recommendation(r2) }\wedge \text{partOf(r1,g) }\wedge \text{partOf(r2,g) }\wedge \mathbf{\text{r1}}\ne \mathbf{\text{r2}}\wedge \text{Transition(t1) }\wedge \text{Transition(t2) }\wedge \mathbf{\text{recommendsToPursue(r1,t1) }}\wedge \mathbf{\text{promotedBy(t1,ca) }}\wedge \mathbf{\text{recommendsToAvoid(r2,t2) }}\wedge \mathbf{\text{promotedBy(t2,ca) }}\wedge \mathbf{\text{CareActionType(ca) }}\mathrm{)}\to \exists \mathit{i}\mathrm{(}\mathbf{\text{ContradictionDueToSameAction(i) }}\wedge \text{relates(i,r1) }\wedge \text{relates(i,r2) }\mathrm{)}$

Contradiction Interaction due to similar Transitions: when two similar Transitions are one recommended to be pursued and the other recommended to be avoided (def. 7);

1. $\forall \mathit{g}\mathrm{,}\mathit{r}1\mathrm{,}\mathit{r}2\mathrm{,}\mathit{t}1\mathrm{,}\mathit{t}2\mathrm{(}\text{Guideline(g) }\wedge \text{Recommendation(r1) }\wedge \text{Recommendation(r2) }\wedge \text{partOf(r1,g) }\wedge \text{partOf(r2,g) }\wedge \text{Transition(t1) }\wedge \text{Transition(t2) }\wedge \mathbf{\text{similarTo(t1, t2) }}\wedge \mathbf{\text{recommendsToPursue(r1,t1) }}\wedge \mathbf{\text{recommendsToAvoid(r2,t2) }}\mathrm{)}\to \exists \mathit{i}\mathrm{(}\mathbf{\text{ContradictionDueToSimilarTransition(i) }}\wedge \text{relates(i,r1) }\wedge \text{relates(i,r2) }\mathrm{)}$

Alternative Interaction due to similar Transitions: when similar Transitions are recommended to be pursued (def. 8.1). This interaction is cumulative within a (merged) guideline, i.e. if a recommendation is related to two interactions of this type, they are the same interaction (def. 8.2)

1. $\forall \mathit{g}\mathrm{,}\mathit{r}1\mathrm{,}\mathit{r}2\mathrm{,}\mathit{t}1\mathrm{,}\mathit{t}2\mathrm{(}\text{Guideline(g) }\wedge \text{Recommendation(r1) }\wedge \text{Recommendation(r2) }\wedge \text{partOf(r1,g) }\wedge \text{partOf(r2,g) }\wedge \text{Transition(t1) }\wedge \text{Transition(t2) }\wedge \mathbf{\text{similarTo(t1, t2) }}\wedge \mathbf{\text{recommendsToPursue(r1,t1) }}\wedge \mathbf{\text{recommendsToPursue(r2,t2) }}\mathrm{)}\to \exists \mathit{i}\mathrm{(}\mathbf{\text{AlternativeDueToSimilarTransition(i) }}\wedge \text{relates(i,r1) }\wedge \text{relates(i,r2) }\mathrm{)}$

2. $\forall \mathit{i}1\mathrm{,}\mathit{i}2\mathrm{,}\mathit{r}1\mathrm{,}\mathit{r}2\mathrm{,}\mathit{r}3\mathrm{(}\mathbf{\text{AlternativeDueToSimilarTransition(i1) }}\wedge \mathbf{\text{AlternativeDueToSimilarTransition(i2) }}\wedge \text{Recommendation(r1) }\wedge \text{Recommendation(r2) }\wedge \text{Recommendation(r3) }\wedge \text{r1}\ne \text{r3}\wedge \text{r1}\ne \text{r2}\wedge \text{r2}\ne \text{r3}\wedge \text{relates(i1,r1) }\wedge \text{relates(i1,r2) }\wedge \text{relates(i2,r2) }\wedge \text{relates(i2,r3) }\mathrm{)}\to \mathbf{\text{i1 = i2 }}$

Alternative Interaction due to Inverse Transition: when two inverse Transitions are one recommended to be pursued and the other recommended to be avoided (def. 9);

1. $\forall \mathit{g}\mathrm{,}\mathit{r}1\mathrm{,}\mathit{r}2\mathrm{,}\mathit{t}1\mathrm{,}\mathit{t}2\mathrm{(}\text{Guideline(g) }\wedge \text{Recommendation(r1) }\wedge \text{Recommendation(r2) }\wedge \text{partOf(r1,g) }\wedge \text{partOf(r2,g) }\wedge \text{Transition(t1) }\wedge \text{Transition(t2) }\wedge \mathbf{\text{inverseTo(t1, t2) }}\wedge \mathbf{\text{recommendsToPursue(r1,t1) }}\wedge \mathbf{\text{recommendsToAvoid(r2,t2) }}\mathrm{)}\to \exists \mathit{i}\mathrm{(}\mathbf{\text{AlternativeDueToInverseTransition(i) }}\wedge \text{relates(i,r1) }\wedge \text{relates(i,r2) }\mathrm{)}$

4.2. External interactions

In this paper we address two types of External Interactions based on the following information about Drug (types): (i) drugs that are known to be incompatible to each other (e.g. Aspirin is incompatible with Ibuprofen) and (ii) drug (types) that are grouped in a broader type/category according to the effects they are expected to promote (Aspirin and Tramadol (types) are grouped/subssumed by Anti-platelets Type/Category).

Fig. 4.

UML class diagram for the TMR4I Model – External Interactions.

Figure 4 presents an UML class diagram for the fragment of TMR4I model regarding External Interactions. Elements presented in a gray-shade mean they were previously introduced. The concept Recommendation is specialized into /Externally Interacting Recommendation (def. 10) to denote the ones that interacts with external information and/or other recommendations.

1. $\forall \mathit{r}\mathrm{,}\exists \mathit{i}\mathrm{(}\text{Recommendation(r) }\wedge \text{ExternalRecommendationInteraction(i) }\wedge \text{relates(i,r) }\mathrm{)}\leftrightarrow \mathbf{\text{ExternallyInteractingRecommendation(r) }}$

The external interaction relation is reified as /External Recommendation Interaction and /relates one or more Recommendations of a Guideline with External Information. The two types of external interaction aforementioned are represented as Incompatible Drug Interaction and Alternative Drug Interaction. They are further described and defined according FOL rules (def. 11 and 12). Finally a Transition or a Care Action Type may regard an External Information. In particular A care action type may involve an External Drug Type (e.g. Administer Aspirin involves Aspirin) and a Transition may regard an External Drug Type (e.g. Reduce Pain regards Painkiller).

Incompatible Drug Interaction: when two recommended (to be pursued) actions are associated with external information about incompatible drugs (def. 11);

1. $\forall \mathit{g}\mathrm{,}\mathit{r}1\mathrm{,}\mathit{r}2\mathrm{,}\mathit{t}1\mathrm{,}\mathit{t}2\mathrm{,}\mathit{c}\mathit{a}1\mathrm{,}\mathit{c}\mathit{a}2\mathrm{,}\mathit{d}1\mathrm{,}\mathit{d}2\mathrm{(}\text{Guideline(g) }\wedge \text{Recommendation(r1) }\wedge \text{Recommendation(r2) }\wedge \text{partOf(r1,g) }\wedge \text{partOf(r2,g) }\wedge \text{r1}\ne \text{r2}\wedge \text{Transition(t1) }\wedge \mathbf{\text{recommendsToPursue(r1,t1) }}\wedge \text{Transition(t2) }\wedge \mathbf{\text{recommendsToPursue(r2,t2) }}\wedge \text{CareActionType(ca1) }\wedge \text{CareActionType(ca2) }\wedge \text{promotedBy(t1, ca1) }\wedge \text{promotedBy(t2, ca2) }\wedge \text{ExternalDrugType(d1) }\wedge \text{ExternalDrugType(d2) }\wedge \mathbf{\text{regards(ca1, d1) }}\wedge \mathbf{\text{regards(ca2, d2}}\text{) }\wedge \mathbf{\text{incompatibleWith(d1, d2) }}\mathrm{)}\to \exists \mathit{i}\mathrm{(}\mathbf{\text{IncompatibleDrugInteraction(i) }}\wedge \text{relates(i,r1) }\wedge \text{relates(i,r2) }\wedge \text{relates(i,d1) }\wedge \text{relates(i,d2) }\mathrm{)}$

Alternative Drug Interaction: when a recommendation for administering a drug have a contradictory or a incompatible-drug interaction, and the transition is associated with external information about the drug category corresponding to the expected effect of the action, then other drugs belonging to the same drug category can be suggested as alternatives, once they are not incompatible with other recommended drugs (def. 12);

1. $\forall \mathit{g}\mathrm{,}\mathit{r}1\mathrm{,}\mathit{i}1\mathrm{,}\mathit{t}1\mathrm{,}\mathit{c}\mathit{a}1\mathrm{,}\mathit{d}1\mathrm{,}\mathit{d}\mathit{c}\mathrm{,}\mathit{d}-\mathit{alt}\mathrm{(}\text{Guideline(g) }\wedge \text{Recommendation(r1) }\wedge \text{partOf(r1,g) }\wedge \text{relates(i1,r1) }\wedge \text{(ContradictionDueToSameAction(i1)}\vee \text{ContradictionDueToSimiliarTransition(i1) }\vee \text{ContradictionDueToInverseTransition(i1) }\vee \text{IncompatibleDrugInteraction(i1))}\wedge \text{Transition(t1) }\wedge \mathbf{\text{recommendsToPursue(r1,t1) }}\wedge \text{CareActionType(ca1) }\wedge \text{promotedBy(t1,ca1) }\wedge \text{ExternalDrugType(d1) }\wedge \text{regards(ca1,d1) }\wedge \mathbf{\text{ExternalDrugType(dc) }}\wedge \mathbf{\text{regards(t1,dc) }}\wedge \mathbf{\text{subssumes(dc,d-alt) }}\wedge \neg \exists \mathit{r}2\mathrm{,}\mathit{t}2\mathrm{,}\mathit{c}\mathit{a}2\mathrm{,}\mathit{d}2\mathrm{(}\text{Recommendation(r2) }\wedge \text{partOf(r2,g) }\wedge \text{Transition(t2) }\wedge \text{recommendsToPursue(r2,t2) }\wedge \text{CareActionType(ca2) }\wedge \text{promotedBy(t2,ca2) }\wedge \text{ExternalDrugType(d2) }\wedge \text{regards(ca2,d2) }\wedge \text{incompatibleWith(d2,d-alt) }\mathrm{)}\mathrm{)}\to \exists \mathit{i}\mathrm{(}\mathbf{\text{AlternativeDrugInteraction(i) }}\wedge \text{relates(i,r1) }\wedge \text{relates(i,ca1)}\wedge \text{relates(i,d1)}\wedge \text{relates(i,d-alt) )}$

2. $\forall \mathit{i}1\mathrm{,}\mathit{i}2\mathrm{,}\mathit{r}1\mathrm{(}\text{Recommendation(r1) }\wedge \mathbf{\text{AlternativeDrugInteraction(i1) }}\wedge \text{relates(i1,r1) }\wedge \mathbf{\text{AlternativeDrugInteraction(i2) }}\wedge \text{relates(i2,r1) }\mathrm{)}\to \mathbf{\text{i1 = i2 }}$

In the next section we illustrate the applicability of the TMR4I model and rules on two case studies for combining sets of guidelines.

5. Case studies on multimorbidity

This section presents two conceptual experiments on detecting interactions for merged guidelines, taken from the literature. They are meant to provide an implementation independent demonstration of the TMR4I model applied to multimorbidity; it also illustrates the improvements it offers compared to the approaches introduced in Section 2. The implementation of TMR4I using Semantic Web languages, discussed in Section 6, serves as an evaluation of the conceptual model, and corroborates the pen and paper exercise of this section.

The two case studies are:

DU+TIA

The first experiment, taken from Wilk et al. [34], originally presented in [38], combines two guidelines, namely Duodenal Ulcer (DU) and Transient Ischemic Attack (TIA), adapted from original guidelines published by the National Institute for Health and Clinical Excellence, UK (NICE).4

⁴

http://www.nice.org.uk/.

OA+HT+DB

The second experiment combines 3 guidelines for Osteoarthritis5 ⁵

http://pathways.nice.org.uk/pathways/osteoarthritis.

(OA), Hypertension6 ⁶

http://pathways.nice.org.uk/pathways/hypertension.

(HT) and Diabetes7 ⁷

http://pathways.nice.org.uk/pathways/diabetes.

(DB) taken from [20].

We make some adaptations to the original case studies by:

• representing only the recommendations that are relevant for studying the interactions and illustrating the approach;

• simplifying the features that are not yet addressed by the TMR/TMR4I models (e.g. time, quantities); and

• adding some extra recommendations that serve to better illustrate our approach.

In particular, when the original guidelines taken from the related work do not provide all information that we need in the TMR model, we make some assumptions based on related paper-based guidelines or common sense.

We divide the experiment in 3 steps: (1) Acquiring guideline data; (2) Combining guidelines and detecting interactions and (3) Addressing undesired interactions and verifying the outcome. For each step the results are presented in figures as instance-schemas of the TMR4I model. They regard the results we would expect to obtain from an information system that implements the model and rules described in the previous sections. We also present and compare with the original approaches applied to each case study.

Fig. 5.

DU guideline taken from [34].

Fig. 6.

DU guideline according to TMR Model.

5.1. Case study 1: DU + TIA

This section repeats a conceptual experiment presented in [38], considering adaptations to the TMR4I model, with the aim of providing an implementation for it. This experiment is originally proposed by Wilk et al. [34] on modeling and merging the guidelines for DU and TIA.

STEP 1: Acquiring guideline data

The original DU guideline, taken from [34], is presented in Fig. 5. This actionable graph is manually created from the original paper-based guidelines (as well as the one further presented). The highlighted recommendations are the relevant ones represented according to the TMR model, illustrated as an instance-schema in Fig. 6. The action Stop Aspirin if used in the original guideline is represented in the TMR DU guideline as a recommendation named Avoid Bleeding, which recommends to avoid the transition promoted by the care action Administer Aspirin. The undesired transition can lead from the situation where gastrointestinal bleeding risk is Low to High. Other two actions Start Eradication Therapy and Start PPI from the original guideline are represented as the recommendations named Heal DU, describing that both the care action Eradication Therapy can lead from the situation where DU is unhealed to healed when H.Pylori is positive, and when H.Pylori is negative instead the care action Administer PPI can promote a similar transition.

Fig. 7.

TIA guideline taken from [34].

The original TIA guideline, taken from [34], is presented in Fig. 7. The highlighted recommendations are the relevant ones represented according to the TMR model, illustrated as an instance-schema in Fig. 8. The actions Start Aspirin and Start Dipyridamole from the original guideline are represented as the recommendations named Reduce Medium Risk VE (Vascular Events) and Reduce High Risk VE. They recommend respectively the transition promoted by the care actions Administer Aspirin, which leads from Medium Risk of VE to Low Risk of VE, and the transition promoted by the care action Administer Dipyridamole, which leads from High Risk of VE to Low Risk of VE.

Fig. 8.

TIA guideline according to TMR Model.

Fig. 9.

Combined DU+TIA guideline according to TMR model with detected interactions.

STEP 2: Combining guidelines and detecting interactions

For combining the two guidelines, Wilk et al. [34] uses CLP to identify and resolve conflicts in two guidelines by consulting a MBK, locally defined, describing possibly conflicting actions/recommendations and their alternative solutions according to experts. For example, the MBK states that the recommendations Stop Aspirin if used and Start Aspirin cannot coexist. Since this combination indeed occurs in the combined version of guidelines, a conflict is identified.

Counterwise, the TMR4I model allows to sistematically identify interactions among recommendations by using the defined rules, as depicted in Fig. 9. A contradiction interaction between the recommendations Avoid Bleeding and Reduce Medium Risk VE is identified since they recommend to pursue and to avoid transitions that are promoted by the same Care Action Type. An alternative interaction is identified between the two recommendations named Heal Duodenal Ulcer, since they recommend similar transitions.8 ⁸

The recommendation Reduce High Risk VE is omitted for sake of simplicity, since it does not have related interactions.

The care actions and transitions are connected to an external drug dataset.

Fig. 10.

Combined DU+TIA guideline according to TMR model, including the new recommendations and detected interactions.

STEP 3: Addressing undesired interactions and verifying the outcome

In order to address the identified conflict in Wilk et al. [34] approach, the MBK provides two solutions: (i) substitute Aspirin by Clopidogrel; and (ii) combine Aspirin treatment with PPI. The authors choose the second option and introduced it in the merged guideline as Start PPI when the risk of stroke is elevated, and also excluded the recommendation Stop Aspirin if used in order to avoid the conflict. Although their outcome would be verifiable by reapplying their approach, the authors did not perform such verification. However, in order to be effective, the possible conflicts would have to be included in the MBK. Finally, since their final goal was not to produce a generic combined version of guidelines, but to prescribe a treatment for a specific patient, they proposed a solution that is applicable to a specific patient.

In our approach both the proposed solutions are introduced as recommendations, without excluding the recommendation Avoid Bleeding. They are named Protect Duodenum and Reduce Medium Risk VE as depicted in Fig. 10 (the original recommendations are presented in gray shade). Naturally, alternative interactions are derived between the original recommendations and the new ones. On the one hand, Protect Duodenum recommends a transition that reverse the undesired transition recommended to be avoided by Avoid Bleeding. On the other hand, the new recommendation Reduce Medium Risk VE recommend a similar transition. Moreover, a repetition interaction can also be identified between the recommendations Protect Duodenum and Heal DU, since they both recommends the same Care Action Administer PPI.

Fig. 11.

The instantiation of the CPG-KPO and the parts of the OA and HT guidelines that participate in the merge, taken from [20].

Therefore, the combined DU-TIA guideline that we produced does not eliminate the original conflict but allows it to be avoided by introducing one or more alternative recommendations. Actually the recommendation Avoid Bleeding is not eliminated since it is a restriction that holds for DU patients regardless what else disease they could have. Indeed, the resultant guideline is both (i) applicable to many patients and (ii) liable to further combination with other guidelines or treatments that the patient already follows. Finally, the internal interactions are identified by relying on the detailed semantics for the recommendations and guideline-independent rules without (necessarily) consulting a MBK.

5.2. Case study 2: OA + HT + DB

This section presents a new experiment taken from Jafarpour’s thesis [20], on combining three guidelines, namely OA, HT and DB. This is meant for illustrating the ability to (i) identify internal interactions between more than two recommendations, combining more than two guidelines, and (ii) identify external interactions. We first introduce how the experiment was originally addressed and then we discuss and compare with our approach.

In Jafarpour’s approach the guideline data is acquired by manually instantiating an ontology. Then constraints are manually created to resolve conflicts between tasks (recommendations) from two guidelines, as illustrated in Fig. 11. The three tasks regarding the administration of Ibuprofen or Naproxen are considered to be in conflict with the hypertension pathway, since these drugs may increase the blood pressure, according to experts. The constraints named conflict 1, 2 and 3 are introduced suggesting the replacement of these drugs by Tramadol or similar. The role of these constraints is to interfere in the execution of the guidelines, i.e. when a task that is to be executed has one of these constraints associated, then instead of executing the task, the constraint instruction will be followed. In this example, the instructions are for substituting the task.

The goal in Jafarpour’s approach (further discussed in Section 8) is to produce a reusable pairwise combination of guidelines, such that several pairwised combined guidelines can be executed together to handle multi-morbidity. Besides the combination of OA+HT, the approach is applied to combine OA+DB and HT+DB such that the three of them can be executed together. However, the solution proposed in this example introduces a repetition interaction, according to the definition presented in 4.1, since Tramadol is recommended four times: in order to address the aforementioned conflicts and also to address another conflict between OA and DB recommendations, where Tramadol is recommended to replace Aspirin as anti-thrombotic. Since recommending the same drug more than once may lead to overdose, it requires attention from the experts. Jafarpour’s approach does not detect the interaction we just mentioned.

STEP 1: Acquiring guideline data

Hereby we present our solution for merging guideline for OA+HT+DB (for sake of simplicity figures are omitted for this step). First, we represent for each guidelines the recommendations that are involved in the conflicts detected by Jafarpour. Then the effects that must be avoided for each disease, which are the reason for the conflicts, are explicitly represented as recommendations within each guideline (if this information is not yet available). For instance for detecting the aforementioned conflict the recommendation Avoid High Blood Pressure promoted by Administering Aspirin is explicitly introduced in the HT guideline. Avoid Bleeding and Avoid High Blood Sugar Level are introduced respectively in OA and DB guidelines. Although this resembles the manual identification of the interactions, it is actually not the case. Once this information is available as part of the guideline, it can be reused to derive many interactions. The care actions and transitions are connected to an external drug dataset.

STEP 2: Combining guidelines and detecting interactions

The recommendations from the original guidelines are reused in order to create a merged guideline, as depicted in Fig. 12 according to the TMR4I model, and interactions manually identified by Jafarpour can be derived: (i) Administer ibuprofen to relief pain from OA contradicts Do not adminster ibuprofen to avoid increase the blood pressure from HT; (ii) Administer thiazide to lower the blood pressure from HT contradicts Do not adminster thiazide to avoid increase the level of blood sugar from DB; and (iii) Administer aspirin to lower the risk of thrombus from DB contradicts Do not adminster aspirin to avoid increase the risk of gastro-intestinal bleeding from OA. Moreover, and alternative interaction is identified among the recommendations Avoid High Blood Pressure and Reduce Blood Pressure since the latter reverse the undesired effect according to the former.

Fig. 12.

Instance-schema illustrating the OA+HT+DB guideline and three contradictory interactions derived.

Fig. 13.

Instance-schema illustrating new recommendations and derived interactions for OA+HT+DB guideline.

STEP 3: Addressing undesired interactions and verifying the outcome

In order to address the contradiction interactions, two solutions proposed by Jafarpour are introduced as recommendations (one of the solutions, regarding reducing the quantity, is not addressed, since it is out of scope of this work) and more interactions are derived, as depicted in Fig. 13 (the original recommendations are presented in gray shade). (i) an alternative interaction is derived between recommendations for Reduce Pain, (ii) another alternative interaction is derived between the three Avoid Thrombi recommendations and (iii) a repetition interaction is derived among the introduced recommendations for Administering Tramadol. Moreover, an extra recommendation Avoid Thrombi promoted by Administer Clopidogrel is added in order to better illustrate the cumulative alternative interaction. Since the resultant guideline can be further verified by applying the same method,

In addition, external interactions can also be identified besides the internal ones, once the original care actions and transitions are connected to an external drug dataset. Particularly in this case study, the recommendations Avoid Thrombi and Reduce Pain have an Incompatible Drug Interaction since the drug types Aspirin and Ibuprofen, associated to the respective care actions, interacts to each other. Moreover, Alternative Drug Interactions can be identified as possible solution for the recommendations involved in an undesired interaction. For example, the recommendation Avoid Thrombi, being involved in contradiction and incompatible drug interactions, has alternative drugs (e.g. Epoprostenol) that can be retrieved according to the drug category (anti-platelet) related to the pursued transition (reduce risk of thrombus).

By performing this conceptual experiment we demonstrate that the TMR4I approach allows a more systematic detection of internal interactions both after combining guidelines and after introducing new recommendations in order to address the interactions. This approach favor the automatization of this task, in contrast with Jafarpour approach that requires ad-hoc interaction rules.

6. Evaluation

This section provides an evaluation for the TMR/TMR4I models and rules by implementing them using Semantic Web representation languages. The goal is to use the Semantic Web to provide a technical solution that applies our conceptual approach into a concrete Web application, available online.9

⁹

See http://guidelines.hoekstra.ops.few.vu.nl/, and GitHub https://github.com/Data2Semantics/guidelines/tree/v1.0.

We instantiate the case studies discussed in Section 5 as individuals in our knowledge base. We then use Semantic Web inferencing to automatically derive the interactions we predicted the TMR4I model would infer.

Listing 1.

Prefixes used in SPARQL queries (and Turtle examples).

The implementation itself is presented in Section 6.1, and Section 6.2 focuses on the instantiation of the case studies.

6.1. Implementation of the TMR models

The TMR and TMR4I models have a very straightforward implementation in OWL 2. To guarantee the content independence of the model (cf. [34]), the schema information (OWL2, rules) and queries are generic and specified independently from the representation of individual guidelines. The latter are represented as individuals – instances – in the triple store.

All unary predicates in the rules 1.1 through 12.2 in Section 3 and 4 are classes, and all binary predicates are either object properties, or an equivalent from the OWL and RDFS vocabulary. The class and property subsumption hierarchy, domain and range restrictions, as well as cardinality constrains follow the structure of the UML class diagrams in Figs 1, 3, and 4.

Not all rules can be translated to OWL restrictions because of the tree-model property that underlies the SROIQ(D) description logic of OWL 2 [17]: an OWL class restriction can only fan out to form a tree shape of which the branches do not connect. This essentially means that two variables introduced in the antecedent of a rule, that are transitively connected through predicates in the antecedent, cannot be connected by a predicate in the consequent of the rule. For example, one cannot represent the fact that the four legs of a table must touch the same floor (unless only a single floor exists in the universe).

There are partial workarounds for this limitation by using property chains [14,15], but for all practical purposes we implemented the restrictions that couldn’t be expressed in OWL2 using a combination of SPARQL queries and the Stardog Rules Syntax,10

¹⁰

See http://docs.stardog.com/#_icv_owl_2_reasoning.

an alternative to the more standard SWRL.11 ¹¹

See http://www.w3.org/Submission/SWRL/.

Stardog Rules Syntax is a SWRL implementation that uses SPARQL syntax [27,28]. It has the advantage of being more readable, but also more expressive in that it allows the use of SPARQL niceties such as filters, property paths and blank nodes. Stardog is a triple store that supports OWL2, SWRL and integrity constraints reasoning at query time.12 ¹²

See http://www.stardog.com.

Another drawback of OWL2 and SWRL-style inferencing is that these allow only for inferring the existence of unnamed entities implicitly. For instance, if we know that two transitions are related, we cannot assert an interaction-individual that relates the respective recommendations. To overcome this limitation, we programmatically introduce these individuals in our knowledge base using SPARQL select queries.

The following sections illustrate the implementation of our model. We first give an example instantiation of a recommendation, followed by a discussion of the rules for internal interactions, and those for external interactions (ones that involve external knowledge, or MBK). For reference, Listing 1 presents the prefixes used in the code examples.

6.1.1. Example recommendation

The Listing 2 provides a short example of an instantiation of the TMR4I model for the recommendation :RecDB-AntiThrombotic to ‘avoid thrombi’ that is part of the Diabetes Mellitus guideline (:CIG-DB). It promotes a transition :T4 that aims to lower the risk of a thrombus from medium to low by means of the :ActAdministerAspirin care action type. This care action is linked to the external identifier DB00945 for the drug (Aspirin) in DrugBank, through the tmr4i:involves relation.

Listing 2.

Excerpt of the TMR4I-based representation of a recommendation to ‘Avoid thrombi’.

6.1.2. Implementation of internal interactions

In our knowledge base, the example recommendation in Listing 2 does not exist in isolation: there are several more guidelines, recommendations, transitions and care action types (as discussed previously). In TMR4I, the internal interactions between recommendations are derived following the FOL rules in Section 4.1. The implementation of these rules is by means of a SPARQL select query that retrieves every two recommendations that matches the pattern in those rules:

• there exists a tmr4i:simlarToTransition between the transitions recommended by two recommendations (see Listing 3, the other rules are similar); or

• there is a tmr4i:inverseToTransition between them; or

• the transitions are tmr4i:promotedBy the same care action.

Then, a SPARQL insert is executed for each pair of recommendations, creating a new individual of type tmr4i:InternalInteraction and relating it to them.13

¹³

This is necessary to work around the limitations of SWRL and OWL with respect to the assertion of new individuals.

Listing 3.

Stardog rule for inferring tmr4i:similarToTransition relations.

Listing 4.

SPARQL rule for classifying Alternative Interactions due similar transitions (FOL 8.1).

The classification of the interaction type is again done via SPARQL Rules. The code on Listing 4 presents the implementation of the FOL rule 8.1 defined in Section 4.1: if a tmr4i:InternalRecommendationInteraction relates two tmr4i:Recommendation instances that both tmr4i:recommendsToPursue two transitions, which have a tmr4i:similarToTransition relation, then the interaction is of the type tmr4i:AlternativeDueToSimilarTransition. The other FOL rules have similar implementations.

As one can see, these rules are generic; they only use vocabulary of the TMR and TMR4I models themselves, and do not contain any specifics of the guidelines discussed in the previous sections.

6.1.3. Implementation of the external interactions

In order to connect to external knowledge bases it is not needed to explicitly instantiate the class External Information (from Fig. 4) but we can use external identifiers (URIs) directly in our knowledge base. For instance, the Turtle code in Listing 2 connects a care action to the representation of Aspirin in DrugBank. Of course, these links have to be added to the care actions by hand, but only once; since care actions are reused across transitions, and transitions are reused across recommendations, which can be reused across guidelines (as we will see below).

In addition to the direct link between a care action and a drug, we also use the drug category information present in DrugBank: the category captures the type of drug, i.e. what its desired effect is (drugs can belong to multiple categories at the same time). TMR4I links drug categories to instances of the tmr4i:Transition class using the tmr4i:regards property (see Listing 5).

For scalability reasons, our knowledge base includes an excerpt of the Linked Data version of DrugBank as published by the University of Mannheim14

¹⁴

See http://wifo5-03.informatik.uni-mannheim.de/drugbank/.

that contains all drug names, drug categories and the drug-drug interactions. The excerpt is made available through our GitHub repository.15 ¹⁵

See https://github.com/Data2Semantics/guidelines/blob/v1.0/src/data/drugbank_small.nt.

Listing 5.

Example connections to DrugBank.

In order to detect external interactions, we proceeded in a way similar to the internal ones. However, we used two specific queries for implementing the FOL rules 11 and 12.1 (defined in Section 4.2) for incompatible drug interaction and alternative drug interaction. The first uses the drug-drug interaction information from DrugBank to detect unique pairs of recommendations that interact because the care actions that promote the recommended transitions involve drugs that form an interaction pair on DrugBank (Listing 6). As with the internal interactions, the system then asserts corresponding new instances of the tmr4i:IncompatibleDrugExternalInteraction class for each pair.

Listing 6.

SPARQL query for selecting the pairs of recommendation that fit the pattern to be related by an external incompatible drug interaction (FOL 11).

The second tries to identify non-interacting alternative drugs based on the drug category specified for transitions that cause a contradiction or incompatibility between recommendations (Listing 7). The result of this SPARQL query is a reified relation between a recommendation, a care action, a drug and the alternative drug found. As with the internal interactions, the system then asserts corresponding new instances of the tmr4i:AlternativeDrugExternalInteraction class for each unique reified relation.

Listing 7.

SPARQL query for selecting the recommendations that fit the pattern to be related by an external alternative drug interaction (FOL 12.1).

On doing so we are able to infer the existence of external interactions and classify them according to the FOL definitions we provided, preserving their structure. This is a limited but important improvement on allowing the identification of drug-drug incompatibilities as well as alternative drugs without human intervention (except for linking the care actions and transitions to DrugBank).

6.2. Populating the knowledge base

This section briefly discusses how the knowledge base is populated. Because all necessary knowledge for inferring the interactions are part of the schema of the knowledge base, the representation of a guideline is only at the instance level. In Listing 2 we already provided an example of what an instantiation of the model for a single recommendation looks like. At the moment this is still a manual process: all guidelines, recommendations, transitions and care actions are modeled using an editor of choice.

In order to repeat the experiment described in the section on the two case studies (Section 5) we proceed as follows:

STEP 1 – All the data for the original guidelines is manually entered. The care actions and transitions are linked to the corresponding drug types and categories from DrugBank. We aim to facilitate this step with a simple web-based user interface.

STEP 2 – To simulate the merging of the guidelines, a new merged guideline is created that duplicates recommendations from the original guidelines, and directly reuses the information about transitions and care actions contained in them. As a result, transitions and care actions are not duplicated across guidelines, but shared. Once the SPARQL-based inferences are run, the internal and external interactions are created and classified within the merged guidelines.

STEP 3 – In order to address contradictory interactions, alternative recommendations can be introduced to the merged guidelines. Again, once the rules are executed, eventual new interactions are derived.

Finally, in order to verify the cumulative interactions, a SPARQL query retrieves recommendations whose interactions relate more than two recommendations. In other words, it retrieves the recommendations whose interactions are related by owl:sameAs, the type of interaction, including pursued or avoided transition, pre and post situations and care action.

Given the definitions of which and how interactions can be identified according to the TMR4I model, we present in the next section an approach of how to apply this model in a multimorbidity case study.

7. Results

This section brings the results we obtained by instantiating the two case studies using the implementation described in the preceding section. The results are presented in tables that present the data retrieved after each step proposed in the previous sections. We also developed a Web-based application that allows to explore both the original guidelines and the combined ones, and their associated recommendations, transitions and care actions.16

¹⁶

The web application is running at http://guidelines.hoekstra.ops.few.vu.nl.

Web-based guideline explorer  The Web-based guideline explorer is a jQuery + Python Flask application that uses SPARQL queries to interact with the Stardog triple store in which the TMR4I model and guideline representations reside.17 ¹⁷

See http://jquery.com, http://flask.pocoo.org, http://www.stardog.com.

Figure 14 shows a screen-shot of the application presents on the left hand side the combined guideline for OA+HT+DB and its interactions. When the recommendation Avoid Thrombi by Administering Aspirin is selected, its details are presented on the right hand side, including the internal and external interactions inferred and explained in a human readable format. By positioning the cursor over an orange interaction, the other recommendation involved in that interaction is highlighted in orange on the left.

In summary, this recommendation says (at the bottom) that the transition for Reducing the Risk of Thrombus can be achieved by executing the care action Administer Aspirin and that there are two other, similar transitions recommended in this guideline (T13 and T7, recommended twice). This recommendation has (i) one contradiction interaction since a care action it recommends is also recommended to be avoided; (ii) one cumulative alternative interaction that involves two other recommendations with similar transitions; (iii) one external drug interaction because Aspirin interacts with Ibuprofen according to DrugBank, and (iv) one alternative care action, namely Epoprostenol, that may alleviate this interaction according to DrugBank.

Fig. 14.

Screenshot of the live Web application, running at http://guidelines.hoekstra.ops.few.vu.nl.

Step 1 – data acquisition  Table 3 presents the original recommendations introduced for DU and TIA guidelines (the other guidelines are omitted for sake of simplicity).

Table 3

Recommendations for original DU and TIA guidelines

Guideline	Recommendation	Mode	pre Situation	post Situation	Care Action
DU	Avoid bleeding	Avoid	Risk of Gastrointestinal Bleeding is Low	Risk of Gastrointestinal Bleeding is High	Administer Aspirin
DU	Heal duodenal ulcer	Pursue	Ulcer is unhealed	Ulcer is healed	Administer PPI
DU	Heal duodenal ulcer	Pursue	Ulcer is unhealed	Ulcer is healed	Eradication Therapy
TIA	Reduce high blood pressure	Pursue	Risk of Thrombus is High	Risk of Thrombus is Low	Administer Dipyridamole
TIA	Reduce medium risk VE	Pursue	Risk of Thrombus is Medium	Risk of Thrombus is Low	Administer Aspirin

Step 2 and 3 – inferences  Tables 4 and 5 present the results obtained after steps 2 and 3, for respectively the first (DU+TIA) and second use case (OA+HT+DB). The new recommendations and interactions added in step 3 are highlighted in bold. Recommendations presenting more than one interaction appear in the table just once but followed by “empty” line(s) containing just the derived interaction type.

Table 4

DU-TIA – Recommendations and respective new interaction types detected after adding new recommendations (highlighted)

Recommendation	Mode	pre Situation	post Situation	Care Action	Interaction Type
Avoid bleeding	Avoid	Risk of Gastrointestinal Bleeding is Low	Risk of Gastrointestinal Bleeding is High	Administer Aspirin	Contradiction Due To Same Action
					Alternative Due To Inverse Transition
Heal duodenal ulcer	Pursue	Ulcer is unhealed	Ulcer is healed	Administer PPI	Alternative Due To Similar Transition
					Repetition Due To Same Action
Heal duodenal ulcer	Pursue	Ulcer is unhealed	Ulcer is healed	Eradication Therapy	Alternative Due To Similar Transition
Protect duodenum	Pursue	Risk of Gastrointestinal Bleeding is High	Risk of Gastrointestinal Bleeding is Low	Administer PPI	Alternative Due To Inverse Transition
					Repetition Due To Same Action
Reduce high risk VE	Pursue	Risk of Thrombus is High	Risk of Thrombus is Low	Administer Dipyridamole	none
Reduce medium risk VE	Pursue	Risk of Thrombus is Medium	Risk of Thrombus is Low	Administer Aspirin	Contradiction Due To Same Action
					Alternative Due To Similar Transition
Reduce medium risk VE	Pursue	Risk of Thrombus is Medium	Risk of Thrombus is Low	Administer Clopidogrel	Alternative Due To Similar Transition

Table 5

OA+HT+DB – Recommendations and respective new interaction types detected after adding new recommendations (highlighted)

Recommendation	Mode	pre Situation	post Situation	Care Action	Interaction Type
Avoid bleeding	Avoid	Risk of Gastrointestinal Bleeding is Low	Risk of Gastrointestinal Bleeding is High	Administer Aspirin	Contradiction Due To Same Action
Avoid high blood pressure	Avoid	Blood Pressure is Normal	Blood Pressure is High	Administer Ibuprofen	Alternative Due To Inverse Transition
					Contradiction Due To Same Action
Avoid high blood sugar level	Avoid	Level of Blood Sugar is Normal	Level of Blood Sugar is High	Administer Thiazide	Contradiction Due To Same Action
Avoid thrombi	Pursue	Risk of Thrombus is Medium	Risk of Thrombus is Low	Administer Aspirin	Contradiction Due To Same Action
					Incompatible Drug External Interaction
					Alternative Drug External Interaction
					Alternative Due To Similar Transition
Avoid thrombi	Pursue	Risk of Thrombus is Medium	Risk of Thrombus is Low	Administer Clopidogrel	Alternative Due To Similar Transition
Avoid thrombi	Pursue	Risk of Thrombus is Medium	Risk of Thrombus is Low	Administer Tramadol	Alternative Due To Similar Transition
					Repetition Due To Same Action
Reduce blood pressure	Pursue	Blood Pressure is High	Blood Pressure is Normal	Administer Thiazide	Alternative Due To Inverse Transition
					Contradiction Due To Same Action
Reduce pain	Pursue	Patient has Pain	Patient has no Pain	Administer Ibuprofen	Contradiction Due To Same Action
					Incompatible Drug External Interaction
					Alternative Due To Similar Transition
Reduce pain	Pursue	Patient has Pain	Patient has no Pain	Administer Tramadol	Alternative Due To Similar Transition
					Repetition Due To Same Action

Cumulative interactions  Table 6 presents the recommendations related by cumulative interactions.

Table 6

Cumulative Interactions

Recommend.	T	pre Situation	post Situation	Care Action	Interaction Type
Avoid thrombi	Pursue	Risk of Thrombus is Medium	Risk of Thrombus is Low	Administer Aspirin	Alternative Due To Similar Transition
Avoid thrombi	Pursue	Risk of Thrombus is Medium	Risk of Thrombus is Low	Administer Clopidogrel	Alternative Due To Similar Transition
Avoid thrombi	Pursue	Risk of Thrombus is Medium	Risk of Thrombus is Low	Administer Tramadol	Alternative Due To Similar Transition

8. Discussion and future work

The outcomes from the two experiments shown that different types of interactions can be (semi) automatically detected in multimorbidity cases by applying TMR4I model, enriched with Semantic Web features. In opposed to the original experiments reported in related work, in both case studies the internal interactions are detect without need for specific MBK or rules, but relying on the detailed semantics provided for the recommendations. Interactions with cumulative behavior (e.g. alternative) are detected among more than two recommendations. Another important difference is that the final outcome, including the merged guidelines and the recommendations introduced to address the conflicts, can be verified again using the very same approach. Finally, DrugBank is used for automatically detecting interactions that could not be derived from the data comprised in the guidelines.

In what follows we provide a comparison between our approach and the others that we analysed in Section 2, summarized in Table 7:

Table 7

Comparison to related works

	Wilk [34]	Jafarpour [20]	Lopez-Vallverdu [23]	TMR4I Model
Core Concepts	Actions & Rules guideline-dependent	Tasks & Constraints guideline-dependent	Actions & Rules guideline-dependent	TMR + Interactions & Rules guideline-INdependent
Representation of Recommendations	Textual Procedural	Textual Procedural	Textual Procedural	Structured Declarative
Language	Workflow & CLP	OWL + SWRL	Proprietary Rule-based Notation	Conceptual: UML + FOLImplemented: OWL + SPARQL
Medical background knowledge	defined for specific guideline merges	No	No	DrugBank
Reuse of CIG knowledge	Yes	Yes, associating rules to the original tasks	Yes, by reusing the rules	Yes, duplicating recommendations, sharing actions/transitions
Interactions Identification	Semi-automatic Pairwise	Manual Pairwise	Manual Pairwise	Semi-automatic Among several guidelines
Type of Interactions	not applicable	identical and conflicting actions, reuse of results, temporal/sequential aspects	Drug-related conflicts	Internal: Contradiction, Alternative and Repetition;External: Incompatible Drug and Alternative Drug
Solutions Identification	Semi-automatic introduced as CLP clauses and further incorporated to actionable graph.	Manual Introduced as text in SWRL constraints	Manual Introduced as standard text in a Rule	Manual: Introduced as TMR recommendations Semi-Automatic: Alternative drugs retrieved from external database
Outcome Verification	Semi-automatic, limited applicability Verifiable by the same approach	Automated by SWRL rules, limited applicability	Manual	Semi-automatic Verifiable by the same approach
Implementation	Proprietary database Allow combining guidelines considering a patient context	Proprietary database Allow executing together many pairwise combined guidelines	Proprietary database Allow combining many treatments	Web available database (Drugbank) Allow combining two or more guidelines

Core concepts Although the analysed approaches also use rules/constraints to identify the interactions among actions and to propose solutions, they do not support a guideline-independent detection of interactions either because the formalism adopted (Wilk [34], Lopez-Vallverdu [23]) is not expressive enough or the model (Jafarpour [20]) does not favour the reuse of rules. For instance, to detect the inconsistency between the recommendations Administer Aspirin & Avoid Administering Aspirin a context-specific rule is proposed. However, for other substances (e.g. if there is inconsistency with insulin administration instead of aspirin) a new rule is required. In our approach we rely on the TMR concepts to define guideline-independent rules for detecting some interaction types. For the same example, the inconsistency between Administer Aspirin and Avoid Administering Aspirin is detected by a generic rule that can be applied to other substances (e.g. Insulin).

Representation of recommendations In all the studied approaches, the representation of the recommendations occur in a textual form, collapsing both concepts recommendation and action, and eventually pre and post-conditions. For instance, Administer Aspirin and Avoid Administering Aspirin are an example of opposed recommendations about the same action that are represented as two different actions instead. The textual description is used to collapse the positive and negative aspects of the recommendation and the action itself. Such characteristic render it difficult the automatic detection of this type of interaction. We instead propose a more structured representation of the recommendation and its related concepts, the TMR model, which favor reasoning about it (although it also has textual labels for describing each concept). Moreover, the relate work impose the actions to be in a sequence, when it is actually not always the case. For instance, Avoid Administering Aspirin is a recommendation that does not need to happen before or after another one. Therefore, we chose a declarative representation of recommendations in principle, while a sequence of recommendations will be an optional feature investigated as future work.

Languages As highlighted in this section, the description languages used to represent guidelines can introduce limitations to the reasoning process. This is the case for Wilk’s and Lopez-Vallverdu’s approaches that can only analyse pairwise recommendations. Jafarpour’s approach adopted OWL+SWRL languages that are more flexible to deal with multimorbidities. We conceptually describe our approach using FOL and UML what give us more liberty to select the computer language later. We adopt OWL+SPARQL for implementation in order to benefit of available Semantic Web features.

Medical background knowledge Since we based our implementation on Semantic Web technologies and there are many semantically described knowledge bases available in the Web, we can evaluate our approach without requiring experts from biomedical domain to create and validate proprietary databases. The same was not observed in the other approaches, which either define it themselves or do not use it.

Reuse of guideline knowledge The laborious work of transforming paper-based guidelines into computer-interpretable guidelines (CIG) is a common process for all approaches. However, concerning the reuse of guideline knowledge, we have adopted a different strategy. While the analysed approaches consider the whole CIG as one piece of knowledge, we chose to split CIGs into two parts: One describing the recommendations and one describing the actions. This choice allows for having shareable pieces of knowledge (i.e. actions and rules). Reusing the recommendations requires a little bit more work because they need to be duplicated from one existing guideline to the other and be validated by domain experts. For the other analysed approaches all reuse of piece of knowledge requires the validation of domain experts. Another advantage observed in our approach is that actions can be modified independently of the guideline (under certain conditions). In the future we intend to better define these conditions and use them to evaluate when a CIG need to be updated.

Interactions All approaches provide ways to detect interactions between recommendations. Jafarpour’s approach proposes a number of types of interactions that can be identified. It allows addressing identical and conflicting actions, as well as reuse of results (similar effec/result), which are close to our proposal, besides addressing temporal/sequential aspects. Lopez-Vallverdu approach is meant for identifying drug-related interactions. Both approaches propose to have one rule to each potential interaction (based on the instances), what can lead to a huge number of rules that become complex to maintain up-to-date. In the approach of Wilk et al. a similar situation is observed, although the rules as pre-defined CLP clauses allow semi-automatically identification of conflicts and correspondent mitigation of operators (types are not defined). However, those approaches do not address interactions involving three or more recommendations. In our approach, we apply guideline-independent rules for automatically identifying some internal and external types of interactions. These rules can also detect interactions holding between two or more recommendations within two or more guidelines.

Outcome verification The introduction of new recommendations requires further verification for eventual new conflicts that could arise. If all potential conflicts need to be solved by adding context-dependent rules, it may lead to a combinatorial explosion of rules. This, in turn, increases the complexity of detecting conflicting rules; especially if the verification is done manually by experts. In particular, Jafarpour defines SWRL rules that allow automatically detecting some time/priority-related conflicts between pairs of introduced constraints, but does not address other types of conflicts and does not find eventual conflicts with existing tasks. In our approach, since we introduced the solutions as recommendation in the same format as the original ones, the same rules can be applied for verifying new conflicts (generated by the outcome of the reasoning engine).

Implementation All approaches were implemented, however only our approach uses Semantic Web technology to evaluate the efficacy of the proposed method. The other approaches developed their own database to evaluate their methods.

The proposed approach is still not mature enough to be applied to handle the whole complexity of real guidelines. However, since it is a complex problem, we are applying an incremental approach to address it. The evaluation of the work done until now uses (simplified) realistic case studies to demonstrate the current contribution. More features will be incrementally added to the approach and evaluated in more complec scenarios. The proposed prototype will also be incrementally improved for demonstrating the feasibility of automatic detection of interactions. The potential end-users of an information system with such feature can be (i) guideline developers when handling diseases that commonly happen together or (ii) physicians in clinical practice setting, if they would need to combine guidelines (when they were not previously addressed by the guideline developers).

An extension of this work addressing hierarchies of Care Action Types (e.g. Administer Aspirin specializes Administer NSAID) and side effects is provided in [39]. Future work includes addressing also sequencing, composition, time and quantities. Further improvements concerning more detailed representation for transitions, situation types and recommendations, besides including goals, evidence and recommendation strength. We plan to further investigate (i) the use of Semantic Web Technologies to implement future versions of the TMR/TMR4I models, as well as (ii) links to other available databases (e.g. Sider) and terminologies (e.g. SNOMED-CT). In particular, the use of standard terminologies mapped to each other (e.g. via UMLS [9]) would allow combining guidelines annotated with different terminologies. We also intend to pursue compatibility with existing CIG languages meant for execution of guidelines and we position our work as complementary to them.

Finally, this work focus on the clinical knowledge modelling and its applicability for multimorbidity issue rather than the process of acquiring/extracting such knowledge. In other words, it is about which knowledge should be acquired in order to be able to account for detecting interactions among the recommendations, as well as suggesting some solution. Therefore, the process of acquiring this knowledge from natural language clinical guidelines or other sources is not the focus of this work.

9. Conclusion

With the ever aging of the population, multimorbidity is becoming a huge problem and require appropriate tools for supporting the physicians to design adapted treatment plans. To this end, we introduce in this paper TMR4I as a model for detecting interactions among recommendations within several guidelines using Semantic Web technologies. We demonstrate that our approach goes beyond state-of-the-art in addressing multimorbidity with respect to some important features. This is possible by (i) relying on a more detailed semantics for representing the recommendations and actions, (ii) defining guideline-independent rules for detecting interactions and (iii) making the most of Web-based external knowledge sources that allow to detect drug-drug interactions and alternative drugs with few or no human-intervention. Our approach favor combining several guidelines since it provides means for (semi) automatically identifying interactions among many recommendations within many guidelines, and effectively verifying the resultant merged guideline by reapplying the approach.