openEHR logo

Decision Language (DL) and Model

Issuer: openEHR Specification Program

Release: PROC latest

Status: DEVELOPMENT

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: openehr, expressions, rules

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-X. 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 Model (DM) and an abstract syntax, denoted the openEHR Decision Language (openEHR DL). The DOM defines the semantics of a first order predicate style logic that can be used to write clinical Decision Logic Models (DLMs).

The intended audience includes:

  • Standards bodies producing health informatics standards;

  • Academic groups using openEHR;

  • Solution vendors.

Prerequisite documents for reading this document include:

Releated 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. Overview

The openEHR Decision Language (DL) and Decision Model (DM) define a formalism for expressing decision logic used in healthcare and biomedical research. The essential characterisation of 'decision logic' understood in this specification is a function-oriented logic that generates deductive inferences, such as clinical classification of patients (including diagnosis) from input data, generally obtained from real world observation and measurement.

For example, a simple decision function can be written to infer from the input variables heart-rate and heart-rhythm whether a patient has atrial fibrillation, or other forms of arrhythmia. Decision functions may be represented in other ways as well, including decision tables, which are widely used in many industries.

Regardless of the structual form, decision logic typically contains numerous 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 diabetes in a patient.

Such conditions and larger logic modules that may include them constitute fragments of logic 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).

The following diagram illustrates the artefacts covered by this specification.

conceptual framework overview
Figure 1. Conceptual framework

In the above, three logical components of the environment are identified:

  • Decision Logic Module (DLM): a module containing decision functions that map input variables to inferences;

  • Data Proxy: a definition of input variables corresponding to a type of real-world entity (e.g. car, cardiology patient) in a convenient form for use in a DLM;

  • Data Access Binding: bindings of concrete data access methods to the logical data elements in a Data proxy.

2.1. Prior Art

The openEHR DL formalism is a small language that builds upon the openEHR Expression Language, whose meta-model is defined in the openEHR Basic Meta-Model (BMM). DL adds constructs for representing conditions, decisions, modules. A small extra meta-model and syntax covers proxy definition, and the importation and binding semantics in the binding objects.

openEHR DL 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:

  • 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);

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

Nevertheless, various elements of Arden and ProForma provided useful inspiration for the formalism described here.

Other relevant formalisms include the OMG BPMN, CMMN and DMN standards, and the HL7 CQL standard. The former group of standards are just now finding 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 many of the same issues as openEHR DL/EL and provided useful ideas.

3. Requirements

The requirements of openEHR DL fall into a number of categories, described below.

3.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;

3.2. Representation

3.3. Binding to Data Context

  • bindings that connect variables to external data sources;

3.4. Type System

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

4. Conceptual Model

4.1. Representation

4.1.1. Decision Logic

A simple language would be a like a programming language, as illustrated below.

representation naive
Figure 2. Naive representation

This will be limited in utility, since we need access to partial executions, possible executions (i.e. recommendations), justification chains (i.e. 'here is the logic chain behind this decision') and so on. A more advanced form of the language would distinguish between:

  • definitions - domain constants;

  • conditions - Boolean-returning domain-specified criteria;

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

An example of a basic formalism supporting these concepts is shown below.

representation basic
Figure 3. Basic representation

4.1.2. External Data

For decision logic to be useful, it must be able to refer to data from the outside world, particularly state data of the case, e.g. the patient, specific devices and so on, in a clinical execution context. The general case is that state and event occurrences of any real world entity may be referred to. The approach taken in openEHR DL is that any such entity is represented by an abstract proxy object that defines its state as a set of properties and potentially structure. From a data perspective, any such set of properties will relate to a particular use. For example, the properties for a leukaemia patient are likely to include white_cell_count, platelets and so on, while a proxy object for ante-natal use will contain obstetric properties. A core set of properties for any patient would include clinical basics such as date of birth, sex, and typical vital signs.

TBC

conceptual proxy
Figure 4. Abstract proxy

4.2. Artefact Scheme

In order to support justifications, recommendations and other advanced functionality requiring transparent access to the logic structures in a Decision Logic Model, a high-level language will be needed that can be either compiled or interpreted such that advanced functions are available without having to specify them mechanically. An artefact scheme based on cross-compilation to executable code is as follows:

artefact scheme
Figure 5. Artefact scheme

Here, decisions defined in the source model are compiled to simple executable form, an executable form with justification (attached rule chain leading to the result), and a recommendation structure.

4.3. Usage

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

4.3.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 DLM 'rule' is likely to be intentionally designed to reflect published clinical best practice.

conceptual decision based
Figure 6. Decision-based

4.3.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 7. Condition-based

4.4. Service Model

The following shows an outline idea of a service interface. This could be made to cater for talking to some DMN service. It could also incorporate the CDS-hooks idea, which is just a recommendation structure.

conceptual service model
Figure 8. Service Model

4.5. Execution Model

Note
to be rewritten

The assumed execution model of the Decision Language is that DL functions are evaluated by an evaluator against a data context, which determines the truth values of the expression(s). The data context is the origin for some or all of the variables mentioned in the expressions, which may be read from and written to. It may concretely be a retrieved data structure, or data via an API call to the EHR, demographics, laboratory system etc.

5. The Decision Language Object Model (DLOM)

5.1. Overview

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

The structure of the dlom packages is shown below.

PROC dlom packages
Figure 9. proc.dlom Package

The packages are described below.

5.2. DL Module Package

The top-level construct of the DLOM is the DL_MODULE, representing a standalone decision logic module. It is shown below.

