Main features of the GLARE system
GLARE is a long-term project started in 1997 to provide a user-friendly and domain-independent tool to support CIG acquisition, representation and execution, and to provide the physician with a wide range of facilities, helping her/him in decision support or CIG analysis tasks. The main goals of the GLARE systems are:
–to be domain-independent. In particular, GLARE has been already applied to deal with a wide range of CIG, ranging, e.g., from asthma to ischemic stroke.
–to be user-friendly. GLARE is intended to be a tool to support physicians (in particular, regarding decision making), not at all to replace them. Such a goal has several implications, including the facts that (i) CIGs representation language must be as close as possible to the physicians’ way of looking at it, and (ii) the “technological” complexity of the system must be hidden to the user-physicians, through a user-friendly and easy-to-use interface.
–to be easily extendable. Indeed, physicians should be provided with plenty of facilities concerning CIG treatment. Thus, the system architecture must be modular and easily extendable.
Of course, each one of the above tasks has deeply influenced the design of GLARE, and its main features.
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.
In order to be as physician-friendly as possible, a limited and “physician oriented” number of types of atomic actions have been identified:
-
work actions, i.e. actions that describe a procedure which must be executed at a given point of the GL;
-
pharmaceutical actions, specifying a drug (or drug category, of active principle) to be administered to the patient, and the posology.
-
decision actions, used to model the selection among different alternatives. We have introduced a distinction between:
-
diagnostic decisions, used to make explicit the identification of the disease the patient is suffering from, among a set of possible diseases, compatible with her findings. A diagnostic decision is represented as an open set of triples <diagnosis, parameter, score> (where, in turn, a parameter is a triple <data, attribute, value>), plus a threshold to be compared with the different diagnoses’ scores;
-
therapeutic decisions, used to represent the choice between paths in a GL, where each path represents a particular therapeutic process. The choice can be made by evaluating a fixed set of parameters (effectiveness, cost, side-effects, compliance and duration);
-
query actions, i.e. requests of information (typically patient’s parameters), that can be obtained from the outside world (physicians, databases, patient visits or interviews). The GL execution cannot go on until this information has been obtained;
-
conclusions, which explicitly identify the output of a decision action.
In particular, the distinction between diagnostic and therapeutic decisions is very fundamental to physicians, and constitutes one of the features that distinguish GLARE from most CIG approaches in the literature. Each kind of action is described by a set of properties. For instance, a pharmaceutical action is described by:
-
Action Type, which for each action of this category takes the value “Administration of Medicament”,
-
Substance, which describes the administered drug,
-
Posology, which describes the dosage and the modality of assumption. This property structure is complex, since it might involve the description of periodicity (Anselma et al. 2006).
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.
Interactions: ontological notions
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 DrugCategoryInteractionsb. 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).
Interactions detection algorithms
It is worth stressing again that interaction detection should be performed at different levels of abstraction, since, in several cases, top-down refinement along the different hierarchies is needed to detect specific interactions. Of course, results strictly depend on the level of abstraction chosen by the user physician. For instance, some interactions can be discovered considering the higher abstraction level of Intentions.
Example 5. Diuretics are a category of drugs frequently used for the treatment of edema (intention). In the case that a patient affected by edema should be treated for hypertension (intention: “decrease blood pressure”), the physician may administer ACE inhibitors or calcium channel blockers. Most of the drugs belonging to these categories do not present explicit interactions with diuretics; however, as shown in Figure
5
, the intention of diuretics ( i.e., “decrease blood volume” in the Figure
5
), of ACE inhibitors ( i.e., “inhibition of ACE”) and of calcium channel blockers ( i.e., “block of calcium channels”) are all sub intentions (ISA arcs in the figure) of the same high-level intention “decrease blood pressure”. Therefore, the physician can decide to change the posology of the administered drugs.
Other interactions come out only at the lowest abstraction level of Atomic Intentions (e.g., of the pharmacological prescription actions).
Example 6.
One of the sub-intentions of the high-level intention to “decrease the urinary retention” is to stimulate contraction of the bladder. That, in turn, can be obtained through the stimulation of the muscarinic receptors (atomic intention), administering, for example, bethanechol
c
(drug). If the patient is affected by peptic ulcer a parallel intention should be to decrease the gastric acid secretion, that can be obtained by the inhibition of the muscarinic receptors (atomic intention), administering pirenzepine
d
(drug). The two atomic intentions are obviously conflicting.
In other cases, interactions may show up only at the drug category level: pharmacological actions may have independent intentions, but the drug categories they imply may interact with each other.
Example 7.
Vasoconstrictors (drug category), for instance adrenaline (drug), reduce the absorption of the lidocaine (drug), which is a local anesthetic (drug category), enhancing its effect. However, anesthetic intention (for lidocaine) and treatment of anaphylaxis (one of the intentions of adrenaline) do not interact.
Last, some interactions can be detected only at the lowest level, considering specific drugs.
Example 8.
Warfarin (drug) is an anticoagulant (drug category) used to prevent the formation of thrombi (intention), whilst erythromycin (drug) is an antibiotic (drug category) commonly used, for instance, in the treatment of respiratory tract infections (intention). There is no interaction between the two categories they belong to; however, the anticoagulant effect of warfarin is enhanced by the simultaneous use of erythromycin.
Our focusing tool is quite innovative, since it allows the physician to navigate both knowledge sources (the CIGs and the ontology) together, thus complementing the general knowledge in the CIGs with the additional knowledge in the ontology.
In this section, we will describe a new methodology to explore the above-mentioned knowledge sources in an interactive and flexible way. In Section “Main features of the GLARE system”, we have shown that GLARE (as well as most CIG formalisms) supports different abstraction levels (through the part-of hierarchy of actions) in the description of CPGs. In Section “Interactions: ontological notions”, we have described how our ontology supports the description of different types of interactions at the different abstraction levels, describing not only interactions between general intentions, but also more specific interactions between drug categories, and drugs.
Two main issues must be considered for the definition of an approach for detection of interaction considering the above knowledge sources
-
(1)
Integration between CIGs and ontology
-
(2)
Interactions with user-physicians.
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.
Abstractly speaking, in our approach, the integration of the knowledge in the CIG and the one in the ontology provides three main levels of detail (henceforth called “dimensions”) at which interactions can be studied:
-
(1)
Action dimension. This dimension is specified directly by the CIG, in which each composite action can be refined into its components (which, in turn, may be composite).
-
(2)
Drug category dimension. Such a dimension is specified by the ontology.
-
(3)
Drug dimension. Such a dimension is specified by the ontology, as the bottom level of the drug category hierarchy.
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
Summing up, as a result of the above consideration, our approach consists of two main tools:
-
(i)
a focusing tool, allowing physicians to navigate into the CIGs to be merged, selecting subparts of them and/or expanding/abstracting them at the chosen level of detail (considering all the three dimensions)
-
(ii)
an interaction analysis tool that, given the output of the focusing on two or more CIGs, analyses the interactions, at the level of abstraction chosen through the focusing tool.
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 c1, …,cn 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 c1, …,cn). 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 ae, 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).