META-GLARE: A meta-system for defining your own computer interpretable guideline system—Architecture and acquisition

Artificial Intelligence in Medicine 72 (2016) 22–41

Contents lists available at ScienceDirect

Artificial Intelligence in Medicine journal homepage: www.elsevier.com/locate/aiim

META-GLARE: A meta-system for defining your own computer interpretable guideline system—Architecture and acquisition Alessio Bottrighi ∗ , Paolo Terenziani Computer Science Institute, Dipartimento di Scienze e Innovazione Tecnologica, Universita’ del Piemonte Orientale, Viale Teresa Michel 11, 15121 Alessandria, Italy

a r t i c l e

i n f o

Article history: Received 11 September 2015 Received in revised form 22 July 2016 Accepted 25 July 2016 Keywords: Meta-modelling Formalization and acquisition of health-care models Computer interpretable guidelines

a b s t r a c t Context: Several different computer-assisted management systems of computer interpretable guidelines (CIGs) have been developed by the Artificial Intelligence in Medicine community. Each CIG system is characterized by a specific formalism to represent CIGs, and usually provides a manager to acquire, consult and execute them. Though there are several commonalities between most formalisms in the literature, each formalism has its own peculiarities. Objective: The goal of our work is to provide a flexible support to the extension or definition of CIGs formalisms, and of their acquisition and execution engines. Instead of defining “yet another CIG formalism and its manager”, we propose META-GLARE (META Guideline Acquisition, Representation, and Execution), a “meta”-system to define new CIG systems. Method and materials: In this paper, META-GLARE, a meta-system to define new CIG systems, is presented. We try to capture the commonalities among current CIG approaches, by providing (i) a general manager for the acquisition, consultation and execution of hierarchical graphs (representing the control flow of actions in CIGs), parameterized over the types of nodes and of arcs constituting it, and (ii) a library of different elementary components of guidelines nodes (actions) and arcs, in which each type definition involves the specification of how objects of this type can be acquired, consulted and executed. We provide generality and flexibility, by allowing free aggregations of such elementary components to define new primitive node and arc types. Results: We have drawn several experiments, in which we have used META-GLARE to build a CIG system (Experiment 1 in Section 8), or to extend it (Experiments 2 and 3). Such experiments show that METAGLARE provides a useful and easy-to-use support to such tasks. For instance, re-building the Guideline Acquisition, Representation, and Execution (GLARE) system using META-GLARE required less than one day (Experiment 1). Conclusions: META-GLARE is a meta-system for CIGs supporting fast prototyping. Since META-GLARE provides acquisition and execution engines that are parametric over the specific CIG formalism, it supports easy update and construction of CIG systems. © 2016 Elsevier B.V. All rights reserved.

1. Introduction Clinical practice guidelines (CPGs) represent the current understanding of the best clinical practice. In recent years the importance and the use of CPGs are increasing in order to improve the quality and to reduce the costs of health care. ICT technology can further enhance the impact of CPGs. In the last twenty years, many different systems and projects have been developed to manage computer

∗ Corresponding author. E-mail addresses: [email protected] (A. Bottrighi), [email protected] (P. Terenziani). http://dx.doi.org/10.1016/j.artmed.2016.07.002 0933-3657/© 2016 Elsevier B.V. All rights reserved.

interpretable guidelines (CIGs), see, e.g., the collections [1–3]. A comparison among some existing systems is described in [4]. A “consensus” book of a part of the CIG community has been published in 2008 [3]. An excellent survey including many different approaches has recently been proposed by Peleg [5] (see Sections 2.1 and 2.2 for a brief analysis of related works). Surveys and comparisons demonstrate that, though each approach proposes its own representation formalism, most approaches model CIGs as a task-network model (TNM): a hierarchical model of the guideline control flow as a network (graph) of specific tasks (represented by nodes). From the architecture point of view, most CIG systems provide specific support for at least two subtasks: (i) CIG acquisition and representation and (ii) CIG execu-

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

tion. However, there are also important diverging features between the different CIG systems, also due to the fact that many of such systems are mostly research tools that evolve and expand to cover an increasing number of phenomena/tasks. This is, for instance, the history of GLARE (Guideline Acquisition, Representation, and Execution), the prototypical system we have been building since 1996 in cooperation with ASU San Giovanni Battista in Turin, one of the major hospitals in Italy [6,7]. Unfortunately, at least in our experience, on the one hand it is quite frequent that due to the need to face a new real-world clinical guideline domain, some extensions to a CIG system are needed. On the other hand, such extensions are often quite complex and time consuming. In easy cases, the definition of the types of nodes used to represent actions have to be extended with new components (e.g., new attributes), so that the acquisition and consultation tools have to be extended to manage it (acquire it whenever a new instance of that type of node is created, store it, and show it during CIG consultation). In more complex cases, the new component may also affect node execution, so that the execution engine has to be modified, too (this was the case, for instance, when we added the treatment of “exceptions” to action nodes [8]). In a complex CIG system (like GLARE) such extensions require a quite large amount of work, since different parts of the code system must be modified, and their interactions considered. In the most complex cases, the amount of change in respect of a current system is so large that it might justify the development of a new system. For instance, this is the solution we were thinking of adopting when considering the use of GLARE for the education task. On the other hand, in research contexts it is very important to be able to easily and quickly extend systems, and to achieve fast prototyping when facing new domains and/or tasks. With such goals in mind, we started to re-design GLARE. Initially, we started to analyse also many other CIG systems in the literature, with the goal of building a new general system, encompassing many of them. In particular, we were aiming to identify a general formalism, enclosing the “best features” of current ones. However, such an initial objective, though quite ambitious, has at least two main disadvantages: (1) such a new general formalism would certainly be rich, general, and complex. These features somehow contrast with the fact that CIGs have to be acquired (with the cooperation of knowledge engineers) by expert-physicians, and have to be consulted/used by general practitioners. It is not reasonable practically to assume that physicians and general practitioners have to learn, understand (and possibly use, during CIG acquisition) very complex formalisms, possibly containing plenty of features that they do not need in the specific application domain they are considering; (2) the long-term experience of artificial intelligence research has shown that there is no “perfect” formalism. Whatever general CIG formalism may be defined it can still require extensions, when facing new (unexpected by the formalism designers) phenomena. As a consequence of (1) and (2), we decided to pursue a completely different and innovative goal: instead of defining “yet another new CIG formalism and system”, we chose to devise a “meta-system”, or, in other words, a shell supporting the definition of new CIG formalisms and systems (or facilitating the extensions of them). Our meta-system, called META-GLARE (META Guideline Acquisition, Representation, and Execution): (i) makes “minimal” assumptions about the CIG formalisms (basically, it simply assumes that CIGs are represented through TNM)

23

(ii) provides general acquisition, consultation and execution engines, that are parametric over the specific CIG formalism being considered (in other words, the CIG formalism is an input of such engines)

The core idea of our meta-approach is:

(i) to define an open library of elementary components (e.g., textual attribute, Boolean condition, Score-based decision), each of which was equipped with methods for acquiring, storing, consulting and executing it; (ii) to provide system-designers with an easy way of aggregating such components to define node and arc types (constituting the representation formalism of a new system); (iii) to devise general and basic tools for the acquisition, consultation and execution of CIGs, represented by TNMs which are parametric over the node and arc types (in the sense that the definition of node and arc types are an input for such tools); (iv) to couple each part of a system (e.g., elementary components, node definitions, system definition) with a declarative description of its main features and composition (automatically built during the system acquisition).

1.1. Advantages In such a way, we achieve several advantages (further discussed in Section 8, through the treatment of some concrete examples of use of META-GLARE):

(1) the definition of a new system (based on a new representation formalism) is easy and quick. Using META-GLARE, a system designer can easily define her/his own new system, basically by defining its formalism: (i) the node types, (ii) the arc types (both are defined types as an aggregation of components from the library), and (possibly) the constraints on the way they can be connected in the graph. No other effort (e.g., building acquisition or execution modules) is needed; (2) the extension of an existing system (through the modification of the representation formalism) is easy and quick. Using METAGLARE, a system designer can easily extend a system by defining and adding new node/arc types (by defining their components), or adding/deleting components to already existing types (with no programming effort at all; notice that the treatment of versioning is outside the goals of the current paper); (3) user programming is needed only in case a new type of component (i.e., not already present in the library) is used (e.g., in the definition of a new node type). In such a case, the new type of component has to be added to the component library. However, the addition is modular and minimal: the system designer has just to focus on the added component, and to provide the code for acquiring, consulting, and (if needed) execute it. Notably, such programming is completely “local” and “modular”: the new methods have to be programmed “in isolation” (without having to care about the rest of the system). In particular, neither the acquisition engine nor the execution engine have to be modified. Indeed, no modification to any software component in META-GLARE architecture (see Fig. 1 below) is required to integrate the new methods: META-GLARE automatically evokes them when needed during acquisition, consultation and execution. (4) as a consequence, fast prototyping of the new (or extended) system is achieved.

24

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

1.2. Comparisons To achieve the above goals, we adopt meta-programming techniques. The techniques adopted in META-GLARE are not entirely new within Computer Science (see the discussion in Section 7). On the other hand, META-GLARE is unique in its extensive application of metaprogramming in the context of CIGs. In such a context, “traditional” systems (such as PROforma [9], GLARE [6,7], GPROVE [10], GUIDE [11], PRODIGY [12]) are tailored to the acquisition and execution of CIGs expressed through a specific formalism. If the formalism has to be changed (e.g., to cope with new phenomena in new applicative domains), programming is extensively needed to modify the CIG acquisition and execution tools. This is, of course, complex, time consuming and costly. On the other hand, Protégé [13] and DeGeL [14] are frameworks coping, more generally, with multiple ontologies. They provide a formalism acquisition tool to acquire new CIG formalism, and provide “for free” the tool for acquiring CIGs in such a formalism. However, if the formalism is changed (through the formalism acquisition tool), programming is needed to modify the CIG execution tool. Differently from such approaches, META-GLARE fully applies the meta-programming methodology, providing also specific supports for CIG execution. Both META-GLARE CIG acquisition and CIG execution tools are parametric concerning the CIG formalism. Therefore, changing a formalism only requires the acquisition of the changes (through META-GLARE formalism acquisition tool), while no modification to the CIG acquisition and CIG execution tools is needed: META-GLARE automatically “adapts” its CIG acquisition and CIG execution tools to cope with the modified formalism. Such an approach is an absolute novelty and a major advance in the area of CIGs, granting fast prototyping of new or modified systems (based on new\modified formalism). Given their high innovative degree, and their relevance, such topics will be analysed more in-depth in Section 7, after the full presentation of META-GLARE methodology. Examples will be provided in Section 8. In this paper, we describe META-GLARE. While in Section 2 we describe the general architecture of META-GLARE, for the sake of brevity, in the rest of the paper we mainly focus on acquisition only. Section 3 describes our meta-formalism, Section 4 the acquisition of a new formalism, and Section 5 the acquisition of a new CIG in a given (previously acquired) formalism. For the sake of completeness, in Section 6 we briefly address META-GLARE execution engine. Section 7 widely discusses the advances of META-GLARE regarding the state of the art, and Section 8 exemplifies them, proposing several examples of applications. 2. META-GLARE architecture The possibility of building a meta-system is based on the one hand on the ability to identify and isolate the commonalities between the different systems, at a high level of abstraction, and on the other hand on the capacity to provide proper tools to generate and “personalize” a new system, with the minimum possible (computational) effort. Therefore, before providing the architecture of META-GLARE, we point out, at a high level of abstraction, what the commonalities it takes into account are, and what kind of “personalizations” it supports. 2.1. Related work: CIG systems and their representation formalisms In the last two decades, several CIG systems have been introduced, each one characterized by a specifc formalism to represent CPGs. CIG formalisms are usually based on a TNM: a (hierarchical)

