Supporting clinical guidelines using DL-temporal reasoning

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/261164169

Supporting clinical guidelines using DLtemporal reasoning Conference Paper · October 2013 DOI: 10.1109/CEWIT.2013.6713766

CITATIONS

READS

0

15

4 authors: Serge Autexier

Mohamed Bawadekji

Deutsches Forschungszentrum für Künstliche I…

Universität Bremen

119 PUBLICATIONS 773 CITATIONS

2 PUBLICATIONS 1 CITATION

SEE PROFILE

SEE PROFILE

Dieter Hutter

Regine Wolters

Deutsches Forschungszentrum für Künstliche I…

Universität Bremen

131 PUBLICATIONS 1,110 CITATIONS

48 PUBLICATIONS 273 CITATIONS

SEE PROFILE

SEE PROFILE

All content following this page was uploaded by Dieter Hutter on 14 January 2015. The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document and are linked to publications on ResearchGate, letting you access and read them immediately.

erschienen in: 10th International Conference and Expo on Emerging Technologies for a Smarter World (CEWIT), New York, 2013 IEEE Society, DOI 10.1109/CEWIT.2013.6713766

Supporting Clinical Guidelines Using DL-Temporal Reasoning Serge Autexier, Mohamed Bawadekji, Dieter Hutter and Regine Wolters German Research Center for Artificial Intelligence (DFKI) Bremen, Germany [email protected] Abstract—The algorithmic character of many clinical guidelines promoted their formal representation and use in decision support systems for giving advice in daily clinical routine. However, their typical formalization as workflow graphs restricts supervised care to a fixed set of treatment paths incapable to react on unforeseen events. Medication, for instance, constitutes a workflow on its own as an iterated process having restrictions on its duration, on the total amount of drugs to take, or the condition to stop it prematurely. Multi-morbidity gives rise to treatments following different guidelines but resulting in the need for alignment of the suggested care. Sometimes, a treatment has to deviate from the official guidelines because, for instance, the patient either refuses a designated intervention or gets an allergic reaction. Nonetheless, the remaining care should follow the guideline as close as possible. Rather than a fixed set of treatments paths encoded in a workflow graph, there is a need for a more flexible approach to react to the characteristics and needs of the individual cases. In this paper we present a new approach in which we consider care as an orchestration of various processes which altogether have to follow given clinical guidelines. The approach is based on the use of formal logics to specify the world as well as actions and processes operating in it. Workflows or other requested activities, which are encoded in clinical guidelines, are represented as temporal logical formulas. Activated as monitors they compare the actual development against the specified behavior and report once the specified behavior has been observed or the world has entered a state which violates the specification. In either case the system can actively react on such a new situation by starting new processes that deal with the occurred new situation. We illustrate our approach with the help of clinical guidelines to treat an acute coronary syndrome.1 Keywords: Clinical Guidelines; Ontologies; Formal Methods; Process Orchestration.

I.

INTRODUCTION

For many years various clinical practice guidelines (CPG, referred to as guidelines) have been developed to support and improve medical care for different types of diseases. CPGs are systematically developed statements to assist practitioners and patient decisions about appropriate health care for specific clinical circumstances [1]. So guidelines are intended to answer 1

This work is supported by the German Federal Ministry of Education and Research (BMBF) under grant 01IS11013B.

