Task Planning (TP) Specification

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:

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.

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.

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.

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.

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.

One of the most basic tenets of workflow processing is assumed here, namely the clear separation of Plan definition and Plan execution. This specification distinguishes more than the usual two levels of representation, as follows:

The first level is implemented by Archetyping of the definition-level model defined in this specification.

The top-level formal concept defined is the Work Plan, which consists of one or more Task Plans. The Work Plan is a definition of work to be performed by one or more workers in order to achieve a defined goal with respect to a single subject of care. A different subject requires a different instance of a Work Plan. Goals are often defined by published guidelines or care pathways, and the overall structure of work defined within a Work Plan and its constituent Task Plans may well be structured according to such publications.

Within a Work Plan, each included Task Plan is a definition of work to be performed in a single work context, by a 'principal performer' and possibly other participants. Multiple Task Plans occur for two reasons:

Sub-plans occur to allow re-use of Plans for smaller pieces of work and also to provide a means of controlling the detail level of work differently for performers of different experience levels.

The entirety of the Work Plan definition is assumed to be executable within a single computational context (i.e. a 'Task Planning engine'), in which methods of notification and worker communication are available, enabling the state of progress of the work defined in the Plan to be fully represented. A Work Plan will often be limited to a single enterprise, but this need not be the case, as long as all of its Task Plans communicate within the same Plan execution context.

More typically, some jobs required by a Work Plan are performed in another organisational context entirely, and from the point of view of the original Work Plan, the second organisation is seen as a 'black box' to which a request can be made and a result might be returned. A common example is a hospital clinical workflow that at some point requires a laboratory result, which is processed by an external organisation. These situations are handled by an 'external request' Task type.

The actual definition of work to be done in one work context with a principal performer consists of Tasks stated within a Task Plan. The most basic structuring notion required is that of a sequential list of Tasks, enabling the representation of the set of steps in a typical linear workflow such as making tea or cleaning a wound.

However, in the real world, almost every job can be sub-divided into smaller pieces of work in a fractal nature. This simple fact requires that the general structure of Tasks is actually a hierarchy, within which sequential Task lists occur commonly (and will be the top-level structure in simple cases). The formal construct provided for this is the Task Group, which may contain Tasks and more Task Groups.

The Task concept defined in this specification is relatively straightforward in the abstract: it corresponds to a separately performable item of work for a performer to execute. A Task within a Plan has a lifecycle whose states indicate whether it is planned, available, complete etc.

In business terms, a Task typically corresponds to:

The Task Group construct replaces the node references found in traditional workflow formalisms such as BPMN, and defines the static graph structure of the 'normal flow' of a Task Plan by implication. Only exceptions to the normal flow are represented with explicit node references.

This provides significantly more power than an explicit graph structure for the normal flow, since Task Groups can have rules attached to them indicating which members should be executed and when, rather than relying on explicit links. The sequential / parallel indicator is one such simple rule. Additional rules could be added, such as:

These more sophisticated rules are represented in a generic way, with the Task Plan engine assumed to implement the underlying mechanics.

A fundamental concept in this specification is work context, which is the factor that distinguishes one Task Plan from another, i.e. one Task Plan (and any sub-Task Plans) corresponds to Tasks to be performed in a single work context. Work context is defined as a single, contiguous cognitive flow in the real world (i.e. not in the computational representation, which must always be considered an approximation updated in snapshot fashion) in which work can be performed seamlessly by one or more performers on a single subject. Concretely, this means that the flow of cognitive activity is unbroken during the work. This may extend over time and even distinct physical spaces, such as in the case of tele-consultations. Normally a single cognitive flow corresponds to a single actor, usually a person, but this is not always the case. More than one person may be involved in performing work on the same subject, but essentially working as one, and relying on real-time verbal or other communication to achieve the effect of a single mind.

Continuous knowledge of the work, and continuous real-time communication with oneself ('train of thought') or directly among multiple performers is what characterises a given context. A different context is one with different cognitive actors, and within which communications are performed by notifications at certain time checkpoints, typically just the beginning and end.

Since parallelism is possible within a single Plan, a performer may be working on more than one thing at once, within the same context, for the subject. In other words, a work context (and a Task Plan in execution) may contain multiple execution paths at a point in time.

If work has to be stopped within one context and passed to a different work context, a context switch is required, and the first worker or team will wait for a response. If the context switch is within the same Work Plan, it is termed a hand-off, which entails switching Task Plans. A context change is also required to request work from an environment external to the current Work Plan.

