An ontological knowledge and multiple abstraction level decision support system in healthcare

GLARE representation language

In the medical literature, clinical guidelines are often described using different levels of detail (and top-down refinement), and oriented graphs of actions, similar to flow-charts are often used to describe the ordering of actions at the different levels. As a consequence, in GLARE, a CIG can be represented as a hierarchical graph, where nodes are the actions to be executed, and arcs are the control relations linking them.

In GLARE, we distinguish between atomic and composite actions (plans), where atomic actions represent simple steps in a CIG, and plans represent actions that can be defined in terms of their components via the “has-part” relation.

Actions in a GL are connected through control relations. Control relations establish which actions can be executed next, and in what order. In particular, the sequence relation explicitly establishes what is the following action to be executed; the alternative relation describes which alternative paths stem from a decision action, and the repetition relation, states that an action has to be repeated several times. In detail, given a repeated action, the number of its repetitions can be fixed a priori, or, alternatively, it can be asserted that the action must be repeated until a certain exit condition becomes true (in this case, the number of repetitions is only known at runtime, during execution). In particular, advanced AI techniques are required to deal with temporal reasoning in repeated actions (Anselma et al. 2006).

Architecture of the kernel of GLARE

The core of GLARE (see box on the left of Figure 4) is based on a modular architecture. CG_KRM (Clinical Guidelines Knowledge Representation Manager) is the main module of the system: it manages the internal representation of CPG, and operates as a domain-independent and task-independent knowledge server for the other modules; moreover, it permanently stores the acquired CPG in a dedicated Clinical Guidelines Database (CG-DB). The Clinical Guidelines Acquisition Manager (CG_AM) provides expert-physicians with a user-friendly graphical interface to introduce the CPG into the CG_KRM and describe them. It may interact with four databases: the Pharmacological DB, storing a structured list of drugs and their costs; the Resources DB, listing the resources that are available in a given hospital (it is therefore used to represent the context-dependent version of a CPG); the ICD DB, containing an international coding system of diseases; the Clinical DB, providing a “standard” terminology to be used when building a new CPG, and storing the descriptions and the set of possible values of clinical findings.

The execution module (CG-EM) executes a CPG for a specific patient, considering the patient’s data (retrieved from the Patient DB). The schema of the Patient DB mirrors the schema of the Clinical DB. Therefore, the inter-action with the Clinical DB during the acquisition phase makes it possible to automatically retrieve data from the Patient DB at execution time. CG-EM stores the execution status in another DB (CG Instances) and interacts with the user-physician via a graphical interface (CG-IM).

It is worth noticing that, through the CG-AM and CG-IM modules, GLARE provides user-friendly interfaces to user, achieving the goal of “hiding” them in the internal complexity of the system.

Extended architecture

To enhance extendibility, GLARE’s architecture is open: new modules and functionalities can be easily added to the system if\when necessary. In recent years, we have added new modules and\or methodologies in order to cope with automatic resource-based contextualization (ADAPT module, (Terenziani et al. 2004)), temporal reasoning (TR, (Anselma et al. 2006) and (Stantic et al. 2012)), decision-making support (DECIDE_HELP, (Montani and Terenziani 2006) and (Anselma et al. 2011)), and model-based verification (VERIFY, (Bottrighi et al. 2010)). While all the methodologies to cope with the above issues have been widely addressed, not all the prototypical software modules have been implemented yet. However, we envisage a modular architecture, in which all such modules will be loosely coupled with the core of GLARE, as shown in the right part of Figure 4.

Since the focus of this paper is decision support, in the following we briefly explain our decision-making facility (see (Montani and Terenziani 2006) and Anselma et al. (2011) for more details).

Decision-theory-based decision support in GLARE

When executing a CIG on a given patient, a physician can be faced with a choice among different therapeutic alternatives, and identifying the most suitable one is often not straightforward. Actually in several situations no alternative is really “better” than the others, from a strictly clinical viewpoint, and CIGs are only meant to present all the range of choices, leaving the user the responsibility of selecting the “right” one.

In clinical practice, various selection parameters (such as the costs and effectiveness of the different procedures) are sometimes available when executing a CIG, but the task of comparing and balancing them is typically left to the user. Decision theory seems a natural candidate as a methodology for supporting this analysis; to this hand, we have created a mapping between the CIG representation primitives and decision theory concepts, and a decision theory tool for supporting therapy selection in GLARE.

