Task Planning Model Specification

This specification benefited from formal and informal input from the openEHR and wider health informatics community. The openEHR Foundation would like to recognise the following people for their contributions.

The work reported in this specification has been funded by the following organisations:

Many of the design ideas presented in this specification came from analysis of use cases from industry sources. In particular, the openEHR implementers Marand and DIPS provided significant detailed requirements, use cases, and design ideas.

Additionally the Activity-Based Design (ABD) project at Intermountain Healthcare (2015-), on which the primary author worked part time proved an important source of cross-fertilisation. The latter project is led by David Edwards and Alan James (chief architect), within the clinical quality program, under Dr Brent James, Chief Quality Officer at Intermountain Healthcare. ABD has a sophisticated architecture based on a custom archetype / template framework, adaptive workflow concepts, application generation and real-time speech recognition. It has pioneered a number of concepts used in the current specification, including the separation of definition, materialised and runtime levels of representation.

Lastly, a review of research literature and standards was conducted. Many of the ideas in YAWL ([[Hofstede_van_der_Aalst_2009]]) and its underlying research influenced this specification. The authors also reviewed various standards, including the OMG’s BPMN and CMMN.

This document describes the openEHR Task Planning Model, which is a formal specification of information representing Planned Tasks. It is designed as a formal extension to the openEHR EHR Information Model, and assumes the types described in that specification.

The intended audience includes:

Prerequisite documents for reading this document include:

Related documents include:

This specification is in the TRIAL state. The development version of this document can be found at https://specifications.openehr.org/releases/PROC/Release-1.0.0/task_planning.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.

This specification for a Task Planning facility for openEHR addresses requirements in a number of areas in which some form of granular planning of clinical tasks is required. The central concept is that of a plan (or set of plans) designed to achieve a goal and that relate to an active biological subject (normally a human or animal patient), rather than a passive object, such as a parcel or tissue sample. The requirements covered include one-off scheduled tasks (e.g. surgical procedure), long-running scheduled tasks (e.g. drug administration), recurring tasks (e.g. monitoring), and coordinated teamwork (e.g. acute stroke management). Related requiredments of individual worker task lists are discussed below.

In more sophisticated environments (generally hospitals), much task planning relates to guideline-based orders and medication administration. There are various levels at which to understand this, from care pathways (potentially covering management of a complex condition like sepsis) to specific workflows for particular elements of care within a pathway. One common conceptual entity is the so-called order set, which is generally understood as:

In openEHR, the first item corresponds to a set of openEHR Instructions, while the second is a candidate for representation in openEHR via the Task Planning facility documented in this specification. Hence, the addition of Task Planning to openEHR provides an important element enabling the order set notion to be formalised in openEHR.

The specification addresses the lack of fine-grained task planning facilities in the basic openEHR specifications, which are limited to the Instruction and Action concepts. These provide ways of stating orders and recording actions performed after the fact, but no way of representing or sharing plans for actions before they are performed. This limitation is described in more detail below.

The approach followed here is to specify representations of task plans at various stages in the planning lifecycle, i.e.:

The models described here are thus designed to support both design-time modelling (via archetypes, terminology subsetting) and runtime execution with modifications and abandonment possible while the work is being performed.

The Entry model described in the openEHR EHR IM defines a way to record clinical statements representing real observations, decisions, orders and actions that have occurred, in the EHR. In this scheme, Instructions represent orders for certain kinds of Actions to be performed. Actions and Observations represent events that have subsequently occurred in the real world - a real drug administration or an actual blood sugar measurement.

There is however a common additional need to concretely plan individual Actions and sometimes Observations ahead of time, as a set of 'tasks', often known as a 'task list'. Here we will use the more general term task plan to mean a specification of a set of actions to be performed by actors (usually human, but potentially machine as well) providing care.

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 some self-standing healthcare job to be done, which may include tasks designed to fulfill multiple orders, and also tasks not defined by orders.