model of the guideline control flow as a network of specific tasks. Such formalisms are “formal” and allow one to unambiguously represent guideline procedures and recommendations. Besides supporting formal languages to acquire and represent CPGs, CIG systems usually also provide execution engines that allow user physicians to “instantiate” general guidelines on specific patients: by accessing the patient clinical data, the execution engine shows to the user physicians only those paths of actions that are applicable to the patient at hand. In such a way, they provide patient-oriented recommendations to physicians, allowing them to fulfill the gap between the CPG generality and the specificity of the patient at hand. Given such advantages, many CIG formalisms and systems have been designed/built in the last two decades. Some of them (the list is in alphabetic order, and is far from being exhaustive) are: Asbru [15], EON [16], DeGeL [14], GEM [17], GLARE [6,7], GLIF [18], GPROVE [10], GUIDE [11], PRODIGY [12], PROforma [9], SAGE [19]. A survey and/or a comparative analysis of these systems is outside the goals of this section. A comparison of Asbru, EON, GLIF, Guide, PROforma, PRODIGY can be found in [4]. An extension of such a comparision to GLARE and GPROVE has been done in [10]. The recent book by Ten Teije [3] represents a consensus of a large part of the computer-oriented CPG community. It presents an assessment of the state-of-the-art, as well as a collection of several recent approaches. Comprehensive surveys of the state-of-the-art about CIG have been already published [20–24]. Such surveys show that the reasearch in the area has achieved quite a consensus about the representation formalism. Although there are notable differences among the approaches, partly due to the different goals they pursue, some important commonalities have been reached. For example, most approaches to model guidelines adopt a TNM: a (hierarchical) model of the guideline control flow as a network of specific tasks. Although different terminologies have been used, all approaches support a basic set of core guideline tasks, such as decisions, actions and entry criteria. Decisions for example are represented by means of logic slots in the Arden Syntax, decision steps in GLIF, decision tasks in PROforma and GLARE, conditions in Asbru, and decisions in EON. The TNMs of most approaches define a fixed set of guideline tasks (one remarkable exception is EON, in which new types of tasks may be introduced). Most approaches also provide explicit support for controlled nesting of guidelines in order to model complex guidelines in terms of subguidelines (e.g., GLIF and EON) or subplans (e.g., PROforma, Asbru, GLARE). GLIF also supports the representation of common guideline structures through macros, which facilitates the reuse of guidelines that are used often (e.g., ‘if-then’ rules). EON, PROforma and Asbru also support the use of goals and intentions to formally specify a guideline on a higher level of abstraction. From the architecture point of view, most CIG approaches provide specific support for at least two subtasks: (i) CPG acquisition and representation and (ii) CPG execution. Concerning acquisition, several issues have been addressed, ranging from the definition of suitable graphical interfaces to enhance the physician-system interaction, to the definition of set of tools supporting the progressive transformation from a textual CPG to its formal representation [25–30]. Execution, intended as the process of applying the recommendations of a specific CIG to a specific patient, is also supported, usually providing both an execution engine and a graphical interface to support user-friendly interaction with physicians. Some approaches, like, e.g., GLARE [6,7], also provide (iii) a dedicated consultation tool, which support physicians in the “abstract” (i.e., “patient-independent”) study\analysis of the content of a CIG. Despite their differences, CIG systems are characterized by the adoption of a specific formalism to represent guidelines, and their acquisition, consultation and execution tools are strictly geared towards the specific formalism. For instance, different types of nodes

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

(actions) have been proposed by different approaches, and their acquisition (and consultation, and execution) tool specify exactly how to acquire (consult, execute) each type. The core idea of our approach is simple: to build a meta-system, representation and interpretation (henceforth, we use “interpretation” as a cover term for acquisition, consultation and execution) must be decoupled. Moreover, since our meta-interpreter must be general enough to interpret different formalisms, it must be based on the commonalities between them, and it must “parametrize” over their differences The first step of our approach is therefore the identification of the “high-level” commonalities between different CIG formalisms that we want to capture in META-GLARE. 2.2. Commonalities between CIG formalisms In this subsection, we briefly point out the main commonalities between CIG formalisms on which we grounded META-GLARE (a detailed analysis of META-GLARE “template” to define new CIG formalisms is proposed in Section 3). Proceeding in a “top-down” analysis, “high-level” commonalities concern the notions of (2.2.1) graph, (2.2.2) nodes and arcs types (2.2.3) attribute types. 2.2.1. Graphs Though there are several exceptions (such as, e.g., systems based on Arden Syntax [31]), many CIG systems represent guidelines as hierarchical graphs. Different types of nodes and arcs are used. Graphs are often hierarchical, in that non-atomic types of nodes are allowed, representing, in turn, a hierarchical graph. In several approaches, there are also “meaning” constraints regulating the possible relationships between node types and arc types, or general constraints about the graph structure. For instance, in GLARE, multiple arcs can only exit from specific types of nodes, i.e., decision nodes, and graphs must be acyclic. 2.2.2. Node and arc types Quite different types of nodes and arcs have been provided in the literature. The main commonality is that each type (of node and of arc) is defined as a set of attributes. 2.2.3. Attribute types There is a huge variety of such attributes, ranging from purely textual attributes (e.g., the textual description of the action performed) to complex attributes such as those used to embody (score-based or Boolean) conditions and/or decisions. In particular, in the following we distinguish between control and non-control attributes, where control attributes are those attributes that affect the (flow of) execution of CIGs. 2.3. Towards a “meta” interpreter of CIG formalisms Given the analysis above, our meta-interpreter (i) deals with hierarchical graphs, and (ii) abstracts from the types of nodes and arcs, and the constraints between them, and the types of attributes. Thus, our interpreter (guideline acquisition, consultation and execution tools) only assumes that a guideline is a hierarchical graph, and is parametrized on the features in it (ii). How is it possible to actually make it effective? There is only one solution: enforcing a strict compositional structure thoughout the meta-system. Indeed, one of the central ideas of our approach is that the interpretation of a graph consists of two main components:

25

(i) management of the high-level graph (without considering the type and content of the arc/nodes constituting it); (ii) management of each node/arc. The management of the high-level graph can be managed by extending standard algorithms (to create and navigate graphs), in such a way that they are parametric over the types of nodes and arcs they deal with. On the other hand, the management of (the content of) each node/arc type is obtained through the sequenced interpretation of the attributes composing it. This means that, practically, each attribute type (e.g., textual attribute, Boolean condition attribute, etc.) must consist of the methods to acquire, consult, and execute it (for control attributes only). Thus, for instance, guideline acquisition consists in the acquisition of a hierarchical graph, which in turn adopts the methods in each attribute type definition to acquire the specific attributes of the involved nodes/arcs (see Section 4 for more details; notably, the same compositional method also applies to consultation and execution).

2.4. Preliminaries: two important distinctions Before moving on, it is important discuss two important distinctions.

2.4.1. CIG formalism acquisition vs. CIG acquisition Two different kinds of acquisition are provided by our metasystem: (1.) the formalism acquisition tool, which assists the systemdesigner in the definition of its own CIG (system) formalism, and (2.) the guideline acquisition tool, which assists a team of physicians and/or knowledge engineers in the acquisition of a specific CIG (e.g., the ischemic stroke guideline) using a specific (system) formalism (already acquired, see point 1). Of couse, the two acquisitions are very different. The first one is used just in case a system designer wants to define his/her own new system or to modify an existing one. Once a system has been acquired, it can be used “forever”, to acquire (and consult, and execute) many different clinical guidelines.

2.4.2. CIG formalism vs. (medical) ontology META-GLARE is a system that supports the definition of new CIG formalisms (see point (1) above). Such formalisms have not to be confused with medical ontologies, (e.g., SNOMED [32], ATC [33]). A CIG formalism is a set of constructs (mainly node types and arc types) which are then instantiated to assume specific values (for their attributes) when the formalism is used in order to acquire a specific CIG (see point (2) above). Ontologies can be exploited during such an instantiation, to provide standard ontological references to the values that are assumed by (the attributes of) nodes and arcs. For example, a formalism may contain the type of node “pharmacological prescription”, described by several attributes (e.g., “name”, “posology”, “drug category”), some of which (e.g., “drug category”) may be constrained to assume as a value (symbolic pointer to) a concept in an ontology (e.g., in the ATC ontology). Indeed, in META-GLARE we support the fact that different ontologies may be used to specify the values of some attribute of nodes and arcs (but META-GLARE is definitely not a tool to support the construction of medical ontologies).

26

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

2.5. META-GLARE general architecture In Fig. 1, we show the general architecture of META-GLARE. Oval nodes represent data structures, and rectangles represent computational modules. The DEFINITION EDITOR module (whose internal architecture will be further detailed and analyzed in Section 4) supports systemdesigners in the definition of a new (system) formalism (or a modification of a previously defined one). The output is the definition of a new (system) formalism, encoded in XML, and stored in a Library consisting of five main components: Fig. 1. The general architecture of META-GLARE.

(i) the attribute type definitions (e.g., “Boolean condition”); it includes, besides several other pieces of information, the (symbolic pointers to the) methods to acquire, store, consult and (in the case of control attribute) execute them; (ii) the definition of node types, each one basically defined as an ordered list of attributes (whose types must be present in the library: see point (i) above); (iii) the definition of arc types, each one basically defined as an ordered list of attributes (whose types must be present in the library: see point (i) above); (iv) the definition of constraints on the composition of node/arcs in graphs representing CIGs (a typical constraint might be due to the fact that the hierarchical graph must be acyclic). Such constraints are directly expressed by (symbolic pointers to) Java methods enforcing them; (v) the definition of CIG formalisms, each one basically characterized by the set of types of nodes and arcs it adopts (see points (ii) and (iii)) and possibly a set of constraints regulating the relationships between such nodes/arcs (see point (iv)).

Globally, the DEFINITION EDITOR manages the definition of a specific CIG formalism. On the other hand, the HG INTERPRETER deals with the aspects which are formalism-independent (i.e., common to all the systems that can be generated by META-GLARE; notably, HG is an acronym for “Hierarchical Graph”). It consists of three sub-components: HG ACQUISITION, HG CONSULTATION, and HG EXECUTION. All of them are based on the compositionality criterion discussed in Section 2.3. In this paper, for the sake of brevity we focus on the HG ACQUISITION module only (in Section 4; for the sake of completeness, the cue-points of the HGEXECUTION module are briefly sketched in Section 6). Finally, the CIG DOCUMENTATION ACQ module is used in order to acquire the “documentation” information concerning a specific CIG (e.g., who are the authors, when the guideline was first produced, the data of its last update, the documentation on which it is based, and so on). We think that the treatment of such documentation can be regarded as independent of the specific (system) formalism. The CIG DOCUMENTATION ACQ produces an XML file which is an input of HG ACQUISITION, which adds it to the description of the specific guidelines. The acquisition and representation of such metadata is largely based on GLIF3’s approach [18], and is not discussed in the rest of this paper. META-GLARE and its modules are developed as Java Applets [34] (thus methods in Fig. 1 are implemented by Java classes). In this way, META-GLARE is a cross-platform application: it can be embedded into a web page and executed via web browsers without any installation phase. The libraries in Fig. 1 are implemented by a database stored in PostgreSQL [35], which is one of most popular free and open source database management systems.

Fig. 2. General graphical description of a computer interpretable guideline formalism definition in META-GLARE.

