Model checking as support for inspecting compliance to rules in flexible processes

Journal of Visual Languages and Computing 28 (2015) 100–121

Contents lists available at ScienceDirect

Journal of Visual Languages and Computing journal homepage: www.elsevier.com/locate/jvlc

Model checking as support for inspecting compliance to rules in flexible processes$ Ioan Alfred Letia n, Anca Goron Computer Science Department, Technical University, Baritiu 28, 400391 Cluj-Napoca, Romania

a r t i c l e in f o

abstract

Article history: Received 22 September 2014 Received in revised form 9 December 2014 Accepted 20 December 2014 Available online 30 December 2014

Context: In backing business processes with information technology, a difficult trade-off appears between the desire to control processes for avoiding undesirable executions, and the flexibility that users need in order to attain their higher level goals. While this is a general trend in general business processes, it is even more acute in specific domains like the medical area, where the clinical guidelines are expected to contribute to the optimization of medical assistance. Objective: We study model checking as support for understanding and solving the inconsistencies between the process models and their corresponding execution. The aim is to provide various human users with output in controlled English for the checking of properties about the execution of such processes, and perhaps input in controlled English for properties of interest from the point of view of the user. Method: For the conformance checking of such complex situations, we use an extended version of a Hybrid Logics model checking tool, for the verification of various properties within an abstract representation model. The extension with Description Logics helps to exploit a more refined representation of the entities involved in the execution of processes. The advantages of using the model checker in visualizing and verbalizing connections of the properties checked with their dependencies over time are shown on a sore throat running scenario, relative to its corresponding clinical guidelines. Results: With new data for an alternative run of the execution, our method can update the abstract model to enable the user to see what might happen or might have happened in such runs of the process model. The new updated abstract model corresponding to the new real situations is then used to analyze whether the overall state is acceptable or should further actions be considered to arrive at an acceptable state of the world. Conclusion: Our results show how the combination of Hybrid Logic and Description Logic can provide the necessary abstraction for the checking to be carried out at a level understandable by the human user when the properties of interest can be translated by a controlled English language interface. & 2015 Elsevier Ltd. All rights reserved.

Keywords: Flexible processes Compliance to rules Dynamic condition response graph Clinical guidelines Hybrid logics Description logics

1. Introduction

☆

This paper has been recommended for acceptance by S. -K. Chang. Corresponding author. Tel.: þ40 264 401480. E-mail addresses: [email protected] (I.A. Letia), [email protected] (A. Goron). n

http://dx.doi.org/10.1016/j.jvlc.2014.12.008 1045-926X/& 2015 Elsevier Ltd. All rights reserved.

The enactment of processes is usually based on rules, activities and resources available in order to attain some goals of the actors involved. Conformance checking aims to detect inconsistencies between the model of processes and their corresponding execution [1,2]. Since such interrelations can be quite complex, a support for modeling

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

which is more user-friendly [3] and which can visualize and verbalize the interactions of the actors is very important. Declare workflows [4,5] aim to take care of flexibility that is required in many real world processes. In a declarative approach any execution fulfilling the constraints of the workflow is allowed, thereby leaving maximal flexibility in the execution. Adding a new constraint in an imperative process description often requires the process code to be completely rewritten, while in a declarative one it requires just an extra constraint to be added. There are many representations as standard procedures and regulations for processes, such as BPMN, Petri Nets or the more recent Guard-Stage-Milestone (GSM) model [6], which is based on artifacts, used to model conceptual entities that are central to guiding the operations (with a changing content). Considering the many options as representation for processes, we decided to use the Dynamic Condition Response (DCR) graphs [5], a balanced compromise between the specification of constraints and the allowance of a certain level of flexibility. Given that real world processes are quite diverse, for a specific application certain models may be more convenient than others, and in some of them we might have to face the challenges of changing contexts, which requires the use of clear guideline procedures, that can ensure the balance in the functioning of the overall system. Such general process guidelines with the aim of keeping a balance between delivery of quality and efficiency were highly covered in the literature [7–9]. In this article we focus on the medical field, but we argue that the work presented here is significant for many other processes. Even though model checking is an accurate analysis technique, used to verify software and hardware systems [10], the analysis of large and complex systems can easily lead to very large state spaces. Although abstraction techniques are well-known for such applications, we are looking to using the abstractions in the models of various processes from the point of view of the users involved in the running of these processes, meaning that in such a real world the information might be incomplete, but perhaps enough for making efficient decisions from the user perspective. 1.1. Structure of article This article is structured as follows. Section 2 unveils current limitations in the verification of business processes and presents the motivation behind the proposed visualization framework exemplified through a suggestive scenario. Section 3 describes the modeling choices for our approach and introduces our general goals and methodological choices. Clinical guidelines for the running scenario are shown, which are used in the model of the process, including the data for attributes, to check process compliance. In Section 4, we detail the model checking technique and the advantages of Hybrid Logics and Description Logics based verifications, all applied on a more extensive verification example, conducted on the running scenario. In Section 5, we show several improvements that our approach can bring in order to handle the

101

dynamics of real world processes in the face of incomplete knowledge. A short presentation in Section 6 highlights how the tools are used in achieving compliance on the chosen scenario. The discussion in Section 7 is devoted to more clearly show the advantages of using Hybrid Logics and Description Logics in checking the compliance in various settings. The related work in Section 8 portrays our main contributions compared to current references on the line of verification in flexible processes. Finally, Section 9 contains a short summary of the presented methodology and concluding remarks. 2. Processes and their compliance to rules Business processes define the operational model of an organization or several inter-connected ones. Hence, the behavior of a business process has to obey various types of regulations imposed for different areas of activities. For example, a business process in the banking sector must comply to a variety of security constraints, while a medical procedure must take into consideration the best practices and recommendations specified by clinical guidelines and, at the same time, obey strict regulations for ensuring at all times the safety of both the patient and the medical personnel involved. The compliance of a business process to a set of regulations can be inferred from its corresponding business process model. However, as very often happens in the real world, the execution of a business process does not fully align with the defined model due to changing contextual information, uncertainty or unpredictable events which might alter the established course of actions, one must consider new approaches for the conformance checking task. 2.1. Sore Throat scenario We consider a process in a hospital regarding the implementation of emergency medical care protocols, relative to general established clinical standards. The adoption of guidelines for supporting physicians in their decision making and diagnostic activities is of crucial importance in the medical domain in order to grant the quality of medical assistance and to improve medical treatments within health-care organizations [7]. We address for examination the medical case of a primary care physician and verify whether the clinical procedure standards were applied in a correct and efficient manner for an emergency situation. A standard emergency care procedure is considered as including: a detailed investigation of all symptoms and medical condition of the patient, followed by a verification of his or her medical history and optionally, taking into consideration the insurance coverage plan, the request for additional tests. Based on the gathered medical data, the doctor establishes a diagnosis and a treatment is prescribed for the patient. The treatment, if successful, leads to an improvement of medical condition of the patient. The ThroatScen presents an adult patient Bryan and focuses around his two visits to a clinical emergency room in order to get proper attendance for his condition. In the

102

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

first medical assessment, the information prevailed from medical records indicate that the patient presented himself complaining about a disturbing cough and sore throat. After basic investigations, the doctor established that Bryan suffered from a minor cold and prescribed a treatment with paracetamol. However, after a few days, the condition of the patient did not improve, forcing him to present himself for a second check up to the emergency room. At the second visit, the patient complained about high fever and a more intense throat pain. These new symptoms caused the doctor to change his initial diagnosis and to establish that the patient suffered from strep throat, a bacterial infection. The given treatment included the prescription of amoxicillin, a common antibiotic. After the administration of the prescribed medicine, the condition of Bryan improved and he was cured. The scope of the investigation is not only to verify whether the standard procedure was followed, but also that all the information was used as evidence in the decision making regarding diagnosis and treatment over the entire process. We consider a simplified version of the emergency case (Fig. 1), with a reduced number of specific medical terms for a better understanding of the process. The case is centered around a sore throat and the possible diseases it

might indicate. Most sore throats are caused by infections with viruses, small organisms that do not respond to antibiotics [21]. Examples include the flu or the common cold viruses. Another cause is bacterial infections indicated by the presence of Streptococcus bacteria [21]. For space considerations, we will consider only the case of the common cold and strep throat as diseases conditioned by the presence of sore throat as symptom. It is often hard to tell whether a sore throat is caused by a virus or by strep bacteria in the absence of a throat test, while, usually, the presence of the cough indicates a viral cause [21]. A secondary infection caused by bacteria could be suspected if high fever is also present, while the majority of sore throats are usually viral [21]. In Table 1 one can see the reduced set of symptoms used as indicators for the two

Table 1 Signs and symptoms of an infection accompanied by a sore throat. Symptom

Viral infection

Cough Sore throat Fever

✓ ✓

Fig. 1. Assessment process for the ThroatScen scenario.

Bacterial infection

✓ ✓

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