In short, in a well-formed CIG, a therapeutic decision action is always preceded by a query action, which is adopted to collect all the patient’s parameters necessary (and sufficient) for taking the decision itself. Each therapeutic decision is therefore based on an (explicit or implicit) data collection completed at decision time, and does not depend on the previous history of the patient. We can thus say that the CIG describes a first-order Markov model, since each time a query action is implemented, the patient’s situation is completely re-assessed, and an (explicit or implicit) query action is always found before a decision action. This observation allows us to represent a CIG as a Markov Decision Process (MDP), which has been recognized as a basic representation framework for dynamic decision making under uncertainty.

In particular, it is straightforward to define the concept of state as the set of patient’s parameters that are normally measured for taking decisions and for assessing therapy outcomes. On the other hand, we consider work actions as the means of producing state transitions, since they are the only actions with a potential effect on the state variables. The utility of reaching a state can be evaluated in terms of life expectancy, corrected by Quality Adjusted Life Year (QALYs) (Gold et al. 1996). We can derive the utility of a state from the medical literature, as we do for obtaining the probability of state transitions. Costs can be interpreted as monetary expenses: each work action will have a price. Additionally, costs can also be evaluated in terms of the time and the resources required to complete work actions.

On the basis of these preliminary mapping considerations, which are general enough to be easily applied within any of the systems for the computerized management of CPGs described in the literature, we are implementing a decision theory facility in GLARE. In our approach, the MDP describing the CIG is represented resorting to a dynamic decision network (Tatman and Shachter 1990), a choice that allows one to explicitly take advantage of conditional independencies from the modeling viewpoint. In particular, the GLARE decision theory facility will enable the user: (1) to identify the optimal policy, and (2) to calculate the expected utility along a path, by exploiting classical powerful dynamic programming algorithms.

Motivations for and advantages of an ontology-based approach

The first step of our approach is the definition of an ontology, clarifying the semantics of interactions, and modeling the different knowledge sources involved in their detection and analysis. In health informatics, ontologies are defined as “collections of formal, machine-processable and human interpretable representation of the entities, and the relations among those entities, within a definition of the application domain” (Rubin et al. 2006).

