Background
Scope
Representation of Care Management Artefacts
This specification defines a model of structured plans that when executed in an engine, provide notifications to workers relating to tasks. Plans are not standalone, and require decision logic as well as access to subject data in order to execute.
Task Plans, along with related decision logic, can be used to represent a number of artefacts used in healthcare including:
-
care pathways - complex condition-specific, outcome-oriented;
-
guidelines - condition-specific, activity-oriented;
-
order set administration plans - condition-specific;
-
patient plans - subject-specific; either derived from published care pathways and guidelines, or created locally within an institution.
They may be referred to by care plans, which provide a patient-level description of intended care and monitoring for a condition.
The openEHR Process and Planning Overview provides a comprehensive overview of these artefacts, Task Planning and its related specifications.
Limitations of the openEHR standard Entry Model
Task Planning addresses the inability of the openEHR EHR architecture to directly represent fine-grained tasks. The Entry model described in the openEHR EHR IM defines a way to record clinical statements representing real observations, decisions, orders and performed actions in the EHR. In this scheme, Instructions represent orders for Actions to be performed, such as 'administer 3 times a day, for 7 days, with meals'. Such orders are consumed by human actors and mentally converted to individual tasks (21 administrations), with Actions and Observations recording what was done after the fact.
There is however a common need to concretely represent the plan of Actions and Observations ahead of time, as a set of individual tasks that can be displayed, verified, performed (or not) and signed off by workers. A set of planned tasks need not all relate to a single order, or indeed any order. The general picture is that a task plan corresponds to any self-standing healthcare job to be done.
What Task Planning Does Not Do
Some common capabilities related to clinical care management are not directly addressed by this specification, as described in the following sub-sections.
Task Lists (TODO Lists)
The specification is based around the concept of a work plan, which is designed to achieve a goal, and at execution time is applied to a subject, i.e. human or other subject of care. The plan notion is thus goal- and subject-centric.
A related concept is that of the task list (aka 'TODO list'), which is a logical list of tasks for a worker to perform. The task list is worker-centric, not subject-centric, and as such, task lists must be derived from concurrently executing work plans. Conceptually this is done by processing all extant task plans for some organisational unit (say a hospital department) and allocating particular tasks to particular actors. Allocation may happen in a just-in-time fashion, and may be modified (e.g. due to unforeseen unavailability of workers), such that a task list is essentially a dynamic personal calendar view for the short term (typically days or weeks) whereas task plans may correspond to any length of time, from a few minutes to years.
This specification does not cover the model of worker task lists or extracted calendar views, although it provides some guidance on how to generate task lists for workers.
Appointment Booking and Management
The planning paradigm envisaged by this specification does not try to directly address the problem of concretely creating and managing bookings for appointments, which, while conceptually simple, in real life unavoidably entails the complexity of ad hoc communication, cancellations, rebooking and so on. Instead it assumes that the existing systems designed to help perform this mostly administrative work will manage to get patients to intended appointments.
However, since the timing of visits is usually clinically determined, it would be reasonable for a task within a plan to request an appointment be created for a visit at some nominal time for some purpose, e.g. week 22 ante-natal review, in next 8 days. Another part of the same plan may have a wait state whose trigger event is the patient turning up for the nominated purpose. However, all of the administrative activity that occurs in order to ensure the patient appears is assumed to be external to the task planning system.
Clinical Decision Support (CDS)
While this specification covers the computable representation of decisions in a work plan, it is not intended to replace CDS systems that perform complex pure decision analysis, typically via access to specialist knowledge bases. Instead, it is assumed that the plans running in the task planning system will make requests of various CDS systems to provide specific answers, e.g. to check medications interactions for a proposed prescription, or propose a type of treatment for a hypertensive patient.
Relationship to Existing Workflow Formalisms
This specification describes a model of planning that includes support for work distribution across multiple performers, nested plans, conditional branching, timing and various other facilities. Many of these are conceptually close to the features found in standard workflow languages such as YAWL (Yet another Workflow Language) [1] and OMG BPMN (Business Process Modelling Notation), as well as emerging case-based standards such as OMG CMMN (Case Management Modelling Notation) and OMG DMN (Decision Model and Notation). Of these, YAWL is the most comprehensive in its design and the most useful source of concepts for the current specification.
While the model described here takes ideas from these languages, there are some key differences as well. The primary conceptual difference is that the subject (i.e. 'case') here is assumed to be a) an intentional agent (generally a human patient) that makes choices, and b) an active biological organism, which reacts to drugs and other interventions. In other words, an entity that cannot be considered a passive object (such as a package or blood sample), as is the case for most logistic workflows, for which languages such as BPMN are designed. (Note that even the patient can be a passive object in some circumstances, such as radiology.) Other departures include the use of a declarative rather than prescriptive means of defining the plan graph structure, and the formalisation of all elements of a plan and its execution.
The main consequence of this is that the design of a task plan is not taken to be a highly deterministic description whose exceptions are generally knowable in advance as they would be for a logistic system whose subjects are passive objects. Instead, tasks and groups of tightly-coupled tasks are specified in a more self-standing way, using preconditions rather than logical join and split operators.