People often ask me why did we develop Task Planning in openEHR (NB: if the status is showing as ‘Retired’, this is an error in the specifications website), doesn’t BPMN do everything needed?
BPMN is in ubiquitous use in numerous domains, particularly logistics, process control, and human resource management (HR). There is nothing wrong with BPMN, with respect to what it was designed for. Most likely the Amazon package you received today was routed through the delivery network by a BPMN workflow running on an Amazon server.
Some attempts have been made to use it in health, and for simple, deterministic workflows, it can be made to work. However, healthcare in general is full of both complexity and unexpected events. The use of workflow automation in healthcare is also not primarily like that in e.g. parcel delivery. The difference is that a workflow in the latter domain is mostly or fully executed by machines, with minimum human intervention. In healthcare, numerous human agents are the workers, and they are doing three things:
- doing – e.g. making observations, administering medications
- deciding – determining what to do next, based on currently available data
- recording – writing to the patient record and / or other systems
Further, in healthcare, the ‘patient’ is inherently non-deterministic – he or she may react in unexpected ways to medication, or may simply not appear for a consultation. Or they may appear, but needed MRI results are not available, so the appointment is wasted.
These challenges have been recognised in the last decade, and an effort was launched within the OMG (the standards body that owns BPMN, UML and other major tech standards) in 2019 to try to augment the BPMN standards for use in health – this was known as BPM+ Health (in 2025, it was moved to HL7). BPM+ Health has done some good work on addressing some of the challenges, and I have personally worked on some of the involved standards, as a representative of the US Veterans Administration (VA). Download the ‘Field Guide’ to learn more.
However, there is not much ability to get around the core semantics of BPMN, CMMN and DMN as being unable to deal with a number of key challenges – things they were never designed for. BPM+ Health has no ability to issue a new major version of BPMN, or any of the related standards such as CMMN or DMN – too much of industry relies on the current specifications.
Separately from these activities, a group of us in openEHR started looking from 2015 on at the same challenges, and considering how the many scenarios we knew in healthcare could be addressed by process automation and decision support. I led the standardisation effort and we involved representatives from three vendor companies as well as various clinicians. The result was a set of specifications known as Task Planning. We determined early on that BPMN was unlikely to fit the bill, and in my background research, along with other colleagues at Intermountain Healthcare, it became clear that the YAWL language was a more appropriate model for understanding how to tackle the problem space. We didn’t use YAWL directly, and it is (as far as I can tell) no longer maintained as a tool. But many of our design concepts, including exception handling and comms channels for workers were taken from YAWL.
The table below explains the main differences between what we did in Task Planning, and BPMN / BPM+.
| openEHR Task Planning | BPMN | |
| Conceptual design | TP is designed to support adaptive workflow executions, where the user can skip tasks, backup and repeat, abandon, and switch to exception paths. This reflects clinical reality. Conceptually borrowed from YAWL. | BPMN works well for relatively deterministic situations which is why it is used so heavily in process engineering, logistics etc. It is not easy to represent exception paths. Less deterministic cases have to be represented in CMMN, which is then integrated into the overall workflow. CMMN has its own meta-model, which means that a BPMN+CMMN plan is expressed in two different notations. |
| Coherence of formalism | TP is an integrated formalism, consisting of the workflow part and a decision language, fully integrated, plus a Subject Proxy service, which describes how to obtain data from real systems. | To use BPMN for healthcare really means using these separately designed and standardised formalisms / notations:
|
| IT systems interaction | In TP, interaction with an EMR or any other application is built into each Task. So the workflow functions as an application backbone as well as a domain workflow. | Interaction with other IT systems (e.g. EMR, PAS etc) requires more Activity (Task) boxes in the workflow. If one clinical task requires viewing data from an EMR and writing data to an Order Entry system, then the clinical task requires 3 Activity boxes in the workflow, not one. This greatly increases the size of the workflows and makes them hard to comprehend and design for domain experts. |
| Exception handling | TP has exception handling built in. They may be triggered by conditions, manual intervention or time. Conceptually borrowed from YAWL. | BPMN does not have a natural way to represent exception paths and conditions – they have to be manually represented in the main workflow. |
| Decision Language formalism | TP decision logic is represented in fully defined Decision Logic Modules (DLMs) that may contain any number of defined variables, logic expressions and documentation – conceptually similar to Arden 2, but in a more powerful and clearer formalism. | Decision logic is represented in isolated DMN decision tables, and not directly governable as a documented, versioned knowledge resource. |
| User override on decisions | In TP, a user may override the TP-computed decision path, and provide reasons for doing so. | BPMN does not support user interaction. |
| Representation of wait states and events. | TP has an intuitive way of representing wait states and events – they are connected to the Tasks waiting on them. | In BPMN, every wait state is another Activity. This greatly increases the size of a workflow definition. |
| Connection between executing workflow and performers. | In TP, the connection between users that perform the work and the workflow execution are modelled explicitly, similarly to YAWL. | Workers are represented in BPMN only very generically as ‘lanes’ within a pool. Different workers can be distinguished, but not the details of role type, how to connect, comms channel or any other practical elements. |
The result of these limitations in BPMN is that relatively simple clinical workflows are much bigger and less comprehensible to a domain expert than than in Task Planning. They are also harder to govern in the sense of being knowledge assets.
In summary, there is nothing wrong with BPMN, but it wasn’t designed for the complexity, rate of domain change, or non-determinism at runtime that we know in healthcare.