3. Definition of CIG formalisms In META-GLARE, system-designers can define their own CIG formalism. On the basis of such a definition, META-GLARE automatically provides them an engine to acquire, consult and execute (consultation and execution are out of the scope of this paper) any CIG, built on the basis of such a formalism. META-GLARE supports any CIG formalism (as introduced by the system-desiger), provided that it conforms to some general rules (which are based on the “commonalities” between CIG formalism that we have identified in Section 2.2 above). In the following, we describe META-GLARE “meta-formalism”, i.e. the formalism it adopts to define new CIG formalisms. As sketched in Section 2.2, in META-GLARE a CIG formalism is based on the notion of TNM: it is a hierarchical graph, fully characterized by its (types of) nodes and arcs and possibly, on graph constraints between them. In turn, nodes and arcs are characterized by the attributes describing them. In the following we detail such a concept. We proceed in a top-down fashion, starting from the notion of formalism (Section 3.1), and then moving towards nodes (Section 3.2), arcs (Section 3.3) and attributes (Section 3.4). In each section, (i) we first provide a general description of our “metaformalism”, taking advantage of a graphical presentation, and then (ii) we show a practical example of a specific instantiation of such a general “template”. The instantiations are described using XML, which is the actual implementation adopted by META-GLARE to store formalisms, nodes, arcs and constraints definitions. The XML file representing formalisms, node types, and arc types are stored in dedicated Libraries. Such libraries are implemented as a (relational) tables in PostgreSQL defined on two attributes: Name (i.e. the name of the formalism/node/arc), which is the unique identifier, and XMLfile, in which is stored the XML document describing the formalism/node/arc. 3.1. Formalism definition 3.1.1. Notation In this subsection, we list and explain the terminology used to describe the formalism in our approach:

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

27

Fig. 3. XML description of the formalism “GLAREformalism”.

formalism is characterized by the type of graph it describes, i.e. by three components: (i) the types of nodes constituting the graphs (ii) the types of arcs constituting the graphs (iii) the constraints on the graph

Fig. 4. General graphical description of a node type.

• a graph is a pair (N, A), where N is a set nodes and A a set of arcs; a graph is undirected when it contains only not-oriented arcs otherwise it is directed; a graph can be cyclic or acyclic. Undirected/direct and cyclic/acyclic are independent characteristics; • a node is a basic element of a graph, representing an action in a CIG; • an arc is a basic element of a graph which connects two or more nodes, and represents the execution flow of the CIG. An arc is oriented (e.g. an arc between a node n1 and a node n2 is not identical to an arc from a node n2 to a node n1 ) when the connection defined by the arc is ordered otherwise it is unoriented (e.g. an arc between node n1 and node n2 is identical to an arc between n2 and n1 ). The connections of an arc are definined trhough their ariety; • the ariety of an arc defines the number of nodes connected by such an arc. In the case of oriented arcs, it defines the cardinalities (i.e. dimensions) of the set of starting nodes and of the set of ending nodes; • the acyclic/cyclic property states whether a graph has or not cycles; • a cycle is a sequence of nodes starting and ending at the same node, in which each two consecutive nodes are connect by an arc.

3.1.2. Formalism description In META-GLARE, each formalism has a compulsory feature, called “FormalismName”, which is associated to the new formalism at the moment of its creation, and identifies it. Indeed, each

The first two attributes are compulsory, and are directly specified as sets of node and arc types respectively (see the attributes “Node types” and “Arc types” in Fig. 2). On the other hand, the last component (constraints on the graph) is optional and (if present) is simply constituted by a set of triple <“name”, “method”, “modality”>, where “name” contains the textual name for the constraint, and “method” the name of the method used to enforce such a constraint on graphs of this type, the “modality”, which specifies how the constraint will be checked (see subsection 5.4). Additionally, (and optionally) each formalism may indicate the ontologies (e.g., SNOMED [32]) it adopts to provide ontological references as values of (some) attributes of nodes/arcs. Notably, different ontologies may be pointed out (e.g., SNOMED for findings and actions, ATC for drugs [33]). Fig. 2 provides in a graphical way the general description of how a new formalism (i.e., a new type of graph) can be specified in META-GLARE. Different specific formalisms can be obtained, by instantiating such a general “template”. In META-GLARE, formalism definitions are stored as XML files. In the following, we show a concrete example of the representation of a formalism in META-GLARE. Example. In Fig. 3 we show how the formalism of our previous CIG system, GLARE [6,7], can be represented in META-GLARE. In the tag Formalism (line 1) the name of the formalism is defined by the XML attribute name, which, in the example, has value “GLAREformalism”. The tag (line 2) contains a set of node tags: one for each node type in the formalism. In GLAREformalism, there are six types of nodes (lines 3–8). In the tag node, the attribute type contains a pointer to the specific type of node (i.e. the name of node types is used as unique identifier), e.g. line 3 contains a pointer to the node type (identified by its name) “plan”. The tag and the tag arc are defined similarly. In Fig. 3, the tags arcs (lines 11–13) define the arc types constituing the formalims. An arc type is indentified like a node type, i.e. via its XML attribute type, which contains the pointer to the arc type. In the same way of nodes and arcs, the graph constraints are defined via the tag . For instance, GLAREformalism has one constraint (line 16), which is described by the XML attribute name. The constraint is called “acyclicity” (see the value of the XML attribute name) and its attribute type contains a pointer

28

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

Fig. 5. XML description of GLARE’s node type “workaction”.

to the method “it.glare.constraint.GLAREformalism.acyclicity”. The attribute modality specifies that the modality is “automatic”, i.e. the HG INTERPRETER checks automatically the constraints (i.e. it must not be triggered by the users). In lines 18–22 the ontologies used in GLAREformalism are specified. In particular, ATC (line 20) is the ontology for drugs (Ontology drug attribute). In GLARE formalism, the ontology for finding and action are not defined (i.e. line 19 and line 21, the values of the Ontology finding and of Ontology action are the empty string).  3.2. Node type definition Each type of node represents a general class of objects (e.g. diagnostic decision), characterized by an ordered list of attributes, each one describing a node attribute. Different instantiations of a node type can be obtained by fixing specific values (e.g. different instances of diagnostic decisions can be used in CIGs, characterized by specific values for the decision criteria attribute(s)). Fig. 4 in the following provides, in a graphical way, the general description of how a node type can be specified in META-GLARE. Different specific node types can be obtained, by instantiating such a general “template”. In META-GLARE, the attributes used to define node types are organized considering three different aspects: (1) whether they are compulsory or optional; (2) whether they are control attributes or not; (3) when they assume a specific value. Concerning issue (1), in META-GLARE each node type contains some compulsory attributes (such attributes are underlined in Fig. 4 and in Fig. 6), and a possibly empty ordered list of optional ones. Concerning issue (2), control attributes affects the flow of execution (i.e. they have an execution method, which has to be executed when the attribute is managed by the HG EXECUTION module). Concerning issue (3), in META-GLARE, node (and arc) attributes can assume specific values at completely different phases: (i) during the acquisition of the CIG formalism (“Class acq attr”, solid line box in Fig. 4); (ii) during the acquisition of a specific CIG (“Inst acq attr”, dashed line box in Fig. 4); (iii) during the execution of a specific CIG (“Inst exec attr”, dasheddot-dot-line box in Fig. 4); Specifically, concerning “Class acq attr” compulsory attributes, each type of node must have

Fig. 6. General graphical description of an arc type.

– a name (attribute “NodeType” in Fig. 4), – an icon for visualization (attribute “NodeIcon” in Fig. 4) and – a method for visualization (attribute “NodeVisual” in Fig. 4) Such attributes assume a specific value when the node type itself is acquired (by the system designer). This obviously implies that such a value is the same for all the instances of such a node type. Notably, besides associating each node with an icon, we also specify a phase task, user-type method (PTU-method) to visualize it. PTU-methods are methods which are parametric on at least one of the different aspects: phase, task, and user-type. PTU-methods will be discussed in Subsection 3.4 in the following. Moreover, the definition of node types must also include the specification of whether the node is atomic or composed (the actions can be further defined in terms of other actions via the has-part relation) (Boolean attribute “Atomic” in Fig. 4). On the other hand, concerning “Inst acq attr” compulsory attributes, each instance of a node type must have a name (attribute “NodeName”), which is given at the time of the instantiation of the node type, i.e. at the creation of a specific instance of that type during the acquisition of a specific CIG (by the expert physicians). Notably, the attribute name may be constrained to be a pointer to an ontological concept (this effect can be obtained by setting to “Ontology Action string” the type of “NodeName”). It must also have an identifier (attribute “ID”, whose value is automatically managed by the system). This is necessary to support the fact that two or more node instances of the same node type having the same name can be instantiated in the same CIG (e.g. two different instances of computerized tomography examination

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

29

Fig. 7. XML description of GLARE’s arc type “alternative”.

of type “Boolean condition”. Possibly, such attributes may assume values at different phases. Example. One can define the “cost” attribute type, and define a node type with the attribute “estimated cost” (which assumes a value when the node is instantiated; i.e., it is an “Inst acq attr”), and attribute “execution cost” (which is an “Inst exec attr”), both of attribute type “cost”. Example. In the following we show a concrete example of a node type, the “workaction” node type of GLARE. The META-GLARE XML representation of such a node type is shown in Fig. 5. Notably, the example shows the definition of “workaction” during the acquisition of the CIG formalism. Thus, only “Class acq attr” has a specific value in Fig. 5.

Fig. 8. General graphical description of attribute types.

within the ischemic stroke CIG). Moreover, there is an automatic attribute “Coordinates” in order to manage its position in the graph and its visualization. In META-GLARE, there is no compulsory attribute that assumes its value at execution time. Typical “Inst exec attr” attributes may be the start and end time of (the execution of) a node (representing an action), its effective cost and its effective duration. Additional non-compulsory attributes may characterize the definition of a node type. As above, they are distinguished by considering when they assume their value. Each of them is characterized by a name, and the type of value it may assume (see the “list ” entries in Fig. 4). The type of values are specified through a symbolic pointer to an attribute type, which must be defined in the ATTRIBUTE TYPE LIBRARY (see Fig. 10 in the following). It is worth noticing that META-GLARE supports the fact that more than one attribute of the same attribute type can appear in the same node type definition. For instance, a node type may have both “including conditions” and “excluding conditions” attributes,

In the XML file, tags are used in order to distinguish among the three different phases (i)–(iii) in which the attributes may assume value (see the discussion above). Concerning the compulsory attributes, the attribute value of NodeVisual (line 5) contains a pointer to the (Java) PTU-method (“it.glare.visual.components.workaction” is the complete path of the Java class which will be invoked). Besides compulsory attributes, “workaction” is characterized by two additional attributes. Considering Inst acq attr attributes, “Description” (line 12) is a textual “string”, while “Preconditions” (line 13) is a “boolCond” (Boolean condition). Additionally, “workaction” is characterized by four attributes that assume a value only at execution time (i.e., four Inst exec attr attributes): startpoint, endpoint, cost, and duration (lines 16–19). 3.3. Arc type definition The definition of arc types is quite similar to the definition of node types. Each arc is characterized by a set of attributes, which may be compulsory or optional, and which may assume values in the three different phases (i)–(iii) discussed above. There is only one limitation: in the class attributes (i.e. Class acq attr) there can be only one control attribute. Concerning compulsory attributes that assume a specific value at the time when the node type itself is acquired (by the system designer), each type of node must have:

30

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

Fig. 9. XML description of the “BoolCond” attribute type.

Fig. 10. Architecture of the DEFINITION EDITOR.

a specific example is shown in Fig. 7). The attribute “ArcTyping” has a default value, which models the case in which there are no constraints on the types of nodes that the arc may connect.

Fig. 11. The graphical user interface for acquire the “Class acq attr” attributes of the node type “workaction”.

• • • •