To meet this need, a further kind of content can be recorded in the EHR, representing task plans containing tasks. Here we understand the word 'task' to mean 'definition of a planned task', i.e. a description of something to be performed in the future.

In order to respond to the need to formally represent clinical Task Plans, and to close the gap between orders and reported actions in openEHR, this specification provides a model of a task planning facility, which is conceptually situated in a larger semantic framework that includes entities at multiple levels, i.e.:

These entities and their relationships can be envisaged as follows.

The above diagram shows task plans as a concrete planning artefact that results from a care plan for a specific patient, and may be partly based on published care pathways and clinical guidelines, each of which can be thought of as a basis for task plans for an ideal patient for a given condition (e.g. pregnancy, sepsis, stroke etc). Where care pathways (or parts thereof) can be represented as formal artefacts, they can act as prototypes for task pan structures. However, a care pathway for a model patient is not the same thing as a task plan(s) for an actual patient, since each real patient has his/her own specific combination of conditions, preferences and ultimately phenotypic specificities. Thus, where task plans are based on care pathways, the latter act as prototypes whose ideal form may be modified by the specific care plan and/or as the care team deems appropriate.

This specification addresses the representation and semantics of concrete task plans. It does not address the representation of the care plan and it does not say anything directly about formal care pathway representation, although it may be surmised for the future that the formal form of a care pathway may have significant commonality with the task plan model presented here, which may provide a useful guide for future work in care pathway representation.

The task plan model does however assume that a task plan may be created due to a care plan of some kind, and that the care plan may in turn have been derived from one or more care pathways or guidelines; accordingly, the means to identify the plan and pathway / guideline are provided.

In the following, the term 'task' denotes the definition of an action to be performed, the report of which is normally documented in openEHR by the ACTION Entry subtype. However, 'task' is also understood more generally, so that it may also when performed, result in an openEHR OBSERVATION or other Entry subtype where appropriate. In the great majority of cases therefore, the term 'task' as it appears here equates to openEHR Actions and Observations.

For the sake of brevity, 'Action' below is intended to imply an openEHR ACTION, OBSERVATION or potentially other Entry sub-type, unless otherwise stated.

The specification is based around the concept of a task 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 thus worker-centric, not subject-centric, and as such, task lists must be derived from task 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.

As soon as the notion of planning is assumed, we enter some form of the workflow space, and it becomes essential to describe the intended paradigm of the human / machine execution environment. This is due to the fact that any description of planned tasks acts as a set of instructions to actors intended to perform the tasks. Since the instructions (task plans) will be represented in the IT layer and the executing actors (generally human, although they may also be devices or software applications) exist in the real world, an account of the interaction between the computing environment and the real world is required.

Although the task plan facility described in this specification is relatively simple compared to some workflow tools, we can nevertheless distinguish the following entities in the environment:

In normal environments such as healthcare, the real-world actors are not passive recipients of commands from a computer application implementing a work plan, but are instead active agents who normally work together to perform a job. Working together involves peer to peer communication, ordering of tasks and so on. A workflow application provides help by maintaining a representation of the work plan, and a representation of its progress in execution. It is immediately apparent that the application’s idea of a given work plan execution and the real world state of the same work are not identical, and in fact may be only approximately related. For example, the computable form of the work plan might only include some of the tasks and actors at work in the real world. There are in fact two workflows executing: a virtual workflow and the real world one, and there is accordingly a problem of synchronisation of the two.

There is also a question of communication between the workflow application and the real world actors, which we can think of as consisting of:

This environment can be illustrated as follows.

This specification describes a model for a 'task plan' concept that incudes support for work distribution across multiple performers, nested task plans, conditional branching, timing and various other facilities. Many of these are conceptually close to the features found in standard workflow languages such as BPMN (Business Process Modelling Notation) and YAWL (Yet another Workflow Language), as well as emerging case-based standards such as CMMN (Case Management Modelling Notation) and 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 differencs 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.

The simplest need is to be able to post a full plan of all actions to be performed for an order, in advance of the order commencing. This would result in a series of Tasks for each planned openEHR ACTION at execution time.