A second kind of change of control is a context fork, whereby the current performer signals to another context to start doing some work, but continues doing his own work.

A context switch is commonly known as 'block and wait' or synchronous processing, while a context fork is known as asynchronous or parallel processing.

The following diagram shows a taxonomy of task types that result from the above considerations.

How does a hand-off actually work? There are two distinct scenarios. Consider a hand-off situation in which one worker is a radiographer taking images of the patient, and who once finished, will hand over to a radiologist, who will assess the images. In this case, the inputs required by the radiologist - the images - are immediately available online, so she can begin her work immediately. The hand-off can therefore be effected by means of notification to the radiologist. In terms of control flow, the radiologist (at least in situations like Emergency Department, acute stroke case) is driven by events: as soon as new images are ready, she works on them. Accordingly, in terms of Task Plans, when the radiographer has completed his Task Plan (doing the imaging), the radiologist is notified, and her acceptance of the work will cause the relevant Task Plan to be activated.

A second common scenario is typified by the first worker being a reception staff-member who receives a patient in a (non-emergency) clinic. When he has completed the usual appointment and administrative record check, he tells the patient to wait in the waiting area for the doctor. The hand-off to the doctor in this case entails the patient (i.e. the 'subject') being physically available when the doctor is ready, and the doctor having the patient visible on a list. The control flow in this case is: the second worker processes his patients from the queue, and will see a particular patient when they get to the head of the queue. Consequently, there is no point in notifying the doctor as such; instead, the latest patient is added to the queue, and seen by the doctor in his turn.

We can state the general question as being when the second worked in a hand-off should commence his work. It could be:

Work context is maintained during a work session during which the work is done by one or more performers. But if the work extends over hours or days (e.g. chemotherapy), worker shifts will end and the work will be taken up by the same or new workers on the next day. The Task Planning model does not consider this kind of worker replacement to be a context switch, since it is assumed that the Task Planning runtime system maintains all relevant context information, available for use by new workers. All that is required to maintain the context is for de-allocation and re-allocation of the work to the new (i.e. replacement) performers.

Following the notion of work context described above, a Task Plan is defined to have a principle performer, that is to say, a single logical executing actor. This is often a single person (or a device or possibly a software service), but might equally be a group of personnel, e.g. ward nurses, who execute the steps of a Task Plan during and across shift boundaries (wound dressing, turning patients, IV maintenance etc). In these cases the separate individuals constitute a 'single mind' as described above, with respect to the subject of care and the work, and their communication is not directly represented within the Task Plan.

In addition to the principal performer, other participations can be specified for any contained Task in a Plan. This allows the Plan to indicate where specific members working in a single cognitive work context should be responsible for specific individual Tasks. However it is assumed that the principal performer is responsible for all actions, and is also the notifier of action completions and cancellations.

The principal performer and other participants are specified in the Plan in terms of professional roles, and optionally a specific agent. This might in some cases be the patient.

Where an overall work plan requires separate actors who do not operate within the same work context, e.g. the various specialists and other professionals who perform different tasks with respect to an acute stroke patient, separate Task Plans each with their own principal performers are required. In this situation, coordination between the various actors is achieved by context switching and notification.

During the execution of a Task Plan, at any given time, a particular physical actor must be assigned as the principal performer, in order for the Plan to proceed. This assignment will change over time for long-running Plans, due to shift changes, out of hours contacts, worker vacations and so on. In this model, worker changes are handled by runtime allocation and are not treated as context switches. The allocation concept is described in more detail below.

Many tasks in the real world can only be performed when certain events occur or conditions become true. This model treats such conditions as wait states, based on events or time.

Time is understood in three possible ways:

The first two are converted to artificial events by the execution system internal clock reaching markers on the Work Plan timeline or calendar. For real event-based times, the kinds of events recognised include the following:

Tasks can be defined to wait on either one or more events.

In this scheme, archetype- and template-based modelling is used as much as possible during the design phase, in order to create a hierarchy 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.

When the design phase is complete, a Work Plan template may be instantiated by a clinical planner in the planning phase, to create definitions instances that are stored in a Composition in the patient EHR. During this phase, adjustments to the definition. Multiple workers may undertake such modifications, which may be performed over some time. At any given time, a particular patient EHR may contain multiple Work Plan definitions.

