openEHR logo

Decision Support Language (DSL) and Model

Issuer: openEHR Specification Program

Release: PROC latest

Status: DEVELOPMENT

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: expressions, rules, workflow

openEHR components
© 2020 - 2020 The openEHR Foundation

The openEHR Foundation is an independent, non-profit foundation, facilitating the sharing of health records by consumers and clinicians via open specifications, clinical models and open platform implementations.

Licence

image Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/

Support

Issues: Problem Reports
Web: specifications.openEHR.org

Amendment Record

Issue Details Raiser, Implementer Completed

PROC Release 2.0.0 (unreleased)

0.5.0

SPECPROC-41. Add Decision Language specification.

T Beale

13 Feb 2020

Acknowledgements

Primary Author

  • Thomas Beale, Ars Semantica; openEHR Foundation Management Board.

1. Preface

1.1. Purpose

This document specifies the openEHR Decision Support Language (DSL), in both abstract syntax form and as a related model, the Decision Supoort Language Model (DSLM). The latter defines the semantics of a first order predicate style logic that can be used to write clinical Decision Support Models (DSMs) that may be used standalone or with a Process / Plan oriented system such as openEHR Task Planning.

The intended audience includes:

  • Standards bodies producing health informatics standards;

  • Academic groups using openEHR;

  • Solution vendors.

Prerequisite documents for reading this document include:

Related documents include:

1.3. Status

This specification is in the DEVELOPMENT state. The development version of this document can be found at https://specifications.openehr.org/releases/PROC/latest/decision_language.html.

Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:

TBD: (example To Be Determined paragraph)

1.4. Feedback

Feedback may be provided on the technical mailing list.

Issues may be raised on the specifications Problem Report tracker.

To see changes made due to previously reported issues, see the PROC component Change Request tracker.

1.5. Conformance

Conformance of a data or software artifact to an openEHR specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal derivations from underlying models, ITS conformance indicates model conformance.

2. Requirements

The requirements of openEHR Decision Support Language fall into a number of categories, described below.

TBD: this section only very rough for now.

2.1. Caller Interaction

  • the ability to capture the reasoning chain for presentation to a caller as a justification;

  • the ability to provide a decision and its possible outcomes, with the current recommendation indicated;

2.2. Representation

2.3. Binding to Data Context

  • bindings that connect variables to external data sources;

2.4. Type System

  • an ability to use externally defined information models that supply types that may be used in DL statements.

3. Overview

3.1. Conceptual Model

The openEHR Decision Support Language (DSL) and Decision Support Language Model (DSLM) define a formalism for expressing decision logic used in healthcare and biomedical research. Decision logic usually sits within a larger environment of plans, workflows and also data sources such as the EHR. The following diagram illustrates the artefacts covered by this specification within the wider computational context.

conceptual framework overview
Figure 1. openEHR conceptual framework for computable care pathways

In the above, the top part illustrates process and plan definitions, of which the care pathway is a specific example in clinical medicine. In openEHR these are expressed as Work Plans, defined by the openEHR Task Planning model. In other environments, OMG BPMN/CMMN representation might be used.

Below the process component, the two components of the decision support framework decribed in this specification are shown:

  • Decision Support Module (DSM): modules containing decision functions that generate inferences from input variables representing real world entities being reasoned about;

  • Subject Proxy Object (SPO): a definition of state variables and events characterising a real-world entity in a convenient form for use in a DSM.

The remaining component (shown at bottom left) is the Data Access Binding (DAB), which consists of bindings to data sources and repositories, such as patient health records and monitoring devices. Data from these locations is extracted to populate the input variables of a Subject Proxy.

In this environment, the Process Definition component may be understood as a primary user of DSMs and SPOs, providing it respectively with access to real world state (e.g. patient vital signs) and the results of inferencing on such state variables. As a consequence (and unlike BPMN), formal expressions do not appear in process definitions, only references to variables and functions.

