Conformance Analysis of Execution Traces with Clinical Guidelines and Basic Medical Knowledge in Answer Set Programming? Matteo Spiotta1,2 , Alessio Bottrighi1 , and Daniele Theseider Dupré1 1 DISIT, Sezione di Informatica, Università del Piemonte Orientale 2 Dipartimento di Informatica, Università di Torino Abstract. Clinical Guidelines (CGs) are developed for specifying the “best” clinical procedures for specific clinical circumstances. However, a CG is executed on a specific patient, with her peculiarities, and in a specific context, with its limitations and constraints. Physicians have to use Basic Medical Knowledge (BMK) in order to adapt the general CG to each specific case, even if the interplay between CGs and the BMK can be very complex. In this paper, we focus on a posteriori analysis of conformance, intended as the adherence of an observed CG execution trace to CG and BMK knowledge. A CG description in the GLARE language is mapped to Answer Set Programming (ASP); the BMK and conformance rules are also represented in ASP, to perform conformance analysis, identifying non-adherence situations to CG and/or BMK, which must ultimately be evaluated by a physician in order to assess whether a trace can be considered as conformant or not. 1 Introduction A Clinical Guideline (CG) is “a systematically developed statement to assist practitioner and patient decisions about appropriate health care for specific clinical circumstances” [1]. The CGs are developed in order to capture medical evidence and to put it into practice, and deal with general classes of patients, since the CG developers (typically expert committees) cannot define all possi- ble executions of a CG on any possible specific patient in any possible clinical condition. CG developers make some implicit assumptions: (1) ideal patient, i.e., patients have just the single disease considered in the CG (thus excluding the concurrent application of more than one CG), and are statistically relevant (they model the typical patient affected by the given disease), not presenting rare pe- culiarities or side-effects; (2) ideal context, i.e., in the context of execution, all necessary resources are available; (3) ideal physicians are executing the CG, i.e., physicians whose knowledge always allow them to properly apply the CGs to specific patients. On the other hand, when a CG is applied to a specific patient, the patient and/or the context may not be ideal. The physicians indeed exploit Basic Medical Knowledge (BMK) to adapt the CG to the specific case at hand. ? This research is partially supported by Compagnia di San Paolo. The interplay between these two types of knowledge can be very complex, e.g., actions recommended by a CG could be prohibited by the BMK, or a CG could force some actions despite the BMK discourages them. Thus the physician judg- ment is very important in order to have a correct execution of a given CG in a specific case, as observed by the Infectious Diseases Society of America in its Guide to Development of Practice Guidelines [2]: “Practice guidelines, however, are never a substitute for clinical judgment. Clinical discretion is of the utmost importance in the application of a guideline to individual patients, because no guideline can ever be specific enough to be applied in all situations.” The issue of studying the interplay between the knowledge in CGs and BMK is relatively new in the literature. Several approaches have focused either on CGs or BMK in isolation, or have considered BMK only as a source of information, such as definitions of clinical terms and abstractions [3]. Only recently some approaches (e.g., [4, 5]) have considered that CGs cannot be interpreted and executed in “isolation”, since CGs correspond to just a part of the medical knowledge that physicians have to take into account when treating patients. In this paper, we explore the interaction between CGs and BMK from the viewpoint of conformance analysis, intended as the adherence of an observed CG execution trace to both types of knowledge. Observe that both CG knowledge and BMK can be defeated (for a more detailed discussion see [4]), and it is the physician’s responsibility to assess if a trace can be deemed as conformant or not. Our goal is to support the physicians in the conformance analysis task, providing them as much information as possible to make this task easier. The approach is based on GLARE ([6] and section 2) to represent CGs; our general framework is described in section 3 and its representation in Answer Set Programming in section 4. In particular, we provide a set of rules defining, on the one hand, discrepancies from one source of knowledge that are, at least potentially, justified by another source; on the other hand, discrepancies that are not justified. 2 GLARE representation formalism In this section, we highlight some of the main features of the GLARE representa- tion formalism (a detailed description is provided in [6]). GLARE distinguishes between atomic and composite actions. Atomic actions are elementary steps in a CG, in the sense that they do not need a further de-composition into sub-actions to be executed. Composite actions are instead composed by other (atomic or composite) actions. GLARE provides four different types of atomic actions: – work actions, i.e., actions to be executed at a given point of the CG; – decision actions, used to model the selection among alternative paths in a CG. GLARE provides diagnostic decisions, used to make explicit the iden- tification of the disease the patient is suffering from, among a set of possible diseases, compatible with her findings. Such a decision is based on patient’s parameters. GLARE also provides therapeutic decisions, used to represent the choice between therapeutic paths in a CG, based on a pre-defined set of parameters: effectiveness, cost, side effects, compliance and duration; – query actions models a requests of information (typically patients’ parame- ters), that can be obtained from the outside world (e.g. physicians, databases, patients visits or interviews). CG execution cannot proceed until such infor- mation has been obtained; – conclusion actions represent the explicit output of a decision process. Actions in a CG are connected through control relations. Such relations estab- lish which actions might be executed next, in which order. GLARE introduces four different types of control relations: sequence, concurrency, alternative and repetition. The sequence relation explicitly establishes which is the next action to be executed; the alternative relation describes which alternative paths stem from a decision action, the concurrency relation between two actions states that they can be executed in any order, or also in parallel and the repetition relation, states that an action has to be repeated several times (i.e. the number of repe- titions can be fixed a priori, or, alternatively, it can be asserted that the action must be repeated until a certain exit condition becomes true). 3 General Framework A main goal of the framework presented in this paper is to exploit reusability of knowledge, in several ways: – A model of the CG in Answer Set Programming (ASP, [7]) is derived auto- matically from the description of the CG in GLARE, and can be used for conformance analysis, as in this paper, i.e., analyzing if and how a single execution deviates from the CG, as well as for verifying properties of the CG, that should hold for all executions, using the approach in [8] as model checker in the loosely coupled framework in [9]. – A common repository of Basic Medical Knowledge can be used, in the frame- work in this paper, with models of different CGs. – In perspective, an ontology of medical terms can provide the link for trig- gering BMK rules for a specific CG and its execution on a specific patient. Figure 1 presents the general structure of the framework. The main entities, which are input to an ASP solver, are: the log, the CG model, the BMK, and a set of compliance annotation rules. The framework evaluates discrepancies between the log (actual execution) with the executions suggested by the CG, with the possible “variations” suggested by the BMK. The log contains the data recorded during guideline execution. It includes data specific to the individual patient, such as medical records (from the Elec- tronic Health Record, EHR) and the actions performed on the patient; it also includes data related to the context (e.g., hospital) in which the CG is performed, such as availability of equipment and personnel. The ASP model of the CG encodes all the admitted treatment paths provided by the CG. Tools such as GLARE provide a formal representation of CGs, which can be translated to ASP. In this framework, information on when an action is Fig. 1. General framework executed is used both to verify whether it is justified by the CG, and to justify execution of subsequent actions in the CG. Both the control flow perspective and the data perspective of the GLARE CG specification is encoded in the CG ASP model. In the current version, quantitative time constraints in GLARE are not supported. To better evaluate the interplay of BMK and CG we take in account the execution model of actions shown in figure 2, similar to the one in [4]. At a given point in the execution of a CG on a specific patient, the control relations in the CG or rules in the BMK indicate that a given action have to be executed (is a candidate). A candidate action is discarded if its preconditions (modeled in the CG) are false; or it may be discarded because of conditions not explicitly modeled in the CG; we expect that some of such reasons for discarding are modeled in the BMK. Decision and conclusion actions are instantaneous and, once started, they can be considered concluded. Work actions and query actions, once started, can either be completed or aborted. An action is aborted if a failure occurs during its execution, or it may be aborted because some condition arises; again, we expect that some of such reasons for aborting are modeled in the BMK. Once an action of the CG is discarded or aborted, in general we cannot infer the correct way to continue the execution of the CG. In some cases the physician would continue the execution skipping the uncompleted action (e.g., for an action having minor impact on the treatment), cases in which she would restart the execution from some point further away (e.g., a previous decision point or the end of the partial plan); in other cases, the entire CG should be interrupted (e.g., the action is essential for the treatment). We do not assume that this information Fig. 2. Action model is modeled, therefore we support interaction of the framework with the analyst which will suggest where in the CG and in the log the analysis can be restarted. The annotation compliance rules are the keystone of the entire framework. They define the output of the analysis, and are triggered by discrepancies, start- ing from the actions recorded in the log and the expected actions derived from the CG and BMK. Two different classes of discrepancies are provided: – Discrepancies of the log with a knowledge source (CG or BMK rule) which are “supported” by another source. – Discrepancies of the log with a knowledge source (KS) not supported by other knowledge. While the second class represents incorrect behavior (wrt the considered KSs), the first one represents a case of (at least, potential) conflict between knowledge sources. Which one should prevail cannot be stated in general [4], and providing knowledge for stating it for all cases is, in general, too costly. Therefore we provide the information in the log, which can be filtered further by the analyst. We assume completeness and correctness of the Log. Completeness with re- spect to actions means that for all actions taken, the following is recorded: – start, discard, abort, complete and failure reason (human and/or technical problem which caused incorrect completion of an action); – the outcome of completed decision actions. Completeness with respect to (patient or context) data means that it contains record of data which have driven the control flow (CF) and data which could force the physician to change the normal execution applying BMK rules. Correctness means that only verified information is recorded, no conflicting data can be stored (e.g., an action is first discarded and then completed). We expect (see [4]) that the BMK provides pieces of knowledge such as: – Actions of a given type, or specific actions, are contraindicated for patients in a given temporary or permanent conditions; e.g.: • treatment with a drug D is contraindicated for patients (known to be) allergic to D; • an invasive exam or therapy is contraindicated in some cases. – the execution of a CG may (have to be) suspended if a life threat arises, and the latter should be treated. Whether the execution actually has to be suspended depends, in general, on whether the current actions being executed are compatible with the treatment of the life threat, and the life threat itself. Specific knowledge in this respect may be available or not. We intend that the life threatening problem, e.g., a heart failure, is not part of the class of problems dealt with by the CG, i.e., in the example, the CG currently being executed is not the one for cardiovascular diseases. The source of knowledge for its treatment should, in principle, come from another CG; however, in this paper we do not address the problem of interaction of multiple CGs and we assume to have available, when analyzing logs for the execution of a CG, the set of possible treatments for other problems. – Actions of a given type (e.g., routine exams) can be performed even if not part of the CG. 4 ASP representation and conformance rules In this section we describe the ASP representation of the Log, CG model, BMK model, and the annotation rules. In the Log, context and patient data, decision outcomes, and action states (discard, started, aborted, completed) are encoded as facts associated with a timestamp. Based on the set of facts data(name,value,timeStamp), action(actID, actState,timeStamp), decided(actID,actIDoutcome,timeStamp), we reconstruct the time line for the framework by means of the predicate next, as follows: next(S,SN):-state(S),state(SN),SN>S, not stateinbetween(S,SN). stateinbetween(S,S2):-state(S),state(S2),state(S3),S