Model Checking for Clinical Guidelines: an Agent-based Approach

Abstract

In this paper, we propose a new computer-based approach to model clinical guidelines. We first show how clinical guidelines can be modelled in an agent like fashion in the specification language Promela of the model checker SPIN. Then, we describe the impact of such a move: by using SPIN model-checking facilities, one can automatically prove a wide range of properties concerning the modelled guidelines. As a proof of concept, we apply such a methodology to the clinical guidelines in GLARE, a domain-independent prototypical system for acquiring, representing and executing clinical guidelines, which has been built within a 7-year project with Azienda Ospedaliera San Giovanni Battista in Turin (one of the largest hospitals in Italy).

1 INTRODUCTION

Clinical guidelines represent the current understanding of the best clinical practice, and constitute an important area of research in Artificial Intelligence (AI) in medicine and in medical decision making (see, e.g. [1]). Clinical guidelines may provide crucial advantages in individual-based health care, by supporting physicians in their decision making and diagnosing activities, both improving the quality of patient treatment and the efficiency of health-related organizations. Many different systems and projects have been developed in recent years in order to realize computer-assisted management of clinical guidelines (see e.g., Asbru [2], GLARE [3], PROforma [4], and also [5,1,6]).

Although the problem of improving the quality of clinical guideline is now becoming a prominent one, the verification capabilities available in the GL systems in the literature is usually rather limited. In many cases, in fact, such systems do associate only very specific and limited inferential mechanisms to the knowledge represented in the guideline. In [7,8], a theorem proving approach is proposed to deal with the problem of protocol verification. A medical protocol is modelled in the Asbru language as a hierarchical plan and then it is mapped to a specification in the interactive theorem prover KIV.

Starting from the observation that clinical guidelines can be regarded as interaction protocols among agents, we aim at defining a comprehensive framework in which a computer-based approach to clinical guidelines is developed in an agent-base setting, and model checking techniques are used to prove properties about the guidelines. In fact, on the one hand, the agent-based approach has proved to provide crucial advantages, in modelling complex systems and behaviours by modularly representing their components and the interactions between them [9]. On the other hand, model-checking techniques [10], successfully used for protocol verification, are now widely used for agent verification [11] for their simplicity and efficiency with respect to the more complex theorem proving approach, which normally requires the interaction with the user.

The paper describes how LTL model checking techniques can be adopted in the verification of clinical guidelines and it reports on the activity of verification of the medical guideline for “stroke” (developed in collaboration with Azienda Ospedaliera San Giovanni Battista in Turin and already tested in the GLARE system [3]) with the model checker SPIN [12]. The guideline, as well as the different agents interacting with it, are modelled as communicating processes in the SPIN specification language Promela, thus providing an explicit representation of the interactions between the different agents/entities in the care environment (e.g., physicians, patients, clinical records). As a by product, our approach also provides a clear declarative semantics to guidelines.

The verification of the properties of the guideline can be done by formalizing the properties to be checked as LTL formulas. The proposed approach provides several reasoning capabilities, such as automatically checking the feasibility of a given (diagnostic and/or therapeutic) procedure under specific contextual conditions (e.g., given the resources available in a specific hospital) and/or for a given specific patient. Despite the fact that the experimentation is still ongoing, in the verification of the guideline we have been able to discover inconsistencies as well as sources of incompleteness. Although the methodology we propose is application-independent, in the following we show how we are implementing it in GLARE.

2 CLINICAL GUIDELINES IN GLARE

GLARE is a domain-independent prototypical system for acquiring, representing and executing clinical guidelines which has been built within a 7-year project with Azienda Ospedaliera San Giovanni Battista in Turin, and has been successfully tested in different domains, including bladder cancer, reflux esophagitis, and heart failure.

2.1 GLARE architecture