In openEHR, an order is represented by an INSTRUCTION instance, which contains a directive to do something such as preform radiography or administer medication. The form of representation in the Instruction is normally interpretable by an agent who will convert it to separate tasks. For example, a drug order for Amoxicillin 500mg oral tablet 3 times/day x 7 days is converted by a human agent to 21 separate tasks, each consisting of taking one tablet at a certain time or day. These tasks can be represented in a task plan, each task of which which can then be performed and signed off by a staff member, e.g. a shift nurse. The task plan acts as a record of what has been done, and what is left to do.

One difficulty with posting a full plan is that in some cases, the work is effectively open-ended, i.e. it has no currently known completion date. This might be because the patient condition being treated is chronic, e.g. insulin or Salbutamol (Ventolin) treatment; or it might be that although the condition is assumed to be limited in time, no current assumption can be made about when, e.g. pain medication of a trauma patient.

A plan for a clinical intervention will typically need to encompass more than one order, in situations where drugs and other therapies are used according to a protocol or regime. For example, in multi-drug chemotherapy based on protocols like CHOP (non-Hodgkin’s lymphoma), COPP or Stanford V (Hodgkin’s lymphoma) etc, a single drug such as Cyclophosphamide is just a component. A task plan for administering chemotherapy according to a R-CHOP protocol would implicate orders for the drugs (R)ituximab, (C)yclophosphamide, (H)ydroxydaunorubicin, (O)ncovin, and (P)rednisolone or Prednisone, and would accordingly include planned tasks for each of these drugs as they are administered according to the protocol.

(Extract from Wikipedia.)

A more general notion is of a protocol or guideline, which is a full set of actions to be performed to achieve a goal. Some of the actions will have corresponding orders, but others, such as making intermediate observations, may not. Examples can be found at sites such as the UK National Institute for Care and Excellence (NICE).

A more flexible version of a plan is 'lookahead' planning, i.e. posting a plan of tasks for a moving window in time, e.g. one day, a few days, a few nursing rotations etc. The idea is not to try to plan out the entire plan execution, since it can easily change or be stopped, e.g. due to change in patient or other unexpected events. In a lookahead approach, some planned tasks are executed, and more planned tasks are added. The planned timing of each set of tasks may change due to the current situation, with the effect that the overall set of tasks that unfolds in time may well be different from an attempt to plan all tasks before any are executed.

For the open-ended cases mentioned above, the only option is a lookahead plan that extends as far ahead in time as the treating physicians are prepared to go.

Many clinical plans involve repetition over time. For example, the 14-day version of the CHOP protocol (CHOP-14) involves execution of the 5 day treatment every 14 days, for 3 iterations. Other clinical plans are essentially permanently recurring for the life of the patient, e.g asthma therapy.

If a task plan is created, the constituent tasks can be viewed by workers as a checklist, and subsequently signed off as having been either performed or not done over time. The utility of this is that the correspondence between the tasks actually performed (represented by ACTION, OBSERVATION etc Entries) and the planned tasks is established. If a planned Action A1 is posted with execution time T, it might actually be performed at time T', but users still want to know that it was planned Action A1 that was intentionally performed, and not some other Action in the task plan. Over the course of the order execution, a picture will emerge of planned Actions being performed and signed off, possibly with some being missed as not needed, or not done for some other reason. Additional Actions not originally posted in the plan might also be done if they are allowed by the general specification of the relevant archetypes.

In many cases, a task plan is intended for execution by a team of specialised performers, with each performer doing their part of the work, and at various points, passing control to another team member. Management of acute stroke is an example of this. In other cases, team members are working more or less in parallel, or by communicating in real time to each other. In both situations, if the workers are not physically in the same room at the same time, notifications are needed to alert each person when to start working on the subject; similarly, callback notifications are needed to alert original workers when other work has been completed, for example, an MRI image taken and report written.