The essential characterisation of decision support logic understood in this specification is a function-oriented logic that generates deductive inferences, such as clinical classification of patients (including diagnosis), from input variables representing known facts about the patient. These include results obtained from real world observation, measurement, imaging etc, as well as previous confirmed diagnosis and records of previous procedures. This specification considers decision support logic to consist of definitions, as well as various logical elements, including:

  • conditions: Boolean-valued simple rules;

  • rules: rules generating non-Boolean values;

  • rule-sets: collections of rules that operate on a common set of input variables to generate a common set of output values.

Rule-sets may come in various forms, including the decision table, a common way of documenting a set of related rules using a 2-dimensional table.

Rules typically contain conditions i.e. Boolean-returning expressions such as heart_rate >= 120 /min and heart_rhythm = |irregular| that are used as criteria for choosing decision paths within a function. In many domains, including healthcare, such conditions are often determined by long-term, evidence-based research, and may be well-known within a domain. For example, the innocuous-looking condition blood_glucose[2h post 75g glucose challenge] > 6.5 mmol/ml is the diagnostic standard for type I diabetes.

Conditions, rules, rule-sets and other inference-generating structures that may include them constitute fragments of knowledge that need to be able to be authored and change-managed independently from contexts that use them, rather than being directly written into (say) if/then/else logic chains as a programmer would typically do. This specification accordingly provides a representational form for such logic, along with artefacts that connect them to data access services (e.g. EHR) and also enable them to be invoked by user contexts (e.g. workflow engines).

Decision support logic necessarily requires a way of defining and expressing its input variables. This is not just a question of creating typed variables, but one of semantics. The 'variables' used in rules represent an ontic view of the subject, that is, a true description of its state in reality. For example, a rule for inferring atrial fibrillation and other forms of arrhythmia may refer to the input variables heart_rate and heart_rhythm. The meaning of these variables is that they represent the real heart rate and rhythm of the patient, rather than being just any heart rate, e.g. from a measurement 3 years ago. Similarly, a variable is_type1_diabetic represents a proposition about the patient in reality.

A second requirement of rule variables is that they are close to the language of the domain, for example is_type1_diabetic and has_family_history_of_breast_cancer are things a clinical professional instantly understands. Semantically, they tend to be highly precoordinated forms of more technical representations, e.g. problem_list.contains (type = 73211009|diabetes mellitus|, status=confirmed).

In order to support the definition of such variables, a connection is of course needed to the technical representation of data found within EHRs, documents, lab messages, real-time devices and other sources. These latter constitute the epistemic knowledge base for extracting the ontic view. They also tend to be highly variable, due to different concrete standards, products and databases. The ability to write decision logic in a natural yet computable way - independent of specific access methods and type systems - thus requires support for various levels of representation above the purely technical data items and APIs found in healthcare information systems. The Subject Proxy component in the scheme illustrated above constitutes the top-most reification of underlying data in the form of domain-comprehensible ontic variables.

3.2. Prior Art

openEHR DSL may be compared to other languages developed in the health arena for expressing 'medical logic', including HL7 Arden Syntax, Guideline Interchange Format (Ohno-Machado et al., 1998), ProForma (Sutton & Fox, 2003), as well as decision support languages such as HL7 Gello. These languages were not directly used, for various reasons including:

  • they do not support any distinction of ontic versus epistemic variables;

  • none have an easily extensible value referencing mechanism;

  • some are too procedural (Arden, GLIF);

  • current versions of some of these languages have been made specific to the HL7v3 RIM, a particular (and obsolete) model of health information designed for message representation (GLIF 3.x, GELLO);

  • none of them have a clear separation of the semantics of process representation, decision logic, proxy data and data access;

  • the maintenance and support is unclear and/or limited.

Nevertheless, various elements of Arden provided useful inspiration for the formalism described here. The Data Access Binding described here may be understood as a solution to the so-called 'curly braces problem' of Arden (Samwald, Fehre, de Bruin, & Adlassnig, 2012), i.e. the need to be able to bind rule logic to real-world variables.