GLARE has been implemented relying on a three layered architecture, shown in figure 1. The system is based on the assumption that knowledge in clinical guidelines is independent of its use (e.g., support, evaluation etc.), so that it is convenient (at least from the knowledge engineering point of view) to distinguish between the problem of acquiring and representing clinical guidelines and the problem of “using” them (e.g., “executing” acquired guidelines on specific patients). In accordance with this approach, at the highest layer in figure 1 it is possible to identify an acquisition and an execution module. The acquisition module is a user-friendly and easy-to-use tool for acquiring clinical guidelines. In particular, it embeds: (i) a graphical interface, which supports primitives for drawing the control information in the guideline, and ad hoc windows to acquire the internal properties of the objects (see section 2.2 ); (ii) facilities for browsing the guideline; (iii) facilities for automatic consistency checking of temporal constraints (via the proposal of advanced AI techniques [13]). The guidelines managed by the acquisition module are physically stored in the GL Database.

Fig. 1.

Architecture of the GLARE system.

The execution module executes an acquired guideline for a specific patient, taking into account the patient’s data, automatically retrieved from the Patient Database. The tool interacts with the user-physician via a user-friendly graphical interface. Advanced simulation, temporal-reasoning and decision-theory techniques are adopted in order to assist user-physicians in their decision-making activities.

The lowest layer of the architecture contains the DBMS, that physically stores the two databases described above, while the intermediate layer consists of a set of XML documents (one for each database). XML acts as an interlingua between the highest layer and the DBMS layer: the acquisition and execution modules actually interact only with the XML layer, through which they obtain the knowledge stored into the DMBS. The use of XML as an interlingua allows us to express the guidelines in a format with characteristics of legibility, and to publish them on the web, rendering easy their dissemination. On the other hand, the DBMS layer grants a homogeneous management of the data, by integrating the guideline representation with the pre-existent hospital information system in the same physical DBMS.

The parts in the dashed box in figure 1 represent the extensions needed to implement our agent and model-checking-based approach, described in Section 3.2.

2.2 Representation language

In order to guarantee usability to physicians non expert in Computer Science, in GLARE we have defined a limited set of clear representation primitives [3]. In particular, we have focused our attention on the concept of action, distinguishing between atomic and composite actions. Atomic actions can be regarded as elementary steps, in the sense that they do not need a further de-composition into sub-actions to be executed. Composite actions are composed by other actions (atomic or composite).

GLARE distinguishes between four different types of atomic actions: work actions, query actions, decisions and conclusions. Work actions are atomic actions which must be executed at a given point of the guideline, and which can be described in terms of a set of attributes, such as name, (textual) description, cost, time, resources, goals. Query actions are requests of information that can be obtained from the outside world (physicians, Databases, knowledge bases). Decision actions are specific types of actions embodying the criteria which can be used to select among alternative paths in a guideline. In particular, diagnostic decisions are represented as an open set of triples <diagnosis, parameter, score> (where, in turn, a parameter is a triple <data, attribute, value>), plus a threshold to be compared with the different diagnoses’ scores. On the other hand, therapeutic decisions are based on a pre-defined set of parameters: effectiveness, cost, side-effects, compliance, duration. Finally, conclusions represent the explicit output of a decision process.

Composite actions are defined in terms of their components, via the has-part relation (this supports for top-down refinement in the description of guidelines). On the other hand, a set of control relations establish which actions might be executed next and in what order. We distinguish among four different control relations: sequence, controlled, alternative and repetition.

3 AN AGENT-BASED REPRESENTATION OF CLINICAL GUIDELINES

3.1 Architecture of the overall approach

Let us now describe the part of the system architecture which is contained in the dashed box in Figure 1. In the model checking approach [10], given a model describing all the possible evolutions of the system and a specification expressed in a temporal logic, the model is checked to see whether it satisfies the specification. In particular, in the model checker SPIN [12] the specification of the model is given in the input language Promela (that will be shortly described in Section 3.1), and the specification (the property to be checked) is a formula of the linear time temporal logic (LTL). The fact that the model checking approach has been successfully used for protocol verification motivates the interest of this approach in the verification of clinical guidelines, which can be regarded as special kinds of protocols.