Plans can be described at varying levels of detail, depending on how workers are intended to work with them. One institution may describe an action such as cannulation atomically, relying on professional training and situational specifics to generate the correct concrete outcome, whereas another may require nurses to follow a guideline such as this Medscape Intravenous Cannulation guideline. In cases where a self-standing clinical task is itself fully described in terms of steps, it is possible to represent the latter as its own task plan, and to be able to refer to it from another task plan. The general case is that any task that could be represented by a single item in a task plan could also be represented by a reference to a separate detailed task plan.

A set of tasks intended to achieve a defined goal could be performed sequentially or in parallel, and may include sub-groups of tasks that can performed together. A common situation is to have a task plan intended for sequential (i.e. ordered) execution by the agent, one of whose steps is actually a sub-group of tasks which can be executed in parallel (i.e. in any order).

It can also be assumed that some tasks in a task plan may be designated as optional, to be executed 'if needed' or on some other condition being true.

The general structure and execution semantics of a task plan therefore includes the notion of sequential or parallel execution of groups of tasks, and also optional execution of some tasks. We can consider the task plan itself as a outer group of tasks for which either sequential or parallel execution can be specified.

Task plans derived from semi-formal care pathways or guidelines (and potentially ad hoc designed plans) may contain 'decision points', which are of the following logical form:

An example of decision points is shown below, in an extract from the Intermountain Healthcare Care Process Module (CPM) for Ischemic Stroke Management:

In this example, the node containing the text "Further CLASSIFY …​" corresponds to a decision point that can be represented as $symptom_onset_time := t, where t is a time entered by a user. The subsequent nodes in the chart can be understood as paths based respectively on the tests $symptom_onset_time < 4.5h and 4.5h < $symptom_onset_time < 6h.

The ability to include decision pathways enables conditional sections of care pathways to be directly represented within a task plan.

Tasks in a plan can be cancelled before being attempted for two types of reasons. One case is when the performer or the system realises the task can’t be performed (perhaps for lack of resources), and it is cancelled from the plan ahead of time. The other case is when the performer or system realises that the task isn’t needed, and can be cancelled as unnecessary, or already done by an external agent (e.g. an examination done at a night clinic).

In the first, case, the cancellation can be understood as a 'failed' task, whereas in the second, it is equivalent to a successful task. These two flavours of cancellation should be understood by the system so that plan success or failure can be reliably determiined.

Inevitably, some task plans will have to be changed or abandoned partway through due to unexpected changes in the patient situation. The question here is: what should be done with the remaining planned tasks that will not be performed? Should they be marked as 'won’t do' (with some reason) and committed to the EHR, or should they be deleted prior to being committed to the EHR?

It is assumed that the answer will differ according to circumstance and local preference, in other words, that planned tasks that are created are not necessarily written into the EHR, but may initially exist in a separate 'planned tasks' buffer, and are only committed when each task is either performed or explicitly marked as not done, or else included in a list of not-done Actions to be committed to the EHR at a point of plan abandonment.

The following kinds of abandonment of tasks should be supported:

It is assumed that at any moment there could be multiple task plans extant for different problems and timelines for the same subject of care, e.g. chemotherapy, hypertension, ante-natal care. If naively created, these could clash in time and potentially in terms of other resources. There should therefore be support for being able to efficiently locate all existing task plans and scan their times, states and resources. This aids avoiding clashes and also finding opportunities for rationalising and bundling tasks e.g. grouping multiple tasks into a single visit, taking bloods require by two protocols at the same sitting etc.

It should be possible to process multiple task plans as part of interfacing with or constructing a 'patient diary', i.e. rationalised list of all work to be done involving the patient.

As tasks are performed and signed off on the list of posted planned tasks, there will generally be differences between Actions actually performed and the tasks on the list. Differences may include:

These differences are obtainable from the EHR since both planned tasks and performed Actions will appear, providing a data resource for analysing business process, order compliance, reasons for deviation and so on.