3.3. Other Standards

Other relevant formalisms include the OMG BPMN, CMMN and DMN standards, and the HL7 CQL standard. The former group of standards are starting (as of 2020) to find use in the healthcare arena, having been developed for other industries including process control, logistics and insurance, and will require further development and integration for use in healthcare. The HL7 CQL standard addresses some of the same issues as openEHR DL/EL.

4. Decision Support Language

4.1. Overview

The Decision Support Language is a high-level language in which modules containing the following elements may be written:

  • definitions: domain constants;

  • conditions: Boolean-returning domain-specified criteria;

  • rules: domain-specified rules structures based on condition/action structures, which may return any type;

  • rule-sets: related sets of rules in various forms, including decision tables.

An example of a basic DSL text is shown below.

decision_module
    Cardiology_basic

data_source
    P: HeartPatient

definitions
    Afib_heart_rate: Quantity = 120 /min
    High_heart_rate: Quantity = 100 /min

conditions
    has_atrial_fibrillation:
        P.heart_rhythm = |erratic|286761003 and
            P.heart_rate >= Afib_heart_rate

    has_tachycardia:
        P.heart_rate >= High_heart_rate and
              P.exertion = |at rest|263678003

rules
    heart_assessment: Terminology_term
        if has_atrial_fibrillation
            Result <- |atrial fibrillation|49436004

        elseif has_tachycardia
            Result <- |tachycardia|11092001

        else
            Result <- |normal|76863003

4.2. Structure

TBD:

4.3. Definitions

TBD:

4.4. Conditions

TBD:

4.5. Rules

TBD:

4.6. Rule-sets

TBD:

5. Plan / DSM Interaction

5.1. Data-sharing

TBD: how to transmit arguments: assume all available in data sources? Need to allow calls to DSM using arguments?

5.2. Plan Structure References to DSM Features

At least two usage styles between the Plan engine and the Decision engine are possible.

5.2.1. Rule-based

In this style, rules are defined within the decision logic modules and the Plan just performs a 'switch' on the output values. This would be useful for non-Boolean decisions, e.g. generating coded terms; also for functions generating many possible values or value ranges. A DSM 'rule' is likely to be intentionally designed to reflect published clinical best practice.

conceptual decision based
Figure 2. Rule-based interface

5.2.2. Condition-based

In this style, only conditions defined within the logic modules are called, and the Plan defines the decision structure, i.e. it is a novel or ad hoc use of existing conditions. Semantically the

conceptual condition based
Figure 3. Condition-based interface

6. DSM Service Model

TBD

7. Examples

The following examples rely on the 'Core Patient' and extension Subject Proxies defined in the openEHR Subject Proxy Specification.

7.1. Perinatal Care

7.1.1. Subject Dataset

subject_dataset Pregnant_patient_DS

extend
    Core_patient_DS

state -- <time_window = "all">

    is_pregnant: Boolean

    is_type1_diabetic: Boolean

    previous_obstetric_hypertension: Boolean

    previous_pre_eclampsia: Boolean

    previous_eclampsia: Boolean

state -- <time_window = "current_episode">

    has_gestational_diabetes: Boolean

    has_pregnancy_hypertension: Boolean

    has_pre_eclampsia: Boolean

    has_eclampsia: Boolean

state -- <time_window = "live">

    amniotic_fluid_state: Terminology_term

    uterine_fundal_height: Quantity

    vaginal_blood_flow: Quantity
        currency = 30mins
        ranges =
            critical_high: |> 500 mL/hr|


state -- <time_window = "live", source = "manual">

    haemorrhage: Boolean

    contractions_commenced: Boolean

    braxton_hicks_contraction: Boolean

7.1.2. GDL3 Rule-set

gdl3_ruleset Obstetric_pregnancy

use
    Pregnant_patient_DS

preconditions

    is_pregnant

