Decision Language (DL) and Model

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) that may be used standalone or with a Process / Plan oriented system such as openEHR Task Planning.

The intended audience includes:

Prerequisite documents for reading this document include:

Related documents include:

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:

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.

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.

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. We consider decision logic to consist of definitions and functions, the latter of which can be abstractly understood as rules, conditions, decision tables and potentially other varieties of function.

For example, a rule 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. A decision table can be considered to be a convenient way of representing a 'rule-set', i.e. a set of related rules driven by a common set of input variables.

Rules typically contain 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.

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).

The following diagram illustrates the artefacts covered by this specification within a larger computational context.

In the above, the top part illustrates the category of 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, two components of the DL framework are shown:

The last component (shown at bottom left) is the Data Access Binding (DAB), which are bindings to data sources and repositories, such as patient health records and monitoring devices. Such data are extracted to become the logical data elements in a Data Proxy.

In this environment, the Process Definition component may be understood as a primary user of Data proxies and DLMs, 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 or CMMN), formal decision / condition expressions do not appear in process definitions expressed as Task Plans.

The general approach to representation for Decision Logic Modules (DLMs) and Data Proxy Objects (DPOs) is to support two forms. The first is an optional high-level language form called Decision Logic Language (DLL) suitable for domain specialist authors, which abstracts away detail typically required by a programming language, and also provides some higher level abstractions, such as complex type operators, temporal logic and so on. DLL texts are assumed to be written by hand, with the aid of a syntax mode for typical editors, or a light-weight UI tool.

The second form is an expression in a standard programming language which is either generated from the first form by a cross-compilation process, or directly generated by a more sophisticated UI tool. This direct expression will be significantly more complex, because it encompasses not just the decision logic and proxy definitions, but the ability to compute recommendations (i.e. decision proposals), reasoning chains and other advanced functionality requiring transparent access to the logic structures of a DLM.

The two types of artefacts are shown below.

The openEHR DL formalism is a small formalism 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, and 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:

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.

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.

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

An example of a basic DLL text is shown below.

For decision logic to be useful, it must be able to refer to states and events of entities in the outside world, e.g. the patient vital signs in both steady state (oxygen saturation) and important transitions (e.g. critical low oxygen saturation). The approach taken in openEHR DL is that any such entity is represented by an abstract data proxy object (DPO) that defines state variables and event conditions as formal features, along with certain meta-data, e.g. currency, defining the worst-case latency of sampling of a variable from its real-world source.

From a semantic perspective, DPO state variables and events represent properties and events occurring in ontic (real-world) entities, such as the patient’s heart. They are typically populated via the patient record and real-time devices (e.g. pulse-oximeter, accelerometer). Consequently, they are understood as being temporally situated on a 'world time' rather than a 'system time' timeline, where the latter corresponds to data commit and availability time.

From a data perspective, the set of features defined in a DPO 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 DPO for ante-natal use will contain obstetric properties. A core set of DPO features for any patient would include clinical basics such as date of birth, sex, and typical vital signs. In general, the collection of features in a DPO will be a somewhat arbitrary 'slice' of all possible variables and events characterising a real-world entity.

The following illustrates two DPOs, one a specialisation of the other.

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

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.

The packages are described below.

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

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.

Some specific rule types are described below.

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