types of infections considered in this article in the diagnosis process. The differentiation between the two types of infection is usually done based on a rapid test or strep culture. However, we will rule out this option as not covered in the medical insurance plan of the patient. 2.2. Guidelines and flexible processes As business process models dictate the operational flow of an organization, the correctness of the model must be ensured at all times. Considering the ThroatScen scenario, we enforce the previous statement by underlining the vital role of medical rules in controlling of the investigations performed, the diagnosis and the treatment prescribed. Guideline models could improve quality and efficiency in medical care delivery, but also the safety of the patient through reduced medical errors. However, guidelines are also perceived as threats due to their inflexibility when it comes to depart from pre-specified paths, but also due to the lack of support for clinicians involvement which may limit the decision making process. As business processes must be executed in real world settings, characterized by uncertainty and unpredictability, they must be specified in a way that allows to be flexibly adjusted [34] to conform to new conditions. However, this increase in flexibility implies a decrease of control and poses significant challenges especially in areas such as medical processes with vital implications in the safety of both the patient and the medical personnel. Hence a balance must be found between the level of flexibility and the number of constraints to be considered in the modeling process. Regular model checking techniques consider a formalization of rules which cover the behavioral aspects of a business process model. However, the execution flow is most often directly dependent on environmental factors. Hence a connection between the behavioral and the data models must be made to allow a more refined verification of flexible business processes. Considering a simple flowchart of the ThroatScen scenario (Fig. 1) one can observe that the execution of the assessment process follows a straight path from the verification and confirmation of the symptoms to the establishment of cold as diagnosis and paracetamol as corresponding treatment. Assuming that the symptoms were correctly identified and that the diagnosis and treatment were set accordingly, the expected outcome should have been an improvement of the medical condition of the patient. However, one can observe that the output was not the one expected and required a rerun of the assessment. In the second run, a similar straight approach was followed: the confirmation of sore throat as symptom, the absence of cough and the inclusion of fever as a new symptom, with a new diagnosis (strep throat) and a new prescribed treatment based on antibiotics. However, although not specifically shown in the flowchart (Fig. 1), the difference between the two assessment instances is that the decision making over the final diagnosis was not entirely based on the set of symptoms identified in the previous step, but also on the analysis of the data from the first consult run, which allowed to

103

completely rule out viral infection as a cause for sore throat and based on the presence of fever to consider bacterial infection as the right diagnosis. Hence, in the modeling of business processes, one must consider the ability to make use of previously gathered data. Process mining [2] addresses the challenges imposed by context dependence, illuminating the road from data to action by analyzing volumes of previously collected information. To be able to address these situations, one must consider extending the initial process model with the one derived from analyzing the process execution logs. Going back to our scenario, one can observe that the diagnosis in the first assessment was based only on the available data in that moment of time. Therefore, with incomplete knowledge, a diagnosis was assumed based on the most obvious evidence, for the case here the presence of cough as a clear sign of a viral infection when accompanied by sore throat. During the second assessment, the information from the previous run allowed for new data inter-dependencies to be established, excluding irrelevant information and invalidating other alternative diagnosis, enabling the correct decision over the right diagnosis for the doctor. Hence, the diagnosis was set not only on past records, but also on deduced connections, by ruling out invalid hypotheses and deciding upon a new diagnosis, which led to the expected results. Hence, clinical guidelines use knowledge and continuous learning from previous cases or possible alternative paths, from diagnosis and investigation through treatment and long-term care. The information obtained is filtered and presented at appropriate times to enhance providence of medical care. Following the assessment workflow, we present a methodology which combines auditing of previous data, hypothetical reasoning and data inferences with the aim of performing a more thorough verification of a flexible process model and provide new ways for model improvement so that current challenges of realworld processes (unpredictability, inconsistency and uncertainty) can be tackled. 2.3. Verification methods The verification of a business process model is useful as it allows an early identification of violations and deadlocks, which can be resolved before the actual execution. However, due to the fact that model checking techniques are based on formal languages, they are too complex for business users to apply. Moreover, the compliance checking of a process model is not an easy task and requires specific tools and formal methods to automatize the process. The set of rules must be translated into an appropriate formal language, which can be further verified via formal methods such as model checking [30,18]. The formalization of guidelines is a challenge for the business process analyst, which must be able to specify conformance rules in a way to easily adhere to the specification of the business process and at the same time interpret properly the returned results [19]. Abstraction methods come as a solution in order to relate information regarding the control and data flow, although they might prove difficult to use by non-expert

104

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

Fig. 2. Interactive framework for the verification of business process models.

users. A visual wrapping of the general process model, the control and data model could be the solution. In this direction, we propose an interactive framework (Fig. 2) that offers a unified view of the operational flow and the data model into a representation which enables the application of model checking methods. Our aim is to incorporate the basic concepts of visual analytics [38] (user, data, model, visualization, and knowledge) in the model checking task to facilitate its use by non-expert users. Building on prior work, we use the support of an extended model checking tool, which enables a more refined verification of rules by considering both the decisions made and the contextual setting. The visual exploration of the model is the key which enables the involvement of the non-expert user in order to extract insights from data via interactions by analyzing visual depictions of that data and deliver proper modeling decisions. However, one must still face the challenge of visually encompassing data and actions and reach a path from data to decision. Behavioral models such as Dynamic Condition Response Graphs offer a visual solution in specifying the

operational constraints, while the data elements and the connection between them can be captured in an ontological model and visually rendered as in [35]. Our main objective is to incorporate the two visual representations in a Kripke like structure to be able to perform the model checking task. By the application of a mapping technique between the data model and the instantiations brought about by the occurrence of events, we are able to provide a more refined representation of context-aware information. Additionally, by considering the inter-dependencies between data, one can infer the changes brought to the data spectrum by an event and how the changes at a certain process instance affects other instances. In this process, visualization plays two pivotal roles: (1) it represents the behavioral and contextual information by highlighting new constructs and relationships; and (2) it serves as the interaction medium to augment areas where violations occur and enable the direct involvement of the process analyst in updating the initial model. Guided by this novel framework, we describe the improvements made to an established business process model in the context of the ThroatScen scenario. The work

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

presented here shows that visual exploitation is best performed in a concrete task where a relatively wellstructured process is defined. In other words, our solution is aimed at combining the reasoning strength of programs with that of humans. We focused on a combined formalism for knowledge and real time which is the fusion of two underlying languages: Description Logic (DL) and Hybrid Logic (HL). When having to consider contextualization, Description Logics allows to oscillate the reasoning process from a general, overall perspective, to a local one detailing the observation space. In the presence of incomplete knowledge [16] and insufficient evidence to validate a general behavior model, we argue that through inference relations, new links might be created, which can be further used in the model checking task to put together the puzzle of data. Additionally, HL allows to anchor on a time axis the occurrences of events, offering a temporal view and at the same time, through its operators, a viable mechanism to jump between different situations and use the data available at different moments of time. By combining the DL and HL reasoning, we can model the temporal and spatial dimensions to reduce the reasoning spectrum to a subset of the state space encapsulating essential information with the final scope of improving efficiency in dealing with changes and general decision making. Complementing the selected logical formalisms with visual representations of data and process executions, our approach provides a further step in the direction of general and flexible automated verification of business processes, which also meets usability requirements. 3. Process model with hybrid logics and description logics The modeling of a business process is a challenging task as it must capture the dynamics of the real world. In other words, the level of abstraction in describing a certain

105

snapshot of the world should be chosen in such a way to allow the representation of both the static elements and the changes brought about by the occurrence of different events. Hence, a representation method should be chosen to allow flexibility in the analysis of business processes. We adopt a view encompassing four different perspectives when it comes to business process model analysis for compliance checking: operational, control-flow, organizational and data perspectives [2]. On top of our methodology we add a visual layer to serve as an interface between the non-expert user and the applied formalisms (Fig. 3). We outline the importance of a visualization support to empower the application of the model checking problem without deepening into the understanding of formalization. The modeling of the real world process dynamics in a Kripke structure is complemented with the ontological representation of the information manipulated within the process instances. The DCR support in the representation of guidelines and protocols allows one to mark the strategic points to be verified on the real world process map (Kripke structure). 3.1. Modeling clinical guidelines for sore throat scenario in DCR In our Sore Throat scenario, we select a minimal general applicable protocol that can be applied in emergency rooms, in order to ensure efficiency and quality in treating the patients. The protocol identifies, as the first step in a medical care scenario, the actual assessment of the patient, which leads to the identification of symptoms. This restriction is represented in our DCR model using the condition relation - between the assessment event and the identification of symptoms. The response relation does not necessarily apply in this case as there might be situations in which the assessment might not lead to any indication of a disease. Moving forward, once a list of symptoms is available, an initial or final diagnosis can be

Fig. 3. Model checking enhanced with visualization support.

106

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

Table 2 Guidelines for treatment prescription in sore throat process. The consult event should occur before checking the symptoms Checking symptoms should occur before setting a diagnosis The prescription of medicine occurs only after the diagnosis is set Event feel sick occurs after the medicine is given Event feel healthy occurs after the medicine is given Events feel sick and feel healthy should not simultaneously occur

- ¼ fðc; csÞg - ¼ fðcs; sdÞg - ¼ fðsd; pmÞg - ¼ fðpm; fsÞg - ¼ fðpm; fhÞg -% ¼ fðfs; fhÞg

Fig. 4. DCR based representation for the general emergency care guidelines.