rules

    anaemia_type: Terminology_term
        Result <-
            if not has_diagnosis (87522002|anaemia|, |>= Current_episode.start|)
                |excluded|
            else
                diagnosis (87522002|anaemia|, |>= Current_episode.start|)

    risk_evaluation: Terminology_term
        ....

    amniotic_fluid_risk: Terminology_term
        Result <-
            map hypertension_state
                {44223004|premature rupture|,
                 86203003|polyhydramnios|}      -> |obstetric emergency|9999
                {59566000|oligohydramnios|}     -> |refer high risk care|1111
                {*}                             -> |normal|0000

    hypertension_risk: Terminology_term
        if has_pre_eclampsia or has_eclampsia
            Result <- |obstetric emergency|9999

        elseif previous_obstetric_hypertension or previous_pre_eclampsia or
                previous_eclampsia or has_pregnancy_hypertension
            Result <- |refer high risk antenatal care|1111

        else
            Result <- |normal|0000

    diabetes_risk: Terminology_term
        if has_gestational_diabetes
            Result <- |refer high risk antenatal care|1111
        else
            Result <- |normal|0000

    anaemia_risk: Terminology_term
        Result <-
            map anaemia_type
                {27342004|anaemia of pregnancy|,
                 |severe|}                          -> |obstetric emergency|9999
                {27342004|anaemia of pregnancy|}    -> |refer high risk care|1111
                {*}                                 -> |normal|0000

7.2. Breast Cancer Decision Protocol

7.2.1. Subject Dataset

Breast cancer specific dataset.

subject_dataset Breast_cancer_patient_DS

extend
    Cancer_patient_DS

state -- <time_window = "current_episode">

    tnm_t: String
        currency = 60 days

    tnm_n: String
        currency = 60 days

    tnm_m: String
        currency = 60 days

    tnm_g: String
        currency = 60 days

    estrogen_receptor: Terminology_term «pos_neg_vs»
        currency = 60 days

    progesterone_receptor:  Terminology_term «pos_neg_vs»
        currency = 60 days

    her2_expression: Terminology_term «pos_neg_vs»
        currency = 60 days

    ki67: Quantity
        currency = 60 days

    ejection_fraction: Quantity
        currency = 60 days

derived
    er_negative:
        estrogen_receptor = |negative|

    er_positive:
        estrogen_receptor = |positive|

    pr_negative:
        progesterone_receptor = |negative|

    pr_positive:
        progesterone_receptor = |positive|

    her2_negative:
        her2_expression = |negative|

    her2_positive:
        her2_expression = |positive|

7.2.2. GDL3 Rule-set

gdl3_ruleset Oncology_breast_cancer

use
    Breast_cancer_patient_DS

definitions
    ki67_threshold: Quantity = 14%

conditions

    ki67_high:
        ki67 >= ki67_threshold

    anthracyclines_contraindicated:
        has_diagnosis (|Transmural MI|) or
        ejection_fraction < 40% or
        has_diagnosis ({|heart failure (class II)|,
                        |heart failure (class III)|,
                        |heart failure (class IV)|})

    taxanes_contraindicated:
        is_type1_diabetic or
        has_allergy (|taxanes|) or
        has_DSntolerance (|taxanes|)