When a Work Plan is ready, the execution phase can begin, done by materialising the Plan definition from the EHR into the TP Engine, where it can be executed. It is the materialised expression of a Plan that is used to record all Plan-related actions by Task performers.

A Plan 'execution' may be long-lived, and extend beyond worker sessions in individual application invocations. The execution state will therefore be persisted for such Plans. During the execution phase, multiple runtime executions will occur, during which some part of the Plan will actually execute with the relevant users (i.e. performers) and applications.

As the work is performed in the execution phase, the results are documented with openEHR Entries, such as Actions and Observations.

The following figure illustrates these phases of work and the series of representations of Work Plans as they progress from archetyped models to runtime executions.

A Work Plan definition can be executed by being materialised. The model recognises three states in the execution phase, as follows.

Since a Task in a Task Plan being executed at runtime represents the Plan execution system’s knowledge of some work being performed in the real world, a way to connect the Plan as it is in the system (e.g. as shown on a UI application, or via notifications such as instant messaging) to the real-world actors performing it is needed. Following YAWL, the architecture described here treats allocation of work to a performer as a formal activity during Plan execution.

Conceptually, worker allocation is understood in the following way. Firstly, it is assumed that Tasks can be allocated to two types of worker resource:

Secondly, at runtime, the actual worker will be resolved at execution time as follows:

It remains the business of the organisation and also the Task Planning engine to resolve how these choices are made.

As per YAWL, more sophisticated implementations of Task Planning may offer numerous allocation strategies, such as first-available, quickest-to-complete, least-frequently-used and so on.

Every Task in a Plan has a lifecycle described by a state machine. The states represent the state of a real world item of work, as known by the Plan execution system; setting them is entirely reliant on the system receiving input from performers. The successful execution path is through the states planned ⇒ available ⇒ completed, with other terminal states cancelled and abandoned available for cases where a Task is cancelled and abandoned respectively. Here, cancelled means 'not needed', i.e. the principal performer determined Task could be cancelled before or during execution, without compromising the Plan. Conversely, the abandoned state indicates that the performer cannot do or complete the Task, or the rest of the Plan. Thus, abandoned for a Task means abandonment of the current Task Plan.

From the viewpoint of Plan execution, the final state of a Task execution determines whether the Plan remaints in the active state, or whether it enters the terminated state. If the Task terminates with completed or cancelled state, it is considered to have succeeded, and the Plan remains active. If the Task is abandoned, it is considered as failed, and the Plan terminates with a failure status.

A special transition override is used to force a Task to into the available state; this represents a performer explicitly overriding preconditions or subject preconditions.

A Task becomes available to perform when three kinds of condition are met:

Control flow reaches a Task in a Plan when either preceding Tasks have been performed (local control flow) or a previously dispatched external Task completes, whose restart location in the current Plan is the current Task.

External preconditions (described above) are met when a point in clock time is reached or an event notification is received.

If the control flow and external preconditions are met, a Task will still not be available until any subject-related preconditions are satisfied. These are conditions that may be specified to ensure the Task is only performed if it is clinically appropriate and safe to do so, such as 'systolic blood pressure < 160 mmHg'.

Since the Task Plan cannot presume to have perfect knowledge of the real world situation, the performer is always allowed to override the external and subject pre-conditions, due to better knowledge. In such cases, the control flow requirement still holds - since this can already be 'overridden' by the performing cancelling preceding Tasks where appropriate.

When a Task does become available for execution, nothing will happen until a performer is allocated to do it. When an available worker is allocated, the Task may be commenced, and further life-cycle states can be reached, i.e. completed, abandoned etc.

The following diagram illustrates these concepts.

One of the major challenges for any workflow system is that of being able to handle unplanned exceptions at runtime and adapt. The Task Planning model makes a key assumption that simplifies deviations at runtime, which is that the human (or other) performer always knows best. This means that Tasks posted to be done by the system are always advisory, and their details (such as time) are advisory. Accordingly, the model provides the following support for execution-time adaption:

The representation of a generic API call is via the API_CALL class, while the QUERY_CALL class provides a way to represent a call to a query service.

For generic API calls, the assumed model of calling is as follows: when the call is invoked, all required parameters are passed; these are obtained from two sources:

The first is specified via the parameter_map attribute, which defines the mapping between the external call parameter names and the names of variables that will be used to populate them at invocation. For example, assume there is an API call in a clinical decision support service with the following signature, which is to be used in a Task Plan:

The parameter_map attribute of the SYSTEM_CALL instance will contain the following, where the left hand item in each case is the name of a Work Plan context value (i.e. variable, expression or constant):

This tells the Task Plan execution system to inject the current value of the context variable subject_sex into the location where the sex parameter is expected and so on.

The second type of parameter is a fixed value, which enables the System call to represent the external call in a preferred way. An example of this is a general API call such as cds_check (type: String, other_args, …​) might be used from within the Task Plan with the first argument fixed in each case, to form specific invocations, e.g. cds_check ("hypertension risk", other_args, …​), cds_check ("diabetes type 2 risk", other_args, …​) etc. Fixed parameters are represented in the bound_parameters attribute of a SYSTEM_CALL instance.

The total set of parameters for any System call is provided by the combination of the contents of the parameter_map and bound_parameters attributes, where either may be empty.

The above provides for API calls whose signature definition may be more or less anything. For the case of query invocation, some simplifying assumptions can be made, and in the interests of clarity, the QUERY_CALL class is defined for this purpose. A QUERY_CALL instance represents a query invocation which is assumed to take the form of either an ad hoc query or a stored query, with substitutable parameters. accordingly, the external API calls are therefore assumed to take one of the two forms:

In the first case, a query string is supplied; in the second, the registered identifier of a stored query is supplied. In both cases, the substitutable parameters are supplied though the args attribute, which is a keyed list of String values that can be substituted into the replaceable parameters found in the query.

In order to represent an invocation of either of these calls, the parameter_map attribute is used to represent the map between the names of the substitutable parameters in the query and variables from the Work Plan context. Since these are often likely to be the same (almost certainly the case for ad hoc queries), mappings are only required for substitutable variables whose names differ in the query and in the Plan context variable set.

The bound_parameters may be used in a similar fashion, to represent fixed-value substitutable parameters.

As a consequence of this scheme, the total set of replaceable query parameters is specified by the combination of the parameter_map, the bound_parameters and the context variables. In many cases, only the latter may be used.

The Work Plan calendar consists of Plan-related entries fixed in time, as per the usual notion of a person’s or organisational calendar. These will normally be a small subset of entries from a/the work management calendar of the organisation in whose IT system the Work Plans are used. A Plan calendar event can be used as the basis for a wait state (TASK_WAIT.events) for Tasks in the Plan, either to indicate that something should be done on the date/time of the calendar event, or with a certain delay. Calendar events may include organisational events, national holidays and patient appointments. Wait states of the form '2 weeks after Easter Sunday' and '24 week ante-natal review (10 Feb 2019)' can therefore be defined in a Plan.

The PLAN_ITEM class is the parent of all fine-grained elements of a Task Plan, which are either TASKs or TASK_GROUPs. It has a mandatory description attribute, which represents a natural language specification of the work of the Task.

At execution time, every Plan Item (i.e. Task and Group) notionally has a lifecycle state, represented by a state machine, containing states and transitions reflecting possible actions by the performer. The lifecycle state of a Task is set by the TP engine and affected directly by performer actions and other logic, while the lifecycle state of a Group is aggregated from the state values of its member Tasks and Groups.

The lifecycle state does not appear directly as a data attribute on the PLAN_ITEM or TASK classes since it is a runtime variable for a Task. Accordingly, it appears in the materialised model, described below. It is however useful to decribe the lifecycle state here, since it represents a key part of Task Plan semantics, and influences whether Tasks (and thus Groups) fail or complete, and potentially whether the Plan continues in execution.

The state machine is shown below.

The state machine is designed to represent both stateless and stateful views of the actual execution state of a Task in the real world. The standard pathway is available ⇒ completed or abandoned or cancelled, which enables a user to indicate the outcome of executing a Task, without having to report interim states during execution in the real world. The pathway through the state underway allows longer-running Tasks to be represented as being worked on. The suspended state is used to represent long-running Tasks that have been put on hold, i.e. are not currently being actively worked on, but are still considered to be underway.

The lifecycle states are described by the TASK_LIFECYCLE enumeration below.

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:

In addition, where a Task Plan is driven by an order set, two attributes are provided to record the details:

Lastly, the workflow_id attribute defined in ENTRY may be set within INSTRUCTION and ACTION to refer to the Order Set instance used in this Task Plan, if set.