It should be possible to record internal costing data against task plans as a whole, and also individual tasks. Additionally, it should be possible to attach external billing information to tasks and task plans. Costing information might be attached to each task, such as consumption of inventory items, time and other resources. Billing information is typically more coarse-grained and reported using nationally agreed code systems, e.g. ICD10 or similar.

A basic choice in the architecture presented here is that it is executable in the sense of all elements used in creating Plan definitions have an objective computational meaning and can be executed according to defined semantics. The intention is that developing task plans is a kind of high level programming, performed using dedicated tools, and whose resulting artefacts are executable. This does not of course mean that the resulting system performs the work (although it may indeed perform some particular Tasks). Instead, it means that the resulting executable artefacts and application(s) when executed in a real world work environment that includes human and other actors, will convert disparate workers with weak communication and coordination into an efficient, integrated, whole.

This follows the YAWL ([Hofstede_van_der_Aalst_2009]) rather than BPMN approach, such that no Plan defined according to this specification has ambiguous meaning.

This specification describes the models and semantics for task plans and their execution by a notional openEHR Task Planning execution engine ('TP engine'). This is assumed to operate in a server computing environment in which other systems exist with which the TP engine communicates. A key system is the openEHR EHR system, via which openEHR EHRs are accessible to the TP Engine.

Outside of the environment exist other organisations with which TP engine communicates by generic means (ultimately, email, phone calls, etc), mediated by an appropriate communications / notification system within the environment.

Users who act as performers of tasks are connected to the engine via applications that communicate to the TP engine via the API of the TP Engine. These applications may be dedicated to Task Planning or a combined openEHR application context containing Task Planning components or forms. Users who act as plan designers are connected to a task planning designer system via a dedicated designer application.

The overall context is shown below.

One of the major differences between the openEHR Task Planning architecture compared to other workflow architectures is that it can rely on shared access to persistent patient EHRs as the location in which context data can be read (e.g. patient variables) and in which records of performed tasks are ultimately stored, in the form of openEHR Compositions containing Entries, in the usual way.

Task Plans are defined, refined and used in various phases in time. A number of related technical representations are used, each appropriate to its phase.

In this scheme, archetype- and template-based modelling is used as much as possible in order to create layers of re-usable models that are progressively more specialised, until close-to-patient models are achieved, typically as templates. This enables the power of the archetype modelling formalism, including specialisation and composition to be used freely, in a similar manner to an object-oriented programming environment.

Within the phases of clinical planning and execution time described above, the Task Plan is not the only information artefact that may be created. The existing openEHR model ENTRY types provide the standard way to represent orders, via INSTRUCTION, and order-related performed activities, via ACTION. In addition, the usual OBSERVATION, EVALUATION and ADMIN_ENTRY types are used to record observations, diagnoses, and administrative events as they occur in clinical time. In abstract terms, Instructions may be understood as formal statements of 'what is to be done', and the other types, as records of 'what was done'. However, Instructions are most suited to concise representations of orderable actions, particularly medication administration, but not for general purpose detailed plans of events. The addition of Task Plans provides a way to specify such plans more flexibly, and in a step-by-step manner.

Both Instructions and Plans may be fully or partially defined by care pathways and/or guidelines, equally, they may be ad hoc developed in the 'old school medicine' sense. The following figure illustrates the relationships among care pathways, the existing openEHR Entry types and Task Plans.

In simple cases, a Task Plan may just be the list of Tasks to fulfill one order, i.e. a single INSTRUCTION prescribing a course of antibiotics. The general case however is that the Task Plan corresponds to a clinical goal which implicates multiple orders, such as the CHOP chemotherapy mentioned above.

Consequently, not every Task in a Task Plan is associated with an order, illustrated by the yellow Task objects in the above figure. While a typical case is that a Task corresponds to an openEHR ACTION that has not yet been recorded (and which normally has a driving INSTRUCTION), it may also correspond to an ACTION that has no INSTRUCTION or indeed an OBSERVATION or possibly an EVALUATION (perhaps some kind of check during a procedure). Indeed, there is also no reason why a Task Plan cannot consist of Tasks that define administrative work and would be documented with openEHR ADMIN_ENTRYs.