set. We highlight this prerequisite by the condition relation - between symptoms and diagnosis. The response relation - does not hold in this case as a set of symptoms might not always provide a diagnosis and further testing might be required. The decision upon a diagnosis is a major milestone as it leads to the prescription of a treatment plan for the patient. Hence, the response relation - will be used for connecting the diagnosis with the treatment prescription phase. The prescription of medication is not always conditioned by having a clear diagnosis such as, for example, when symptomatic treatment must be prescribed in order to eliminate false indicators of a disease. The prescribed treatment has a direct influence on the condition of the patient, which might respond to the treatment and improve, in which case we say that the treatment is successful or it might fail, meaning that the patient continues to be sick. Hence the change of the medical condition of the patient comes as a response to the treatment prescribed by the doctor, emphasized in the DCR graph by the response relation -. A treatment cannot have two separate effects on a patient, meaning that it can either improve or not his or her condition. Therefore, it must be clearly stated that both situations cannot occur at the same time, expressed in the DCR representation using the exclude relation -%. The use of dynamic inclusion/exclusion relations in processes with multiple runs allows for an event to alternate between being in conflict with another event occurrence or not. Regarding conflict relations, which are monotone, once an event is identified as being in conflict with another one it remains in conflict and hence it does not allow the context to be changed. Formally, given the set of actions Act ¼ fconsult; check symptoms; set diagnosis; prescribe medicine; feel sick; feel healthyg and the set of corresponding events