questions like “What is necessary, what is dispensable, what is obsolete?”. Therefore, guidelines are written down to evaluate „the extensive knowledge (scientific evidence and practice experience) to special care problems, to clear contradicting positions and to define the present action of the choice under consideration of use and damage and as relevant outcomes not only morbidity, but also patient's satisfaction and quality of life are to be considered“ [2]. Internationally and nationwide the high-class management in the health care is looked as a priority aim of a guideline [3, 4], so that guidelines are also called „control instruments in the health service“. Their principal task exists regarding to Helou [5] „in a reduction of undesirable quality deviations in the care and in an increase of the quality level on a higher, normative expectation corridor“. Although it has been recognized for long that following CPGs improves the success rate of clinical care, implementation of guideline recommendations in daily clinical routine remains an open question [6, 7]. Since most of the guidelines exist only in a text-format they have to be formalized so that they can be computer-interpretable. This process of formalization includes several steps, beginning with the definition of a complete set of criteria mentioned in the guideline, the definition of entry points, decision points and actions and ending with the definition of possible next steps and criteria for the evaluation concerning success or failure of a single action. This gave rise to a series of works to formalize clinical guidelines in a computable model (see for instance [8, 6, 9]). These approaches focus in particular on encoding the workflows underlying these guidelines in terms of corresponding languages like flow charts or petri nets. However, in many cases there is no single workflow for an entire medical care but there is a wealth of workflows covering only individual periods or particular aspects of the medical care. Therefore there is a need for a more flexible approach to react to the characteristics and needs of the individual cases considering patient individual factors like medications, comorbidities and complications during the treatment process. In the past we developed a methodology and a corresponding tool (SHIP-tool [10] ) to orchestrate individual processes by monitoring and reacting on these evolving processes in general. In this approach, we represent the world of these processes in a (decidable) Description Logic and update this representation with the help of messages sent by the processes or sensors sampling particular properties of the world. Temporal logic

978-1-4799-2546-9/13/$31.00 ©2013 IEEE

formulas are used to describe a particular evolution of the (virtual) world. Activated as monitors they compare the actual development against the specified behavior and report once the specified behavior has been observed or the world has entered a state which violates the specification. In either case the system can actively react on such a new situation by starting new processes that deal with the occurred new situation. Figure 1 illustrates this methodology.

noses defining the necessary treatment strategy according to the guidelines of the European Society of Cardiology [11, 12, 13]: • Stable coronary artery disease (stable CAD), where optimal medical therapy (OMT) or OMT + revascularization in form of percutaneous coronary intervention (PCI) or coronary artery bypass grafting (CABG) can be indicated depending on the type of lesion (1/2 vessel disease (1/2VD) vs. 3 or more vessel disease (3VD) and anatomic site of coronary vessel (e.g. proximal LAD)) • Non-ST-elevation myocardial infarction (NSTEMI), where the decision on invasive strategy and time of revascularisation is depending on risk stratification (e.g. GRACE-Score) • ST-elevation myocardial infarction (STEMI), where PCI or immediate fibrinolysis has be performed within 2 hours after beginning of chest pain.

Fig. 1: Methodology underlying the SHIP-Tool

In this paper we describe the instantiation of the SHIPapproach to support clinical guidelines. In particular, we exemplify our approach by the implementation of significant parts of a clinical guideline for the management of acute coronary syndromes. II.

GUIDING MYOCARDIAL REVASCULARISATION

The collective term „acute coronary syndrome“ (ACS) refers to situations where the blood supplied to the heart muscle is interrupted and therefore heart tissue is dying. Common signs of ACS are e.g. chest pain, discomfort, pain in arms, neck, back or stomach, shortness of breath and sweating.

Figure 3: Classification of ACS and treatment strategy

We use this classification and the associated conditions as the basis for the examples of hierarchical workflow management in the following sections. Treatment of ACS also includes the prescription and intake of drugs – not only during a certain procedure like PCI but also in a long-term period after an ACS has occurred. With every new prescription, drug-drug-interactions, possible contraindications and maximum dosage have been checked to avoid adverse drug reaction and to ensure patient safety. III.

Figure 2: The spectrum of ACS. ECG = electrocardiogram; NSTEMI = non-ST-elevation myocardial infarction; STEMI = STelevation myocardial infarction (NSTE-Guideline, page 3003)

By performing an electrocardiogram (ECG) and a blood test (troponin), ACS can be classified in one of the following diag-

THE LOGICAL FRAMEWORK

In general, the SHIP-Tool [14] provides an implementation, execution and simulation platform for workflow processes allowing the user to integrate and monitor existing devices, services or even entire systems. This is achieved by providing a logical formalism to describe situations of the real world and their general rules in an abstract way. Description logic (SROIQ) is used to represent the actual state of the real world (the ABox) as well as the modeling of the structure and relations given in that world (the TBox). Concepts are formed from the top and bottom concepts T and F, concept names and nominal concepts by union, intersection, complement, existential and universal quantification as well as number role restrictions.

For instance, the following specification defines the concept AcsSymptoms as a union of pairwise disjoint concepts, like for instance NonProximalLAD (which describes the segment where the lesion occurred). AcsSymptoms = SymptomsForRev SymptomsForOMT UnknownSymptom NonProximalLAD ProximalLAD

