openEHR logo

Process & Planning Overview

Issuer: openEHR Specification Program

Release: PROC latest


Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: process, guidelines, GDL, planning, 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.


image Creative Commons Attribution-NoDerivs 3.0 Unported.


Issues: Problem Reports

Amendment Record

Issue Details Raiser, Implementer Completed

PROC Release 2.0.0 (unreleased)


SPECPROC-xx. Add Overview document.

T Beale

27 Jul 2020


Primary Author

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

1. Preface

1.1. Purpose

This document provides an overview of the openEHR PROC component specifications, including the openEHR Decision Logic Module (DLM) Language, openEHR Task Planning and Subject Proxy service.

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 document is in the DEVELOPMENT state. The development version of this document can be found at

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 process specifications forum.

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.

2. Introduction

2.1. openEHR Process and Planning Artefacts

openEHR provides specifications for various models and languages to address the area of process and guideline-driven healthcare. These are as follows:

Together these enable the authoring of guidelines (GDL3 format), executable care plans and in-application active forms. There is also an existing guideline language, Guideline Definition Language 2 (GDL2), which defines an earlier self-standing guideline format, and which can be replaced by the DLM format GDL3 guideline.

2.2. Prior Art

openEHR DLM language 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 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.

Much of the formal semantics of the DLM formalism comes from experience with GDL2 deployments.

2.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 DLM/EL.

3. Conceptual Framework

Within a clinical process-driven healthcare environment, two high-level artefacts are commonly recognised: care pathways and guidelines, where guidelines are usually understood as specific to particular diagnostic and treatment processes, and care pathways as larger decision structures that combine guidelines around a major healthcare goal, e.g. 'manage sepsis'. At a clinical level, both types of artefact are understood to broadly consist of structured plans consisting of tasks and decision points, and decision rules, which provide input values for decisions. A third kind of artefact which is required for computational representation (but taken for granted in published guidelines) is the set of subject variables referred to, i.e. patient state, diagnoses and so on. The latter can be understood in two parts: declarations (names and types) and bindings, which are concrete methods of populating such variables from data sources. The following illustrates these conceptual artefacts without implying anything about a deployment or service architecture.

conceptual model
Figure 1. openEHR conceptual framework for care pathways and guidelines

3.1. Plans

In the above, the top box (pink) illustrates a plan definition, used to express a pre-defined structured set of tasks. In openEHR these are expressed as Work Plans, defined by the openEHR Task Planning model. Work plans are indispensible for various scenarios, including:

  • long term management plans unfolding over a time period in which personnel constantly change, and the plan is the main record of work done / to do;

  • highly detailed actions defined by clinical pathways for complex conditions such as sepsis, where the complexity level is beyond unaided cognitive capacity;

  • reminders and checklist items for basic actions that are sometimes missed or forgotten due to busy workplace and fatigue;

  • actions requiring sign-off in some way;

  • coordination of workers in a distributed team;

  • actions that result in recording something in the EHR;

  • actions of varying levels of granularity that are needed in a training mode.

Using the openEHR Task Planning model, plans for any of the above situations can be defined by domain experts and executed. Work Plans are executed by a plan engine, which connects with workers (generally human, although software agents and autonomous devices may also perform tasks) and acts as a co-pilot for each one, reminding them of tasks and relevant details according to the worker’s process. It also manages coordinating notifications and commits and retrieval to and from the EHR. In this way, it can convert disparate workers with weak communication into an integrated, coordinated team.

One of the key formal elements of a Work Plan is decision points (see e.g. the node marked 'CASE heart assessment' in the plan diagram above), where plan branching occurs, based on conditions and rules that ultimately depend on subject variables. In the openEHR architecture, all such decisional logic is expressed in dedicated Decision Logic Modules (DLMs), rather than within the plan. This ensures all decision conditions are treated as first order knowledge artefacts, rather than being hidden as (possibly duplicated) ad hoc expressions within the plan, where they are difficult to find and maintain.

3.2. Decision Logic Modules (DLMs)

In the conceptual model, the box on the lower right (green) represents decision logic modules, which express the rules, decision tables etc that encode published guidelines, and express the decision logic of plans. DLMs are used to represent the simplest Boolean conditions such as high_blood_pressure = systolic_blood_pressure >= 140 mm[Hg] used in plans, as well as complex chained logic representing stand-alone guidelines, scores and other rule-based clinical entities.

The essential characterisation of decision logic in the openEHR process specifications is a function-oriented logic that typically represents deductive inferences, such as clinical classification of patients (including diagnosis), based on input variables representing known facts about the subject (i.e. patient). These include results obtained from real world observation, measurement, imaging etc, as well as previous confirmed diagnoses and records of previous procedures. Other kinds of reasoning may be used as well, including Bayesian and other statistical and Artificial Intelligence (AI). In the latter case, DLM functions make calls to appropriate specialised services.

DLMs are written in the openEHR Decision Language (DL) consists of various formal elements, including:

  • input variables: declarations of subject-related variables that are referenced within the conditions and rules;

  • conditions: Boolean-valued simple rules based directly on subject variables;

  • rules: complex 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; may be represented as 2-dimensional decision tables;

  • output variables: intermediate rule results that may be inspected by calling components.

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

3.3. Subject Data

On the lower left (blue / grey) is the subject dataset, which is managed by the Subject Proxy service. Whatever the concrete architecture, these components serve to populate the subject data required by the Plans and Decision Logic Modules. As such, Data Access Bindings (DAB) are required to extract data from specific data sources and repositories, such as patient health records and monitoring devices, and where data is not available from these sources, users may be requested to provide it.

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 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 in highly variable representations, due to the use of different 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.

4. Architectural Use-cases

The formal artefacts described above may be deployed in different ways to achieve various goals.

4.1. Plan-oriented Systems

Many applications are designed around plans as the organising principle, such as complex medication administration (e.g. multiple cycles of multi-drug chemotherapy), team-based acute stroke response, ante-natal care and chronic condition management. In such cases, the system or application architecture will typically resemble the following.

plan architecture
Figure 2. Example Plan-based system architecture

4.2. Guidelines and Decision Support

Another major category of clinical process IT is guideline-based decision support. In this case, DLMs are used to express potentially complex guidelines to evaluate e.g. risk of acute events (heart attack, stroke etc). They are usually evaluated in an event-based manner, being triggered by e.g. commits to the EHR, or by a family practitioner opening the patient record for a particular patient.

gdl architecture
Figure 3. Example Guideline-based system architecture

5. Subject Data-sets


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

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