A sequential Task Group corresponds to a single thread of processing at execution time, in which each of the Tasks becomes available to the worker (i.e. Task Plan’s principal_performer) in order, and according to the specific conditions associated with each Task. The following illustrates a sequential Task Group in TP-VML. Note that although there is visually an end-group icon (right hand end), there is no separate class or instance in the model - both the start-group and end-group icons visually represent the TASK_GROUP as a logical container.

The parallel Task Group represents a different degree of complexity, since it enables concurrent threads of work at execution time. In terms of YAWL and Petri net workflow theory, a parallel Task Group corresponds to paired split and join points. The following illustrates a parallel Task Group in TP-VML. The multi-point shape of the exit and entry elements is intended to convey the idea of multiple possible branches (the limitation of 3 points is purely visual, semantically, any number of branches is supported).

The first difference between a parallel Group and a sequential one is that when a parallel Group is arrived at in the control flow, once any wait state is satisfied, the first Task in all of the outgoing branches is made available. Subsequent execution behaviour depends on the type of split and join logic (i.e. AND, OR, XOR, or other) which is represented by the attribute TASK_GROUP.concurrency_mode, whose possible values indicate to the execution engine three things:

Here, the notion of 'completion' corresponds to the completed state in the Task lifecycle state machine described earlier, inferred from the completion states of the items in the branches. The detail of how Task Group lifecycle state is aggregated from contained items is described in detail in Section 7.3. Here we describe only the logic determining the completed state, for the sake of simplicity.

The AND case is the simplest, since there is no conditional processing - all paths must be followed. An AND Group essentially represents work that should be performed, but for which the ordering is more relaxed than for a strict sequential Group.

The XOR case represents a 1/N choice, and is understood in this specification as representing the intent that only one path can sensibly be followed, usually because the branches are mutually exclusive alternatives in reality. Consequently, in execution, an XOR Group is processed such that as soon as one branch is chosen by a performer transitioning a Task from the available state, the first Task in all remaining branches is transitioned to cancelled, effectively cancelling the non-chosen branches. In this case completion is also trivial to determine.

However the OR case is more complicated. A minimal interpretation of 'OR' logic is that as soon as one branch in the Group completes, the Group is considered completed, and no more Tasks from other branches are available to perform. A maximal interpretation is that Group completion is achieved only when every path commenced completes. The model represents these two cases explicitly, via the values or_first_completed and or_all_started respectively of TASK_GROUP.concurrency_mode.

The following table summarises the semantics of the four concurrency modes.

The parallel / concurrent semantics attached to the Task Group do not indicate anything about decisional processing, i.e. the conditions that might be used to choose outgoing paths from the split point represented by a Task Group in the XOR and OR logic cases. Consequently, the choice of path(s) to follow in the parallel case is determined by the performer, not the system. In order to specify conditions on paths, the conditional subtypes described below are used.

Task Groups of sequential and parallel types may be mixed in a hierarchical fashion. One structure is such that the overall work of a Task Plan is defined as a sequential Group in which some members are a parallel Group, as shown below.

Similarly, the outermost Group may be parallel, with the work being defined as sections of sequential work situated within a parallel Task Group, as shown below.

The combination of the Task Group / Task hierachical pattern, which implicitly defines the graph structure of the 'normal flow' of a Task Plan, and the generic control attributes defined on TASK and its descendant types enable a significant amount of execution-time Plan processing to be implemented independently of any specific Task semantics.

A significant consequence of the Task Group construct in the TP model is that each Task Group forms a sub-network within its container, where a network is understood in the graph theory sense of a directed graph with a start s and terminal node t, containing paths from s to t n which all member elements are found. This holds for descendant types of TASK_GROUP, including the Decision Structures described below. This is a more limited form of connectivity than allowed in YAWL or BPMN, which do not require matched split and join points.

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.

Tasks are represented by the TASK class whose two concrete sub-types distinguish the two basic flavours of Task, namely dispatchable and performable. TASK is a generic (i.e. templated) class, whose generic parameter is constrained to the type TASK_ACTION, the latter of whose subtypes defined the particular kinds of Tasks available.

The DISPATCHABLE_TASK<T> 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 state that is triggered on receipt of a callback. How callbacks function in detail is described below.

There are some key differences between the two kinds of Task as shown in the following table.