Since 2001, there has been an increasing use of ontological approaches to health (Liaw et al. 2013). As a matter of fact, the adoption of formal ontologies is almost becoming standard in medical informatics, since it provides many advantages, including terminological standardization and the definition of a common semantics. For instance, SNOMED (http://www.ihtsdo.org/snomed-ct/) is a widely used clinical terminology, and stresses that “the use of a standard clinical terminology makes a significant contribution towards improving the quality and safety of healthcare by enabling consistent representation of meaning in an electronic health record”. In particular, the definition of an ontology for interactions allows us to achieve several different goals:

Define shared semantics for guidelines and interactions: we need to define a semantic model for interactions and guidelines actions. Such semantic model must be shared and “understood” both by information systems and by human users (Gruber 2009; Rubin et al. 2006).

Define a standard for terminology and representation: GLARE is a standard for guidelines representation. The use of ontologies for the action model supports the standardization between different guidelines. In addition, ontologies are often used to disambiguate terms. The use of existing and consensus ontologies for data representation avoid ambiguities and allows the reuse of the knowledge.

Unify different sources: in the medical field, data can derive from different sources. Unify them using ontologies helps to improve data quality (Liaw et al. 2013).

Reason on the data: the use of standard ontology representation as RDF or OWL allows processing the content of information through existing reasoners (McGuinness and van Harmelen 2004): “by incorporating defined rules, ontologies may also generate logical inferences” (Pérez-Rey et al. 2006).

Interactions and levels of abstraction

Our ontology of interactions is based on the consideration that physicians usually analyze the interactions between guidelines at different levels of detail. At the highest level, they take into account the intentions (or goals) of actions (see, e.g., examples 1 and 2 in the following). Then, moving towards more specific information, they may also consider the interactions between specific drugs categories (e.g., Example 3), and, finally, between specific drugs (e.g., Example 4).

Example 1. Intentions Interaction: in the treatment of edema due to heart failure, the main intention is to decrease the accumulation of fluids. In the case in which that particular patient also manifests a syncope crisis, it is likewise necessary to increase the blood pressure. However, this later intention forces the heart to a higher activity, which in turn may increase the heart failure, worsening the edema.

Example 2. Intentions Interaction: in patients affected by thrombosis, anticoagulant drugs are usually administered, in order to decrease the formation of thrombi. If the patient affected by thrombosis has also a risk of bleeding ( e.g. due to a minor surgery) the anticoagulant therapy must be discontinued because of the need to increase the blood coagulation.

Example 3. Drug Categories Interaction: the administration of antacids (category) at the same time of other drugs orally administered can change the intestinal absorption of the later decreasing their effects ( e.g. levofloxacin).

Example 4. Drugs Interaction: in many cases, interactions involve individual drugs. For example, between trimethoprim and sulfamethoxazole there is a strengthening synergism: the antibiotic effect of their concomitant administration is stronger than the sum of the two single effects.

Our goal is to devise a general ontology underlying the detection of guideline interactions. Our methodology is completely general, and we are not committed to any specific pre-existent ontology. However, given its relevance and generality, we use the SNOMED ontology (http://www.ihtsdo.org/snomed-ct/) as a reference one. Sometimes we also consider the Anatomical Therapeutic Chemical (ATC) ontology (http://www.whocc.no/atc) as concerns the drug classification. We extend them in order to model both the different sources of interactions (intentions, drugs categories, drugs) and the different types of interactions between them.

For the sake of interaction detection, the description of guideline actions must include the intention of composite and work actions, or the drug (class of drugs, active principle) of pharmacological actions. We first describe our ontology of intentions (subsection “Intentions Ontology”) and of drug classes (subsection “Drug Classes Ontology”). Then, in subsection “Interactions Ontology”, we describe our ontology for the interactions (between intentions, and between drug classes and drugs).

Intentions ontology

At a high level of abstraction, an action can be represented by its objectives or (desired) effects. In this section, we focus on the objectives of composite actions (plans), work actions and pharmacological ones, and we call them Intentions (i.e., the goals that the physician expects to obtain realizing that action)^a.

Intentions can be organized along a hierarchy of ISA and PART-OF relations: high-level intentions can be decomposed into lower-level intentions, and alternative decompositions are possible.

For instance, Figure 5 shows (not exhaustively) the hierarchy of the intention “Decrease Blood Pressure”. That intention is typically obtained through the realization of several lower-level intentions and many alternative decompositions (and combinations between them) are possible. Then, lower level intentions can be decomposed by many part-of relations (as can be seen for the “Improve Lifestyle” intention), or not (for example “Block of Calcium Channels”). A particular case is represented by the combination of more intentions in order to reinforce the higher-level one: the intention “Inhibition of Angiotensin Converting Enzyme (ACE)” is both a sub-intention of “Decrease Blood Pressure” and a part of the combined intention “Decrease Blood Volume + ACE Inhibition”.

Ultimately, at the lower level, the intentions can be described as (desired) modifications of specific parameters of the patient status. In the following, we call such intentions atomic intentions. In our ontology, atomic intentions can be represented by a couple <BodyPartAttribute, Modality> in which BodyPartAttribute is the attribute that is expected to change, and Modality is an element belonging to the set {Increasing, Decreasing, Stability} and describes how the attribute is expected to change. Of course, if needed, the hierarchy of modalities might be further refined. For instance, we can distinguish between different degrees of increase/decrease. Figure 6 shows that BodyPartAttribute is in its turn connected with the respective body part. Both concepts have a counterpart in SNOMED Ontology: BodyPart is equivalent to the SNOMED concept “Body Structure” and BodyPartAttribute to the SNOMED concept “Observable Entity”, whilst concepts of Intention and Modality are not included in SNOMED.

We illustrate the concepts previously described by an example (see Figure 7): the intention of improving the cardiac activity can be to increase (Modality) the cardiac activity (BodyPartAttribute), which is in turn linked to the BodyPart cardiovascular system. Both Cardiac Activity and Cardiovascular System are individuals of the SNOMED Ontology.

Drug classes ontology

As discussed in Section “GLARE representation language”, in GLARE the representation of a pharmacological action includes, amongst others, an attribute (substance) that specifies the drug category (or the specific drug, depending on the level of detail of the CIG itself) prescribed in order to achieve the action’s atomic intention. The value of such an attribute is a link to a sub-concept of the ontological concept DrugCategory (see the higher part of Figure 8).

DrugCategory (and its refinements in the hierarchy) are used in order to achieve (atomic) intentions (see the “aimsTo” arc in Figure 8).

The DrugCategory concept is not flat: it is the root of a hierarchy of categories and its expansion depends on the classification used. In fact, there are in literature several ways to classify the drugs (e.g. those based on the chemical type of the active ingredient, those based on the way they are used to treat a particular condition, etc.). We will use the SNOMED classification for our examples: its concept “Drugs or Medicaments” (that is hierarchically organized) contains our concepts DrugCategory and Drug. However, our approach is independent of the chosen classification, so it is possible to use also other ones (e.g., ATC).

A hierarchical classification of drugs is crucial: several CIGs identify accurate pharmacological prescriptions, pointing out specific drugs, whilst other ones can identify the only drug categories of the pharmacological actions, leaving the physician the task of choosing the drug case by case.

In general, our methodology (see Section “Interaction Detection Algorithm”) is independent of the specific ontology, since it supports the navigation of the drug category ontology along the ISA relationships.

Interactions ontology

As discussed above, our approach supports the description of CIGs at different levels of abstractions. First of all, GLARE supports top-down action refinement in the action description, through the decomposition of nested composite actions (plans) into their parts (components). Plans are “high-level” actions, aiming at achieving “high-level” goals, i.e., intentions (see Figure 5). At a finer level of details, GLARE pharmacological and work actions (which are part of plans) have atomic intentions, which can be achieved through the administration of drugs (see Figure 8). In turn, drugs can be organized through a multiple-level hierarchy of abstraction, going from drug categories to specific drugs (see Figure 9).

Consequently, it is important to notice that interaction can be identified (with different levels of detail) at each one of the different levels of abstraction. As a consequence, in our ontology, we distinguish between IntentionInteractions, AtomicIntentionInteractions, and DrugCategoryInteractions^b. In Figure 10, we show the higher level of our ontology of interactions.

IntentionInteraction is an interaction between two intentions, and has an InteractionType. In Figure 11, we distinguish between three basic types of interactions between intensions. The “Independence” type covers cases in which the intentions do not interact. The “Concordance” type covers cases in which the two intentions are not independent, but reinforce each other (see example 5 below). The “Discordance” type covers cases in which the two intentions negatively interact with each other (see for instance example 1).

Notice that we have deliberately chosen to support a “fuzzy” representation of interactions. Indeed, in many cases, medical intentions are not 100% in agreement or disagreement. However, more “sharp” types of interactions can also be added to the ontology. For instance, the “Opposite” type could be added as a refinement of the “Discordance” type, to cope with opposite intentions (see example 6 below).

As shown in Figure 11, AtomicIntentionInteraction is a subconcept (ISA arc) of Intention Interaction, being an Interaction between two AtomicIntentions (which, in turn, are Intentions).

Drug category interactions (see Figure 12) occur between two Drug Categories (or subconcepts), and cause a variation of their (atomic) intentions. In our formalism, an interaction between two or more drug categories is modeled as the variation of one or more atomic intentions of the actions involved in the interaction itself, so it is completely described by the intentions it changes and the variation it causes. Since an atomic intention is itself described by a modality, an interaction is a variation of that modality (MV) and its domain is the same set {Increasing, Decreasing, Stability} seen for the concept Modality (see below examples 3, and 7 in the next section).

The representation of drug-drug interactions (i.e., interactions between two Drugs) is similar, but requires at least one of the elements involved belongs to the Drug class (see examples 4, and 8 below).

Integration between CIGs and ontology

The integration between CIGs and ontology is important, since, in many cases, CIG actions are described at quite a high level of detail, while specific interactions may arise at lower levels. For instance frequently CIG pharmacological actions only indicate drug categories. However, at the very end, a specific drug of that category must be prescribed to the specific patient, and we have previously shown examples in which, while two drug categories do not interact, specific drugs of the two categories do interact. Such interactions can only be detected if the CIG knowledge is expanded with the knowledge (about drug interactions) in the ontology, and achieving such an integration is one of the main results of our tool.

In our approach, the two knowledge sources (i.e., CIGs and ontology) are strictly connected: as mentioned above, the types of CIG actions and the values of many properties of actions are links to ontological notions (see, e.g., the description of pharmacological actions in Section “GLARE representation language”). In particular, in our approach the representation of pharmacological actions in the CIGs provide the crucial link for the expansion: through the substance attribute, each pharmacological action specifies a drug category (or, in some cases, a specific drug) to be used, pointing out to the concept representing it in the ontology.

Interactions with user-physicians

In our opinion, a black-box tool that, given two (or more) CIGs and the ontology, provides in output all the possible interaction actions in the CIGs (possibly considering also the possible “expansions” provided by the ontology), is not really useful for the user-physicians. CIGs often consist of hundreds of actions, and the pharmacological prescriptions they contain may often be achieved through the adoption of several different drugs. Thus, a tool detecting interactions between any pair of actions and drugs belonging to two (or more) CIGs, and blindly operating at all levels of abstraction, would simply output too many interactions to be useful to the physician. For such a reason, we aim at devising a flexible and interactive detection tool allowing physicians to navigate through the different abstraction levels, thus supporting the natural methodology they adopt to cope with co-morbidities. For instance, at the highest level, a physician may want to start considering only the interactions between the intentions of the “macro-actions” of the guidelines. Then, focusing on a specific part of the guideline, (s)he may want to move down to a more detailed analysis, considering the decomposition of the “macro action” into its parts, and/or the specific drugs category considered in order to reach the high-level intentions. In general, our approach will provide physicians with the possibility of moving in both directions, i.e., going down from a general to a more specific analysis, or moving up, from a specific analysis to a higher level of abstraction.

Interaction detection process

When analyzing the interaction between two or more CIGs, the user-physician can iteratively use such tools to create her/his “personalized” interaction detection process, as required by the specific circumstances and goals. In other words, instead of providing a pre-defined (and unique) way of detecting interactions, and super-impose it on user-physicians, we provide her/him with the proper tools, allowing her/him to interactively work out the detection process (s)he needs (please remember the comments to Example in the “Background” Section).

Given the general picture, we now refine it by providing the focusing and the interaction analysis tools.

The focusing tool

The focusing tool is recursive and highly interactive: at each time the physician user chooses a part of one of the guidelines or a specific action and the dimension along which (s)he wants to explore it. Then the system provides the new visualization of the guideline considering that expansion. The exploration status of each guideline is maintained in a guideline _navigator: this data structure keeps track of each expansion done. A guideline navigator can be represented as an ordered list of views (guideline_view) of the same CIG: initially, it is initialized to the view that represents the higher level of abstraction of the guideline, then, each time the user performs an exploration action (described in the following), a new level representing the new view is added to the guideline navigator. During the navigation, when the user decides to return to a higher level of abstraction, the last level of the navigator is deleted. Figure 13 shows in detail the structure of a guideline navigator.

Given two or more CIGs to be merged, a guideline navigator is used for each one of them, and the user-physician can operate independently on each one of them. Three basic operations are provided for focusing: ZOOM_IN, ZOOM_OUT, and SELECT.

The SELECT operation allows the user to create a new level of the navigator, which contains only the selected action (s).

The ZOOM-OUT operation recovers the penultimate expansion in a guideline navigator, deleting the last view.

The ZOOM-IN operation creates a new abstraction level in the guideline navigator, allowing for user-driven refinements. The definition of such an operation is quite complex, since it may consider refinements along different and heterogeneous levels of abstraction, and the user can operate recursively (i.e., decide to refine newly determined refinements).

The ZOOM-IN operation is applied on a guideline_navigator (gn1 in the algorithm in Figure 14), and modifies it, by appending a new guideline_view (New_View), which represents the new refinement. At the initialization step, the user has to specify which actions of the last guideline view of gn1 (s)he wants to modify (To_Refine_Set is initialized by such a set of actions). If To_Refine_Set is not empty, then New_View is created as a copy of the last view of gn1. Then, each action a in To_Refine_Set is independently refined, through the REFINE operation (see later). The REPLACE operation simply substitutes a with the newly identified refinements into New_View. Whenever a new refinement is added, we allow users to update To_Refine_Set, adding actions of the new refinement to it. In such a way, we provide users with the possibility of going on with this process until the desired level of detail is reached.

The REFINE operation takes in input a guideline_view (gv) and a action in it, and performs one step of refinement. The way in which such a refinement is obtained depends on the type of a. If a is a composite action in the guideline_view gv, its expansion is simply the sub-guideline constituted by the actions composing it. Thus, the refinement can be easily determined on the basis of the description of the guideline gv itself. On the other hand, if a is a pharmacological action, the representation of a contains the attribute substance, whose value is a link to the ontological entity representing drug category to be administered (drug_cat). Thus, through the Down operator, the algorithm determines the set of descendants of drug_cat in the ISA hierarchy in the ontology (the case in which a is a specific drug is a degenerate one, in which the result of Down is empty). Of course, each one of the descendants c₁, …,c_n is a possible alternative refinement of drug_cat. To convert this notion into a guideline-like format, the function BUILD_ALTERNATIVES constructs a new piece of guideline, consisting of a decision node connected to n pharmacological action nodes (each one prescribing one of the drug categories c₁, …,c_n). We worked at an OWL implementation of the ontology queries that are part of the algorithms, thus we highlight them in the figures. We expresses queries through the Manchester syntax (http://www.w3.org/2007/OWL/wiki/ManchesterSyntax) for OWL-DL, supported by Protégé reasoners. In the Figure 15, for example, the descendants of the substance of the action a are obtained through the query:

“(Drug or DrugCategory) and isA some (inverse substance value a)”.

The nested query “inverse substance value a” retrieves all the drugs or drug categories linked to the action a^e, while the external one returns all the elements in the ontology that are directly descendants of at least one of the first (in this case, inheritance is not considered along isA arcs).

Interaction analysis algorithm

Once the level of abstraction of the analysis has been specified by the user-physician, through the focusing tool, (s)he may look for the interactions at the chosen level. Though the Interaction analysis easily applies also to cases in which more than two CIGs are considered, for the sake of brevity here we consider only the case of two CIGs. After the focusing analysis, the user-physician has determined exactly which parts of the CIGs (s)he is interested in, possibly expanding CIGs with the ontology (e.g., expanding a pharmacological action prescribing a drug category into a therapeutic decision followed by the actions of administering its sub-categories), to reach the desired level of abstraction/detail. At this point, the interaction analysis tool operates as described in the ANALYSE_INTERACTIONS operation below (see Figure 16).

Given two guideline views gv1 and gv2, all composite, work and pharmacological actions are considered. The set of pairs of actions <a1, a2> such that a1 belongs to gv1, and a2 belongs to gv2 is constructed (intPairSet), and the result (intTripleSet) is initialized to the empty set. Notice that intTripleSet is a set of triples <a1, a2,interactions>, where <a1, a2> is a pair in intPairSet, and interactions is a set of interactions (the possible interactions between a1 and a2). Then, for each pair <a1, a2> in intPairSet, the algorithms of interaction search are applied, returning the set interactions of possible interactions (see the algorithms below), and the triple <a1, a2, interactions> is added to the set intTripleSet.

Interaction search algorithms operate only on pairs of “homogeneous” actions. Indeed, this is not restrictive, since we provide user with operators (ZOOM-IN, ZOOM-OUT) to choose the desired level of abstraction. If a1 and a2 are both composite or work actions, the interactions between their intentions have to be analyzed in the ontology. In our ontology, pharmacological actions have intentions (indeed, atomic intentions), and prescribe the administration of drug categories (or drugs). Thus, both the interactions between intentions and those between drug categories (or drugs) are considered. However, in the case of pharmacological actions added to the CIG by the expansion step (see BUILD_ALTERNATIVES in the REFINE operator), no intention is specified (the system cannot automatically determine action intentions), so that only the interactions between the prescribed drug categories (drugs) are considered.

Given two actions a1 and a2, FIND_INTENTION_INTERACTIONS finds the interactions between their intentions. Since actions in CIGs may have multiple intentions, all of them are retrieved (considering the aimsTo arcs exiting a1 and a2 in the ontology). Two types of intention interactions are captured by the algorithm FIND_INTENTION_INTERACTIONS in the following. The first type (onto_interactions in the algorithm) is determined by looking at the ontological information. For each pair <i1,i2> of intentions (such that i1 is an intention of a1 and i2 of a2), the ontology is explored (by following backward the arc hasElement of the concept IntentionInteraction) in order to determine the interaction holding between them. Then, the retrieved interaction is added to the set onto_interactions. On the other hand, some interactions between atomic intentions can be automatically inferred even if they are not directly specified in the ontology. Specifically, if two intentions concern the same BodyPartAttribute, but involve different variations for it, the respective interaction can be automatically inferred. Such a second type of interactions is determined by the second part of algorithm. In particular, if two intentions share the same value of Modality, their interaction is classified as “Concordance”, whilst, in other cases, its classification is “Discordance”, with a specific case in which the modalities are opposite (“Decreasing” and “Increasing”) and the interaction type is “Opposite”. Such interactions are added to the ontology, and the union of the two types of interactions is returned as output.

Finally, FIND_DRUG_INTERACTIONS is defined in a similar way but, obviously, involves searching the ontology for different paths of arcs.

For both the algorithms, we provide an implementation based on OWL. As previously exposed, the FIND_INTENTION_INTERACTIONS needs to retrieve two types of interactions: those that already exist into the knowledge base and those that can be automatically inferred starting from it The first phase of the algorithm (see Figure 17) consists in a query that retrieves all the IntentionInteractions between the set of intentions of the first action a1 and the one of a2. The resulting set of interactions (that corresponds to the onto_interactions) is not exhaustive because the ontology does not contain the interactions between all the possible couples of intentions. At this point we need to infer the interaction type between each couple of intentions <i1,i2>, belonging respectively to a1 and a2 sets, that have not a corresponding interaction in onto_interactions. In order to achieve this objective we extended the ontology through a set of Semantic Web Rules (http://www.w3.org/Submission/SWRL/) and we use them in order to assign to each interaction an inferred type. An interaction regarding i1 and i2 is added to the ontology (in the algorithm, for the sake of brevity, we denote as ‘new IntentionInteraction’ a constructor that creates the individual and the arcs hasElement to i1 and i2), then rules added an arc hasType if they recognize automatically a type for that interaction. Rules can automatically recognize both “Concordance” and “Discordance” types (included the “Opposite” one), also considering inheritance of BodyPartAttributes. For example, the following couple of rules infer a “Discordance” type considering inheritance:

IntentionInteraction(?inter), hasElement(?inter,?i1), hasElement(?inter,?i2), focusOn(?i1,?bpa), focusOn(?i2,?bpa2), isA(?bpa2,?bpa), hasModality(?i1,?mod1), hasModality(?i2,?mod2), DifferentFrom (?mod1,?mod2)

-> hasType(?inter, discordance)

The above rule creates an arc hasType that reaches ‘Discordance’, starting from an IntentionInteraction inter that has two elements i1 and i2 that focus on two BodyPartAttributes which are, in the isA hierarchy, one an ancestor of the other and which have different modalities. For the sake of brevity, we omit other similar rules, such as the one for inferring ‘Concordance’. Due to the Open World Assumption intrinsic in OWL reasoners, the ‘Independence’ type cannot be automatically inferred, but we consider independent all those interactions that have not an interaction type after the application of the above rules.

The last step of the algorithm consist in a second query on the extended ontology. This query is equal to the first one. However, at this time the resulting set of interactions contains also the interactions added in the second part of the algorithm.

The algorithm FIND_DRUG_INTERACTIONS (Figure 17) is simpler, because the interactions between drugs are explicitly stored in the ontology. It is consists of a query that retrieves all the drug category interactions or drug interactions that involve at least one drug (or drug category) recommended by the action a1 and one recommended by a2 (following forward the substance arcs).

Use of CIG tools

Obviously, the main users of CPGs, and of their computerized versions (CIGs), are physicians. Indeed, the primary goal of CPGs is to support physicians in their decision making activities, providing them with appropriate evidence-based recommendations for the diagnosis and/or treatment of a specific disease. CIG approaches further enhance the support to physicians, e.g., automatically focusing on the specific part of the clinical guideline under actual consideration, and automatically “customizing” the guideline to the specific patient at hand, thanks to an automatic connection to the Patient Health Record. Several advanced CIG approaches can be used by physicians to have different forms of decision support. For instance, the approach in Terenziani et al. (2002) provides physicians with “What If” analysis, and the methodology in (Montani and Terenziani 2006; Anselma et al. 2011) applies standard Decision Theory concepts to the CPG context, in order to provide to user-physicians a cost/benefit analysis (where costs are estimated as Quality Adjusted Life Years (Gold et al. 1996)). The treatment of several diseases (e.g., many chronic diseases) involves several actors (e.g., caregivers, family and hospital physicians, community physicians) not geographically co-located. In such a case, CIG approaches like the one in Bottrighi et al. (2013) can provide crucial advantages for agent coordination and delegation, granting for the continuity and the quality of the treatment, as well as for its optimization.

Interestingly, also patients may be direct users of some CIG tool. The recent European project MobiGuide (http://www.mobiguide-project.eu/) aims to provide personalized secure clinical-guideline-based guidance to monitored patients also outside the clinical environment. In such a project, users are provided with software tools helping them to personalize certain cost/utility decisions, and to directly access CIGs recommendations.

On the other hand, the healthcare managers’ perspective is quite different: they are not generally involved in the application of a specific CIG to a specific patient. However, they are focused on clinical processes, on their quality, and on their optimization. Thus, they can use the consultation facilities provided by CIG approaches in order to have a general view of how clinical processes should be organized, according to the best-practice derived from the medical evidence. In addition, managers can use approaches such as Bottrighi et al. (2012) in order to check the adherence (conformance) of the clinical processes executed in one or more healthcare organizations with the best-practice processes suggested by CIGs. This analysis might be helpful not only to study the quality of the treatments provided, but also for cost/process optimization purposes. Finally, and more important, healthcare managers are involved in the definition and application of healthcare processes in their organizations. Usually, CPGs are “general” bodies of knowledge, often developed by national/international committees, providing “high-level” best-practice recommendations and procedures. Thus, there is often quite a huge gap between general CPGs (and CIGs) and the actual procedures executed in a specific organization (e.g., in a specific hospital). Both local restrictions (e.g., not all the technological instruments are available in all the hospitals) and local optimizations must be considered, to contextualize a general CIG to a specific organization. So far few software tools have been developed to help managers in such a challenging task (consider, e.g., Terenziani et al. (2002)).

General advantages provided by the adoption of CIGs

The adoption of CPGs and, in particular, of CIGs, provides crucial advantages. CIGs provide decision support to physicians, giving them evidence-based recommendations on the treatment of a specific patient, considering patient’s data (CIG tools usually support an automatic retrieval of patient’s relevant data from the Patient Health Record).

Of course, the main gain is for individual patients, since CIGs enforce the quality of healthcare treatments, on the basis of the up-to-date medical evidence.

However, a major gain is also provided to healthcare managers and organizations. As a matter of fact, the adoption of CIG in a (local, regional, national, or even international) healthcare organization provides crucial advantages such as

–A guarantee about the quality of the provided healthcare services (since they are dictated by the most up-to-date medical knowledge and evidence)

–A guarantee about the standardization of such services. This issue may be crucial in several geographically “sparse” and not-homogeneous regions, or countries.

–A support in the coordination of healthcare services (for treatments that involve multiple and not geographically co-located actors)

–A support for process and cost optimization (still granting the quality of services).

However, it is important to remember that CPGs are, roughly speaking, a set of evidence-based recommendations about the treatment of patients affected by one specific disease. Thus, they apply to “typical” patients, affected by a disease. Specific patients, with specific (and atypical, from the point of view of the treated disease) conditions, may not be suited for the treatments suggested by the evidence-based CPG. In such cases, it is usually up to the physician to understand that the patient is, somehow, atypical for the CPG, and to identify the appropriate adaptations of the treatment suggested by the CPG.

The identification of the adaptations is particularly challenging for co-morbid patients, who, having two or more diseases, are “atypical” (with respect to the CPGs coping with such diseases, independently of each others). This issue is addressed by the approach presented in this paper.

Advantages and uses of our approach for interaction detection

In particular, both physicians and managers can use the approach described in this paper.

First of all, our approach can support a physician treating a specific comorbid patient. In such a context, the possibility of moving down from the “general” actions in the CIGs to the analysis of the interactions of specific drug categories and also of specific drugs is of paramount importance.

However, thanks to its generality, our approach can be used also for the “abstract” analysis (i.e., just considering the guidelines, with no reference to a specific patient) of the interactions between two or more guidelines that are commonly used together, with the final goal of providing some combined guideline (or, at least, part of it) merging them. In such a case, the possibility of reasoning also about “high-level” actions\tasks in CIGs is certainly crucial.

The analysis of interactions and the “partial merge” of two CIGs may be carried on by managers and physicians, and may lead to new clinical procedures that ensure both clinical quality and optimization of costs. The detection and analysis of interactions is a crucial step in order to achieve such a goal:

–“negative” interactions (e.g., interactions in which one drug decreases the effect of the other, or, even worst, has the opposite effect of the other) are (usually) to be avoided, since they may be dangerous for the patient and, anyway, are not cost effective.

–“positive” interactions (e.g., interactions in which one drug decreases the effect of the other, or has the same effect of the other) are (usually) desirable, because they achieve the “common” goals of the two guidelines. Of course, if two actions, one in a guideline and one in the other, achieve the same goal and have similar clinical side effects, one (the most costly) of the two may be omitted in the “combination of guidelines”, to optimize costs. Moreover, in the cases of administration of drugs “reinforcing” each other’s effects, the drug posology may be reduced, thus also reducing the cost of treatments.

In general, we strongly believe that, giving the increasing number of co-morbid patients (also due to the increasing aging of the population in many countries), and the social impact of co-morbidities, the definition of new clinical patterns which are both evidence-based and optimized is likely to have a significant positive impact in local and/or national/international healthcare systems and organizations.