rules

    molecular_subtype: Terminology_term
        if er_positive and her2_negative and not ki67_high
            Result <- |Luminal A|

        elseif er_positive and her2_negative and ki67_high
            Result <- |Luminal B (HER2 negative)|

        elseif er_positive and her2_positive
            Result <- |Luminal B (HER2 positive)|

        elseif er_negative and pr_negative and her2_positive and ki67_high
            Result <- |HER2|

        elseif er_negative and pr_negative and her2_negative and ki67_high
            Result <- |Triple negative|

        else
            Result <- |none|

    chemotherapy_regime: Terminology_term
        if not metastatic
            if molecular_subtype in {|Luminal B (HER2 negative)|, |Triple negative|} and
                    (tnm_t > '1a' or tnm_n > '0')
                Result <- |taxanes|

            elseif molecular_subtype = |Luminal A| and
                    (tnm_t >= '3' or tnm_n >= '2' or tnm_g >= '3')
                Result <- |anthracyclines|

            elseif molecular_subtype = |Luminal B (HER2 positive)| and
                    (tnm_t = '1b' or tnm_t = '1c' and tnm_n = '0')
                    or
                    molecular_subtype = |HER2| and
                    (tnm_t = '1b' and tnm_n = '0')
                Result <- |paditaxel + trastuzumab|
            else ...
                Result <-

        else -- metastatic
            if ...
                Result <-
            elseif ...
                Result <-
            else
                Result <-

8. The Decision Support Language Model (DSLM)

TBD: this section is a rough draft at the moment

8.1. Overview

The org.openehr.proc.dslm package defines the Decision Support Language Model (DSLM), a structural model of the openEHR Decision Support language. It relies on the openEHR BMM.

The structure of the dslm packages is shown below.

PROC dslm packages
Figure 4. proc.dslm Package

The packages are described below.

8.2. DS Module Package

The top-level construct of the DSLM is the DS_MODULE, representing a standalone decision support module. It is shown below.

PROC dslm.module
Figure 5. proc.dslm.module Package

TBD: to be continued.

8.2.1. Class Descriptions

8.2.1.1. DECISION_MODULE Class

Class

DECISION_MODULE

Description

A container for a set of statements along with related BMM definitions, meta-data, terminology and bindings.

Inherit

AUTHORED_RESOURCE, BMM_CLASS

Attributes

Signature

Meaning

0..1

proxy_properties: List<BMM_PROPERTY>

Properties representing real-world objects, such as the patient state, the patient history (logical EHR) etc.

0..1

definitions: List<BMM_CONSTANT>

Constant definitions needed by module.

Functions

Signature

Meaning

0..1

create_bmm_class

Generate a BMM_CLASS structure in which:

  • constants = this.definitions;

  • this.conditions are converted to Boolean-returning functions with no parameters whose body is a single assignment statement of the form Result = DL_CONDITION_DEF.definition;

  • this.rules are converted to Boolean-returning functions with no parameters whose body consists of the DL_CONDITION_RULE.body.

8.3. DS Rules Package

Specific Rule types are defined as descendants of DS_RULE, which may be understood as a pseudo form of the BMM_FUNCTION meta-type, i.e. a particular kind of function with a body. The following UML view illustrates.

Some specific rule types are described below.

8.3.1. Condition Chain Rule

A DS condition chain rule is one that consists of a chain of condition / result pairs and an 'else' result to cover a failure to match any condition. It is illustrated in the following UML view.

8.3.2. Case Rule

A DS case rule is one that obtains a value from an expression and determines the Result based on the interval in which the value falls. It is the equivalent of a 'case' statement in many languages. The match criterion on each branch of the rule is specified in terms of C_PRIMITIVE constraint types, from the openEHR AOM2 model.

8.3.3. Class Descriptions

References

Ohno-Machado, L., Gennari, J. H., Murphy, S. N., Jain, N. L., Tu, S. W., Oliver, D. E., Pattison-Gordon, E., et al. (1998). The GuideLine Interchange Format - A Model for Representing Guidelines. J Am Med Inform Assoc, 357–372.

Samwald, M., Fehre, K., Bruin, J. de, & Adlassnig, K.-P. (2012). The Arden Syntax standard for clinical decision support: Experiences and directions. Journal of Biomedical Informatics, 45, 711–718. Retrieved from https://www.sciencedirect.com/science/article/pii/S1532046412000226

Sutton, D. R., & Fox, J. (2003). The syntax and semantics of the PROforma guideline modeling language. J Am Med Inform Assoc., 10(5), 433–443. Retrieved from https://www.ncbi.nlm.nih.gov/pmc/articles/PMC212780/