a name (attribute “ArcType” in Fig. 6), an icon for visualization (attribute “ArcIcon”) a method for visualization (attribute “ArcVisual”) a Boolean attribute (“OrientedArc”) to specify whether the arc is oriented or not. • the attribute “Ariety” to specify the number of nodes connected by the arc. Arcs with multiple staring and\or ending nodes are supported (i.e., 1:1, 1:n, n:1, and n:m arcs). • the attribute “ArcTyping” to specify the types of nodes that the arc may connect. Different specifications must be provided, depending on the ariety of the arc, and on whether it is oriented or not. For instance, in the case of oriented 1:n arcs, typing can be specified as a set of pairs {, . . ., }. For the sake of clarity and compactness, such details are not shown in Fig. 6 (but

Considering compulsory attributes that assume their value when an instance of the arc is created, each arc instance must specify the nodes it connects (attribute “ConnectedNode”). In the case of oriented arcs a starting node and one or a set of ending nodes (depending on the ariety) must be specified. In the case of non oriented arcs, the n (n ≥ 2) nodes they connect must be specified. As in the case of node types, also arc types have no compulsory attribute that assume value at execution time. Different specific arc types can be defined, by instantiating the general “template” shown in Fig. 6. In the following, we show a concrete example (see Fig. 7). Example. In Fig. 7, we show the XML definition of GLARE’s “alternative” arc type during the acquisition of the CIG formalism. The definition does not include any optional attribute. The “alternative” arc is an oriented one (line 6), and has ariety “1:N” (line 7; i.e. it connects one node to a set of nodes). Lines 8–25 of the definition state that the starting node of an alternative arc must be either a “therapeutic decision” node (line 9) or a “diagnostic decision” node (line 17), and the ending nodes can be “therapeutic decision”, “diagnostic decision”, “plan”, “workaction”, “conclusion”, “enquiry” nodes in both cases (lines 10–15 and lines 17–23). Line 26 of the definition is an optional attribute; in particular it is a control attribute,

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

which specifies how the selection between alternatives has to be performed.  3.4. Attribute type definition Attributes are the basic constituents of nodes and arcs and thus, ultimately, of CIG formalisms. Of course, each attribute type may be used in many different contexts. For instance, the attribute type Boolean condition can be used in different formalisms (or in the same formalism) to characterize different types of nodes (e.g., different types of decisions) and/or different types of arcs, but might also be used more than once in the definition of the same node type (e.g., to characterize pre-conditions and post-conditions of node types modeling clinical actions). In META-GLARE, each attribute type is characterized by a set of compulsory features that must be provided when a new attribute type is entered in the Library (i.e. during the acquisition of the CIG formalism). Each attribute type has a name (attr type name, which has a textual value). The feature “attr mode” distinguishes between (i) control attributes, that affect the flow of execution of CIGs (e.g., Boolean decision, repeat); (ii) temporal attributes that provide temporal constraints about the execution of CIGs; notably, such attributes do not alter the flow of execution, but affect execution in that they may impose constraints on when nodes are executable; (iii) neutral attributes, that do not affect the CIG execution (e.g., the “numeric range” type, for specifying a minimum and maximum bound for the numeric value that an attribute instance may assume). The “composite” feature (which has a Boolean value) specifies whether an attribute is composite or simple, and “attr constraint” feature specifies whether the attribute has some constraints (e.g. a numeric attribute can be associated with a range of admissible values). If the attribute is composite an additional compulsory feature must be used to specify the set of attribute types composing it. The “OntologyType” feature defines whether the attribute value is linked to an ontology. OntologyType has actually three allowed values: finding, drugs and action. In the case that the attribute value is not constrained by an ontology, this feature has no value (see Fig. 9 line 10). Notably, the user specifies only the type of ontology and does not specify a particular ontology, since the reference ontologies for a formalism are defined during the formalism definition (see the discussion in Subsection 3.1). Moreover, each attribute type must specify a range of methods to acquire (“attr Acq” feature), to store (“attr Store” feature) and to consult (“attr Cons” feature) it. Additionally, control attributes must also specify methods for executing them (“attr Exec” feature). It is important to notice that only pointers to the methods are provided in the definition of the attributes, while the methods themselves are stored in the Java applet. Much more importantly, all the above methods are what we call “PTU-methods”. In our approach, PTU-methods are methods which are parametric on at least one of the different aspects: phase, task, and user-type. In Fig. 8, “PTU-methods” indicate the aspects they are dependent on. Three different “phases” are possible in META-GLARE: formalism acquisition, CIG acquisition, and CIG execution. For instance, the method for attribute acquisition (“attr Acq” feature) may depend on the phase (consider again, e.g., the example about the “cost” attribute type). The set of possible tasks in META-GLARE is an open one. For the moment, only the “regular” task (denoting the standard use of CIG systems) has been considered (an additional task may be, e.g. “edu-

31

cation”; see however the discussion in Section 8). Also the set of possible user-types is an open one, allowing one to distinguish, e.g. between “medical experts”, “user-physicians”, “healthcare agents”, and so on. In general, both consultation and execution methods are taskdependent and user-dependent. The feature “attr BNF” is used in order to store in a declarative way the “format” of the values that such an attribute type may assume. For the sake of generality and accuracy, the format is specified through a standard context-free grammar, expressed in Bacus Naur Form (BNF) [36]. In the case of composite attributes, the methods to acquire (“attr Acq” feature), to store (“attr Store” feature) and consult (“attr Cons” feature) and possibly execute (“attr Exec” feature) state how to “compose” the acquisition/storing/consultation/execution methods of their components in order to acquire/store/consult/execute the composite attribute itself. Analogously, the “attr BNF” feature specifies the syntactic form of the composition, and uses the components types as tokens of the grammar. All the above features have to be fixed when the new attribute type is entered in ATTRIBUTE TYPE LIBRARY.

3.5. A concrete example: Boolean conditions Different attribute types can be defined, by instantiating the general “template” shown in Fig. 8. In the following, we show a concrete example (see Fig. 9). As an example, in the following we describe META-GLARE current treatment of Boolean conditions (extensions are foreseen in order to cope with more complex cases of temporal patterns [37]). Fig. 9 shows the internal XML representation. The tag attr Mode (line 3) defines that it is a control attribute, to state that a “boolCond” affects the execution of CIGs. The tag composed (line 4) specifies that is a composite attribute (i.e. value = “true”). The attribute attr BNF contains an explicit description (in the standard Backus Naur Form notation) of the syntax of Boolean conditions (rows 6–22 in Fig. 9). A Boolean condition () may be a temporal pattern () or not (). A temporal pattern specifies a time interval of interest (e.g. from 1/1/2016 to 31/1/206). It may check whether a condition () hold in the time interval, or whether an atomic non temporal condition () occurs a given number of times in the time interval, or whether given data of the patient (as in GLARE and in several other medical approaches, patient data are represented as pairs , e.g., ) has a given trend in the interval. A Boolean condition not regarding a pattern () is simply a combination of atomic Boolean conditions () through the OR, XOR, AND and NOT Boolean operators (of course, parenthesis are supported). Atomic Boolean conditions may be temporal () or not (). A non-temporal condition is simply a comparison between a patient data and a value. On the other hand, temporal conditions require the evaluation of data values at specific time points or intervals of time, or specify temporal relations (e.g., “before”; in particular, we have chosen to adopt the relations of Allen’s Interval Algebra [38]) between them. In line 23, the tag OntologyType specifies that this attribute does not refer to any ontology (i.e. value = “”). In line 25–28, there are the definition of PTU-methods that the HG INTERPRETER will use to manage the attribute type “boolCond”. Observe that, the XML definition does not contain the Java code of that PTU-methods, but only symbolic pointers to them (i.e. the complete path of the Java class).

32

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

Fig. 12. Architecture of the HG ACQUISITION module.

Fig. 13. The graphical user interface of HG ACQUISITION module when (A) a formalism has not been selected and (B) after the selection of a formalism (specifically, “GLAREformalism”).

Fig. 14. A part of guideline for ischemic stroke (i.e. the expansion of plan “Rehabilitation 1”) during the acquisition using the formalism “GLAREformalism” shown in subsection Section 3.1.2.

The method it.glare.execution.components.BooleanConditionExec (see Fig. 9) specifies Boolean conditions’ semantics, i.e. how Boolean conditions have to be interpreted by the HG EXECUTION module. Starting the description “bottom-up”, a simple condition () is evaluated by automatically retrieving the value for the pair from the clinical record of the patient, and by comparing it through the specified operator (< or = or > or < = or > = ) with the value given in the condition. A Boolean value (true or false) is returned as output. The first two types of temporal conditions () specified in the BNF grammar are managed in a similar way, except for the fact that the clinical record

of the patient is inspected at a specified point or interval of time. On the other hand, the evaluation of the third type of temporal conditions involves two steps: (1) first, the clinical record of the patient is inspected to find the time intervals when the two input atomic conditions hold, and then (2) it is checked whether such time intervals satisfy the given Allen’s temporal relation (a true\false value is returned). Boolean conditions not regarding a pattern () are simply interpreted on top of the interpretation of simple and temporal conditions, through the appplication of the Boolean operators OR, XOR, AND and NOT (respecting the priority of such operators, as specified by the grammar). Finally, the first type of pat-

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

33

4.2. Libraries The libraries in Fig. 10 are implemented by a database stored in PostgreSQL. Each library is implemented as a (relational) table. The schema of these tables is constituted by two attributes: the first one stores the unique identifier for the component, and the second attribute stores the XML file, in which the corresponding component is described. In this phase of the implementation, we have already implemented a basic attribute library containing several attribute types (and their acquisition and storage methods):

Fig. 15. The graphical user interface for acquisition of a Boolean condition, taken from the computer interpretable guideline for ischemic stroke.

tern conditions () specified in the grammar is simply executed by verifying whether the given holds in the specified time interval; the second by verifying whether the given occurs exactly “” times in the specified time interval; the third by verifying whether the occurrences of the given in the specified time interval follows or not the trend specified in the condition ().  4. Acquisition/extension of a CIG formalism and of its components: the DEFINITION EDITOR The DEFINITION EDITOR (see Fig. 1) allows system-designers to acquire new attribute types, new node/arc types, new constraints, and even new formalisms, automatically producing the corresponding XML documents and storing them into the appropriate Libraries. It supports the extension of (system) formalisms already defined through META-GLARE, or the definition of entirely new (system) formalisms, also providing a graphical interface to make the interactions user-friendly. In subsection 4.1 we detail the architecture of the DEFINITION EDITOR. In Section 4.2, we briefly sketch the current content of the Libraries. Finally, in Section 4.3, we describe the graphical interface. 4.1. Architecture of the DEFINITION EDITOR The DEFINITION EDITOR module is implemented as a Java Applet, and consists of three sub-components: ATTRIBUTE TYPE DEF, NODE/ARC TYPE DEF, and FORMALISM DEF. These sub-components allow the system designers to define new attribute types, new node/arc types, and new formalisms (possibly containing new constraints) via specific user-friendly GUIs, to produce automatically the corresponding XML documents (using the JDOM package [39]) and to store them into the appropriate libraries. In particular, ATTRIBUTE TYPE DEF supports the introduction of a new attribute type (e.g., “fuzzy-logic decision”), giving in output an XML representation in the ATTRIBUTE TYPE LIBRARY. NODE/ARC TYPE DEF supports the definition of new types of nodes and arcs. Such types are simply defined as ordered lists of typed attributes, where the type of each attribute must be included into the ATTRIBUTE TYPE LIBRARY. An XML representation is provided as output (in the NODE/ARC TYPE LIBRARY). Finally, FORMALISM DEF supports the definition of a new formalism, which includes two components: the set of types of nodes and arcs it adopts (taken from the NODE/ARC TYPE LIBRARY) and a set of constraints regulating the relationships between such nodes/arcs (taken from the FORMALISM LIBRARY). Once again, an XML representation is provided in output (in the FORMALISM LIBRARY).

• • • • • • • • • • • • • • • • •

Integer; IntegerRange; Double; DoubleRange; Enumerate; String; BoolCond (i.e. Boolean condition); AtomicBoolCond (i.e. atomic Boolean atemporal condition); TemporalCond (i.e. atomic Boolean temporal condition); BooleanDecision; ScoredDecision; QualitativeDecision; DataEnquiry; NumberRepetition; ConditionedRepetition; GoTo; ConditionedGoTo; We have used this attributes to define and store

(i) some node types: • • • • • •

plan; workaction; therapeutic decision; diagnostic decision; conclusion; data enquiry;

• some arc types: • • • •

alternative; sequence; concurrent; n out of m.

We have defined and stored the acyclicity constraint. Finally, we have used all these components to build some formalism, in order to test the HG ACQUISTION module. In particular, we have adopted META-GLARE to acquire GLARE formalism as shown in section 3.1.2. (see also Experiment 1 in Section 8) 4.3. Graphical interface To facilitate system designers in the acquisition of a new formalism, or in the extension of an existing one, a graphical interface is provided by the DEFINITION EDITOR. First of all, the DEFINITION EDITOR GUIs allow users to work on a formalism, a node/arc, or an attribute type, using the proper sub-component (i.e. ATTRIBUTE TYPE DEF, NODE/ARC TYPE DEF, FORMALISM DEF, see Fig. 10). A user might want to define an entirely new formalism or just some new node/arc/attribute types, to store them in the libraries and to use them later.

34

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

The DEFINITION EDITOR (via FORMALISM DEF) allows system designers to easily create or modify a CIG formalism. The system designer can select previously defined node types (stored in the NODE/ARC TYPE LIBRARY) and add them to the current formalism, or can define new node types to be added to it. A graphical interface also supports the definition of node and arc types. For instance, we show the support for the definition of the “Class acq attr” attributes of node types. In Fig. 11 we show the acquisition of the node type “workaction” of GLAREformalism. The graphical user interface (GUI) shows to the system designer a table with the list of compulsory attributes (“Name” column), and the system designer has to fill the “Value” column with the values that such attributes assume. Morever the user can add new features using the button “Add”. The button “Remove” allows removal of additionl attributes only.

5. Acquisition and storage of a specific CIG, in a specific formalism While the DEFINITION EDITOR can be used by system designers used in order to acquire new formalisms in the Libraries, the HG ACQUISITION module can be used by expert physicians and knowledge engineers to acquire specific instances of CIGs represented in one of the formalisms specified in the Library (see again the architecture in Fig. 1). Notice that the HG ACQUISITION module is parametric with regard to the CIG formalism (and therefore over the node/arc types and constraint types it adopts), in the sense the it supports the acquisition of CIG instances in any of the formalisms entered in the Library. Thus, no extension\modification to the HG AQUISITION module is required when a new formalism is entered in the Library. In this section, we focus on the acquisition of CIG instances in META-GLARE, using as a running example the CIG for ischemic stroke (for more details see section 5.3) developed by ASU San Giovanni Battista in Turin, and considering the GLARE formalism for the acquisition. In order to acquire a specific CIG in the CIG LIBRARY (e.g. the CIG for the ischemic stroke), users must first select one of the formalisms in the FORMALISM LIBRARY (e.g. the “GLAREformalism”), whose description (stored in a XML document, see section 3.1.1) will be provided in input to the HG ACQUISITION module (i.e. the definition of all its components are stored in the libraries, ie. NODE/ARC TYPE LIBRARY and ATTRIBUTE TYPE LIBRARY, as discussed in Section 4, and shown in Fig. 12). In case that an appropriate formalism has not been defined, the users can build a new formalism using the DEFINITION EDITOR module and store it (see the discussion in section 4) and then they can use it. The HG ACQUISITION module takes as input the chosen formalism and retrieves its description (stored in a XML document), and supports user-physicians and knowledge engineers in the acquisition of any CIG, expressed in the given formalism. Operationally speaking, our HG ACQUISITION module consists of two main components, each one provided with a graphical interface: (i) a component used to acquire the hierarchical graph representing the “control flow” of nodes in the CIG, in the form of a graph (G ACQUISITION in Fig. 12, where “G” stands for “Graph”), and (ii) the module used in order to acquire the “content” of each node and arc in the graph (NA ACQUISITION in Fig. 12, where “NA” is an acronym for “Node/Arc”). Specifically, G ACQUISITION provides a general framework to acquire Hierarchical Graphs, and is parametric over the types of nodes and of arcs it may contain. This is shown in Fig. 12, since G ACQUISITION takes as input the FORMALISM LIBRARY, and the NODE/ARC TYPE LIBRARY where it can take the definition of the (system) formalism, and the icons to visualize node and arcs. Thus,

G ACQUISITION provides a general (system-independent) framework to acquire graph, that is then instantiated to the specific formalism provided as input. Analogously, NA ACQUISITION provides a general (formalism-independent) framework for acquiring the content of nodes and arcs, which is instatiated by taking in input the definitions of nodes, arcs, and of their attributes from the appropriate libraries. As a consequence, in META-GLARE, both the acquisition of the graph and of the node/arc content is performed in two steps, the first of which is completely automatic, and completely invisible to META-GLARE users: (1) META-GLARE automatically instantiates the general (formalism-independent) acquisition framework to the chosen (system) formalism. (2) Users adopt the instantiated framework to acquire a specific CIG, in the chosen (system) formalism. Finally, HG ACQUISITION converts the CIG acquired via G ACQUISITION and NA ACQUISITION automatically in a XML file and stores it in the CIG library. Obviously, HG ACQUISITION provides also the possibilty to load an acquired CIG (stored as an XML file in the CIG library) and to modify it. 5.1. Graph acquisition: system independent framework and its instantiation In META-GLARE, CIG graph acquisition is performed through a user-friendly graphical interface, which consists of three main parts: (i) a menu bar, (ii) a window for the hierarchy, and (iii) a window for a (non hierarchical) graph. Such parts are exemplified in Fig. 13. Each part, independently of the input formalism, achieves specific tasks. In Fig. 13, we show the GUI of HG ACQUISITION module when (A) a formalism has not been selected and (B) after the selection of one formalism (specifically, GLAREformalism). The menu bar (dashed dotted box of Fig. 13A and B) provides users with the possibility of selecting the (type of) nodes and arcs they want to insert in the graph, as well as the possibility of triggering the activation of constraints on the graph. The bar provides some independent and general facilities (as shortcuts), e.g. to save the current guideline. Such facilities are shown in Fig. 13A. In Fig. 13B, the bar also contains the icons of node/arc types provided by the chosen formalism. Since GLAREformalism has only one constraint (i.e. aciclicity) and its modality is “automatic” (see Fig. 3), there is no icon referring to it, since the user can not trigger its activation. The hierarchy window (solid box in Fig. 13A and B, below the menu bar) is used to show, in the form of a tree, the part-of relations between nodes in the hierarchical graph (PartOf tree henceforth); Fig. 13 shows the GUI of HG ACQUISITION when a new (empty) CIG is created and thus the PartOf tree is empty. Instead, Figs. 14 and 17 show an example of a PartOf tree corresponding to an acquired (non-empty) CIG. By default, the root of the tree represents the whole CIG (see Figs. 13 A and B, 14 and 17). Each composite node in the PartOf tree has as many sons as its components, and there is no limit to the possible nesting of part-of relations. Leaves in the PartOf tree represent non-composite nodes of the graph (see Fig. 14). The graph window (dashed box in Fig. 13B) represents a specific one-level graph in the given CIG, showing the nodes and arcs constituting it. Figs. 14 and 17 and show an example of non-empty graph. CIG acquisition proceeds as follows. At the beginning (after the selection of a formalism), the hierarchy window only contains the root, and the graph window is empty (see Fig. 13B). Users (expert physicians and knowledge engineers) can select nodes and arcs

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

35

Fig. 16. The XML description of an instance of the node type workaction taken from the computer interpretable guideline for ischemic stroke (i.e. one of the “workaction” node in Fig. 14).

Fig. 17. A part of guideline (i.e. the top level) for ischemic stroke acquired using “GLAREformalism” via META-GLARE.

from the bar to the graph window, to draw the top-level graph (the JGraphX package [40] is used to such a purpose). The hierarchy window is automatically updated by META-GLARE by adding a new icon in the PartOf tree whenever a new node is entered into the graph window. Users can click on (composite nodes in) the part of tree to enable the acquisition of the sub graphs describing (the composition of) composite nodes. An (initially empty) graph window appears, allowing the acquisition of the graph describing the components of the selected composite node. Any order of acquisition is supported (except the fact that composite nodes must be first created, before enabling the possibility of specifying their sub graph). Finally, the check of constraints may be simply triggered by selecting them from the menu in the bar. Notably the constraints, whose modality is “automatic”, are not present in the bar. The above mechanism is general, in the sense that it is independent of the specific formalism being considered. In order to acquire a new CIG, users must first specify which formalism they want to adopt, i.e. they select one of the systems stored in the FORMALISM LIBRARY. This formalism is given in input to the HG ACQUISITION module, which instantiates the above general mechanism to the specific system. Obviously, such an instantiation is totally transparent to the users, which directly interact with the instantiated acquisition tool (as shown in Figs. 13 B and Fig. 1414). We have implemented our system-independent mechanism to instantiate a specific formalism through a Java method. Such a method takes as input the selected formalism and retrieves the XML description of each node and arc from the NODE/ARC TYPE LIBRARY to find their graphical information (see attribute NodeIcon and ArcIcon in subsection 3.2 and subsection 3.3) and the pointer to the PTU-methods for their visualization (see discussion and features NodeVisual/ArcVisual in Section

3). G ACQUISTION, based on the JGraphX package, takes the PTU-method pointers and uses them both to show acquired nodes/arcs and to acquire new nodes/arc via the Java mechanism Class.forName(). The Class.forName() mechanism allows one to invoke a method of an external Java class giving as parameter a pointer to this class and to one of its methods (i.e. a string specifying it).

5.2. Acquisition of the content of nodes and arcs The NA ACQUISITION module is parameterized over node/arc types. The general (system-independent) framework for the acquisition of the content of nodes and arcs is trivial. As a matter of fact, in META-GLARE, each node/arc is fully defined by the ordered list of the attributes defining it (as described in Section 3). Each attribute has an attribute type, and the definition of each (attribute) type must contain a PTU-method to acquire it. Thus, the general framework is simply constituted by a procedure which is activated when the user clicks on a node/arc, and triggers the acquisition of each “Class acq attr” attributes in its definition. From a technical point of view, we use the Java mechanism Class.forName() as described above. The instantiation of such a framework to a specific formalism is easy. The definition of the type of the node/arc is retrieved from the NODE/ARC TYPE LIBRARY, and is used in order to retrieve the ordered list of its attributes and their types (in the ATTRIBUTE TYPE LIBRARY). During CIG acquisition, the values of all “Class acq attr” attributes of the given node/arc must be acquired. This task can be easily achieved by the NA ACQUISITION module, by accessing the ATTRIBUTE TYPE LIBRARY, to retrieve the (pointers to) the methods to acquire and store it, and by executing such methods.

36

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

Example. As a concrete example, let us consider the acquisition of an instance of Boolean condition in GLARE formalism (for instance, during the acquisition of a precondition of a GLARE workaction node). The NA ACQUISITION module retrieves its XML document the pointer to the acquistion method (i.e. it.glare.visual.components.acquire.DialogBoolConditionAcq; see Fig. 9), and invokes it using the Java mechanism Class.forName() to create the GUI in Fig. 15, to allow users to acquire any Boolean condition expressed in GLAREformalism. Then the NA ACQUISITION module retrieves from the XML document the pointer to the storing method (i.e. it.glare.model.components.BooleanCondition, see Fig. 9), and invokes it using the Java mechanism Class.forName() to store the acquired data. In Fig. 15, we show the GUI supporting users to acquire a specific Boolean condition taken from CIG for ischemic stroke. The user has defined a Boolean condition consisting of an AND of two atomic Boolean atemporal conditions. Observe that only the buttons corresponding to allowed elements are active (and usable), i.e. in the situation shown in Fig. 15, users can add either an AND operator or an OR operator or XOR operator, and cannot open parenthesis or add a new condition. The acquistion of an instance of a node\arc\attribute type generates its XML description, which will be a part of the XML document of the CIG. In Fig. 16, we show an XML description corresponding to an istance of the workaction type node (see Fig. 5). Notably, such a node is an instance of the node type in Fig. 5, so that it inherits from it all its “Class acq attr” attributes (see Fig. 16 lines 2–7). Additionally, in Fig. 16 lines 8–13, we can find the values of “Inst acq attr” features. The values are acquired by the user using the NA ACQUISITION module, as described above. For example, in line 9, there is the NodeName of this workaction node instance: “workaction1”. 5.3. Acquisition of a CIG instance The acquisition of a CIG instance is obtained through the acquisition of the nodes and arcs composing it. As an example, we show the clinical guideline for the ischemic stroke developed by ASU San Giovanni Battista in Turin, and acquired in META-GLARE using GLARE formalism. The CIG has more than two hundred actions. Fig. 17 shows the top level of the CIG. The CIG top level has been organized as a sequence of eight plan actions. The first action is triage (plan action “Triage T1” in Fig. 17), followed by two diagnostic actions (plan actions “Diagnosis 1 (D1)” and “Diagnosis 2 (D2)”). Then there are two pharmacological treatment actions (plan actions “Pharmacological Treatment 1 (PT1)” and “Pharmacological Treatment 2 (PT2)”), followed by the evaluation of dysphagia (plan action “Evaluation of dysphagia”). Then rehabilitation is performed (plan action “Rehabilitation 1”) followed by pharmacological treatment. The CIG has been acquired using the CIG formalism “GLAREformalism” (shown in section 3.1.2 and discussed in Experiment 1 section 8).

Fig. 18. The pseudocode of the module HG EXECUTION.

ever requested by users, while “automatic” constraints are checked whenever a “save” action is executed. 6. Execution of CIGs: a hint of the approach Though this paper mainly focuses on acquisition, for the sake of completeness in this section we briefly address META-GLARE execution module (module HG EXECUTION in Fig. 1). A preliminary but more extended presentation of META-GLARE execution is provided in [41]. We are currently working on a long paper completely focused on the execution engine of META-GLARE. Firstly, it is important to point out that in META-GLARE also the execution module is parametric with respect to the CIG formalism. As a consequence, after the acquisition of a formalism, META-GLARE provides “for free” its execution engine (and not only the engine to acquire CIG instances, as in Protégé and in DeGeL). Such a result is achieved by extensively exploiting the criteria of compositionality. The core ideas at the basis the META-GLARE execution engine are simple: (i) the execution of a CIG is obtained through the execution of the nodes and arcs composing it; (ii) each node/arc in the CIG is an instance of a type of node/arc in the input formalism, and the node/arc type definition basically consists of a sequence of typed attributes. The execution of a node\arc is obtained through the (sequential) execution of the control attributes composing it; (iii) the type definition of each control attribute (in the Library of attributes, see subsection 3.4) contains a (pointer to) an execution method, i.e. a method which specifies how its execution will be performed. Such an execution method will be executed by the HG EXECUTION algorithm (see Fig. 18); (iv) the execution of a composite node is obtained through the execution of its components.

5.4. Constraint checking During the acquisition phase, the constraints on the graph (if present) must be checked. The HG ACQUISITION module first looks at the definition of the formalism, to retrieve the proper constraints (if any), and then accesses the FORMALISM LIBRARY, to retrieve the (pointers to) the methods to execute them. In our approach, the HG ACQUISITION module supports (for each constraint) two different modalities of constraint checking: automatic and manual. In the formalism definition, the checking modalities of each constraint are defined. “Manual” constraints are checked when-

In META-GLARE approach, the execution of a specific CIG is parametric over a specific a patient, on which the CIG must be executed, and on the formalism, in which the CIG has been acquired. For the sake of brevity, the CIG formalism and the patient are not explicitly mentioned in the pseudo-code in Fig. 18 Before the execution of execute CIG, currents is initialitated with the starting node of the CIG G. The function execute CIG works as follows. All the nodes in currents are considered (line 1) and executed in parallel (notice that the parallel execution is an intrinsic feature of our approach). The execution of a composed node (line 2)

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

is recursively obtained through the execution of its components (line 3). On the other hand, the execution of each atomic node involves the execution of each one of its control attributes, (considered in the order of appearance; line 5). Each control attribute is executed exploiting the Java Class.forName() mechanism. The execution engine retrieves the pointer to its Java execution method (see discussion in Section 3) and invokes it (line 6). Notably, the execution of each control attribute provides as output a modality (which may be either go on or an “exception” type: abort, exit, suspend, goto). If such a modality is an “exception”, the execution engine properly manages it (through the execution of the method modality.modality Exec; line 8)1 ; otherwise it simply goes on to the execution of the next control attribute in the node. After the completion of the execution of a node, its exiting arc is taken into account (line 9). The execution method of the control attribute of the arc (arc.control attr.attr Exec) is retrieved from the Library, and is invoked (line 10). The output of such an execution is a set of nodes (the next nodes to be executed; notice that we admit multiple ending nodes for an arc). Thus, execution applies to such nodes (line 11). The execution ends when new nodes is empty (i.e. no new node has still to be executed). Despite its apparent simplicity, the above mechanism, in conjuction with the possibility of defining different attribute types, with their own execution methods, grants both expressiveness and modularity\extendability. As regad expressiveness, at the current stage of the Library implementation, our approach supports, among the other, the control patterns in the following: • alternative between actions • sequential actions; • concurrent actions: • “fork”: n actions execute together. We support different subcases: - the n actions execute in any order; • the execution of the n actions is temporally constrained (e.g, they start at the same time, or some delay must be respected – see [42]); • n out of m actions (stemming from an arc with multiple output nodes) are execute, • “join”: - join n actions; • join n out of m actions; • repetitions: • do n times; • do n times during a time interval; • do until a condition will become true; • periodic repetitions (see [42]); • action with pre-conditions and/or post-conditions; • control flow actions: • (conditioned/unconditioned) abort; • (conditioned/unconditioned) go to; • (conditioned/unconditioned) suspend until a condition will be true; • acquisition of external information (blocking mode). In the following, we show how META-GLARE supports two of these control patterns. Example.

Join n actions out of m

1 For instance, the “abort” modality involves the abortion of the execution of the whole CIG, while the “exit to” modality only involves stopping the execution of the current node\arc, and continuing the execution at the node specified by the exit instruction. More details can be found in [41].

37

The control pattern “join n actions out of m” is defined in META-GLARE through the definition of a proper type of arc, in the ARC TYPE LIBRARY. Such an arc type has m as input ariety (to state that at most m actions can join), and as control attribute the attribute WaitN, whose execution method specifies that the execution must go on (to execute the output nodes of the arc) only when the execution of n of the input nodes (of this arc) has been completed. Example.

Actions with preconditions and post-conditions.

In META-GLARE, this control pattern can be defined using the Boolean condition type attribute (see subsection 3.5). The action type has two dedicated control attributes: one for the preconditions and one for the post-conditions. Since the execution of an action type instance consists of the execution of the ordered list of its control attributes, the control attribute describing the precondition will be the first one in the list, and the control attribute describing the post-condition will be the last one. At the execution time, the exit modality is returned in case the pre-conditions or the post-conditions fail (are false). As regard modularity\extendability, it is very important to stress that new control patterns can be easily added to META-GLARE in a modular way, by simply defining new control attributes (and their execution methods) to the library of attributes, and using them in the definition of new nodes and arcs. Such a fundamental feature is exeplified by Experiment 3, in Section 8. 7. Novelty of the META-GLARE approach with regard to the state of the art In summary, the core idea of the META-GLARE approach is: (i) to define an open library of elementary components (e.g. textual attribute, Boolean conditions, Score-based decisions), each of which was equipped with methods for acquiring, consulting and executing it; (ii) to provide system-designers with an easy way of defining node and arc types (constituting the representation formalism of a new system) in terms of the elementary components constituting them; (iii) to devise general and basic tools for the acquisition, consultation and execution of CIGs, which are parametric regarding the formalism used to represent them (in the sense that the definition of node and arc types are an input for such tools). A similar idea in a completely different context has emerged in Computer Science in the 70s, with the definition of the socalled “compilers of compilers”, like YACC (Yet Another Compiler of Compilers [43]). In particular, META-GLARE takes as input any CIG formalism and provides as output a CIG system (i.e. an acquisition, a consultation and an execution engine) for such formalism just as YACC takes as input any context free language (expressed through a formal attribute grammar) and provides as output a compiler for it. More recently, model-driven software engineering (MDSE) has emerged as a promising methodology for software systems, targeting challenges in software engineering relating to productivity, flexibility and reliability. MDSE is especially useful as a methodology for the development of healthcare systems, and even a dedicated workshop (the International Workshop on Metamodelling for Healthcare Systems, 2014 (http://mmhs.hib.no/2014/) and 2015 (http://mmhs.hib.no/2015/)) has been created to face such a topic. Indeed, the application of models to software development is a long-standing tradition, and has become even more popular since the development of the unified modeling language (UML). Yet we

38

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

are faced with ‘mere’ documentation, MDSE has an entirely different approach: Models do not constitute documentation, but are considered equal to pieces of code, as their implementation is (semi)automated. MDSE therefore aims to find domain-specific abstractions and makes them accessible through formal modelling. This procedure creates a great potential for automation of software production, which in turn leads to increased productivity, increasing both the quality and maintainability of software systems. We share part of the methodology of MDSE, such as the use of three levels of models (the meta-formalism level, the formalism level, and the CIG instance level), but a relevant difference should be pointed out. In “standard” MDSE approaches, the final model is used to semi-automatically generate the application code, through the adoption of transformation rules. On the other hand, there is no semi-automatic code generation in META-GLARE. Indeed, the HGinterpreter is already provided by META-GLARE, but it is parametric over the CIG formalism, so that a CIG interpreter is automatically obtained when a specific CIG formalism is selected. In the area of CIGs, the GLIF [18] and the DeGeL [14] approaches have already explored the idea of a “meta-approach”, though quite differently with respect to our proposal. GLIF is a framework for CIG acquisition and execution, which has been built exploiting the Protégé framework [13]. In particular, the GLIF formalism has been designed using Protégé and then specific CIGs (expressed in GLIF formalism) can be acquired using the Protégé knowledge modelling tool. Thus, Protégé can be seen as a “meta”-tool, and GLIF as a specific CIG formalism defined using it. However, it is worth noticing that Protégé is not specifically devoted to CIG formalisms. More generally, Protégé is a free, open source ontology editor and a knowledge acquisition system, considered the leading ontological engineering tool. Protégé expressiveness is more general and powerful than our meta-formalism described in Section 3, which has been designed specifically in order to consider only CIG formalisms. Also the DeGeL framework [14] has been developed to manage multiple-ontologies (an ontology in DeGeL approach corresponds to a formalism in our approach). In particular, the DeGeL’s Uruz tool is parametric over an input ontology (called “source-ontology”) and allows one to acquire specific CIGs based on it. Additionally, a Hybrid Meta-Ontology is defined and the source-ontologies include pointers referring to it (in order to support CIG classification and dissemination). As regard CIG acquisition, the DeGeL approach is very similar to our approach. However, in our work we also focused on meta-formalism specification. Notably, both in the case of the use of Protégé to build GLIF, and in the case of DeGeL, the “meta-frameworks” are not CIGspecific but, more generally, are frameworks to acquire ontologies. CIG formalisms (like GLIF’s one) can thus be seen as specific cases of ontologies. Protégé and DeGeL offer tools to acquire ontologies (equivalent, in our approach, to the acquisition of a specific CIG formalism), and specific instances of such ontologies (equivalent, in our approach, to the acquisition of a specific CIG in a specific language). However, two main differences distiguish the META-GLARE approach from the use of Protégé and DeGeL to define and acquire CIG formalisms and specific CIGs: (i) first of all, while META-GLARE is CIG-specific, Protégé and DeGeL are frameworks coping, more generally, with ontologies. This means that both their meta-languages and formalism acquisition tools are not specifically tailored towards CIG formalisms, thus making the acquisition of a new CIG formalism less system-designer-friendly than in our approach. Much more important, being devoted to ontologies (ii) Protégé and DeGeL do not provide supports for CIG execution. Thus, in Protégé (when defining GLIF) and in DeGeL, the “meta” approach only regards acquisition, not focusing on the execution phase. On the other hand, in META-GLARE, we focus on CIG formalisms only and in such a way we have been able to design an integrated meta-

approach in which both (formalism) acquisition and execution are considered together. To better characterize META-GLARE with regard to the “traditional” CIG approaches (e.g., PROforma [9], GPROVE [10], GUIDE [11], PRODIGY [12]) on the one hand, and with respect to the Protégé and DeGeL approaches on the other, it is worth to stressing that: (i) once a CIG system, based on a specific formalism, has been defined, its behaviour in the acquisition and execution of a specific guideline (e.g. a guideline for ischemic stroke) is basically the same in the three approaches; (ii) the distinctions among the three different approaches emerge when considering the definition of a new CIG system, based on a new representation formalism, or the modification of an existing system, in order to extend its formalism. Let us consider issue (ii) in more detail: 7.1. “traditional” CIG approaches In a traditional CIG approach, the system designer first identifies a specific formalism to represent clinical guidelines. Once the formalism has been defined, the system designer programs an acquisition and an execution tool tailored to cope with the specific formalism. This means that any change in the formalisms requires that the system designer goes through the code of the acquisition and execution module, identifies the correct points in the code where changes have to be performed, and programs to appropriately change\extend the code. Notably, in real CIG systems, whose code dimension and complexity is quite high, this approach usually requires a lot of effort for each (even relatively small) change. At least, this was our experience with our GLARE system. In order to overcome such a general limitation, and to facilitate fast changes and fast prototyping, the approaches of the second and third type below have been introduced; 7.2. Protégé and DeGeL approaches Though significantly different, Protégé and DeGeL have a very important similarity. Both approaches support the definitiion and management of multiple ontologies. Of course, such ontologies may, as a specific case, be used to represent CIG formalisms (even if this is just one of the possible uses of such ontologies). When they are used to define new CIG formalisms, Protégé and DeGeL overcome part of the limitations of the “traditional” approaches. As a matter of fact, Protégé and DeGeL (a) provide a module to acquire a new formalism (ontology) and, once a formalism has been defined (b) they automatically provide the tool to acquire CIG instances described in the given formalism. This means that, in such approaches, when a system designer wants to build a new CIG system (based on a new formalism), or to modify an existing system (by changing its formalism), s\he can take advantage of the formalism acquisition module to define the new formalism, and gets “for free” the tool to acquire CIGs based on the new formalism. This way of operating is much easier and faster than the one in “traditional” approaches. However, in Protégé and DeGeL, the system designer has still to take care of the execution tool. This means that, for example, when modifying a given formalism, the system designer has still to go though the code of the execution tool, search for the appropriate pieces of code and change\extend them. Thus, a degree of programming is still needed, to adapt the execution tool. This may still be quite time consuming, expecially in case of real (and complex) CIG systems;

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

7.3. META-GLARE approach The META-GLARE approach further generalizes the support provided by Protégé and DeGeL, to cover also the execution tool. As in Protégé and DeGeL, also META-GLARE provides a tool to acquire new formalisms. However, in META-GLARE, not only the tool to acquire specific CIG instances, but also the tool to execute them are parametric concerning the input formalism. This means that, when a system designer wants to build a new CIG system (based on a new formalism), or to modify an existing system (by changing its formalism), s\he can take advantage of META-GLARE to define the new formalism, and gets “for free” both the tool to acquire and to execute CIG instances based on the new formalism. There is no need to go through the CIG execution tool (and through the CIG acquisition one) to look where to modify it: indeed, since it is parametric with regard to the formalism, it “automatically adapts” to interpret the new formalism. In such a way, META-GLARE achieves the advantages (1)–(4) discussed in the introductory Section. In short, the definition of a new system and\or the update of an existing one are easy and quick. The system designer can easily define her/his own new system, by defining its formalism through the formalism acquisition tool (DEFINITION EDITOR module in Fig. 1). Programming is needed only in case a new component has to be added in the component library. However, the addition is modular and minimal: the system designer has just to focus on the added component, while no modification to any software component in META-GLARE architecture (see Fig. 1 above) is required to integrate the new methods. Thus, fast prototyping of the new (or extended) system is achieved (see also the experiments in Section 8). 8. Experimental evaluation and future applications

attribute types used in GLARE where already provided by the ATTRIBUTE TYPE LYBRARY, so that only acquisition was needed. Experiment 2.

Experiment 1.

Using META-GLARE to re-build GLARE.

This experiment substantiates our claim that, through METAGLARE, a new CIG system (consisting of an acquisition and an execution tool) can be easily built with limited or no programming effort. We have used META-GLARE in order to re-build our GLARE system. This experiment has been used as a running example throughout this paper. In particular, in Section 3.1 we have shown the high-level META-GLARE definition of GLARE formalism (see the XML representation in Fig. 3), and we have described the definition of the “workaction” node (Section 3.2, Fig. 3) and of the “alternative” arc (Section 3.3, Fig. 5). In Section 5, we have also exemplified the acquisition of the ischemic stroke CIG in the GLARE formalism. The acquisition of GLARE formalism was performed by Irene Lovotti as part of her Master thesis, and required less than one day of work. No programmming effort was needed at all and, as a result, we had a new version of GLARE, consisting of both the tools to acquire CIG instances and to execute them on patients. Obviously, this exciting result is biased by the fact that all the

Adding to GLARE a new type of node.

This experiment demonstrates that, using META-GLARE, the formalism of a given CIG system can be easily extended. After the acquisition of GLARE, we extended it with a new type of node, consisting of (1) some non-control attributes (e.g. textual attributes for name and goal, numerical attribute for cost, and so on); (2) a sequence of three control attributes, “precondition” (of type BoolCond), “body” (of type external action) and “postcondition” (of type BoolCond). In particular, the intended purpose of (the control attributes of) the node is that, during execution, preconditions (which are Boolean conditions) are first checked on the patient data. If they are not satisfied, the execution of the node fails (and fail recovery is started); otherwise, an external action is executed on the patient. After the execution, postconditions are verified, possibly leading to a failure of the execution of the node. All the required attribute types in the experimental evaluation were already present in the library. As a consequence, the systemdesigner had just acquired (in few minutes) the new node definition (through the graphical interface of the DEFINITION EDITOR). No other effort was required.  On the other hand, some programming is required in case a new attribute type (not already existent in the library) has to be added. Such cases are exemplified in the following, where we discuss two future applications of META-GLARE. Experiment 3.

In this paper, we have presented META-GLARE general architecture, focusing on the acquisition components. META-GLARE takes as input a CIG formalism (based on the TNM model) and provides as output a CIG system, intended as the modules needed to acquire, consult and execute any guideline instance represented on top of such a formalism. Thus, it support fast CIG system prototyping, both when building a new CIG system (on the basis of a new TNM-based formalism), and when extending a current one (with the addition of new features to a CIG formalism). To experimentally evaluate META-GLARE, we have perrformed several tests. In the following, we briefly report two of them (Experiments 1 and 2). In order to provide a more complete feeling of possible applications of METAGLARE, we also discuss two future applications (Experiments 3 and 4).

39

Extending GLARE with “cost-utility” decisions.

When choosing among clinically “equivalent” (with respect to the patient at hand) therapies, the “long term” effects of the therapeutic choice (e.g. what path of actions should be performed next, what are their costs, durations and expected utilities) may be helpful to discriminate. Decision theory [44] may be helpful in this context. In particular, it allows one to identify the optimal policy, i.e. the (sequence of) action(s) changing the states of the system in such a manner that a given criterion is optimized. In order to compare the different action outcomes, one commonly assigns a utility to each of the states reached. Since there is uncertainty in what the states will be, the optimal policy maximizes the expected utility. It has been recently shown how decision theory can be exploited in the CIG context, to model cost/benefit decisions [45]. Currently no facility for cost/benefit decisions are provided in META-GLARE Library. Thus, to extend a (META-GLARE-based) CIG formalism (such as GLARE) with a new type of control attribute (say Cost/BenefitDecision) modelling cost/benefit decisions, new methods must be developed by the system designer, to acquire, consult, and execute it, and inserted into the Library. However, it is important to stress that no modification to META-GLARE acquisition, consultation and execution engines has to be performed.  Experiment 4.

Building a CIG “educational” system

Within the ROPHS (Report On Piedmont Healthcare System) project, we have started cooperation with the group led by Dr. Prof. Francesco Della Corte, Chair of Department of Emergency Medicine: anaesthesia and intensive care of Azienda Ospedaliera Universitaria “Maggiore della Carità” in Novara, Italy, which has a long-term tradition in the education of physicians and healthcare providers, in the context of emergencies, also exploiting telemedicine and, more generally, software educational tools (http://www.dismedmaster. org). In such a context, we have used GLARE in order to acquire a

40

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

CIG for the emergency treatment of severe trauma [8], and we have used it as a simulation engine to support healthcare provider education. Though the adoption of GLARE in such educational courses proved to be quite helpful, such an experience has clearly shown us that the educational context has particular goals, whose achievement requires radical changes to “traditional” CIG systems, such as GLARE. Specifically, we identified two specific peculiarities, which quite sharply distinguish the educational context from the traditional use of CIG systems for physicians’ decision support: (1) “traditional” CIG systems support physicians in taking (therapeutic and diagnostic) decisions, usually by applying the decision criteria stored in CIG decision actions to the patient’s clinical data, and showing physicians the suggested alternative(s); such a modality is useful also in the educational context: during the training phase, it is useful to show to “students” the decision criteria, and the result of applying them to specific patient data. However, the system should also be used in order to test the students’ abilities. In such a context, the students have to choose autonomously between the different alternatives, without any system suggestion (while the suggestions of the system can be exploited a-posteriori, to compare them with the student’s choice); (2) in the “testing” phase, it might be useful to show guidelines containing also “clinically wrong” paths. Students must be able to detect and avoid them. However, of course, such paths must be managed in a quite “ad-hoc” way by the CIG system, since they are not part of the evidence-based CIG, and must be shown/executed only within specific goals (testing within the educational task), and specific users (students). Additionally, in the educational context, (3) it is important to distinguish between different types of users. In this context, it might be helpful to distinguish users not only on the basis of their role (e.g. physicians vs. healthcare volunteers), but also on their level of expertise. In our opinion, such peculiarities are large enough to justify the need of developing a new CIG system, geared towards education, instead of building a “huge” monolithic system supporting very different tasks (however, it is worth stressing that META-GLARE would equally support also the extension of a given system with the new peculiarities discussed above). Also in this context, the adoption of META-GLARE can provide clear advantages. Exploiting the Libraries, all the types of nodes and arcs, and the constraints already defined can be imported in the new system. Thus, the system designer can just focus on the peculiarities (1)–(3) above. Roughly and quickly speaking, thanks to META-GLARE, they can be easily supported as follows: (1) a new task, say “educational test execution” should be introduced. The execution method of each type of decision node in the system (e.g., in GLARE we have two types of decision nodes, since we distinguish between diagnostic and therapeutic decisions) must be augmented (by programming new code), in order to support such a new task. Indeed, the new code is quite trivial, since basically it must simply ask to the users to make a selection within the alternative paths originating from the decision, without providing her/him any suggestion; (2) new types of nodes and arcs (“wrong” node and arc types) must be added (e.g. as an extension of the corresponding “correct” types in the Library), characterized by the fact that they are taken into account only within the execution of specific tasks (e.g. educational test execution), for specific users. Once again,

only the code for the execution methods of the new types has to be programmed; (3) such a feature is directly supported by META-GLARE, which allows one to define different types of users, and to specify (for each node and arc type) different behaviours (during consultation and/or execution), depending on the user type (through the adoption of PTU-methods). Once again it is worth stressing that also in this context all the required programming is “local” to the specific (PTU-)methods. No modifications to the general (and system-independent) acquisition, consultation and execution engines are required. Once the new code is added, it will be directly evoked by the acquisition, consultation and execution engines when appropriate (so that the system designer has not to worry about and lose a substantial amount of time to analyse and custom the interactions of the new code with the META-GLARE engines).  9. Conclusions, related and future work CPGs constitute one of the main tools to support evidence-based medicine, supporting healthcare optimization and standardization. In the last two decades, several different computer-assisted management systems of CIGs have been developed within the Artificial Intelligence in Medicine community. Each CIG system is characterized by a specific formalism to represent CIGs, and usually provides a manager to acquire and execute them. As discussed in Section 2, there are several commonalities between most formalisms in the literature. However, each formalism has its own peculiarities since it is geared towards the treatment of specific phenomena. Thus, in many situations, facing a new clinical domain involves an extension of an existing CIG formalism (and of its manager), and in some case it may even lead to the decision to build a new CIG system. Such operations, however, are usually very complex and time consuming, contrasting with the goal of fast prototyping, which is of paramount importance, especially in the research area. The goal of our work is to provide a flexible framework to the extension or definition of CIG formalisms, and of their managers, supporting fast and easy prototyping. In order to achieve such a challenging goal, we propose an innovative approach. Instead of proposing “yet another system” to acquire, represent and execute CIGs, we propose a “meta-system”, i.e. a shell to define (or modify) CIG systems. Roughly speaking, the input of META-GLARE is a description of a representation formalism for CIGs, and the output is a new system able to acquire, represent, consult and execute CIGs described using such a formalism. In our opinion, our innovative approach provides two main types of advantages, both strictly related to the notion of easy and fast prototyping. Using META-GLARE (1) the definition of a new system (based on a new representation formalism) is easy and quick; (2) the extension of an existing system (through the modification of the representation formalism) is easy and quick. Both advantages have been widely discussed considering some experimental evaluations (see the experiments in Section 8), showing that META-GLARE support fast prototyping of a new (or extended) system. As the experiments clearly show, in METAGLARE programming is needed just in case new attribute types (or new constraints) have to be added. However, even in such cases, only local programming is needed: the acquisition, consultation and execution methods for the new attribute types have to be programmed and inserted in the Library, without having to take care of the interactions with the rest of the system. Indeed, META-GLARE

A. Bottrighi, P. Terenziani / Artificial Intelligence in Medicine 72 (2016) 22–41

acquisition and execution engines do not need any modification at all: they simply will invoke such methods when appropriate. Thus, we look at META-GLARE as a suitable research vehicle to address new CIG phenomena, allowing system designers to focus just on the required extensions (and, specifically, on the formalism extensions), while minimizing the programming effort as regards the definition of both the tool for CIG instance acquisition and execution. As widely discussed in Section 7, such a feature distinguishes META-GLARE not only from current “traditional” CIG systems, but also from Protégé-based and DeGeL −based approaches. We have already developed a prototypical version of the acquisition component, while the implementation of the consultation and of the execution engine is still under development. The completion of such engine is the primary goal of our future work in this context, together with the definition of a new educational CIG system, developed on top of META-GLARE along the lines sketched in Section 8 (see Experiment 4). As a later step, we plan to extend META-GLARE with some of the advanced features we have already provided in the GLARE system, like temporal reasoning facilities [42], decision-theoretic cost/benefit analysis [45], model-based verification to check CIGs’ properties [46], and techniques to cope with comorbidities [47]. Acknowledgements The authors are very indebted to Irene Lovotti and Stefania Rubrichi, for their invaluable contribution in the realization of the acquisition engine, to Dr. Mauro Torchio and Dr. Gianpaolo Molino of ASU San Giovanni Battista in Turin for their invaluable contribution in acquisition of CIG for ischemic stroke, and to Professor Yuval Shahar for the stimulating discussions during KR4HC 2015. The research described in this paper has been partially supported by Compagnia San Paolo, within the GINSENG project. References [1] Health Telematics for Clinical Guidelines and Protocols.Gordon C, Christensen JP, editors. Amsterdam: IOS Press; 1995. [2] Fridsma DB. Special issue on workflow management and clinical guidelines. JAMIA 2001;22(1):1–80. [3] Computer-Based Medical Guidelines and Protocols: A Primer and Current Trends.ten Teije A, Miksch S, Lucas P, editors. Amsterdam: IOS Press; 2008. [4] Peleg M, Tu S, Bury J, Ciccarese P, Fox J, Greenes RA, et al. Comparing computer-interpretable guideline models: a case-study approach. JAMIA 2003;10(1):52–68. [5] Peleg M. Computer-interpretable clinical guidelines: a methodological review. J Biomed Inform 2013;46(4):744–63. [6] Terenziani P, Molino G, Torchio M. A modular approach for representing and executing clinical guidelines. Artif Intell Med 2001;23(3):249–76. [7] Terenziani P, Montani S, Bottrighi A, Molino G, Torchio M. Applying artificial intelligence to clinical guidelines: the GLARE approach. Adv Artif Intell 2008:273–82, in [3]. [8] Leonardi G, Bottrighi A, Galliani G, Terenziani P, Messina A, Della Corte F. Exceptions handling within GLARE clinical guideline framework. AMIA Annu Symp Proc 2012:512–21. [9] Fox J, Johns N, Rahmanzadeh A. Disseminating medical knowledge: the PROforma approach. Artif Intell Med 1998;14(1–2):157–81. [10] Bottrighi A, Chesani F, Mello P, Montali M, Montani S, Storari S, et al. Analysis ˜ D, ten of the GLARE and GPROVE approaches to clinical guideline. In: Riano Teije A, Miksch S, Mor P, editors. Knowledge Representation for Health-Care: Data, Processes and Guidelines LNCS, vol. 5943. Springer; 2010. p. 76–87. [11] Quaglini S, Stefanelli M, Cavallini A, Micieli G, Fassino C, Mossa C. Guideline-based careflow systems. Artif Intell Med 2000;20(1):5–22. [12] Johnson PD, Tu SW, Booth N, Sugden B, Purves IN. Using scenarios in chronic disease management guidelines for primary care. AMIA Annu Symp Proc 2000:389–93. [13] http://protege.stanford.edu (accessed: 30.14.16). [14] Shahar Y, Young O, Shalom E, Galperin M, Mayaffit A, Moskovitch R, et al. A framework for a distributed, hybrid, multiple-ontology clinical-guideline library, and automated guideline-support tools. J Biomed Inform 2004;37(5):325–44. [15] Shahar Y, Miksch S, Johnson P. The Asgaard project: a task-specific framework for the application and critiquing of time-oriented clinical guidelines. Artif Intell Med 1998;14(1-2):29–51.

41

[16] Musen MA, Tu SW, Das AK, Shahar Y. EON: a component-based approach to automation of protocol-directed therapy. JAMIA 1996;3(6):367–88. [17] Shiffman RN, Karras BT, Agrawal A, Chen R, Marenco L, Nath S. GEM: a proposal for a more comprehensive guideline document model using XML. JAMIA 2000;7(5):488–98. [18] Peleg M, Boxwala AA, Ogunyemi O, Zeng Q, Tu SW, Lacson R, et al. GLIF3: the evolution of a guideline representation format. AMIA Annu Symp Proc 2000:645–9. [19] Tu SW, Campbell JR, Glasgow J, Nyman MA, McClure R, McClay J, et al. The SAGE guideline model: achievements and overview. JAMIA 2007;14(5):589–98. [20] Computer-Based Support for Clinical Guidelines and Protocols. Studies in health technology and informatics (83).Heller B, Löffler M, Musen M, Stefanelli M, editors. Amsterdam: IOS Press; 2001. [21] Wang D, Peleg M, Tu SW, Boxwala AA, Greenes RA, Patel VL, et al. Representation primitives, process models and patient data in computer-interpretable clinical practice guidelines: a literature review of guideline representation models. Int J Med Inform 2002;68(1-3):59–70. [22] Computer-Based Support for Clinical Guidelines and Protocols. Studies in health technology and informatics (101).Kaiser K, Miksch S, Tu SW, editors. Amsterdam: IOS Press; 2004. [23] Isern D, Moreno A. Computer-based execution of clinical guidelines: a review. Int J Med Inform 2008;77(12):787–808. [24] Grando MA, Glasspool D, Fox J. A formal approach to the analysis of clinical computer-interpretable guideline modeling languages. Artif Intell Med 2012;54(1):1–13. [25] Svàtek V, Ruzicka M. Step-by-step mark-up of medical guideline documents. Int J Med Inform 2003;70(2–3):329–35. [26] Shalom E, Shahar Y, Taieb-Maimon M, Bar G, Yarkoni A, Young O, et al. A quantitative assessment of a methodology for collaborative specification and evaluation of clinical guidelines. J Biomed Inform 2008;41(6):889–903. [27] Kaiser K, Miksch S. Versioning computer-interpretable guidelines: semi-automatic modeling of ‘Living Guidelines’ using an information extraction method. Artif Intell Med 2009;46(1):55–66. [28] Peleg M, Tu Sw. Design patterns for clinical guidelines. Artif Intell Med 2009;47(1):1–24. [29] Serban R, Ten Teije A. Exploiting thesauri knowledge in medical guideline formalization. Method Inform Med 2009;48(5):468–74. [30] Shiffman RN, Michel G, Rosenfeld RM, Davidson C. Building better guidelines with BRIDGE-Wiz: development and evaluation of a software assistant to promote clarity, transparency, and implementability. JAMIA 2012;19(1):94–101. [31] Hripcsak G. Writing arden syntax medical logic modules. Comput Biol Med 1994;24(5):331–63. [32] International Health Terminology Standards Development Organisation: SNOMED Clinical Terms, http://www.ihtsdo.org/snomed-ct (accessed 2.05.16). [33] WHO Collaborating Centre for Drug Statistics Methodology: Anatomical Therapeutic Chemical classification system, http://www.whocc.no/atc/ (accessed 2.05.16). [34] http://docs.oracle.com/javase/tutorial/deployment/applet/index.html (accessed: 30.04.16). [35] http://www.postgresql.org (accessed: 30.04.16). [36] Revised report on the algorithmic language ALGOL 60. Naur P, editor. Commun ACM 1960;3(5):299–314. [37] Shahar Y. Dynamic temporal interpretation contexts for temporal abstraction. Ann Math Artif Intell 1998;22(1):159–92. [38] Allen JF. Maintaining knowledge about temporal intervals. Commun ACM 1983;26(11):832–43. [39] http://www.jdom.org (accessed 5.06.15). [40] http://www.jgraph.com/ (accessed 2.05.16). [41] Bottrighi A, Rubrichi S, Terenziani P. META-GLARE: a meta-engine for ˜ D, Lenz R, Miksch S, executing computer interpretable guidelines. In: Riano Peleg M, Reichert M, ten Teije A, editors. Knowledge Representation for Health Care, LNCS, vol. 9485. Springer; 2015. p. 37–50. [42] Anselma L, Terenziani P, Montani S, Bottrighi A. Towards a comprehensive treatment of repetitions, periodicity and temporal constraints in clinical guidelines. Artif Intell Med 2006;38(2):171–95. [43] Johnson SC. Yacc Yet another compiler-compiler, vol. 32. Murray Hill, New Jersey: Bell Laboratories; 1975. [44] Russel S, Norvig P. Artificial Intelligence: A Modern Approach. 2nd ed. London: Prentice Hall; 2003. [45] Anselma L, Bottrighi A, Molino G, Montani S, Terenziani P, Torchio M. Supporting knowledge-based decision making in the medical context: the GLARE approach. IJKBO 2011;1(1):42–60. [46] Bottrighi A, Giordano L, Molino G, Montani S, Terenziani P, Torchio M. Adopting model checking techniques for clinical guidelines verification. Artif Intell Med 2010;48(1):1–19. [47] Piovesan L, Molino G, Terenziani P. An ontological knowledge and multiple abstraction level decision support system in healthcare. Decis Anal 2014;1:8.