We can infer from the above that the main driver of a Task Plan isn’t in general an order, but a care plan or guideline that usually includes orders, or else plain old ad hoc planning.

A high-level view of how clinical work generates openEHR information can be visualised conceptually with a modified version of the Clinical Investigator process diagram as follows:

According to this scheme, TASK_PLAN and TASK are new types of information that can be committed to the EHR.

Despite the above explanation, the difference between Instructions (as defined in openEHR) and Task Plans may not be completely clear. However, there is a key difference, which is the semantic level at which the two are expressed. A typical order, represented in an openEHR INSTRUCTION has an algorithmic form, such as "Amoxicillin 3 times a day, orally, for 7 days". Although healthcare professionals do not typically think about it, this expression is in fact a small program that is mentally interpreted to produce resultant actions such as giving one tablet at 9:15 am, one at lunch and so on.

We can think of a Task Plan for ordered actions as the interpreted form of the original order statement(s), that is to say, a completely 'unfolded' list of single Tasks in time such as 'give 1 Amoxycillin oral tab at lunch'. This is a form suitable for displaying on work lists, checking off and ensuring no mistakes are made. When a Task is performed, it will still give rise to the appropriate openEHR Entry recording the details, such as 'gave 1 Amoxycillin tab at 13:37'.

With a Task Plan, various elements need to be referenceable at runtime. Tasks and Task Groups are identified via the uid attribute inherited from LOCATABLE via PLAN_ITEM, and which is populated with a Guid. References to a Task or Task Group are thus achieved with UID_BASED_ID instances carrying a Guid.

Generic classes for specifying time formally and in customary form such as 'afternoon' are provided for use in the main model. These are shown bottom right of the above UML diagram: TIME_SPECIFIER and descendants.

A Task Plan may contain logical variable references and expressions, which are used in various ways within the Plan structure. These are globally collated and tracked at runtime at the Work Plan level, i.e. in common to all Task Plans. To facilitate their definition and computable use, they are fully typed. The following UML diagram illustrates.

An instance of PLAN_DATA_CONTEXT represents the full set of tracked variables and expressions used in a Work Plan, which are either atomic variables or expressions that reference such variables, respectively represented by the classes CONTEXT_VARIABLE<T> and CONTEXT_EXPRESSION<T>. These classes and the abstract parent are generic, with the parameter being the formal type of variable or expression.

Variables are typically related to subject state, such as patient vital signs, key demographic characteristics and so on, or the clinical care process, such as the 'time since stroke event', while expressions are used to represent logical expressions such as systolic_bp - diastolic_bp, where systolic_bp and diastolic_bp are defined as single variables. The syntax of expressions is defined by the {openehr_expression}[openEHR Expression language].

Each context variable has a symbolic name (CONTEXT_VARIABLE.name), a type from within the openEHR type system (EXPR_TYPE_DEF), and a populating_request, which defines how to populate the variable with a System Request, typically an EHR query or similar.

There are two types of variables - 'event' and 'state', which distinguish the update basis. An Event variable is 'watched' by some technical means, and its value is updated whenever it changes. The CONTINUOUS_EVENT_VARIABLE specialised type can be used for managing updates of continuous valued variables (i.e. real values) such that changes below a certain threshold, say 2% do not register.

The following figure shows the key classes in the proc.task_planning.definition package.

The remaining classes are shown in various specialised views below.

The top-level structure for defining plans is a WORK_PLAN, which includes one or more related TASK_PLANs making up a logical goal-oriented plan. Inclusion is achieved via UID references to Task Plans (WORK_PLAN.plans and WORK_PLAN.top_level_plans) rather than physical containment. This relationship allows related Task Plans to be grouped, which occurs for two reasons described earlier: re-use of Task Plans as sub-plans of other Task Plans, and team-based Plans, featuring hand-offs between Task Plans. For a Work Plan, two distinct lists of Task Plans are maintained: plans, which references all Task Plans, and top_level_plans, which is a list of those Task Plans that act as the start points for activity for the various actors. Non-top-level plans are those used as sub-plans.