The translation of the guideline to Promela is performed starting from its XML specification in GLARE and we refer to section 3.2 for a description of how the guideline can be mapped to a Promela specification. A similar translation is applied to the patient data. The behaviour of the external environment, of the Database and of the physician are all modelled as Promela processes. SPIN translates each process (each agent) into a finite automaton, and the global behaviour of the system is obtained by computing an asynchronous interleaving product of automata. The resulting automaton represents the global state space of the system (the model containing all the possible executions of the guideline) and can be built on-the-fly during the verification process.

A property which has to be verified on the system is passed to the verifier through an interface, which maps it into a temporal formula, as required by SPIN. SPIN converts the negation of the temporal formula into a Büchi automaton and computes its synchronous product with the system global state space. If the language of the resulting Büchi automaton is empty then the property is true on all the possible execution of the system, otherwise the verifier provides a counterexample for the property (an execution path on which it is false).

3.2 Representing GLARE clinical guidelines using PROMELA

The specification language Promela allows a high level model of a distributed system to be defined by modelling each agent in an extended pseudo C code, including synchronization primitives and message exchange primitives.

Before describing how the guideline is encoded in Promela, let us point out the underlying hypotheses. First of all, the stroke guideline only defines qualitative constraints on the temporal ordering of actions. More precisely the actions can be executed sequentially or concurrently, and the evaluation of temporal constraints is not required during the execution of the guideline. For this reason the timestamps associated with the data (describing the time at which the measurement of each datum was taken) are not used in constraints to be evaluated during the execution of the guideline. They are only used by the Physician who has to decide if they are still reliable. As we model the physician as a nondeterministic process answering the requests from the guideline, we do not need to have the time values available during the computation and hence to represent them in the model. Hence, we only represent the fact that the timestamps are exchanged between the guidelines and other agents, but we will only give symbolic (constant) values to them, to mean that the time value is known at that point of the computation.

The model of the system is described by specifying the following agents as Promela processes: the Guideline agent; the Physician agent; the Outside agent; the Database agent.

The Physician agent is modelled as a nondeterministic process which interacts with the guideline by evaluating the patient data, choosing among the different alternative feasible paths and deciding among the different “backtracking” alternatives in the case of action failure. The Outside agent, representing the outside world, provides up to date values for data (together with the time of their measurement) when they are not already available from the database. It also stores data in the database, executes work actions and reports about their success or failure.The Database agent models the behaviour of the patient database, allowing for data insertion and retrieval. The Guideline agent models the overall behaviour of the guideline. Each construct in the guideline is mapped to a Promela statement or (for complex statements) to a Promela piece of code. For instance, each work action is mapped to a conditional statement in which the action preconditions are evaluated and, in the case they hold, the action is sent to the Outside agent for execution. The sequence relation and the concurrent relation are mapped to the sequence and to the parallel composition constructs in Promela. Decisions are mapped to a sequence of send operations which inform the physician about the supported paths, followed by a selection construct which allows the selected path of the guideline to be followed according to the physician decision.

The translation of a clinical guideline to a Promela specification starts from the XML specification of the guideline and is implemented in Java using top-down recursive parsing.

3.3 Semantics

Although in the rest of the paper we did not take such an aspect into account, it is important to stress the model checker provides an explicit representation for the semantics of the clinical guidelines. In particular, it is remarkable to note that, in our approach, such a semantic is obtained in a fully automatized way, through a three step translation: first, the guidelines acquired through GLARE graphical interface is mapped onto the XML representation; second, such a representation is mapped onto Promela agent-base language; third, Promela specification is converted into an global state space automaton on which model checking is performed. We thus provide in a fully automatic way an automata-based semantics for the guidelines being acquired by GLARE.

3.4 The verification task

Besides providing an explicit semantics for the guidelines, the automata-based model is crucial from the practical point of view, since it allows one to prove different kinds of properties regarding the given guidelines:

1. properties concerning a guideline “per se”. One can check if the guideline contains a path of actions satisfying a given set of properties (e.g., a path including actions X, Y and Z, or a path in which no action of type X is executed, or a path not requiring a given laboratory test, or a path requiring only a given set of resources, and so on);