The following specification defines the concept CABGRequirementFulfilled as a subset of Patient showing the symptoms ProximalLAD and sy_3VD:

CABGRequirementFulfilled < Patient & ex HasAcsSymptoms.ProximalLAD & ex HasSymptoms.sy_3VD

The definition makes use of roles which are relations between two concepts where the first one indicates the domain of the relation while the other states its range: HasSymptoms : Patient * Symptoms HasAcsSymptoms : Patient * AcsSymptoms

Changes in the real world are communicated to the logical representation in terms of updates (ABox-updates) specifying both, a set of new facts and a set of past facts to be removed from the actual state. In our setting, updates concern only facts specified in the ABox rather than changes in the terminological semantics defined by the TBox. Given the relations between different facts in the TBox we can add (or remove, respectively) also facts that are logically implied by the new (or past, respectively) facts. Furthermore, explicitly specified indirect effect rules [15] allow us to include implicit or indirect consequences of existing facts into the ABox, solving the ramification problem. This update mechanism is also used to initiate changes in the real world by executing actions or processes operating in terms of ABox-updates. To monitor behaviors in the environment, the SHIP-tool uses a temporal logical formalization (LTL) to specify temporal processing of an actual state by upcoming ABox-updates. There are techniques to monitor such specifications over time and to detect when a specified behavior has been completely observed or has been violated. The SHIP-tool allows one to specify and activate these monitors that then evolve over the time using formula progression [16]. Each ABox-update represents a state transition in the LTL-world. Monitoring the behavior of the system, a specified property (1) is either satisfied after a finite number of steps (i.e. ABox-updates) and the monitor terminates successfully, (2) the system reached a state in which the property will evaluate to false independently of any continuation and in this case the monitor terminates with failure, or (3) the behavior observed so far allows for different continuations resulting either in a successful run or in a failure and in that case the monitor is still running. Thus, a monitor is successful if the behavior observed in the real world satisfies the specification and fails otherwise. Actions represent parameterized atomic interactions (ABox-updates) of a service with its environment. Actions are described by a finite set pre of ABox-assertions, the preconditions of the action, and a set effects of ABox-assertions, the

effects of executing the action. Effects can be unconditional or conditional. The following specification defines the start of a PCI therapy. As a precondition, the patient must be eligible for this treatment ( (p, pCI):HasTreatment ). As effects, we “initialize” critical parameters of the treatment, like for instance, the type of PCI treatment ( PCIUnknownTherapy ) and potentially upcoming contraindication against Aspirin (ContraindicationForAspirinUnknown), which will be given as an initial medication. action StartPCITherapy(p) = { pre = p:Patient, pCI:PCI , (p, pCI):HasTreatment effect = t:UnknownTime, (p, t):WaitSince, sy:UnknownAcsSymptom, (p, sy):HasSymptoms , th:PCIUnknownTherapy, (p, th):HasPCITherapy, no:ContraindicationForAspirinUnknown, (p,no):HasContraindication }

Processes are specified based on these elementary actions to react on successful or failed developments of the world (monitors). This enables us, for instance, to monitor the behavior of devices or users and to react to any non-expected behavior. At the other end of the spectrum it allows us to define complex activities and workflows in terms of processes acting on existing devices and services and communicating with the user. For example, the following process AskEKGState initiates the individual treatment plan depending on the result of the ECG recording (cf. Figure 3). process Treatment { AskEKGState(p); switch case d1:StableCAD and (p,d1):HasDiagnosis => (StableCADTreatment(p)) case d:STEMI and (p,d):HasDiagnosis => STEMITreatment(p) case d:NSTEMI and (p,d):HasDiagnosis => NSTEMITreatment(p) }

The interweavement of process descriptions with monitoring as well as the interleaved execution of parallel processes, both based on the same world representation, provides a powerful formalism to implement processes to assist and monitor activities in the environment in interaction with users and based on existing services and devices. IV.

FORMALIZATION OF GUIDELINES