A Work Plan has a number of global attributes, as follows:

Both WORK_PLAN and TASK_PLAN are descendants of CONTENT_ITEM, which makes them a type of content that may occur in a COMPOSITION. Compositions used for this purpose have their category attribute set to the openEHR coded term |Work Plan|. This enables Work Plans to be committed to the openEHR EHR.

As can be seen, the definition of a TASK_PLAN is a TASK_GROUP, which has as its members any number of PLAN_ITEMs, which resolve to either TASK_GROUP (and some specialisations described below), or TASK.

PLAN_ITEM has a mandatory description attribute, which represents a natural language specification of the work of the Task. It also has two optional attributes that control the generic behaviour of Tasks and Groups: wait_spec and repeat_spec. The first enables a wait state (described above in the section Time and Wait States) to be applied to a Task or Group, which is triggered by time-related Events (clock time, reaching a point in a calendar) or other kinds of Events (external notifications etc). This allows the timing of a Task to be specified.

The second attribute, repeat_spec, enables a Task or Group to be marked as repeating. This is not primarily intended to replace the use of individual Task instances over time, such as repeated medication administrations, but rather to be used to indicate if larger sections (typicaly a Group) of planned Tasks are repeatable. Where repeats are specified, they will be unrolled into literal copies in the materialised expression of the Plan.

The specific definition of the work of Tasks is provided by TASK.action, of type TASK_ACTION and its subtypes. Two abstract sub-types distinguish the two basic flavours of Task Action, namely dispatchable, meaning 'sent elsewhere for processing', and performable, meaning 'defined and performed within the current Plan'. The following UML diagram shows TASK_ACTION and its subtypes in detail.

TASK_ACTION includes three attributes that apply to all subtypes. The first is subject_preconditions, which enables subject-related preconditions to be expressed, i.e. conditions referencing variables relating to the subject such as vital signs. These preconditions can be understood as conditions for safe processing, and should either be satisfied before proceeding, or else overridden by a competent performer who understands the implications.

A subject precondition is formally represented as a BOOLEAN_CONTEXT_EXPRESSION, whose expression value is a string in {openehr_expression}[openEHR Expression Language] syntax.

Pre-conditions are evaluated at the point at which the Task to which they are attached becomes available during execution. If any pre-condition evaluates to False, the Task is in theory unable to be performed. A clinical professional may override at execution time, since it may always be the case that particular circumstances obviate the need for a particular pre-condition that normally applies.

The second generally applicable attribute is costing_data, since cost information may clearly be relevant to any Plan item. Costing is dealt with in detail below.

The third attribute is review_dataset which provides the ability to specify a data set or form to display when entering a Task, to aid the performer.

In a similar manner, a small number of attributes apply to Dispatchable Actions and Performable Actions. The former class has two attributes to do with managing context change and callback. The wait flag indicates whether the current Task waits (i.e. blocks) while the dispatched work is performed, or whether it continues on asynchronously. The first constitutes a context switch, the second a context fork. The callback attribute attaches a special kind of Event-wait that is triggered on receipt of a callback. How callbacks function in detail is described below.

Performable Actions have three attributes. The other_participations and resources attributes allow other performers and passive resources to be defined for an Action. Both are subject to an allocation process at execution time, similar to that of the principal_performer. Finally, the capture_dataset allows a dataset or form to be specified, for which data must be obtained during the Task execution.

The subtypes of TASK_ACTION consist of the following (reading from the right hand side):

The following sections provide more detail on some of these model features.

More advanced applications of Task Plans include three common conditional structures, which may be considered as specific patterns based on the core classes. They are expressed in terms of descendants of TASK_GROUP and are illustrated in the following UML model.