2. properties of a guideline in a given context. Specific contexts of execution may impose several limitations on the executable actions of guidelines, related, e.g., to the lack of certain resources (e.g., laboratory instruments). The consequences of such limitations may be automatically investigated taking advantage of the model checker. For instance, the model checker can prove whether there is or not a therapy for a patient affected by a given disease, in the case a specific set of resources is available (not available).

3. Properties of a guideline when applied to a specific patient. Provided that the model checker has in input all the data in the patient record, the feasibility of a given action, or path of actions on the specific patient can be proved.

4. Integrated proofs. Of course, given the flexibility and the task-independence of the model checker, any combination of the above types of proofs is feasible. For instance, one may ask whether, given a patient with a specific disease and set of symptoms, and given a hospital with a specific set of resources, there is a path in the guideline which applies to the patient and satisfies given properties.

During the verification of the stroke guideline we have been able to discover some inconsistencies in the original formulation. In particular, we wanted to check that, if a recovery treatment has been excluded at some point of the guideline, later on the guideline does not prescribe a continuation of the recovery treatment. This property happens to be false. The property to be verified has been represented with the following LTL formula:

$$\begin{array}{l}\square (\text{conclusion}==\text{recovery}\_\text{treatment}\_\text{excluded}\\ \to \neg \diamond \text{proc}\_\text{recovery}\_\text{treatment}==\text{started}).\end{array}$$

SPIN produces a counterexample to this property. As an example of property concerning the contextualization of the guideline to a given hospital, let us suppose that the angiography is not available in the hospital. We want to check if the angiography is eventually required on every execution of the guideline or if there exist some execution on which it not required. We need to verify the following LTL formula: (required_test = = angiography). This property is not true on all the runs of the stroke guideline and a counterexample is returned from the model checker.

4 RELATED WORK AND CONCLUSIONS

In this paper we have proposed a model checking approach for the verification of clinical guidelines. Clinical guidelines are translated to the specification language Promela of the model checker SPIN and the properties to be checked are formulated as LTL formulas. Although the experimentation is still ongoing, the automatic verification of properties on the stroke guideline has been able to discover some inconsistencies in the guideline that had not been previously detected by hand. Also, we have been able to contextualize the guideline to specific contexts and specific patients and to prove properties about it. In [7,8] a theorem proving approach is proposed to deal with the problem of protocol verification. A medical protocol is modelled in the Asbru language as a hierarchical plan and then it is mapped to a specification in KIV, an interactive theorem prover for higher order logic. Properties are expressed in a variant of Interval Temporal Logic. In particular, [8] provides an evaluation of the feasibility of the approach based on the formalization and verification of two real-life medical protocols, namely the “jaundice” protocol and the “diabetes mellitus” protocol. In [14] (that was published after the submission of our paper) it is described how efficient model checking techniques can be used in the verification of the guidelines properties. The Asbru model is translated into the input language of SMV model checker. Structural and medical properties of the jaundice protocol are formalized as ACTL formulas (that is CTL formulas only allowing universal path quantifiers). From several points of view our approach is similar to this last one, although the adoption of different model checking tools allows for the verification of slightly different properties (as ACTL and LTL are incomparable).

Although there is a wide agreement about the importance of providing a clear semantic model for clinical guidelines, this issue has been faced in several quite different ways within the medical informatics community. In most cases, the semantics of guidelines has been only implicitly provided via an execution engine, which provides an interpretation of guidelines by executing them on specific patients. Considering explicit representations, a formal operational semantics has been provided for PROforma [4], via the definition of an abstract execution engine and of rules describing how the different guideline operations change the state of such an engine. On the other hand, in SAGE a mapping to standard terminologies and models (such as the virtual medical record) is advocated [15].

While the Asbru protocol representation language allows the semantics of guidelines to be defined through Asbru formal semantics [16], a logical semantics to guidelines has been provided in [17]. There a graphical notation to express medical guidelines is introduced, which can be automatically translated to the logic-based formalism provided by the SOCS computational logic framework. As mentioned above, in our approach the semantics of guidelines is provided through their mapping to Promela, by modelling them as automata. However, as a future work, we aim at developing a more declarative and logical semantics for guidelines.