In order to support the clinician by making a medical decision regarding a given guideline, the system has to support different issues. On the one hand it has to inform the physician about the guideline recommendations at the time at which a medical decision has to be made with respect to a particular medical state. On the other hand the system should monitor vital medical conditions mentioned in a guideline before the execution of a specific medical procedure starts. Therefore, the required medical knowledge must be translated form a textformat to a logical representation in the first place. This translation step covers the identification of all medical facts, e.g. diagnoses, types of symptoms, etc. including their relation-

ships in the guideline and their encoding by means of Description Logic (DL), which forms the terminological part (TBox) of the ontology. The TBox as a formalization of the static part of a guideline serves as an axiomatization for reasoning about the actual medical state of an arbitrary patient, which is stored as DL-specification in the ABox. The specification of a patient comprises various types of data from different sources, for example, his master file data, his (actual) condition, his symptoms, and his laboratory values building a medical history of a patient and evolves over the time. New symptoms or new laboratory values are introduced via ABox-updates either manually or by external systems (e.g. a hospital information system). The guideline recommendations, which in general specify different treatment strategies, are implemented by means of dynamic processes. Each process describes one fraction of a treatment strategy, which allows us to model various workflows with respect to a medical state of a patient. The execution of a process is initiated either by an update of the actual state of a patient or by the result of performing another process. Furthermore, a process is capable of interacting with the user or with other medical information systems by carrying out specific actions in the ABox (in particular, the interaction is provided in a higher abstraction layer e.g. via graphical user interface). Before starting an execution of a process, critical medical conditions referring, for instance, to the patient’s history can be checked with the help of LTL-monitors. They succeed if the medical care follows the given guideline and fail in situations in which the medical care violates the guideline. Each monitor covers typically only a fraction of the entire medical care prescribed in the clinical guideline. In this context, we distinguish mainly between three kinds of monitors: Atomic monitors are typically used to observe a finite set of medical conditions mentioned in a guideline before taking a particular immediate action to a patient. Therefore, atomic monitors are started before performing the related processes in the system. The successful termination of an atomic monitor starts the new process that, for example, initializes particular medical activities and starts the next monitors supervising the next phase of the medical care. An advantage of the atomic monitors is the flexibility to easily incorporate additional medical constraints that belong to other relevant guidelines without the need to modify the entire medical workflow implemented in the system. Hence we encode such constraints in an atomic monitor and finally binding it to the associated process. For instance, suppose the system has to guide a physician when performing a procedure like angiography or percutaneous coronary intervention (PCI) on a patient with acute coronary syndrome (ACS). We enforce the system to adhere to additional guideline recommendations concerning the treatment of diabetes patients with Metformin. The guideline of ACS states that Metformin should be interrupted before executing angiography or PCI because the risk of side effects, like lactic acidosis, may increase when receiving contrast media that are required for performing the aforementioned procedure. In order to encode this particular guideline recommendation in an atomic monitor we define the following ABox-assertions. Let p:Patient, Φ:Diabetes, Ω:Metformin and Ψ:Discontinue be

concept assertions, declaring that p, Φ, Ω and Ψ are individuals of concepts Patient, Diabetes, Metformin and DisContinue respectively, and (Ω, Ψ):HasIntake be a role assertion stating that the relation HasIntake holds between the individuals Ω and Ψ. The other role assertions mentioned in this paper are fairly self-explanatory. Finally, we use in the scope of this paper only two terms of LTL, namely U states for until while F states for eventually: monitor MonitorDiabetes(p) = F(ex Φ:Diabetes and (p, Φ):HasDisease and Ω: Metformin and (p, Ω):HasTherapy and Ψ:DisContinue and (Ω, Ψ):HasIntake)

The role assertion HasIntake denotes whether a prescribed treatment Ω is still intaken or interrupted. While the former statement is illustrated in the monitor MonitorDiabetes, the latter can be expressed when we update the ABox in such a way that the individual Ψ becomes a member of concept Continue where both concepts Continue and DisContinue are defined as a pairwise disjoint of the super concept TreatmentUse as follows: TreatmentUse = Continue DisContinue