The first pattern is a structure in which a set of Task Groups are treated as separate branches from a common point in the Plan. Each branch is entered conditionally according to the Boolean expression included on the branch. The classes CONDITION_GROUP and CONDITION_BRANCH provide this structure, which is equivalent to an if/then/else structure in a programming language. Semantically, the branches are evaluated in order, in the matter of an if/then/else structure, and the final member may be a catch-all branch that matches if nothing else does. Accordingly, the execution_type is constrained to sequential.

The following diagram shows a typical condition structure.

The second structure corresponds to a decision point in a workflow at which some expression is evaluated, and each outgoing branch corresponds to a sub-set of the expression’s value range (value_constraint attribute). The classes DECISION_GROUP and DECISION_BRANCH provide this structure, which is equivalent to a switch statement in a programming language. The branch sub-ranges should ideally be individually mutually exclusive, and collectively they should cover the entire value range of the expression. However, as with the Condition Group, the branches are processed in order stated in the definition (execution_type is constrained to sequential), which enables overlapping value constraints on the branches, and also a final catch-all 'else' branch, if needed. The latter would have an open value constraint of the correct type.

The following diagram shows a typical decision structure.

The third structure is a wait state at which multiple branches correspond to the receipt of different events. Taken together, the events constitute a set of logical alternatives at the relevant point in the Plan. This structure is modelled using the classes EVENT_GROUP and EVENT_BRANCH, and is equivalent to a when / then / else rules structure in a rule-based programming environment.

Repetition may be specified in the model via the attribute PLAN_ITEM.repeat_spec. This is intended to be used to designate sub-sections in a Plan as being repeatable rather than single Tasks, since the main point of a Task Plan is precisely to define individual Tasks in time for execution and sign-off.

One challenge with creating Task Plan definitions is the level of detail to use, with respect to the variable level of skill of different performers. For a senior nurse, a briefer version of the Plan would be preferable with actions such as 'set up IV with catheter' being a single atom, whereas a trainee may need to see a more detailed set of sub-tasks.

To enable a single Plan to be used in both ways, the concept of 'training level' is included in the model, on the TASK_GROUP class. This enables any Group of Tasks to be marked as having a specific training level, where a higher number corresponds to less experience. At execution time, the training level of the allocated performer can be obtained, and then used in comparison to the training level indicated on each Group (including the top-level Group of the whole Plan). If the user training level is higher, then the Group may be shown only as a single step (using its description, inherited from PLAN_ITEM); otherwise it may be shown as the set of sub-steps. This provides a simple way for the same Plan to be presented in different forms matching different performer experience levels.

The default value of training_level is 0.

The classes WORK_PLAN and TASK_PLAN may contain various references to externally defined clinical quality artefacts that they are based on or relate to, as follows:

The following diagram shows the definition structures corresponding to four typical wait states, where a Task is waiting on a timing or other Event.

The following diagram shows the defnition structure for a dispatchable Task Action with a callback.

As described in the earlier section Execution Concepts, Work Plan execution traverses three states: materialised, activated and terminated. These are described in the following sub-sections.

The Model overview figure shows a package proc.task_planning.materialised. This is a partial specification of classes that could be instantiated at Task Plan execution time to track Plan execution, and is provided as a guide to implementing a materialised form for runtime use. A minimal materialised model is described here, as a means of indicating some of the general issues that will be encountered in representation of the runtime form of a Plan definition. It should not be considered either normative or complete. The model is shown below.

The history of execution events from a Work Plan execution is represented in the runtime instances of classes defined in the proc.task_planning.history package, of which EXECUTION_HISTORY is the root.

As shown above, two types of execution event are defined:

The first type may also include forward references to EHR Entries that were committed as a result of a Task being performed. This facilitates logical indexing of planned and performed work items.

The Execution history for a Plan execution will grow and might become quite long for some Task Plan executions. How it may be persisted in various ways. The following possibilities are all compatible with both the model, and typical EHR requirements:

This approach cleanly separates the definitional representation of a Task Plan, which should only change if changes to the plan are made, and the execution state, which is built during the work performance.