E ¼ fc ðconsultÞ; cs ðcheck symptomsÞ; sd ðset diagnosisÞ; pm ðprescribe medicineÞ; fs ðfeel sickÞ; fh ðfeel healthyÞg, the following guidelines (Table 2 with their visual representation in Fig. 4 as a DCR graph) should be considered in an emergency medical care. 3.2. Model for a real world process in compliance checking Kripke structures [18] offer a fully independent way of representing the operational behavior of a process, and once a Kripke model M is built, it enables further verification of properties of interest. A Kripke structure is a sequence of states corresponding to a process (S ¼ s1 ; s2 ; …), connected between them through accessibility relations (R), where each state is described by a set of propositions and nominals, each of them being mapped to the corresponding states by a valuation function (V). A prerequisite for conformance analysis is to organize the information that describes the real world process under investigation in an abstract representation, which enables a formal reasoning method to be applied. A Kripke structure is used for representing the real world sequencing of events and as a formal basis for our model checking process. The main events are used for labeling links between states, while nodes are labeled by suggestive nominals and complemented by a set of state variables for describing the situation of the world. In a first step we identify the main process events based on the available medical records. Definition 1. Given a process modeled as a Kripke structure M ¼ 〈S; R; V〉, we define a process event as any pair e¼ðs1 ; s2 Þ, where s1 ; s2 A S and (s1 ; s2 Þ A R. We consider for each significant recorded event a separate state of the process, while the links provide an

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

107

Table 3 States for treatment prescription in sore throat process. State

Parameters

Specification

Consult SympSC SympSF DiagSC DiagSF TreatSC TreatSF Sick Healthy

{dr, p} {cough, soreT, p} {fever, soreT, p} {virInf, dr} {bactInf, dr} {antiv, dr} {antib, dr} {sick, p} {healthy, p}

The doctor examines the patient Patient shows signs of cough and sore throat Patient complains about fever and sore throat Viral infection is set as diagnosis Bacterial infection is set as diagnosis The doctor prescribes antivirals The doctor prescribes antibiotics Patient feels sick Patient is cured

Fig. 5. Kripke structure of sore throat process.

indication of the action that triggered a change of state. Each state is described by one or more parameters representing pieces of vital information for capturing the changing state of affairs from one recorded state to another. The mapping of parameters to their corresponding states is shown in Table 3. Any information not mentioned for a state is considered as not holding for that specific state. An important aspect to consider in the modeling of a real world process is the granularity level in the representation of the available information. To avoid the stateexplosion problem [10], a refinement can also be done by eliminating those events that are not directly related to the tasks of interest. Although there are many approaches suggested in the literature for reducing the state space [22,1], we use here an eagle eye perspective, focusing on capturing only the aspects of interest from the point of view of a physician. For our consult example, we have the general guidelines (specified as DCR relations in Fig. 4)

represented in the Kripke structure of the Sore Throat process in Fig. 5. 3.3. Data model for attributes in process compliance The modeling of a real world process does not have to capture just the operational aspect of the process, but it must also deal with the terminological baggage, the enclosed knowledge. The available domain knowledge plays an important role in the conformance checking of business process models by capturing additional connections and links between state specific concepts, which might validate certain connections at the operational level or might signal possible conflicts or deadlocks. Description Logics are tailored to express such knowledge about concepts and concept hierarchies and are a solid foundation for ontology representation and reasoning [23]. We use the DL SROIQ for representing the

108

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

Table 4 State specific domain knowledge. State labels

State related concept labels

Consult SympSC SympSF DiagSC DiagSF TreatSC TreatSF Sick Healthy

{Consult, Sick, Doctor, Patient} {Symptom, SoreT, Cough, Patient} {Symptom, SoreT, Fever, Patient} {Diagnosis, ViralInf, Doctor} {Diagnosis, BactInf, Doctor} {Treatment, Antivirals, Doctor} {Treatment, Antibiotics, Doctor} {Condition, Sick} {Condition, Healthy}

Fig. 7. Partial graphical view of STBox and SABox1 for first consult situation.

Fig. 6. Consult STBox.

domain knowledge in our real world process as a basis for reasoning about conformance to standard guidelines and regulations from a data perspective. Medical guidelines use recommendations based on available evidence. Therefore, verifying whether a procedure fulfills a certain property requires the specification of the available contextual data. In this representation, states are the basic building blocks that shape the operational flow. The mapping between each state from the Kripke model and the corresponding set of concepts from the medical domain describing the snapshot of the world at that specific state is shown in Table 4. The domain ontology ThroatScen for our medical care scenario encapsulates knowledge from both medical and pharmaceutical domains. Therefore, in the context of diagnosis and treatment checking, we need in the terminological box STBox of the ThroatScen a clear definition of each concept describing the world (Fig. 6). The axioms from the terminological box of ThroatScen define a symptom as an indicator of a medical condition: sick if the symptom holds (line 17) or healthy otherwise (line 18). A symptom is a subjective evidence of a disease (line 8). A treatment, whether symptomatic (line 14) or specific for a disease (lines 12 and 13), should have a direct impact on the medical condition of a patient (line 11). The assessment is an action performed by a doctor (lines 1 and 2) to determine the symptoms and a possible disease of a patient (line 3). The domain ontology of the ThroatScen is shown in Fig. 7, with an assertional box SABox1 including the

Fig. 8. Updated model of the world after second consult situation.

instantiated values of the concepts. The ThroatScen scenario covers two consult runs, respectively the first and the second visit of the patient. Each visit brings about different instantiations of the terminological box concepts, hence two separate assertional boxes, SABox1 (Fig. 7) for the first run of the consult, respectively SABox2 (Fig. 8) for the second run. 4. Verifying compliance via model checking Compliance checking of general guidelines need to consider also the localization aspect, meaning that the verification process must include the different specific settings in which the rules are applied. Consequently, one must deal with the contextualization [7] of the general model, where the expressive power of Hybrid Logics are used to represent context dependent properties for the model checking task. Specific hybrid operators such as the down-arrow binder ↓ or the @ operator allow different perspectives in the reasoning process, for example, when needing to establish the eligibility of a diagnosis or treatment based on a changing set of symptoms. 4.1. Verifying conformance to behavioral guidelines in DCR For the ThroatScen scenario we verify the application of each guideline specified as a DCR relation (Fig. 4) against

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

the operational model (Fig. 5). The DCR graph captures six possible events, respectively: the consult (c), the identification of symptoms (cs), the setting of a diagnosis (sd), treatment prescription (pm) and the change of condition to healthy (fh) or to sick (fs). Each of the six event occurrences have a direct impact on specific subsets of state parameters {p, dr, soreT, cough, fever, bactInf, virInf, antiv, antib, sick, healthy} (Table 5). We consider first the condition showing that the identification of the list of symptoms is a mandatory requirement for placing a diagnosis (- ¼ fðcs; sdÞg). In our model, the condition can be expressed as: all occurrences of a diagnosis state (a state in which a diagnosis variable holds) must have at least one symptom state (a state in which at least a symptom variable holds) on the path of predecessor states. f 1 : ↓iðvirInf 3 bactlInf ÞððPÞðiÞ-cough 3 soreT 3 feverÞ

ð1Þ

For our ThroatScen scenario such a property would be instantiated and shown to the user in controlled English [36]: If in the state (named by i) either viral or bacterial infection hold as diagnosis, then in a past state (named by P(i)) a symptom was identified (cough, sore throat or fever). In the Kripke structure representation of the operational model (Fig. 5), one can identify the diagnosis states DiagSC and DiagSF, respectively two states in which symptoms are identified: SympSC and SympSF. As both diagnosis states immediately follow the symptom states, we can see that f1 holds in this part of our model. We consider next the condition referring to the property that all symptom states must have a consult state in which the variables referring to the sick condition of a patient and the ones designating the roles of patient, respectively doctor, hold on the path of the predecessor states (- ¼ fðc; csÞgÞ. f 2 : ↓iðcough 3 soreT 3 feverÞððPÞðiÞ-p 4 sick 4 dÞ

ð2Þ

In the context of the ThroatScen, f2 would be expressed for our user in controlled English in a form like the following text. Since in the state (named i) cough, sore throat or fever was confirmed by the doctor, then in a past state (P(i)) the patient complained to the doctor of being sick. Formula f2 holds in our model as both SympSC and SympSF states follow immediately after the Consult state, in which the sick condition holds.

109

Concerning the response relations (Table 2), - ¼ fðsd; pmÞg says that the prescription of medicine follows after a diagnosis is set, and we should verify whether for all diagnosis states, there are successor states in which a treatment is prescribed, meaning that the treatment variable is true. f 3 : ↓iðvirInf 3 bactInf Þð½FðiÞ-antiv 3 antibÞ

ð3Þ

The instantiation of f3 for various situations in the scenario would be conveyed to the user in natural English as If viral infection or bacterial infection is diagnosed by the doctor (state named by i), then in a following state (F(i)) the corresponding medicine must be prescribed for the patient (antivirals or antibiotics). The formula f3 is true in our model as all diagnosis states, DiagSC, respectively DiagSF, have as successors the TreatSC, respectively TreatSF treatment states, in which variables antiv or antib are true. We can check the response relations - ¼ fðpm; fsÞ; ðpm; fhÞg as one single property. These two relations refer to the condition that the prescription of a medical treatment must lead to a state in which the patient condition is either improved (-fðpm; fhÞg), meaning that the patient is considered healthy, or the patient remains sick (-fðpm; fsÞgÞ. f 4 : ↓iðantiv3 antibÞð½FðiÞ-sick 3 healthyÞ

ð4Þ

In our scenario such a property would be articulated to the user in controlled English as follows. If in the state (named by i) antivirals or antibiotics were prescribed, then in a following state (F(i)), the medical condition of the patient observed by the doctor is sick or healthy. The formula is true in our current model since both states, TreatSC, respectively TreatSF, lead to one of the states Sick or Healthy. Another guideline considers the exclude relation between the states referring to the two possible conditions of the patient: sick, respectively healthy, expressed by -% ¼ fðfs; fhÞg. f 5 : ↓iðsick-trueÞð↓jðhealthy-trueÞð@i :healthy 4 @j :sickÞÞ ð5Þ The meaning of f5 is that a patient cannot be recorded by the doctor as being sick and healthy at the same moment of time, which is the case in our model as the two medical conditions were results of different treatments prescribed at

Table 5 Influence of events over state parameters. Event

Parameters

Corresponding states

- ¼ fðcs; sdÞg - ¼ fðc; csÞg - ¼ fðsd; pmÞg - ¼ fðpm; fsÞg - ¼ fðpm; fhÞg -% ¼ fðfs; fhÞg

{soreT, cough, fever, virInf, bactInf} {p, sick, dr, soreT, cough, fever} {virInf, bactInf, antiv, antib} {antiv, antib, sick} {antiv, antib, healthy} {sick, healthy}

SympSC, SympSF, DiagSC, DiagSF Consult, SympSC, SympSF DiagSC, DiagSF, TreatSC, TreatSF TreatSC, TreatSF, feelS TreatSC, TreatSF, feelH feelS, feelH

110

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

Table 6 Timeline of events.

different moments in time. This property could be phrased to the user as below. If in a state (named by i) the condition sick holds then in that state the patient cannot be healthy. If in a state (named by j) the condition healthy holds then in that state the patient cannot be sick. Based on the conditions (1)–(5), expressed in Hybrid Logic, we can see how by combining specific temporal and modal operators we can specify complex properties in the real world of processes, which can be directly shown to the user in controlled English, making it easy for the user to follow properties in the abstract model. The above model verification has shown how the required ordering of events specified in the general clinical guidelines can be declared. However, as the behavioral model (Fig. 5) encapsulates two consecutive runs of the consult procedure, for a better visualization, we need a clearer delimitation between the events from each run. Within the trace in Table 6, we refer to the first run as TP1, which includes all events from the first consult instance, while TP2 includes the series of events from the second consult instance. Additionally, we associate to each event an approximate time-stamp (t 12;16;20;… ) to outline the overlapping of events. Initially, the partial trace for all instances is empty. At time t0, the first consult assessment c1 takes place. The consult event will remain active until the rest of the events from the first run (cs1, sd1 and pm1) are completed. Once the treatment has been prescribed in the first run, c1 terminates. The event cs1 becomes active at the same time as event c1, sd1 is activated once cs1 is completed and pm1 becomes active once sd1 terminates. The termination of c1 triggers the completion of pm1 and the start of event fs1 (patient feeling sick). The second consult assessment c2 starts while event fs1 is still active, triggering the events cs2, sd2 and pm2. The event fh2 is enabled once event pm2 is completed and fs1 becomes inactive. Although the checking of the ordering of events is in conformance to the general medical guidelines, an important aspect was not addressed in the verification,

specifically, the validation of transitions did not consider the availability of resources and the amount of evidence to support a specific change in the state of affairs. For example, even if a state in which symptoms are identified leads to the establishment of a diagnosis, one could not verify at this point whether a valid decision was taken based on the available information. Hence, we outline the necessity of a validation of transitions to be performed considering the existing evidence. Since we need a more refined model, we apply the description logic SROIQ for reasoning about data at both conceptual and instantiated levels. 4.2. Data perspective in compliance checking With the DL we can perform the required reasoning on a set of available data within the scope of extracting information that might prove useful for the model checking task. We apply the DL to verify whether the set of data at each state is in conformance with the general clinical procedure model. With the DL we can determine new links between unrelated pieces of information, and, based on inferences, discover possible missing connections between available evidence. We start the validation process with the first consult instance. The SABox1 depicted in Fig. 7 offers a glimpse over the available medical evidence from the first visit of the patient. To be able to verify conformance in the data model, one must establish first which subset of information corresponds to each state of the process. Hence, a mapping must be done from the assertional information of an ABox over the part of the Kripke structure corresponding to the first consult instance. To perform the mapping we apply the solution proposed in [24], using the notion of interpretation of a state, which is defined as the set of individuals and values from the assertional box that hold in that state. Definition 2. Given a Kripke model M ¼ 〈S; R; V〉 and the associated domain ontology ρ ¼ ðT Box; ABoxÞ, we define IðsÞ an interpretation for a state s A S as the pair IðsÞ ¼ ðΔ ; IðsÞ Þ IðsÞ where the domain Δ is a non-empty set, and IðsÞ is a

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

111

Table 7 Inference relation I1. (I1) STBox ⊔ SABox1 F hasDiseaseðbryan; coldÞ: (a) ðhasSymptomðbryan; soreT ⊓ coughÞ (b) SoreThroatðsoreTÞ ⊓ CoughðcoughÞ (c) ðViralInf  hasSymptomðCough ⊓ SoreThroatÞ

Fig. 10. Inferred relation I1.

Fig. 9. Mapping assertional knowledge on the process model.

function that assigns to every concept name A D T Box a set IðsÞ IðsÞ AIðsÞ D Δ , to every role r a binary relation r I ðsÞ D Δ IðsÞ IðsÞ Δ , and to every individual a an element aIðsÞ A Δ [24]. As a result we obtain the domain of interpretation [24] for each state of the subset (Fig. 9), and then we have to verify whether the contextual setup at one state enables the occurrence of an event that triggers the following state. Definition 3. Given a Kripke model M ¼ 〈S; R; V〉, the associated domain ontology ðT Box; ABoxÞ, and a process event e ¼ ðs1; s2Þ, where s1; s2 A S, we say that e holds for Iðs2Þ Iðs1Þ our model if Δ FΔ . Hence, for each event e ¼ ðs1; s2Þ we verify whether there is a role assertion r such that rða; bÞ D ABox, where a Iðs1Þ is an individual belonging to Δ and b is an individual Iðs2Þ belonging to Δ . We consider the event cs ¼(Consult, SympSC) from the first consult run. By checking the interpretation domain of the two states, Consult and SympSC (Fig. 9), one can IðSympSCÞ observe that Δ includes a role assertion between IðConsultÞ individual bryan, which belongs to Δ and the instantiations of the concepts Symptom, cough and soreT, IðSympSCÞ belonging to Δ , respectively hasSymptomðbryan, cough 4 soreTÞ. Consequently, the occurrence of cs in the first consult instance is considered valid also based on the evidence available at that time. Moving to the second event sd ¼ ðSympSC; DiagSCÞ, one must verify whether there is a connection between symptoms soreT and cough and the Disease concept instance cold. Considering the evidence hasSymptomðBryan; cough 4 soreTÞ, we verify whether cold can be inferred as diagnosis (Table 7). Based on the inference relations a–c together with the terminological assertions specifying that both SoreThroat and Cough are subclasses of the class Symptom (lines 6 and 7 in STBox), cold can be entailed as diagnosis (Fig. 10), hence event sd is considered valid. We want to outline that an inference process can be used in decision making

Table 8 Inference relation I2. (I2) STBox ⊔ SABox1 F hasTreatmentðcold; paracetamolÞ: (d) Disease ⊑ ViralInf (e) ViralInf ⊑ hasTreatmentðAntiviralsÞ (f) ViralInf ðcoldÞ (g) ParacetamolðparacetamolÞ (h) Antivirals ⊑ Paracetamol (I1) hasDiseaseðbryan; coldÞ

regarding a diagnosis. However, DL reasoning cannot confirm a diagnosis bona fides, but only whether the available evidence supports or rules out a certain diagnosis over another. Next, for the event pm ¼ ðDiagSC; TreatSCÞ we check whether a connection can be inferred between some individuals from the interpretation domains of the two states, for example whether paracetamol can be prescribed as a treatment for cold (Table 8). The role assertion hasTreatmentðcold; paracetamolÞ was deduced based on the inference chain d–h and the inferred relation I 1 : hasDiseaseðbryan; coldÞ. One can notice that the verification for each event is done by following the ordering imposed by the clinical guidelines (Fig. 4). This approach captures the exact context in which an event is triggered, meaning the set of available assertions in the interpretation of a state at a specific point in time, but also the inferred relations from previous event verifications, which hold in that situation of the world. 4.3. Reasoning about alternatives All previous inference based checks considered only the known events, respectively the modeled links between states (Fig. 5). However, when one must reason with incomplete knowledge about a situation of the world, there might be cases in which new connections can be inferred between states. Hence, we see the necessity of broadening the reasoning spectrum in order to incorporate also possible alternative paths, which might provide useful information about past occurrences or predictions of

112

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

Table 9 Inference relation I3. (I3) STBox F hasTreatmentðDiseaseÞ ⊑ Medication: (j) Disease ⊑ ( hasSymptom⊓ 8 hasTreatmentðAntibiotics ⊔ AntiviralsÞ (k) Symptom ⊑ ( hasTreatmentðMedicationÞ (l) Medication ⊑ ðParacetamol ⊔ AmoxicilinÞ (m) Antibiotics ⊑ Amoxicilin (n) Antivirals ⊑ Paracetamol

Fig. 12. Updated model for first consult situation based on DL reasoning.

Fig. 11. Inferred relation I3.

future events. Through inference, one might identify new role assertions between individuals from different interpretation domains of states, which might have been overlooked in the previous modeling of the world. As an example, if we consider the interpretation domain of the TreatSC state, a role assertion can be established between the instantiation of the Paracetamol concept and the instantiation of the Viral Infection concept cold (inferred relation I2), but also between paracetamol and the instanI tiated values of the Symptom concept belonging to Δ SympSC , respectively fcough; soreTg. The relation follows from a new inference I3 (Table 9), which indicates the connection between the medication for a symptom and the actual treatment of a disease. I3 states that the medication for a symptom is included in the treatment for a disease signaled by that specific symptom (Fig. 11). The relation is deduced based on the inference chain j n, which indicates that a disease is signaled by one or more symptoms and it is treated with medication. Additionally, it is known that a symptom is treated with a specific medication (line 15 in the STBox). Hence, the treatment for a disease includes the medication for its symptoms. The new relation can be translated in the real process model by the addition of a new link in the Kripke structure between states SympSC and TreatSC. Consequently, a new process event might be added to the set of events E. Let pmu A E be the new process event triggered by the inference relation I3. We update the partial Kripke structure corresponding to the first consult instance with the new link indicating the occurrence of pmu, shown in Fig. 12. We now check whether the updated model still complies with the standard clinical guidelines. From the DCR based representation (Fig. 4) it is known that the prescription of a treatment pm comes as a response to a set diagnosis sd (relation - ¼ fðsd; pmÞg), but the setting of a diagnosis (event sd) is not a mandatory condition for the prescription of a treatment. Making the correspondence with the real world, we consider the case when a symptomatic treatment might be prescribed for a patient in order to eliminate some of the symptoms and reduce the set of

possible diagnoses. Another aspect that one must consider is whether the new event pmu can occur simultaneously with the event pm. We use again a connection to a real world situation to provide an explanation. A doctor can prescribe a treatment for a disease and at the same time write a prescription for treating a separate symptom or condition. Hence, the two events can occur at the same time, the only condition being for the symptom not to be already included in the set of indicators for a treated disease. 4.4. Dealing with deviations from normal behavior Considering the verification of event fs ¼ ðTreatSC; SickÞ, one can observe that the domain of interpretation for the state Sick already includes the role assertion hasEffectðparacetamol; sickÞ as a clear indicator of the connection between states TreatSC and Sick (Fig. 9). Given the assertion from line 11 in the STBox, the sick condition can indeed appear as a result of a treatment. However, going further to line 12 in the STBox, one can observe that the prescription of antivirals such as paracetamol for a viral infection (cold) should have a positive result, hence the patient should become healthy. Assuming that all the above inferences were correctly deduced by the DL reasoner, one needs to identify the cause that led to reaching the Sick state. This situation highlights the limitations of DL reasoning when having to deal with the dynamics of real world environments in which unforeseen events usually appear. The DL ABox offers a description of a state of affairs in an application domain, but it cannot extend beyond the limits of one situation of the world, which would allow another perspective on the interpretation of events. Hybrid Logics comes as a solution by allowing, based on its expressive power, to formally provide different interpretations of a world. By analyzing a state of affairs and keeping at the same time a perspective on past and possible future actions and their effects, one can bring more light over an unpredictable turn of events. 5. Reasoning over different contextual situations We focused so far on presenting the advantages that inference based reasoning brings to the compliance checking task, but also the limitations of DL when dealing with pieces of information brought about by unpredictable occurrences of events. One must consider the dynamics of real world processes in which different perspectives and interpretations of the world must be provided so that certain decisions or conclusions can be formulated, hence

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

113

world model (Fig. 5). f 6 : ↓i:ðcoughÞððFÞðiÞ-ð (jðparacetamol- > Þ 4 ð½Fj-:coughÞÞ ð6Þ In our ThroatScen scenario the above property can be expressed in controlled English as follows.

Fig. 13. Updated model of the world in the second consult situation.

the need of a language expressive enough to meet some aspects of the natural language. Although there is no logical language to rule them all, we see how Hybrid Logics can enable different perspectives in the reasoning about events.

5.1. Reasoning in the updated model of the world In the ThroatScen scenario, the negative result of the first treatment led to a second assessment of the patient, which revealed that cough was no longer present, while sore throat remained and fever appeared as a new symptom. The change of the symptom set triggered also a change of the state of affairs. A new diagnosis was given and a new treatment was provided with a positive effect on the condition of the patient, illustrated in Fig. 8 as an updated situation of the world. This new set of states of the second assessment (Fig. 8) brings about new domains of interpretation to be considered in the reasoning process (Fig. 13). Within the updated assertional model, applying a similar inference process as in the case of the first assessment, it follows that, based on the new subset of symptoms fever and soreT, strep throat (streptococcal infection) can be considered as a valid diagnosis. Moreover, by checking the interpretation domain of the state Healthy, one can notice that the role assertion hasEffectðamoxin; healthyÞ holds, indicating that the treatment prescribed at the second visit was successful. The analysis of the available information from the second consult instance might provide useful insights on what it concerns the decisions made in the first consult and the resulted effects. Additionally, we verify how the information from the first consult instance impacted the decision making process in the second consult instance. To be able to analyze the connections between the two separate situations of the world, we can use the HL specific operators: the down-arrow binder ↓, which provides the switch between different reference points, and @i to set a new perspective in our reasoning. In the first consult instance, the presence of the symptom cough (line 9 in the STBox) ruled out strep throat as possible diagnosis, as testing for bacterial infection is not recommended when the patient presents signs that strongly suggest a viral etiology (e.g. cough) [21]. The treatment prescribed for viral infection led therefore to the elimination of cough from the symptom set in the second consult instance. We then verify the condition referring to the elimination of a symptom once the corresponding medication is prescribed against the real

When in a state (named by i) cough is identified as symptom, then cough remains an active symptom until a following a state (named by j) where the corresponding treatment (paracetamol) is prescribed, causing a following state (F(j)) without cough. This formula is true in our model since in all symptom states following the state in which paracetamol is prescribed as treatment (state TreatSC) the cough symptom is no longer present (Fig. 5). The elimination of cough as symptom reduced the spectrum of possible diagnoses in the second consult instance by invalidating all the diseases signaled by cough, including those having both cough and sore throat as symptoms: D=ðDCough [ DCough [ SoreT ) (Fig. 14). In the second consult instance, bacterial infection is considered a possible diagnosis as it includes sore throat among its symptoms, but it excludes coughing. Viral infection is ruled out as a diagnosis also by the presence of fever as symptom and indicator of bacterial infection [21]. f 7 : ↓i:ðcough4 soreTÞð↓j:ðfeverÞð½FðiÞ-virInfUjÞÞ

ð7Þ

Formula f7 is phrased in controlled English as follows. In a state (named by nominal i) in which cough and soreT hold as symptoms, the diagnosis of viral infection will hold until fever appears as new symptom (at a state named by nominal j), which determines a change of diagnosis (Table 1). 5.2. Reasoning with hypotheses There is a broad overlap between the signs and symptoms of streptococcal and viral infection (Table 1) for diagnosis to be made with precision on the basis of clinical grounds alone [21]. Considering this aspect, the diagnosis process in the first consult instance is reduced to hypothetical reasoning. Based on the existing evidence (the presence of the symptom cough) and on the assumption that viruses are the most common cause of acute infection [21], viral infection is selected as first possible diagnosis (following

Fig. 14. Diagnosis based on overlapping symptoms.

114

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

possible presence of an upper respiratory infection on top of the bacterial infection. By reducing the observation space to a subset of interconnected states which exchange information that shrinks the probabilities of candidate conditions to negligible levels, using evidences such as symptoms and past knowledge, the diagnosis process can be improved. This enables also a more efficient handling of unpredictable changes in the condition of the patient and to adjust quicker the epistemic confidences in the mind of the diagnostician. 6. Using the tools

Fig. 15. Relating past and current situation in hypothetical reasoning.

Occam's razor principle, which suggests looking for the simplest, most common explanation first). By analyzing the first treatment results and the new set of symptoms at the second consult instance a more accurate decision can be made. From the properties f6 and f7 one can see that symptoms play a crucial role in selecting one diagnosis over another. Moreover, the application of a symptomatic treatment (as indicated by the inference relation I3) might rule out those symptoms that do not hold and determine the disease concept, which encapsulates the remaining symptoms, for our case here BactInf. Hence, a direct connection should be considered for future cases between the applied treatment and the following examination of symptoms, which allows a quicker interpretation of the symptomatic treatment results. In our model, this can be translated by the introduction of a new link of type cs between the states TreatSC from the first consult run and SympSF from the second consult one (Fig. 15). This new connection enables a more efficient differential diagnosis procedure by allowing a closer observation of the condition of the patient and the elimination of false positive signs. For example, considering the first consult run, in order to verify the hypothesis that the patient suffers from viral infection, antivirals are prescribed as treatment for the symptoms cough and sore throat. The immediate reexamination of the symptoms of the patient helps in establishing the correctness of the prescribed treatment and of the initial hypothesis. The presence of sore throat after the application of the initial treatment indicates a possible other cause for this symptom, which leads to a new hypothesis that considers bacterial infection as diagnosis, confirmed also by the presence of fever. The elimination of cough as symptom after the administration of the initial treatment indicates a

The logical and visual layers presented above are orchestrated by tools that automate the model checking task: the DL reasoner HermiT1 included in the Protégé framework2 and the Hybrid Logics Model Checker HLMC.3 The data model of the ThroatScen scenario was specified under an ontological representation. To validate the model, consistency checking was performed in the Protégé framework. By applying the DL Reasoner HermiT, new relations were added through inference processes (Fig. 16). The reasoner supported also the checking of the inferred properties I 1 ; I 3 and enabled a visual perspective on the model checking task for the data model. The verification of the Hybrid Logic formulas f1–f7 for the operational model corresponding to the ThroatScen scenario was instrumented with the model checker HLMC [13]. Given as input a Hybrid Logic formula it is verified against the Kripke model (an XML file). Each state of the Kripke model is specified by means of an identifier and by the introduction of one or more nominals denoting it, while the binary accessibility relations are identified by a name and a list of the pairs of worlds for which the relation holds. For the valuation function of the Kripke model, propositional symbols are included together with the set of worlds at which they hold, with a partial specification of the Kripke model shown in Fig. 17. Each HL formula is provided according to HLMC specific syntax [13], for example: Bx ð@x ðPastðbactInfÞ & ðcoughjsoreTjfeverÞÞÞj Byð@y ðPastðvirInfÞ & ðcoughjsoreTjfeverÞÞÞ

for formula f1. Checking the formula against the Kripke model we receive the states in which it holds, in this case the symptom states that appear on the predecessor paths of the diagnosis states DiagSC and DiagSF, respectively SympSC and SympSF, with Fig. 18 showing a fragment. 7. Discussion We have presented the results of an analysis of the types of properties that can be effectively verified by model checking, from the general behavioral constraints to evidential based decision making. We have also offered 1

Available at http://www.hermit-reasoner.com/ Available at http://protege.stanford.edu/ Available at http://luigidragone.com/software/hybrid-logics-modelchecker/ 2 3

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

115

Fig. 16. Visualization in Protégé of the inferred model for ThroatScen.

an overview of the usefulness of the verification task at different stages in the execution of a business process. By combining HL and DL based reasoning, we have shown improvements concerning the exchange of data between interconnected states and the usage of new links for a more efficient flow of information. Model checking tasks can use different logics for the specification of the formulas to be verified against a model, such as temporal logics [25], with its variants Computational Tree Logic (CTL) and Linear Temporal Logic (LTL) or, for the case here, Hybrid Logics. While LTL is used for describing the events along a single computation path, CTL considers all the paths that are possible from a given state. Although temporal logics are widely applied in the literature [25,7] for the verification task of properties that must hold within a model, in a contextual dependent setting, in which process executions must adapt to the resources available at that time, HL is able also to explicitly show the local perspective of the reasoning task. Considering the consult scenario, LTL can be successfully applied for the verification of the general guidelines specified as DCR conditions (Fig. 4). Specifically, for the

mutual exclusion property that must hold for the events fs and fh in formula f5, LTL would allow a more simple expression. l5 : □:ðhealthy 4 sickÞ:

ð8Þ

Translated in natural language for the non-expert user, l5 expresses the condition that Always (□), the two possible medical conditions for a patient (healthy and sick) cannot hold at the same time. However, for other conditions, LTL might not be able to capture all the aspects to be verified. For example, if we select the condition formally specified by formula f7, stating that as long as sore throat and cough hold in the state in which symptoms are identified, the diagnosis of viral infection will also hold as a valid option until the subset of symptoms changes, respectively until fever appears as symptom, the corresponding LTL formula would be l7. l7 : □ððcough 4 soreTÞ-⬨ðvirInfUfeverÞÞ

ð9Þ

116

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

Fig. 17. Kripke model as XML input file for HLMC.

Explained for the non-expert user, l7 translates as follows in natural language: Generally (□), the presence of symptoms cough and sore throat, will eventually (◊) lead to the diagnosis of viral infection. However, the LTL formula does not capture the situational aspects (valid only for the two consult instances), lacking any context reference (such as that it is based strictly on the

medical history of the patient and on the investigations performed at that time). Hence, the reasoning must keep a local perspective over the analyzed data and event occurrences. Moreover, if the reasoning is performed as part of an auditing process, which focuses on past happenings, one must be able to express and differentiate between the knowledge available at different points in time. In the HL formula f7 the use of the binder ↓ to label the state at which symptoms are identified, enables a shift in perspective to the moment when cough and sore throat hold.

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

117

Fig. 18. Excerpt of the verification process in HLMC.

As ◊ pushes the reasoning process towards a general time reference as shown in LTL formula l7, the downarrow binder allows us to label the states of reference, which enable a certain trail of events. Hence, the possibility to express formally the temporal related flavors of natural language are of major importance in the reasoning task for real world processes, where the dynamics may influence the truth values of statements in different moments of time. The LTL formula l7 gives a general flavor to the

specified condition, and does not allow a shift in perspective from one moment to another. Additionally, LTL proves its limitations in capturing the setting in which the condition must hold. In an audit process, for example, the scope is to identify the contextual aspects that led to the execution of one specific sequence of events. When we need contextualization, description logics can be used to move the reasoning process from a general, overall perspective, to a local, detailed observation. With

118

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

the help of DL we could include the available information at a specific context in the reasoning task (e.g. the SABox1 and SABox2 situations of the first and second consult). 8. Related work While we use the HL(@, ↓, ( , A, F, Next, P, U, S) variant of Hybrid Logics to check whether contextual related properties hold for the model, HL(@, ↓) has been used in the model checking of strategic equilibria in the analysis of game-like systems [27]. As the strategic game model in [27] is rather theoretic, the authors did not need a more refined model that requires an ontology. They also did not need to exploit the rich expressive operators of Hybrid Logics. Another model checker for Hybrid Logics (HyLMoC) [28] aimed to model qualitative spatial reasoning and reasoning on information spread over graph-like structures. As we are not interested in just spatial structures, but on more abstract spaces, since the real world scenarios that we envisage may suffer from the space explosion problem, we did not consider using it. Model checking using description logic has been studied recently and shown to provide significant advantages in the version of Bounded Model Checking (BMC) on the variant ALCI of the DL, by a specific encoding and experimented on the FaCT þ þ DL reasoner [29]. We have not been interested in improving the performance of the HLMC model checker, but rather in using the DL model for a better (and more efficient) visualization of the knowledge available for the user. The effect of the BMC in our case is obtained by a rather short distance between the concepts in the TBox. When the state space of a multi-agent system is too large for a model checker to compute, it is sometimes possible to reduce it by abstraction before feeding the system to a model checker [30]. A model checking approach for the analysis of abstract system properties has been shown on an automotive scenario from the service oriented computing domain [31]. On the same line, the scenario-driven analysis of systems specified through graph transformations of [10] has the most significant scenarios in view. Another abstraction for dealing with the state space explosion problem in model checking [22] applies a selection of a set of variables that are insensitive to the property of interest. Since our intention is to represent the knowledge of the user in the form that the user knows and understands, we have kept the explosion problem under control by exploiting the abstraction capabilities of the human actor. Compliance checking of business process models using the visual language BPMN-Q has been done in CTL [19]. By using BPMN queries, it was shown how to give a business process modeler feedback about the presence of a problem and the part of the model causing that problem [32]. The support for enterprise service modeling and generation presented in [3] includes a model checker for verifying BPEL code generation. The tree-based overlay structure can represent organizationally structured services with process flows, but it does not tackle the exceptions that might arise during running, as we are concerned with in this article. In [1] the authors have studied the

conformance between a process model and its corresponding execution log, using an incremental approach. We have followed this idea of conformance by considering the current execution log and looking into the future to seek a continuation from the current situation to help the user find ways in finalizing the task. Although we do not use a very refined model for the processes that we represent, we have oriented our work towards the very rich business artifacts with Guard-Stage-Milestone lifecycles [6], for which the DCR representation is a first step. In a guideline modeling language, both CTL and LTL have been used to model check, for critiquing, clinical guidelines [8]. Patterns have been proposed (abstract enough) to capture the normal and abnormal scenarios of assignment and delegation of tasks in collaborative work in health care teams [9]. In [33] we are shown how one can implement flexible goal-based plan specialization using an argumentation-based decision model that separates the decision-relevant knowledge from the plan specifications. We have used a simple clinical guideline scenario since it is easier to understand the mechanisms, but again with the future aim to more complicated processes. Rule-based compliance checking with process mining has also been done with LTL [2], trying to cover several perspectives: functional, control-flow, organizational and data. Our approach is able to consider all these perspectives, although we have not detailed them, and besides we use the expressive power of HL(@, ↓, ( , A, F, Next, P, U, S) with a more abstract and refined perspective. While user recommendations for the optimized execution of business processes have been shown in declarative business models [34] by solving it as a constraint satisfaction problem (CSP), our approach offers the user the power to inspect whatever the user considers significant. That could be auditing, decision making, debugging, or other applications. An ontological representation has been used in [35], for a visual perspective of the concepts belonging to the T Box and their instantiated values in the ABox, with the aim to show the workings of a mechanism for the enactment of policies and norms in a multi-agent system. 9. Summary The flexibility advocated in [4] is very well portrayed in scenarios of collaborative work in health care teams [9], but also in goal-based plans of daily decisions [33], and in adverse interactions in pairs of guidelines [37]. Such cases can also appear in other business oriented activities in which a simple and rigid workflow model might not be sufficient, because most such activities are usually in interaction with others. We have shown how conformance to behavioral guidelines can be represented and verified it in the case of our ThroatScen scenario and, more importantly, how the properties to be checked can be straightforwardly translated into controlled English in Eqs. (1)–(5). This aspect underlines the verbalizing feature of the methodology shown in this article, which provides a very useful window for the user of such support.

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

Various contextual situations have been considered and shown how they can be managed using a corresponding updated model of the world of interest for the user, with new properties for such cases shown in Eqs. (6) and (7) together with their translated controlled English. Such an adaptation in the representation through remodeling is very significant for the user when the intention is to make changes visible by a proper phrasing of such changes in the environment. In Eqs. (8) and (9), when another logic like LTL is used instead of HL, we have shown two simpler expressions, but with less expressive power than the one that users might want, and which is provided by HL, but not by LTL. On the same line of thought, the expressive power of DL (very useful fo the user) can be seen in Fig. 7.

Table 11 Syntax and semantics of SROIQ axioms. Box

Syntax

Fig. 19. Semantics for temporal logic.

Semantics

ABox: Concept assertion

C(a)

aI A C I

Role assertion

Rða; bÞ

〈aI ; b 〉 A RI

Individual equality

ab

aI ¼ b

Individual inequality

a≉b

aI a b

TBox: Concept inclusion

C⊑D

C I D DI

Concept equivalence

C D

C I ¼ DI

RBox: Role inclusion

R⊑S

RI D SI

Role equivalence

RS

RI ¼ SI

Complex role inclusion

R1 ○R2 ⊑ S

RI1 ○ RI2 D SI

Role disjointness

DisjointðR; SÞ

RI \ SI ¼ ∅

9.1. Conclusion In our approach, we combined the advantages of Hybrid Logic and Description Logic based model checking

119

I

I I

in the verification of properties of interest in different contextual settings, with more complex processes. The visualization support offered by this abstract representation allows a better understanding of the workings of processes and of the way in which data is manipulated inside their execution. By complementing the two logical formalisms with visual and verbal representations of data and process executions, our approach provides a further step in the direction of general and flexible automated verification of business processes.

Acknowledgments The authors gratefully acknowledge the support by CNCSIS-UEFICSU, National Research Council of the Romanian Ministry for Education and Research, Project ID_170/2009.

Fig. 20. Semantics for hybrid logic.

Appendix A A.1. Syntax and semantics of hybrid logics

Table 10 Syntax and semantics of SROIQ constructors. Type

Syntax Semantics

Individuals: Individual name

a

Roles: Atomic role

R

RI

Inverse role

R

f〈x; y〉∣〈y; x〉 A RI g ΔI  ΔI

aI

Universal role

U

Concepts: Atomic concept

A

AI

Intersection

C⊓D

C I \ DI

Union

C⊔D

C I [ DI

Complement

:C

Top concept Bottom concept Existential restriction Universal restriction

> ? ( R:C

ΔI =C I ΔI ∅

Nominal

fag

8 R:C

fx∣ some RI successor of x is in C I g fx∣ all RI successors of x are in C I g faI g

Hybrid Logics can be defined as a derived version of the Modal Logics [11,12], which adds support for specific operators combined with temporal operators. Temporal logics (TL) extend propositional logics with temporal operators future F, past P, until U, since S, so that with the set of propositional symbols PROP ¼ fp1 ; p2 ; …g, the syntax of temporal logic is the one below with the semantics in Fig. 19.

φ≔> ∣p∣:φ∣φ 4 φ∣Fφ∣Pφ∣φUφ∣φSφ The dual of P is Hα ¼ :P:α and the dual of F is Gα ¼ :F:α. Hybrid logics (HL) extend temporal logics with special symbols that name individual states and access states by name [11]. With nominal symbols NOM ¼ fi1 ; i2 ; …g called nominals and SVAR ¼ fx1 ; x2 ; …g called state variables the syntax of hybrid logics is shown below.

φ≔TL∣i∣x∣@xt φ∣↓x:φ∣( x:φ With i A NOM, x A WVAR, t A NOM [ WSYM, the set of state symbols WSYM ¼ NOM [ WVAR, the set of atomic

120

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

letters ALET ¼ PROP [ NOM, and the set of atoms ATOM ¼ PROP [ NOM [ WVAR, the operators @; ↓; ( are called hybrid operators with the semantics in Fig. 20 [13]. Nominals are not the only aspect that sets hybrid languages apart from traditional modal and temporal languages. Additionally, hybrid languages may contain the at operator @i which gives random access to the unique state named by i and holds if and only if p holds at the state named by i. Moreover, hybrid languages may be extended with the down-arrow binder ↓x. that assigns the variable name x to the current state of evaluation. Finally, the existential binder (x. binds the variable name x to a state in the model. Hybrid languages come with various items of machinery, but we use here the language known as HL(@, ↓, ( , A, F, Next, P, U, S) [11, chapter 14], to which we refer simply by HL. A.2. Syntax and semantics of Description Logic Description Logics (DLs) [14] are a family of logic-based formalisms for the representation of and reasoning about conceptual knowledge with the constructors shown in Table 10 where a; b A NI are individual names, A A NC is a concept name, C; D A C are concepts, and RA Roles is a role. The semantics of the operators used in SROIQ are shown in Table 11. Information about the world can be maintained in rich knowledge bases by updating the ABox, approximating some kind of evolution of the knowledge base [15–17]. Since such operations can be quite complicated, we prefer to use in this article the expressive power of the HL which can refer to different situations in the abstract representation of the model containing different copies of the current knowledge base. Description Logics (DLs) [14] are based on concepts (or classes), which denote sets of objects, for representing the domain of interest and roles (or relations), which denote binary relations between objects. DL knowledge bases are constituted by two components: the terminological box T Box, which contains intensional description of the domain of interest, expressing general knowledge about concepts and their relationships, and the assertional box ABox, which contains extensional information, capturing the state of affairs described by concepts instances. In other words, a DL knowledge base K ¼ ðT Box; ABoxÞ consists of a set of universal assertions defining the classes and relations (T Box) as well as a set of membership assertions about the belonging of individuals to specific classes or concepts from the domain ABox. I Given an interpretation I ¼ 〈Δ ; I 〉, where I is the interpretation function i.e. a function mapping each conI I I cept to a subset of Δ and each role to a subset of Δ  Δ , we say that I is a model of a (or satisfies) T Box or ABox assertion α, if α is true in I 4 . We say that I is the model of a knowledge base K ¼ 〈T Box; ABox〉 if I is a model of all assertions in T Box and ABox. A.3. Dynamic condition response graph A Dynamic Condition Response graph consists of a set of events, a marking defining the execution state, and four

binary relations between the events defining the conditions for the execution of events, the required responses and the notion of dynamic inclusion and exclusion of events. We also have a set of actions, a labeling function assigning an action to each event, a set of roles, a set of principals and a relation assigning roles to actions and principals. Definition 4. [5] A dynamic condition response graph is a tuple G ¼ ðE; M; Act; -; -; 7 ; lÞ where 1. E is the set of events 2. M A MðGÞ ¼ PðEÞ  PðEÞ  PðEÞ is the marking and MðGÞ is the set of all markings 3. Act is the set of actions 4. - D E E is the condition relation 5. - D E E is the response relation , 6. 7: E  E f þ; %g defines the dynamic inclusion/exclusion relations by e-þ e0 if 7 ðe; e0 Þ ¼ þ and e-% e0 if 7ðe; e0 Þ ¼ %. 7. l: E-Act is a labeling function mapping every event to an action.

We use DCR Graphs to refer dynamicconditionresponsegraph s.

to

the

model

of

A.4. Structure of model for compliance checking The validation of process models relies on model checking for performing the automatic verification of properties. Model checking [18] is the problem of determining for a particular model M of a logical language whether a given HL formula μholds in that model, that is M F μ. It can be used for checking either properties of linear models, e.g. a sequence of observed states, or, in our case here, models of dynamic systems. Model checking is usually based on the use of a representation structure or Kripke structure for the system modeling and of some kind of declarative language for specifying the formula to be checked against the model. Definition 5. A Kripke structure M consists of an infinite sequence of states S ¼ s1 ; s2 ; …, R a family of binary accessibility relations on M and a valuation function V that maps ordinary propositions and nominals to the set of states in which they hold, i.e. M ¼ 〈S; R; V〉 [18]. In the graph oriented representation of M, the nodes correspond to the sequence of states brought about by different modalities represented as links between states. The links connecting two states represent the events that determine the transition from one state to another. Having built the Kripke structure enables us to use a variety of very powerful declarative languages, such as Linear Temporal Logics (LTL) or Hybrid Logics for further extracting and validating relevant information. Although temporal logics are usually applied as specification languages in the model checking task [19,2,7],

I.A. Letia, A. Goron / Journal of Visual Languages and Computing 28 (2015) 100–121

something crucial is missing when it comes to verifying the dynamics of a real world process. Temporal logics lack mechanisms for naming individual or sets of states, and for dynamically creating new names for individual or sets of states. Hybrid Logics, through the presence of nominals, can be exploited to allow accessing possible worlds, using its expressive power to specify both knowledge and time related properties to be verified against a given model. The focus is on local model checking [20], traversing necessary parts of the input in order to establish the satisfaction relation between a given world and a formula. Global model checking computes all the worlds in a Kripke structure that satisfy the input formula. However, often we are concerned with a certain snapshot of the world and it would suffice to know for that specific fraction of the world whether it does satisfy the input formula [20]. Description Logics complement the Hybrid Logics based approach. As formalisms that are widely used for knowledge representation, Description Logics allow to capture the data of interest and relations among different pieces of information at different levels of abstraction, creating a detailed contextual setting. The proposed methodology combines the HL and DL based formalisms as the basis of the model checking problem allowing to capture a wider spectrum of data and relations to be further verified against a model given as a Kripke structure. References [1] A. Rozinat, W.M.P. van der Aalst, Conformance checking of processes based on monitoring real behavior, Inform. Syst. 33 (2008) 64–95. [2] F. Caron, J. Vanthienen, B. Baesens, Comprehensive rule-based compliance checking and risk management with process mining, Decis. Support Syst. 54 (2013) 1357–1369. [3] L. Li, J. Grundy, J. Hosking, A visual language and environment for enterprise system modelling and automation, J. Vis. Lang. Comput. 25 (2014) 253–277. [4] W.M.P. van der Aalst, M. Pesic, H. Schonenberg, Declarative workflows: balancing between flexibility and support, Comp. Sci. Res. Dev. 23 (2009) 99–113. [5] T.T. Hildebrandt, R.R. Mukkamala, Declarative event-based workflow as distributed dynamic condition response graphs, in: Programming Language Approaches to Concurrency and Communication-cEntric Software, Springer, 2010. [6] E. Damaggio, R. Hull, R. Vaculin, On the equivalence of incremental and fixpoint semantics for business artifacts with Guard-StageMilestone lifecycles, Inform. Syst. 38 (2013) 561–584. [7] A. Bottrighi, L. Giordano, G. Molino, S. Montani, P. Terenziani, M. Torchio, Adopting model checking techniques for clinical guidelines verification, Artif. Intell. Med. 48 (2010) 1–19. [8] P. Groot, A. Hommersom, P.J.F. Lucas, R.-J. Merk, A. ten Teije, F. van Harmelen, R. Serban, Using model checking for critiquing based on clinical guidelines, Artif. Intell. Med. 46 (2009) 19–36. [9] M.A. Grando, M. Peleg, M. Cuggia, D. Glasspool, Patterns for collaborative work in health care teams, Artif. Intell. Med. 53 (2011) 139–160. [10] V. Rafe, Scenario-driven analysis of systems specified through graph transformations, J. Vis. Lang. Comput. 24 (2013) 136–145. [11] C. Areces, B. ten Cate, Hybrid logics, in: P. Blackburn, J. Van Benthem, F. Wolter (Eds.), Handbook of Modal Logic, Elsevier, Amsterdam, 2007, pp. 821–868.

121

[12] L.S. Moss, H.-J. Tiede, Applications of modal logic in linguistics, in: P. Blackburn, J. Van Benthem, F. Wolter (Eds.), Handbook on Modal Logics, Elsevier, Amsterdam, 2007, pp. 299–341. [13] M. Franceschet, M. de Rijke, Model checking hybrid logics (with an application to semistructured data), J. Appl. Log. 4 (2006) 279–304. [14] F. Baader, The Description Logic Handbook: Theory, Implementation, and Applications, Cambridge University Press, 2003. [15] B. Bagheri Hariri, D. Calvanese, M. Montali, G. De Giacomo, R. De Masellis, P. Felli, Description logic knowledge and action bases, J. Artif. Intell. Res. 46 (2013) 651–686. [16] H. Liu, C. Lutz, M. Milicic, F. Wolter, Foundations of instance level updates in expressive description logics, Artif. Intell. 175 (2011) 2170–2197. [17] E. Kharlamov, D. Zheleznyakov, D. Calvanese, Capturing modelbased ontology evolution at the instance level: the case of DL-Lite, J. Comput. Syst. Sci. 79 (2013) 835–872. [18] S. Cranefield, M. Winikoff, Verifying social expectations by model checking truncated paths, J. Logic Comput. 21 (2011) 1217–1256. [19] A. Awad, M. Weidlich, M. Weske, Visually specifying compliance rules and explaining their violations for business processes, J. Vis. Lang. Comput. 22 (2011) 30–55. [20] M. Lange, Model checking for hybrid logic, J. Logic Lang. Inf. 18 (2009) 465–491. [21] S.T. Shulman, A.L. Bisno, H.W. Clegg, M.A. Gerber, E.L. Kaplan, G. Lee, J.M. Martin, C. Van Beneden, Clinical practice guideline for the diagnosis and management of group A streptococcal pharyngitis: 2012 update by the Infectious Diseases Society of America, Clin. Infect. Dis. (2012). [22] C. Tian, Z. Duan, N. Zhang, An efficient approach for abstractionrefinement in model checking, Artif. Intell. Med. 461 (2012) 76–85. [23] F. Dau, P. Eklund, A diagrammatic reasoning system for the description logic ALC, J. Vis. Lang. Comput. 19 (2008) 539–573. [24] I.A. Letia, A. Groza, Compliance checking of integrated business processes, Data Knowl. Eng. 87 (2013) 1–18. [25] J. Bentahar, H. Yahyaoui, M. Kova, Z. Maamar, Symbolic model checking composite web services using operational and control behaviors, Expert Syst. Appl. 40 (2013) 508–522. [27] N. Troquard, W. van der Hoek, M. Wooldridge, Model checking strategic equilibria, in: Model Checking and Artificial Intelligence, LNAI, vol. 5348, Springer, 2009, pp. 166–188. [28] A. Mosca, L. Manzoni, D. Codecasa, HyLMoC: a model checker for hybrid logic, in: M. Gavanelli, F. Riguzzi (Eds.), CILC09: 24-esimo Convegno Italiano di Logica Computazionale, Ferrara, Italy. [29] S. Ben-David, R. Trefler, G. Weddell, Model checking using description logic, J. Logic Comput. 20 (2010) 111–131. [30] M. Cohen, M. Dam, A. Lomuscio, F. Russo, Abstraction in model checking multi-agent systems, in: Eighth International Joint Conference on Autonomous Agents and Multiagent Systems, 2009, pp. 945–952. [31] M.H. ter Beek, A. Fantechi, S. Gnesi, F. Mazzanti, A state/event-based model-checking approach for the analysis of abstract system properties, Sci. Comput. Program. 76 (2011) 119–135. [32] R. Laue, A. Awad, Visual suggestion for improvements in business process diagrams, J. Vis. Lang. Comput. 22 (2011) 385–399. [33] M.A. Grando, D. Glasspool, A. Boxwala, Argumentation logic for the flexible enactment of goal-based medical guidelines, J. Biomed. Inform. 45 (2012) 938–949. [34] I. Barba, B. Weber, C.D. Valle, A. Jimenez-Ramirez, User recommendations for the optimized execution of business processes, Data Knowl. Eng. 86 (2013) 61–84. [35] M. Sensoy, T.J. Norman, W.W. Vasconcelos, K. Sycara, OWL-POLAR: a framework for semantic policy representation and reasoning, J. Web Semant. 12–13 (2012) 148–160. [36] S. Ferre, SQUALL: the expressiveness of SPARQL 1.1 made available as a controlled natural language, Data Knowl. Eng. 94 (2014) 163–188. [37] S. Wilk, W. Michalowski, M. Michalowski, K. Farion, M.M. Hing, Mitigation of adverse interactions in pairs of clinical practice guidelines using constraint logic programming, J. Biomed. Inform. 46 (2013) 341–353. [38] S. Reddivari, R. Shirin, B. Tanmay, N. Cain, N. Niu, Visual requirements analytics: a framework and case study, Requir. Eng. (2013) 1–23.