PROC dlom.module
Figure 10. proc.dlom.module Package

TBD: to be continued.

5.2.1. Class Descriptions

5.2.1.1. MODULE Class

Class

MODULE (abstract)

Description

A limited module concept, similar to BMM_CLASS.

Inherit

BMM_DECLARATION, AUTHORED_RESOURCE

Attributes

Signature

Meaning

0..1

ancestors: List<MODULE>

Extension ancestors.

0..1

used_models: List<DL_MODEL_REF>

Externally defined BMM models used by this EL Module.

0..1

definitions: List<BMM_CONSTANT>

Constant definitions needed by module.

5.2.1.2. DL_MODULE Class

Class

DL_MODULE

Description

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

Inherit

MODULE

Attributes

Signature

Meaning

0..1

conditions: List<DL_CONDITION_DEF>

Boolean conditions defined by module for use in rules.

0..1

rules: List<DL_RULE>

Ruleset consisting of rules of various types.

0..1

proxy_properties: List<BMM_PROPERTY>

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

1..1

proxy_objects[]*: PROXY_MODULE

Imported proxy modules

Functions

Signature

Meaning

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.

5.2.1.3. DL_MODEL_REF Class

Class

DL_MODEL_REF

Description

A reference to an included BMM Model, providing types.

Attributes

Signature

Meaning

1..1

model: BMM_MODEL

5.2.1.4. DL_CONDITION_DEF Class

Class

DL_CONDITION_DEF

Description

DL representation of an argumentless Boolean function that defines a condition.

Attributes

Signature

Meaning

1..1

definition: EL_EXPRESSION

Invariants

Inv_boolean_definition: definition.is_boolean()

5.3. DL Rules Package

Specific Rule types are defined as descendants of DL_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.

PROC dlom.rules
Figure 11. proc.dlom.rules Package

Some specific rule types are described below.

5.3.1. Condition Chain Rule

A DL 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.

PROC dlom.rules condition chain
Figure 12. Condition chain rule

5.3.2. Case Rule

A DL 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.

PROC dlom.rules case
Figure 13. Case rule

5.3.3. Class Descriptions

5.3.3.1. DL_RULE Class

Class

DL_RULE (abstract)

Description

Abstract parent of DL rule types. All rules have a name (inherited from BMM_DECLARATION), and a type (from BMM_TYPED).

Inherit

BMM_TYPED, BMM_CLASS_ENTITY

Attributes

Signature

Meaning

1..1

body: BMM_STATEMENT_ITEM

5.3.3.2. DL_CONDITION_RULE Class

Class

DL_CONDITION_RULE

Description

A kind of rule consisting of a chain of Condition/action branches.

Inherit

DL_RULE

Attributes

Signature

Meaning

1..1
(redefined)

body: DL_CONDITION_CHAIN

The body of the rule.

5.3.3.3. DL_CONDITION_CHAIN Class

Class

DL_CONDITION_CHAIN

Description

Rule type that returns a result based on one or more conditions.

Inherit

BMM_STATEMENT

Attributes

Signature

Meaning

1..1

items: List<DL_CONDITION_BRANCH>

Items in the chain.

0..1

else_result: EL_INSTANCE_REF

Result to use if logical 'else' branch is followed.

5.3.3.4. DL_CONDITION_BRANCH Class

Class

DL_CONDITION_BRANCH

Description

A condition / result pair (sometimes known as a 'when/then rule').

Attributes

Signature

Meaning

1..1

condition: DL_CONDITION_DEF

The rule condition.

1..1

result: EL_INSTANCE_REF

The rule result, in the form of a terminal expression of the form of a literal value, module definition (i.e. constant), or function call.

5.3.3.5. DL_CASE_RULE Class

Class

DL_CASE_RULE

Description

A case rule.

Inherit

DL_RULE

Attributes

Signature

Meaning

1..1
(redefined)

body: DL_CASE_GROUP

The body of the rule.

5.3.3.6. DL_CASE_GROUP Class

Class

DL_CASE_GROUP

Description

Body of case rule construct.

Inherit

BMM_STATEMENT

Attributes

Signature

Meaning

1..1

items: DL_CASE_BRANCH

Branches of the case rule.

0..1

else_result: EL_INSTANCE_REF

Result to use if logical 'else' is followed.

1..1

value: EL_EXPRESSION

The value-generating expression that is the basis for the decision structure to be evaluated.

5.3.3.7. DL_CASE_BRANCH Class

Class

DL_CASE_BRANCH

Description

One branch of a case rule.

Attributes

Signature

Meaning

1..1

condition: C_PRIMITIVE_OBJECT

Constraint expression constraining the value of a decision branch.

1..1

result: EL_INSTANCE_REF

The rule result, in the form of a terminal expression of the form of a literal value, module definition (i.e. constant), or function call.

5.4. Proxy Module Package

The class PROXY_MODULE represents an object proxy, i.e. source of real-world data.

TBD: to be continued.

5.4.1. Class Descriptions

5.4.1.1. PROXY_MODULE Class

Class

PROXY_MODULE

Description

A module for defining a collection of properties representing real-world values.

Inherit

MODULE

Attributes

Signature

Meaning

0..1

external_defs: List<BMM_PARAMETER>

External variable definitions.

0..1

local_defs: List<BMM_LOCAL>

Local variable definitions.

0..1

procedure_defs: List<BMM_PROCEDURE>

1..1

data_binding: DL_DATA_BINDING

Data bindings.

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.

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/