908
MEDINFO 2013 C.U. Lehmann et al. (Eds.) © 2013 IMIA and IOS Press. This article is published online with Open Access by IOS Press and distributed under the terms of the Creative Commons Attribution Non-Commercial License. doi:10.3233/978-1-61499-289-9-908
Modeling Decision Support Rule Interactions in a Clinical Setting Margarita Sordo,ab Beatriz H. Rocha,ab Alfredo A. Morales,a Saverio M. Maviglia,abElisa Dell’Oglio,a Amanda Fairbanks,a Teal Aroy,a David Dubois,a Sharon Bouyer-Ferullo,a Roberto A. Rochaab a
Clinical Informatics Research and Development, Partners Healthcare, Boston, MA, USA b Brigham and Women’s Hospital, Harvard Medical School, Boston, MA, USA
Abstract Traditionally, rule interactions are handled at implementation time through rule task properties that control the order in which rules are executed. By doing so, knowledge about the behavior and interactions of decision rules is not captured at modeling time. We argue that this is important knowledge that should be integrated in the modeling phase. In this project, we build upon current work on a conceptual schema to represent clinical knowledge for decision support in the form of if…then rules. This schema currently captures provenance of the clinical content, context where such content is actionable (i.e. constraints) and the logic of the rule itself. For this project, we borrowed concepts from both the Semantic Web (i.e., Ontologies) and Complex Adaptive Systems (CAS), to explore a conceptual approach for modeling rule interactions in an enterprise-wide clinical setting. We expect that a more comprehensive modeling will facilitate knowledge authoring, editing and update; foster consistency in rules implementation and maintenance; and develop authoritative knowledge repositories to promote quality, safety and efficacy of healthcare. Keywords: Medical Informatics, Knowledge Representation, Semantic Web, Ontologies, Complex Adaptive Agents.
Introduction Orchestrating rule execution in traditional rule-based systems is mainly handled in a centralized manner: basically relying on rule properties to control the order in which rules are executed. This is achieved mostly through execution parameters and conditions, rule priorities, and execution flow. Although this approach is effective and widely used, it basically relegates the encoding of rule interactions to the implementation stage in the software development cycle. It is as if decision rules were static entities only allowed to react when conditions in their antecedents are met, but without any regard or awareness to what other rules may react to, and to whether this reaction – or behavior – from other rule(s) may affect them. This approach may create inconsistencies among rules as single entities versus rules as collective body. When placed together, single rules are no longer isolated; they become part of an aggregation where the dynamics of the whole is modeled by the aggregated dynamics of individuals. We do believe that decision rules are richer than just isolated entities pre-placed as decision points along an execution flow. Furthermore, if decision rules are in fact capable of exhibiting a more dynamic behavior when aggregated, then such behavior should be explicitly integrated and represented as part of a more comprehensive
modeling process. In order to achieve this, we propose an approach to modeling rule interactions based on Semantic Web technologies, specifically on Ontologies and some basic concepts borrowed from Complex Adaptive Systems. The next sections present a brief description of these topics. Semantic Web In the words of Tim Berners-Lee [1], “the Semantic Web is an extension of the current Web in which information is given well-defined meaning, better enabling computers and people to work in cooperation”. In other words, a combination of formal, explicit meaning or semantics of data and schema definitions allows the integration and interpretation of data from disparate sources, thus enabling more powerful information processing. Different technologies are stacked up in a layered approach that provides functionality for exchanging and processing data. From bottom up (see Figure 1), the Semantic Web architecture [2] provides the means for encoding text (Unicode), identifying sources (URIs), and structuring and exchanging information (XML). Moving up, the Resource Description Framework (RDF) [3] uses three fundamental concepts: entities, properties, and statements. Statements are represented as triplets of the form (subject, predicate, object), and they are used to describe facts about resources; i.e., entities and their properties and relationships among entities. As an extension of RDF, the Resource Description Framework Schema (RDFS) [4] provides the means for modeling classes, properties, hierarchy of classes and properties, and simple domain and range restrictions. SPARQL Protocol and RDF Query Language (SPARQL) [5] is a query language used to query RDF data (triplets). It provides the means for extracting information from Semantic web resources. One level up, Web Ontology Language (OWL) [6] is the standard for knowledge representation and inferencing for the Semantic Web. It is characterized formal semantics and RDF/XML-based serializations knowledge on the Web. Finally, Rule Interchange Format (RIF) [7] and Semantic Web Rule Language (SWRL) [8] provide a framework for describing relations in terms of rules. RIF also defines a set of languages for rule interchange. Ontologies Ontologies have been proposed as the backbone of the Semantic Web and, more generally, for management of formalized knowledge [9]. Ontologies refer to a conceptualized and agreed upon collection of entities in some domain of interest. Such entities are unambiguously described by means of a shared vocabulary, resulting in an enriched content with machine-processable semantics that can be communicated and processed by computers. In other words, Ontologies describe objects, concepts, and their relationships in a particular area of
M. Sordo et al. / Modeling Decision Support Rule Interactions in a Clinical Setting
interest by means of a particular modeling language and terminology [10].
Figure 1 - Semantic Web Architecture From a modeling perspective, Ontologies are of particular interest for this project as they support clinical content formalization, and align with ongoing efforts for extraction, modeling, and curation of expert knowledge currently embedded in variety systems across Partners Healthcare [11]-[14]. A large amount of expert knowledge is in the form of decision rules. These rules provide decision support to aid clinicians improve the outcome of treatments by e.g., prompting clinical alerts about the patient current condition; diagnosis support by highlighting key symptoms and findings; medication ordering by suggesting appropriate medications and dosages based on the medical condition of a patient; and cost reduction by suggesting effective alternative treatments and medications. Complex Adaptive Systems (CAS) Simplistically defined, CAS are composed of simple agents. Each agent has a series stimulus-response rules that basically describe its behavior when placed in an environment [15]. Holland defines seven basics (four properties and three mechanisms) common to all CAS [16]. Given that we are trying to model simple interactions among rules and not complex adaptive behavior, we have selected four basics that we believe best contribute to the desired interaction, namely: a) Aggregation: This property has two senses. The first refers to the concept of grouping or aggregating things into categories, treating them as equivalent. The second sense relates to what CAS can do and not to how we model them. It concerns the emergence of complex behaviors of the collective when simple agents are aggregated. The first sense of the definition allows us to categorize rules with similar features, whereas the second allows us to describe in a declarative way what rules can or cannot do; b) Tagging: This mechanism facilitates the formation of aggregates and delimitation of boundaries – both features key for describing behavior, interactions and context; c) Internal Models: This mechanism facilitates abstraction of relevant features, where patterns are identified and modeled. Models of interest are internal to each agent, and the agent will only react to external stimuli matching its internal representations; and d) Building Blocks: This mechanism basically allows for reusability in terms repetitions and combinations of simple things in order to build more complex ones. Past/Related Initiatives The Knowledge Management Group (KM) at Partners Healthcare has been working in the area of knowledge representation for many years. Authors have participated in several projects aimed at developing standards-based approaches to
909
extracting and representing clinical content in its multiple modalities, e.g. electronic health record (EHR), clinical guidelines, clinical decision support (CDS) [11]-[14]. Past efforts were mostly aimed at extracting and documenting content from various applications; identifying a variety of dissimilar and non-standard approaches to representing knowledge; heterogeneous terminology sources, implementation platforms, programming languages, as well as other factors, e.g., whether an authoring tool was provided for editing of rules, whether the logic is encoded in tables, or directly in executable statements, or whether the knowledge is implicit in the sequence/ flow of data entry applications and their controlling logic. The resulting inventory of all available documentation on clinical knowledge (i.e., decision support rules, order sets, ontologies, and documentation templates) is published in a Knowledge Management Portal intended to foster shareability among consumers of clinical content (e.g., clinical content developers, subject matter experts, and practicing clinicians) and promote best practices across Partners Healthcare. Current Work The next logical step in the current KM effort is the formalization, or conceptualization of extracted content. Current efforts are focused on developing a Clinical Knowledge Entity Metamodel (CKEM) to support the definition of a set of conventions, elements, and types common to our internal domains, e.g., patient demographics, medications, and diagnoses. The ability to use a common CKEM to represent diverse domains provides the basis for a shared understanding among teams from diverse disciplines, as well as a common root for tools and processes across domains. All models derived from the metamodel are declarative in nature, providing the building blocks for a flexible representation of content across all domains. The key element in the metamodel is the knowledge Entity. An entity metadata is represented in the metamodel as a set of “common properties” and “type-specific properties”; and content is represented as an aggregation of entities of different types and roles within a domain. One of these entities is the production rule. A production rule is basically a decision rule of the form: if…then. Production rules have an if part or condition, and a then part, or action. The condition part is basically a Boolean combination of simple expressions, whereas the action part could be an assertion, modification or retraction of facts; or some other side effect. In other words, production rules are logic statements that specify the execution of one or more actions when their conditions are satisfied. As part of the content modeling efforts at Partners Healthcare, we are implementing a schema to represent production rules (from hereon we will refer to decision support rules as production rules). Such schema captures the provenance of the clinical content, the context where such content is actionable (i.e., constraints) and the logic of the production rule itself. The next section describes the current rule schema and the proposed extensions to handle rule interactions in a clinical setting.
Methods Current Schema for Decision Rules Based on the CKEM described in the previous section, the current schema for production rules consists of two main sec-
910
M. Sordo et al. / Modeling Decision Support Rule Interactions in a Clinical Setting
tions – see Figure 2: a) Generic Properties contain information about Provenance consistent with the Provenance Ontology proposed by W3C [17], and Constraints for the overall content of the rule, e.g., a production rule may apply to patients of all ages, and the constraint for AgeGroup would be set to “any”, or to both genders, and so the Gender constraint will be set to “any”; and b) Type-specific Properties, which model the rule expression, i.e., the data declarations, the conditions in the antecedent of the rule; the constraints where such conditions apply, and the execution constraints for the consequent of the rule. These three type specific properties lay the foundation for modeling both the rule itself and its behavior. We will further describe them in the following section.
Figure 2 – Simplified Schema for Production Rules Type Specific Properties ruleExpression. The rule expression models data declarations; the logic in the antecedent of the rule as Boolean combinations of simpler conditions or ‘primitives’ representing similar medical concepts within different contexts; and the action(s) in the consequent of the rule. After reviewing different standards for rule representation, we selected a portion of ArdenML to model the rules [18]. Based on the original Arden Syntax, and implemented as an XML schema [19], ArdenML provides the necessary mechanisms and operators to explicitly define the conditions in both the antecedent and consequent of a rule. Further, the XML schema was seamlessly incorporated into our Entity Metadata schema as an extension of the entity type. hasConstraint. Rule expressions can be constrained to narrower targets than the whole rule. As long as we keep this in mind, we can define as many “sub contexts” as we need for a single rule. For example, an alert for an abnormal laboratory result may be relevant to all patients regardless of gender and age, and so the constraints in the generic properties of the rule should be set to Gender=ANY, AgeGroup= ANY. However, the threshold value(s) for the rule may be different depending on the age of the patient, and so, by specifying such threshold values constrained by age groups in the data definition of the rule expression, we can still model the alerting rule as simply as e.g. if labResult >threshold then alert; where the values assigned to threshold are constrained by the context (AgeGroup) where such values apply. In other words, the logic is the same, but the (content) comparison values are defined by context. hasExecutionConstraint. We propose to use execution constraints to model the behavior of the rules. To achieve this we
have borrowed four concepts from CAS as described before. First, we propose tagging the production rules in terms of membership and behavior. We can think of membership as “patches” [15] the rules belong or are relevant to. For example, a laboratory result rule is a member of the LabResults rule set; within this set, the rule could be a member of the chemistry subset of rules or “patch”; further, the rule could belong to the electrolytes sub-subset in the chemistry rules, and so on – as it is the case, for example, with rules checking potassium, sodium, chloride, and bicarbonate results. So, by tagging rules we can explicitly model the context where such rules are expected to interact. We think of behavior as the manner in which rules conduct in regard to themselves as well as in relationship to other rules in a given environment. In our proposed model, behavior towards, or as a response to others, takes precedence over behavior towards self. At the time of this writing, we have identified three possible scenarios for behavior in regards to self: i) the rule will fire every time the conditions in the antecedent are met; ii) the rule will fire once in a pre-defined period of time; and iii) the rule will never fire. As for interactions among rules, we have identified the following scenarios, when all conditions in the antecedent are met: i) fire even if other rules in the same “patch” – membership – have fired; ii) fire only if no other rule has; iii) fire first in the same “patch”; iv) precededBy (rule), where the rule will fire after the specified rule; and precededBy(patch), where a patch will be executed only after the specified patch has been executed. Although a slight departure from core CAS behavior, this is mainly targeted at modeling execution flow, both at a local (rule) level, as well as a more global (patch) one. Entities may have multiple memberships with the specified behaviors towards self and other. Such membership/behavior combinations can be aggregated to model complex behaviors in different “patches”. We believe that by having conceptual tags in terms of memberships and behaviors that can be aggregated to model complex interactions among rules, we can build internal models for each rule so they react to the environment in accordance to their internal representations. Similar to the building blocks mechanism of CAS, the rationale behind our approach is to model behavior as simply as possible and, then, aggregate and combine to model more complex behaviors. In the remaining of this paper, we present some exploratory examples and discuss findings and limitations.
Results We focused our initial analysis on the clinical content of three computerized applications at Partners Healthcare. The reviewed applications were: 1) Results Manager (RM) is an application in the outpatient setting that enables clinicians to review, acknowledge, and act upon abnormal/critical results of chemistry, hematology, radiology, and cytology tests in a timely manner; 2) Adverse Drug-Events (ADE) monitor reviews patient medication profiles for pairs of interacting drugs (the program considers physiological changes, reflected in abnormal laboratory results, that may occur as a result of an adverse drug-drug interaction); and 3) Adult and Pediatric Immunization Scheduling protocols, which in accordance with the Centers for Disease Control and Prevention (CDC) guidelines, suggest appropriate vaccination schedules, dosages, and warns against potential adverse effects. These three applications provide the empirical setting to evaluate our proposed approach.
M. Sordo et al. / Modeling Decision Support Rule Interactions in a Clinical Setting
Scenarios 1) Results Manager: The RM alerting rules are broadly classified by test type, e.g., chemistry, hematology. We propose a finer classification so rule interactions can be more accurately modeled. For example, chemistry tests such as potassium, sodium, chlorides, magnesium, and bicarbonate are all members of an electrolyte blood test panel that measures the levels of electrolytes and carbon dioxide in the blood. Electrolytes are interdependent of each other; if one varies, another one will vary also in order to compensate for the unbalance. For scenarios like this, where tests can be further grouped into specific categories, we propose the following tags: membership: laboratoryTest/chemistry/electrolytes; behavior-self: fire every time; behavior-others: fire if no one else has. So, in this scenario, all the abnormal/critical electrolyte results will be flagged accordingly, but only the first electrolyte result will trigger an alert. Other chemistry rules that do not belong to the electrolytes “patch” can be tagged separately, and their behavior will remain independent of other rules. For example, a patient with renal failure is monitored for kidney function. A creatinine (chemistry) test is ordered in addition to an electrolyte panel. In this scenario, it is likely that a) potassium levels will be abnormal; resulting in, among other things, a sodiumpotassium imbalance; and b) creatinine levels will be abnormal due to poor clearance of creatinine by the kidneys. The creatinine rule is tagged as follows: membership: laboratoryTest/chemistry; behavior-self: fire every time; behaviorothers: fire even if other rules have fired. The resulting behavior would be one alert for the abnormal electrolyte panel (as a whole), and one alert for the abnormal/critical creatinine result. For abnormal tests that are the result of a specific illness or treatment, as in the case of an oncology patient with low platelets (thrombocytopenia) undergoing chemotherapy, it is desirable to suppress the abnormal results alert. For this scenario, we propose the following: membership: laboratoryTest/hematology/oncology; behavior-self: fire first time in period of time; behavior-others: fire every time. This combination of membership/behaviors will result in the rule firing once within a pre-defined period of time, even if subsequent results, within such period of time are abnormal. This scenario and the modeled behavior are patient-population specific. However, we can, for this same rule, model another behavior – e.g., non-oncology patients – where the rule will fire every the time an abnormal result happens. For this latter case we would have: membership: laboratoryTest/hematology; behavior-self: fire every time; behavior-others: fire every time. By having multiple membership/behavior definitions for a rule, it will be possible to model different behaviors specific to contexts or “patches”. 2) ADE monitor: There are several rules that refer to specific medications while others refer to a family of medications, e.g., patient on anticoagulants and low platelets; patient on Warfarin and low platelets; patient on Heparin and low platelets. Even though these three rules check whether a patient is on anticoagulant therapy and has low platelet counts, we might want to keep them for the sake of thoroughness. It could be desirable to model the behavior of these rules by indicating that if a more specific rule fires (medication = warfarin or heparin), the more general should not (family of medications = anticoagulants), and so we could tag these rules as follows: membership: ADE/anticoagulants; behavior-self: fire every time; behavior-others: fire every time (for medicationspecific), and fire if no one else has (for medication-family). If
911
a more generic approach is desired, the behavior-others tags can be reversed. 3) Immunization Scheduling Protocols: The immunization scheduling rules include 13 vaccines approved by the CDC. Content from the CDC guidelines was modeled to reflect all the necessary conditions for each vaccine and dose combination, as stated in the published schedules. However, the interaction among rules, and, more specifically, groups of rules along the execution flow was not captured at the modeling stage. This resulted in e.g. moving rules, adding execution priorities to the rules, adding extra rules to control the execution flow, so both the required functionality can be replicated, and the execution flow can be adjusted to reflect updates to the vaccination protocols from the CDC. Currently, the main execution flow has been modeled as “folders” (equivalent to “patches”) containing task-related decision rules (see Figure 3). Inside these “folders’, when necessary, rules have priorities attached so an execution flow can be modeled. All these details should be documented at the modeling stage and not at implementation stage. Figure 3 depicts the generic execution flow for an immunization protocol: For any given vaccine, the first step is to check for potential contraindications: situations where a vaccine administration is not recommended, e.g., reaction to previous vaccine administration, patient medical history (e.g., altered immunocompetence). If there are no contraindications, the next two steps determine the validity of previous administrations, and the risk status of the patient based on the patient’s current medical condition(s). The NotIndicated step checks whether there are reasons for not administering the vaccine; for example, the patient already contracted the disease, or already received a complete vaccine series. If a vaccine is indicated, Precautions checks whether there are patient-specific conditions (e.g., pregnancy) a physician should consider prior to administering the vaccine, so they can make a fully informed decision based on potential risks. The Administration recommendation provides a recommendation in terms of vaccine product, dosage based on all the gathered information regarding previous administrations/products, as well as high risk status and precautions. Lastly, clinical judgment alerts physicians about situations when they need to use their clinical expertise to determine if a vaccine should be given or not.
Figure 3 – Immunization Rule Flow – simplified view We modeled the behavior of the “patches” – folders containing task-specific rules – to mimic the required execution flow by using the precedence behavior. First, we tagged all rules in each folder as members of the patch; second, the behavior-self
912
M. Sordo et al. / Modeling Decision Support Rule Interactions in a Clinical Setting
for all rules in a patch was set to “fire every time”; third, the behavior-other for the rules in a patch was set to “fire if no one else has fired”; fourth, the precedence for each patch was set to Precedence(nameOfPreviousPatch), with the exception of the contraindication patch which we tagged as Precedence() – the empty parameter indicating this patch is first in the execution flow. So, the previousValidAdministrations patch should have Precedence(Contraindication); determineHighRisk patch should have Precedence (PreviousValidAdministrations) and so on. Precedence as means for modeling execution flow is discussed in the next section, as part of our findings.
Discussion We have evaluated the feasibility of the modeling strategy proposed above by implementing relevant test scenarios through our analysis of the aforementioned applications. We have shown that with a relatively simple model we can represent interactions of a variety of rules. We found that by adding the concept of precedence to “patches” we could better represent rule flow. By doing so, Precedence could be modeled as a behavior for patches, separated from the precedence among rules within a patch, hence preserving the execution flow of rules inside a patch, while adding an extra layer of interactions between patches. We believe this enhancement is consistent with the building blocks concept of CAS, and it will allow us to model more complex behavior not only among rules inside patches, but also between patches.
Conclusions Robust and comprehensive approaches are key to accurately modeling content of any type. In the case of productions rules, it is highly desirable to capture and model not only knowledge pertaining the logic and actions of such rules, but also their expected behavior in the form of interactions among themselves. Currently, such interactions are not considered at modeling time, and we strongly believe they should be. The proposed approach presented in this paper, although exploratory, provides simple means for capturing such interactions in terms of memberships and behaviors. Our expectation is that a richer conceptual representation for production rules will facilitate rule authoring, foster consistency in rules implementation and maintenance; and develop authoritative knowledge repositories to promote quality, safety and efficacy of healthcare. We anticipate a more robust model as we continue expanding and evaluating our approach. Our plans are to complete these tasks in the next month, and then begin the implementation of a user interface for populating rule templates, so content can be modeled in a more comprehensive, consistent manner.
References [1] Berners-Lee T, Hendler J, Lassila O. The Semantic Web. Scientific American 2001: 284(5): 34-43. [2] W3C Semantic Web [Internet]. W3C Standards. 2013 [cited 2012 December 8]. http://www.w3.org/standards/semanticweb/ [3] Resource Description Framework (RDF) [Internet]. W3C Recommendation. [cited 2012 December 8]. http://www.w3.org/RDF/
[4] Resource Description Framework Schema (RDFS) [Internet]. W3C Recommendation [cited 2012 December 8]. http://www.w3.org/TR/PR-rdf-schema [5] SPARQL Query Language for RDF [Internet]. W3C Recommendation. [cited 2012 December 8]. http://www.w3.org/TR/rdf-sparql-query/ [6] OWL Web Ontology Language [Internet]. W3C Recommendation. [cited 2012 December 8]. http://www.w3.org/TR/owl-guide/ [7] RIF Overview [Internet]. W3C Working Group Note. [cited 2012 December 8]. http://www.w3.org/TR/rifoverview/ [8] SWRL: A Semantic Web Rule Language Combining OWL and RuleML [Internet]. W3C Member Submission. [cited 2012 December 8]. http://www.w3.org/Submission/SWRL/ [9] Gruber T. A Translation Approach to Portable Ontology Specifications.Knowledge Acquisition 1993:5(2):199-220. [10]Genesereth MR, Nilsson N. Logical Foundations of Artificial Intelligence. Morgan Kaufmann Publishers: San Mateo, CA., 1987. [11]Greenes RA, Sordo M, Zaccagnini D, Meyer M, Kuperman GJ. Design of a Standards-Based External Rules Engin for Decision Support in a Variety of Application Contexts: Report on a Feasibility Study at Partners Healthcare Systems. Stud Health Technol Inform 2004; 107 (Pt1): 611-615. [12]Sordo M, Hongsermeier T, Kashyap V, Greenes RA. Partners Healthcare Order Set Schema: An Information Model for Management of Clinical Content. In: Yoshida H, Jain A, Ichalkaranje A, Jain LC, Ichalkaranje N, eds. Advanced Computational Intelligence Paradigms in Healthcare – 1. Studies in Computational Intelligence 48, 2007; 1-25 [13]Zhou L, Maviglia SM, Goldman DS, Barley A, Lewis J, Hongsermeier T, Rocha RA. A Methodology for the Design, Development and Maintenance of Enterprise Clinical Decision Support Rules. AMIA Annu Symp Proc. 2009 Nov: 1107. [14]Regier R, Gurjar R, Rocha RA.A Clinical rule editor in an Electronic Medical Record Setting: Development, Design and Implementation.AMIA Annu Symp Proc. 2009 537. [15]Resnick M. Turtles, Termites &Traffic Jams: Explorations in Massively Parallel Microworlds. The MIT Press, 2000. [16]Holland JH. Hidden Order: How Adaptation Builds Complexity. Addison-Wesley, 1995. [17]PROV-O: The PROV Ontology [Internet]. W3C Working Draft. [cited 2012 December 8]. http://www.w3.org/TR/prov-o/ [18]Kim S, Haugh PJ, Rocha RA, Choi I. Modeling the Arden Syntax for Medical Decisions in XML. International Journal of Medical Informatics. 2008: 77:650-656. [19]ArdenML schema, stylesheet and examples [Internet]. [cited 2012 December 8]. http://61.78.109.24/ArdenML/ Address for correspondence Margarita Sordo, PhD Clinical Informatics Research and Development, Partners Healthcare, 93 Worcester Street, 2nd Floor, Wellesley, MA 02481 – USA. email:
[email protected]