The type DISPATCHABLE_ACTION is the abstract parent of various Action subtypes that represent work requested to be done by some other agent, i.e. external to the current Task Plan. The three sub-types correspond to 3 different types of other performer, i.e.:

The general execution scheme for such Actions is as follows:

The following sub-sections described the various subtypes of DISPATCHABLE_ACTION, while callbacks are described in detail further down.

In order for performers to execute Task Groups and individual Tasks within a Plan, specific data must often be reviewed to enable the performer to proceed. This is generally the case for Tasks that involve administering drugs to a patient, where the dose depends on one or more variables relating to the patient state, such as ECG data, INR, heart rate etc.

To achieve this, the Task Planning model formalises the relationship between a 'data set' and a Task that may use it. A 'data-set' in openEHR is a template, normally displayed as a form within an application. In the Task Planning context, a data set may also be a sub-section of a template or form, specified by a path, to allow more than one Task to be used to construct each section of a form. The following UML diagram shows the data-set related classes in detail.

Two variants of data-set are defined, as follows:

Either a template or form identifier (or both) maybe be used to specify a data-set. The populating_call attribute may be used to define a system call that will pre-populate either kind of data-set. The form_section_path attribute is populated if a data-set section (i.e. part of a form) needs to be specified.

A review data-set may be specified on any Plan Item (i.e. Task Group or Task, of any kind) via the attribute PLAN_ITEM.review_dataset, in order to signal to the runtime system to request the display of data at the start of that part of the Plan.

A capture data-set may be specified for a PERFORMABLE_TASK only (since the work of the Task in this case is what achieves the desired data capture), via the capture_dataset attribute.

For reference, any review data-set may have any number of capture data-sets used to capture the data associated with it, via the REVIEW_DATASET_SPEC.capture_datasets attribute. This enables the relationship between potentially numerous (typically small) forms/dialogs used to obtain data from users and the commonly larger forms used to display such data.

Both kinds of data sets described here may be the same as or related to templates and/or forms used in the generation of Task EHR data, mentioned in PERFORMABLE_ACTION.prototype.

Where Tasks involve data entry as part of the work, the data capture may occur over more than one Task, to be committed at some final Task when the data-set is deemed complete by the user. To support such progressive data capture, the notion of a commit group is used. This is an identifier for a logical data-set that might be entered in one or more forms over a number of Tasks. It is formally represented by the optional commit_group attribute in CAPTURE_DATASET_SPEC, of type DATASET_COMMIT_GROUP. To represent a progressively entered data-set, an instance of this type is used on each Task contributing to the data-set (need not be contiguous), with all but the final instance having the Boolean attribute completion_step set to False. The final Task in the series is marked by setting this flag True, at which point the execution engine may perform a standard commit action. The following diagram illustrates a typical instance of this structure.

Most Task Plans include decision structures, in which one of multiple branches may be taken depending on specific conditions. There are four varieties of such structure, which are defined as specific descendants of the TASK_GROUP class, as shown in the following UML model.

The CHOICE_GROUP class defines the essential semantics for all conditional structure types, which is that they conform to a parallel (execution_type is constrained to parallel), XOR-logic (i.e. single path) concurrency model, as indicated by the class invariants. In traditional workflow processing, any instance of a CHOICE_GROUP is thus logically an XOR gate.

The specific sub-types are based on the design principles described earlier, which distinguished both different conditional structural types, and three different levels of system support, i.e. 'automated', 'decision support' and 'ad hoc'. The combination of structural types and levels of system/user interaction levels is realised in terms of variations on the CHOICE_GROUP and CHOICE_BRANCH classes shown above, which define a generic notion of a decision point from which multiple branches emanate. The variations in system support manifest as follows.

In the override and adhoc cases, a justification may be provided at execution-time for having overridden or made a particular adhoc choice. This is represented in the materialised model, and therefore does not appear in the definition model.

The three fully defined decision patterns are described below.

The first 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. A final 'else' branch may be defined using a CONDITION_BRANCH with an expression representing the True value. At execution time, the branches are evaluated in order, in the manner of an if/then/else structure.

The following diagram shows a typical condition structure.

The second pattern 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. As with the Condition Group, the branches are processed in the order stated in the definition, which allows overlapping value constraints on successive branches. A catch-all 'else' branch may be represented as a DECISION_BRANCH with an open value_constraint (i.e. matching all values).

The following diagram shows a typical decision structure.

The final 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.