This update would retain the DL-ontology consistent because the range of the relation HasIntake is belonging to the complex concept TreatmentUse. Then, the monitor MonitorDiabetes evaluates to true and enables the execution of the associated process. On the contrary, the failure of the monitor would indicate that a critical medical constraint is violated with respect to the applied guideline. This type of monitor is suitable when observing an atomic process. However, when the implementation of a workflow comprises several processes which are running either sequential or in parallel then we need (global) monitors that are capable of observing the entire workflow including the interaction between simultaneous processes. Hierarchical monitors comprise a finite set of atomic monitors that are performed in sequence depending on the evaluation of a previous one. We call the first monitor invoked in the hierarchical monitors a root monitor. The hierarchical monitors are typically used to supervise either an entire treatment following the guideline beginning with its entry points, the evaluation of lab values, the prescription of an appropriate treatment and ending with the discharge from hospital or a fraction of a workflow consisting of multiple steps. After a treatment for a patient is started and her/his initial state is presented in the SHIP-tool as ABox assertions, a root monitor is automatically invoked for that patient. This root monitor observes both, the initial state of a patient and the various medical conditions indicating the beginning of different treatment strategies mentioned in a guideline. Each treatment strategy occurring as a DL-formula in the root monitor is combined with an associated hierarchical monitor, which is only invoked when the related medical conditions can be deduced from the ABox. To illustrate the usage of these hierarchical monitors, assume that we have to supervise the treatment of a patient who is suffering from ACS. The guideline recommends alternative procedures and therapies depending on the diagnosis, which results of the echocardiography (ECG) and the type of past and

