Daniyal, A., Abidi, S.R., Abidi, S.S.R.: Computerizing Clinical Pathways: Ontology-Based. Modeling and Execution. Stud. Health Technol. Inform., 150, 643--647 ...
Exploiting OWL Reasoning Services to Execute Ontologically-modeled Clinical Practice Guidelines Borna Jafarpour, Samina Raza Abidi, Syed Sibte Raza Abidi NICHE Research Group, Computer Science Deapartment, Dalhousie University. {borna, sraza, abidi}@cs.dal.ca
Abstract. Ontology-based modeling of Clinical Practice Guidelines (CPG) is a well-established approach to computerize CPG for execution in clinical decision support systems. Many CPG computerization approaches use the Web Ontology Language (OWL) to represent the CPG’s knowledge, but they do not exploit its reasoning services to execute the CPG. In this paper, we present our CPG execution approach that leverages OWL reasoning services to execute CPG. In this way, both CPG knowledge representation and execution semantics are maintained within the same formalism. We have developed three different OWL-based CPG execution engines using OWL-DL, OWL 2 and SWRL. We evaluate the efficacy of our execution engines by executing an existing OWL based CPG. We also present a comparison of the execution capabilities of our three CPG execution engines. Keywords: Clinical Guidelines, Semantic Web, Execution Engine, OWL
1 Introduction To operationalize Clinical Practice Guidelines (CPG) in clinical care settings there exist a variety of methods to computerize the paper-based CPG in terms of computer interpretable format and then to execute the computerized CPG through clinical decision support systems. A few approaches to mention are PROforma, GLIF, and EON. Semantic Web technologies offer (a) knowledge representation languages for authoring ontologies that encapsulate the knowledge regarding a specific topic and (b) reasoning services that can be used to perform reasoning on the modeled knowledge. Although OWL, as a knowledge modeling language, is extensively used to represent the CPG knowledge [3], [5], [6], the reasoning potential of OWL is not properly exploited to execute the OWL-based CPG models. There are a few semantic web based execution engine that use Semantic Web Rule Language (SWRL) to execute CPG that are modeled using OWL [1], [2]. However, these execution engines are closely tied to a specific CPG and are not generic enough to be applied to other guidelines. In this paper, we explore the use of OWL reasoning services to develop generic execution engines that can execute CPG modeled in OWL. We present three generic OWL-based CPG execution engines based on OWL-DL, OWL 2 and OWL-DL + SWRL. We present a comparison of the executional capabilities of our CPG execution engines. We also compare their execution performance by executing a CPG modeled in an OWL-based CPG ontology [6].
2 OWL-Based Execution of Clinical Practice Guidelines As per our approach, to execute an ontologically modeled CPG through OWL-based reasoning services, it is necessary to preprocess the OWL-based CPG in order to supplement it with additional OWL constructs to further enhance the executional semantics to the OWL-based CPG. This extension of the original OWL-based CPG to an extended OWL-based CPG is required to (a) address the Open-World (OWA) and Non-unique Naming Assumptions (NNA) adopted by OWL reasoners, (b) handle preconditions, (c) provide a richer data-type expressivity for performing mathematical and logical operations on patient data, (d) handle loops and (e) handle state transitions. The nature of the extensions to the original OWL-based CPG is determined by the requirements of the target CPG execution engine. Our CPG execution engine is composed of a program that uses an API to load, save and manipulate the CPG ontology and an OWL reasoner. Our execution engine program performs queries to find Active tasks and inserts triples in the ontology to record (a) the completion of tasks, (b) any output/recommendation/decision generated by the task. All the execution activities—such as finding the next tasks, checking preconditions, state transitions—are undertaken by the OWL reasoner within the CPG ontology. We use Pellet as the reasoner and Jena as the API to load, manipulate and save OWL files in this project. TURTLE syntax is used to demonstrate the OWL constructs used in this paper.
2.1 OWL-DL based CPG Execution Engine Our first CPG execution engine uses OWL-DL which is the most expressive yet decidable species of OWL. However, this CPG execution engine does not support the handling of loops and mathematical functions. We explain below how we extended the original OWL-based CPG ontology to address the below issues so that the OWL reasoners can effectively execute the CPG: State Transitions. Our execution is governed by a state transition model which consists of five different states: Inactive, Active, Completed, Discarded, WaitingForSubsteps (Wfss). To handle the desired state transitions, specific OWL triples are added to the ontology. For instance, the state transition rule “A composite task is completed if all of its sub tasks (denoted by hasTask property) are completed” is implemented by assertion of the following triple set: [a owl:Restriction; owl:onProperty :hasTask; owl:allValuesFrom :Completed]rdfs:subClassOf :Completed.
Preconditions. Handling precondition satisfaction criteria of “all” or “any” can be easily implemented using owl:allValuesFrom and owl:someValuesFrom, respectively. However, handling “any k” rules needs Qualified Cardinality Restriction (QCR) expressivity which is not supported in OWL. Our workaround is to create n!/(n-k)!k! intermediate nodes which represent different combination of k out of n preconditions. A combination point is satisfied when all of its assigned preconditions are satisfied (owl:allValuesFrom) and a task has a satisfied criterion when at least one of its
combination points is satisfied (owl:someValuesFrom). This method may create a large number of intermediate nodes which can slow down the reasoning process. Open-World Assumption and +on-unique +aming Assumption. The OWA states that from the absence of a statement, a reasoner cannot infer that it is true. NNA states that it is possible that two names refer to the same entity. For instance, if task t1 has two subtasks t11 and t12 which are Completed, we expect the OWL reasoner to infer that t1 is Completed as well. However, because of the abovementioned assumption, this is will not happen and we need to assert that t1 has exactly two subtasks (because of OWA) and they are not referring to the same task with different names (because of NNA) to draw the desired conclusion. :t1 a [a owl:Restriction owl:onProperty :hasTask owl:cardinality 2]”. :t11 owl:differentFrom :t12
2.2 OWL 2 based CPG Execution Engine OWL 2 is the new version of OWL, and its advantage for CPG execution purposes is that it (a) supports QCR that allow to efficiently handle “any k out of n” precondition satisfaction criteria, and (b) offers datatype expressivity to handle user defined ranges when comparing numeric values of datatype properties. The OWL 2 CPG execution engine builds on the OWL-DL execution algorithm and state transition strategy, with additional methods to (a) handle preconditions more effectively and (b) perform numeric comparisons to evaluate preconditions. Preconditions are handled more effectively because there is no longer the need to create n!/(n-k)!k! intermediate nodes. We illustrate the OWL 2 based improvements to address the following issues: Preconditions. To handle satisfaction criterion of “any k out of n”, we iterate over the tasks and create three OWL classes for each k that we encounter during processing: (i) Task_Preconditions_Required_k: shows the minimum number of preconditions that should be satisfied in order to say that the task’s criterion is satisfied. The task with the criterion “any k” is set as an instance of this class (during preprocessing) (ii) Task_Preconditions_Satisfied_k whose members are the tasks that have at least k preconditions satisfied at that point in time (During execution). Note that this does not signify the exact number of preconditions that the task needs to be satisfied in order for it to be deemed as being complete. It uses the QCR capability of OWL 2 in the following way: :Task_Preconditions_Satisfied_k a [a owl:Restriction; owl:onProperty :hasPrecondition; owl:onClass :SatisfiedPrecondition; owl:minQualifiedCardinality k].
(iii) An intersection of these two classes which represents the tasks that are waiting for k preconditions and have at least k satisfied precondition and should be regarded as tasks with satisfied precondition criterion. Datatype Expressivity. To handle a precondition (p1) such as “older than 18” we need to compare the age of the patient against a data range. Our solution is to create three classes for each comparison: (a) Precondition_Should_GT_18 whose instances are assigned during preprocessing, (b) Precondition_Has_GT_18 whose instances are
entities with a value larger than 18 for their hasAge property and are assigned via the data ranges capability of OWL 2 during execution and (c) intersection of the above mentioned classes which is a subclass of TaskSatisfiedPrecondition.
2.3 OWL-DL + SWRL based Execution Engine. OWL 2 has the following limitations for the purposes of CPG execution: (a) no ability to handle loops because of the lack of a mathematical function for incrementing a counter; (b) limited data type expressivity. For instance, it cannot compare two property values that are entered during execution (e.g. is first blood work measurement showing a value greater than that of the second one?). To address these shortcomings, we have developed an execution engine that leverages SWRL Comparison and Math built-ins to enhance the functionalities of the OWL-DL based execution engine. These SWRL rules are added to the OWL-DL based execution engine during preprocessing. To account for decidability issues that may arise as a result of using SWRL we have developed a DL-Safe [4] solution for handling loops. Data type expressivity and loops are handled in the following fashion: Datatype Expressivity. OWL-DL and OWL 2 are not capable of comparing two property values from two different objects. This can be necessary for comparisons of two values that are entered during execution of the guideline. We used SWRL rules and its built-ins for this mean. For instance, the built in swrlb:greaterThan is used to handle all "GreaterThan" comparison criteria in the CPG. hasNumericValue(?v1,nv1) ^ hasNumericValue(?v2, ?nv2) ^ hasComparisonCriteria(?comparison, greaterThan) ^ swrlb:greaterThan(?nv1, ?nv2) → SatisfiedPrecondition(?p)
Loops. Using a single value and a single rule to keep the record of iteration is not DL-Safe because the OWL reasoner uses the new value to fire the rule infinitely. This causes undecidability in the ontology. We use SWRL built-in swrlb:add to manage a counter for for loops and impement a DL-Safe solution by defining two datatype properties: hasItr.um that holds the iteration number and is set 0 at the beginning and hasItr.umCopy that holds a copy of the hasItr.um’s value. The loop handling rules operate as follows: (i) When the first task of the loops is Completed, value of hasItr.um is copied to hasItr.umCopy, and (ii) When the last task of the loop is Completed, 1 is added to hasItr.umCopy and its value is copied to hasItr.um. Loop is terminated when we reach the maximum number of iterations.
3 Discussion and Comparison We tested and measured performance of our execution engines by execution of the CPG for Congestive Heart Failure and Atrial Fibrillation explained in [6] and through a range of clinical scenarios that were developed by medical experts. Same experts validated the correctness of the generated recommendations based on the CPG under execution. We also developed a graph traversal based execution engine [5] which is
included in the speed and executional capabilities comparison of Table 1. Basic Execution Tasks are what OWL-DL offers. Table1.Capabilities (± : somewhat supported, +: supported, -: not supported) and performance (1 is the fastest) of the CPG execution approaches.
Basic Execution Tasks QCR DataTypeExpressivity Rules Reasoning Loops Speed
Graph Traversal OWL-DL OWL 2 SWRL + + + + + + + + + ± + + + + + + ± 1 2 3 4
Table 1shows that from a speed perspective, graph traversal based approaches seem to be superior to semantic web approaches. However, it should be noted that the graph traversal based execution approaches do not directly support reasoning (based on intermediate results and inputs), handling of a range of relations (such as functional, transitive, causal, etc) and exceptions—given the complexity of CPG and the criticality of the knowledge processing expected in clinical setting these functionalities are important to have in a CPG execution engine. From an implementation perspective, graph based approach create a tight coupling between the CPG ontology, the execution engine, and technologies that are used in it which makes the execution engine tied to specific technologies. On the contrary, semantic web approaches allow for the execution semantics to be represented separately, such that the reasoner can establish the necessary linkages between the domain knowledge and the execution semantics, which results in flexibility to choose technologies to execute the guidelines. Hence, we argue that OWL based approaches for CPG execution provide a comprehensive and sound execution environment.
References 1. Arguello Casteleiro, M., Des, J., Prieto, M. J. et al.: Executing Medical Guidelines on the Web: Towards Next Generation Healthcare. Knowl-Based Syst., 22, 545--551 (2009) 2. Casteleiro, M. A., Des Diz, J. J.: Clinical Practice Guidelines: A Case Study of Combining OWL-S, OWL, and SWRL. Knowl-Based Syst., 21, 247--255 (2008) 3. Daniyal, A., Abidi, S.R., Abidi, S.S.R.: Computerizing Clinical Pathways: Ontology-Based Modeling and Execution. Stud. Health Technol. Inform., 150, 643--647 (2009) 4. Motik, B., Sattler, U., Studer, R.: Query Answering for OWL-DL with Rules. Web Semant., 3, 41--60 (2005) 5. Din, M. A., Abidi, S. S. R., Jafarpour, B.: Ontology Based Modeling and Execution of Nursing Care Plans and Practice Guidelines. In: 13th World Congress on Medical Informatics, IOS Press, Cape Town (2010) 6. Abidi, S.: Ontology Based Knowledge Modeling to Provide Decision Support for Comorbid Diseases. In: 2nd International Workshop on Knowledge Representation for Health-Care (KR4HC), Springer Verlag, Lisbon, (2010)