actual symptoms. We extend the specification of the previous example by defining possible symptoms and diagnoses. Diagnosis = {diagUnknown, diag_1, diag_2,…,diag_n} and Symptoms = {symp_1,symp_2, …,symp_n} The hierarchical root monitor is formalized as follows: monitor RootMonitor (p) = ex diagUnknown:Diagnosis and (p, diagUnknown):HasDiagnosis U (ex ECG:echocardiography (p, ECG)HasPerformed and ( (ex diag_1:Diagnosis and (p, diag_1):HasDiagnosis and MonitorDiag_1(p)) or … or (ex diag_n:Diagnosis and (p, diag_n):HasDiagnosis and MonitorDiag_n(p)) )

This monitor specifies the temporal behavior of the system in which a patient p has an unknown diagnosis (diagUnkown) until an echocardiography is performed and one of the diagnoses diag_1, diag_2,…,diag_n is established. Depending on the established diagnosis diag_i the corresponding monitor MonitorDiag_i is invoked to supervise the further treatment. Hence, each MonitorDiag_i describes the requirements of the guideline concerning the specific treatment of the patient given the diagnosis diag_i.

Suppose we want to monitor the intake of drugs for a patient who suffers from ACS. A critical issue of prescribing a specific drug is the occurrence of any contraindication in the further course of the treatment. It requires the immediate notification of the physician. Another issue is that each time the drug has to be given to the patient the nursing staff has to be notified until either a contraindication occurs or the medication stops with intent. The constraints of our example decompose mainly into two conditions; (1) the prescription of drugs and their possible contraindications, and (2) the duration of drug intake. Each constraint is modeled as a separated process and supervised with an associated monitor. Once the physician prescribes a specific drug to a patient and updates his medical state in the system, the two aforementioned monitors will be immediately started. The first monitor MonitorDrugTimer waits for the time interval between two doses2 where the role assertion WaitSince is a relation between the individuals p and t. If the monitor evaluates to true it terminates successfully and starts the associated process supervising the correct intake of the drug; i.e. it notifies the nurse each time the drug has to be given to the patient, accumulates the overall dose, and informs the nurse when the end of the duration or the maximal dose of the medication have been reached.

Suppose a physician updates the medical state of a patient according to ECG recording in the system, the monitor RootMonitor will evaluate to true if one of the alternatives holds, indicating that the diagnosis decision is compliant with the guideline of ACS and the next step of the treatment progress is observed by the system. This check results in invoking the monitor of the corresponding diagnosis. In our example, once the diag1 is confirmed in the system a monitor MonitorDiag_1 is invoked. This monitor has typically the following form:

monitor MonitorDrugTimer(p) = F(ex t:DrugTimeInterval and (p,t):WaitSince )

monitor MonitorDiag_i (p) = F((symp_1:Symptoms and (p,symp_1 ):HasSymptom and MonitorProcedure_1) or … or (symp_n:Symptoms and (p,symp_n ):HasSymptom and MonitorProcedure_n) )

The formula denotes a development that eventually a patient p has a contraindication cont for a drug d she/he has taken. As usual, the monitor terminates successful if a contraindication occurs in the course of a treatment. This monitor is used to enable the start of an associated process that immediately informs the health personnel and stops the first monitor supervising the intake.

The monitor demands that some symptom symp_i occurs eventually in the future and that the following treatment satisfies the corresponding restrictions of MonitorProcedure_i. In general, we allow also for multiple symptoms to invoke a monitor procedure. The occurrences of individual symptoms trigger the kind of procedure that is prescribed in the course of a treatment; i.e. symptoms related to a specific procedure are combined with an associated monitor of the procedure. For example, the invocation of the monitor MonitorProcedure_1 depends on the update of the medical state of a patient to include the occurrence of the symptom symp_1. If no symptoms are observed at all, the monitor MonitorDiag_i is stuttering, i.e. it waits until one of the disjunction properties is satisfied. In this way, we observe the behavior of the entire treatment process step by step in compliance with the guideline of ACS. Concurrent monitors are composed of atomic monitors like the hierarchical monitors. However, concurrent monitors run in parallel allowing us to encode heterogeneous constraints of medical care in independent monitors. Thus, they are mainly applied in processes which are performed simultaneously.

The second monitor MonitorDrugContraInd waits for the occurrence of new symptoms that are known as contraindications related to a specific drug. The temporal logical formula of the monitored medical condition is as follows: monitor MonitorDrugContraInd(p) = F( ex d:Durg .ex cont:ControInd. and (p,d)HasDrug and (p,cont):HasContraindication and (cont,d ):ContraIndicated )

V.

IMPLEMENTATION

The presented support for clinical guidelines has been implemented in the SHIP-tool with respect to the treatment of ACS. While in the first place this constitutes a formal specification of an excerpt of the corresponding ACS guidelines, further additions have been made to the SHIP-tool itself to ease the interaction with users and medical (information) systems. The system provides a graphical user interface tailored to the particular needs of this application. In particular, it allows for prescribing a specific medication or adding new syndromes to the actual medical state of a patient without the need of using the underlying description logic explicitly. To support the interaction with medical information systems we developed an application in Scala that answers specific queries about the 2

To realize real time constraints we use an external clock to send timeupdates to the DL-specification.

patients’ histories or their actual states. Queries can also be used to initialize different activities, e.g. to inform the user about a specific guideline recommendation or to notify medical (information) systems about changes of patient data. Running monitors describe the temporal behavior that the system has to show in order to cause particular reactions, i.e. the continuation or start of the execution of processes. Thus, a monitor describes a period of time in which its corresponding process waits for some specific development, which is caused by updates coming from either the outside (i.e. external systems or user) or concurrent processes. In case these updates correspond to actions that a user has to take, a monitor constitutes a description of the user’s further actions; i.e. we can synthesize necessary actions of the user from inspecting the running monitors and then make corresponding suggestions to the medical staff in order to fulfill the guideline recommendations. At the moment we are implementing such a planner in the SHIP-tool.

[1]

[2]

[3]

[4]

[5] [6]

[7]

[8]

VI.

CONCLUSION

We presented an instantiation of the SHIP-tool to support the implementation of clinical guidelines in practice. Following the principles of the SHIP-approach we model our medical world in Description Logics and use temporal logic to represent the recommended procedures contained in the guideline as monitors. Since the states and guidelines are represented in formal but still decidable logics, we are able to use formal logical reasoning to deduce also facts of an actual state, which are not explicitly given and thus provide some kind of information system. Rather than specifying a fixed workflow graph, we decompose a guideline into separate periods of treatment, the behavior of which are described as monitors. This allows for a hierarchical modeling of the medical workflow, which is flexible when adding further constraints to the care caused, for instance, by multi-morbidity or emerging contraindications. While we only implemented the guidelines concerning the treatment of ACS, the approach is flexible enough to deal also with other clinical guidelines. In principle, all guidelines contain evidence-based recommendations and provide more or less algorithmic information. While graph based formalizations require this information to locate activities and processing of symptoms, our approach of monitors supervising medical activities and events is still applicable when no workflow is explicitly available. Finally, the use of a logic representation enables the formal verification of required properties of an admissible treatment following the specified guideline. For example, it would be interesting to verify that a patient will never be prescribed a drug that has already caused some contraindication in the previous treatment.

View publication stats

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

Institute of Medicine (IOM), Committee on Clinical Practice Guideline, “Guideline for clinical practice - from development to use,” National Academy Press, 1992, field, M.J., Lohr K.N. G. Ollenschläger et al., Lehrbuch der Evidenzbasierten Medizin in Klinik und Praxis. Deutscher Ärzteverlag, 2000, ch. Kritische Bewertung von Leitlinien. Council of Europe, “Developing a methodology for drawing up guidelines on best medical practices (recommendation (2001)13 and explanatory memorandum),” 2001. World Health Organization (WHO), “Leitlinien in der gesundheitlichen Versorgung,” WHO Regional Office for Europe, 1997, Bericht von der Tagung der WHO, Schloß Velen, Westfalen, 26. bis 28.01.1997. A. Helou, Das Public Health Buch. Gesundheit und Gesundheitswesen, 2. Auflage. Verlag Urban & Fischer, 2002, ch. Medizinische Leitlinien. J. Grimshaw et al., “Effectiveness and efficiency of guideline dissemination and implementation strategies,” International Journal of Technology Assessment in Health Care, vol. 21, no. 1, 2005. A. Oxman, “An overview on strategies to promote implementation of evidence-based healthcare,” in Evidence-based practice ind primary care 2nd edition, C. Silagy and A. Haines, Eds. London: BMJ books, 2001. P. De Clercq et al., “Approaches for creating computer-interpretable guidelines that facilitate decision support,” Artificial Intelligence in Medicine, vol. 31, no. 1, pp. 1–27, 2004. P. Gross, S. Greenfield et al., “Optimal methods for guideline implementation: Conclusions from Leeds castle meeting,” Medical Care, vol. 39, no. 8, August 2001, suppl. II. S. Autexier, D. Hutter, and C. Stahl, “An implementation, execution and simulation platform for processes in heterogeneous smart environments,” in Proceedings of the Fourth International Joint Conference on Ambient Intelligence (Aml-2013), Dublin, Ireland, J. C. Augusto and R. Wichert, Eds. Springer-Verlag, LNCS, 2013. The Task Force on the Management of ST-Segment Elevation Acute Myocardial Infarction of the European Society of Cardiology (ESC), “Esc guidelines for the management of acute myocardial infarction in patients presenting with st-segment elevation,” European Heart Journal, vol. 33, p. 2569–2619, 2012, doi:10.1093/eurheartj/ehs215. The Task Force for the Management of Acute Coronary Syndromes (ACS) in patients presenting without persistent ST-segment elevation of the European Society of Cardiology (ESC), “Esc guidelines for the management of acute coronary syndromes in patients presenting without persistent st-segment elevation,” European Heart Journal, vol. 32, p. 2999– 3054, 2011, doi:10.1093/eurheartj/ehr236. The Task Force on Myocardial Revascularization of the European Society of Cardiology (ESC) and the European Association for CardioThoracic Surgery (EACTS), “Guidelines on myocardial revascularization,” European Heart Journal, vol. 31, p. 2501–2555, 2010, doi:10.1093/eurheartj/ehq277. S. Autexier and D. Hutter, “Constructive DL update and reasoning for modeling and executing the orchestration of heterogenous processes,” in Proceedings of the Internation Workshop on Description Logics, Ulm, Germany, 2013. F. Baader, M. Lippmann, and H. Liu, “Using causal relationships to deal with the ramification problem in action formalisms based on description logics,” in Logic for Programming, Artificial Intelligence, and Reasoning - 17th International Conference, LPAR-17, Yogyakarta, Indonesia, October 10-15, 2010. Proceedings, ser. LNCS, C. G. Fermüller and A. Voronkov, Eds., vol. 6397. Springer, 2010, pp. 82–96. A. K. Bauer and Y. Falcone, “Decentralised LTL monitoring,” in FM 2012: Formal Methods - 18th International Symposium, Paris, France, August 27-31, 2012. Proceedings, ser. LNCS, D. Giannakopoulou and D. Méry, Eds., vol. 7436. Springer, 2012, pp. 85–100.