openEHR logo

Task Planning Information Model

Issuer: openEHR Specification Program

Release: latest


Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: task, planning, EHR, EMR, reference model, openehr

openEHR components
© 2017 - 2017 The openEHR Foundation

The openEHR Foundation is an independent, non-profit community organisation, facilitating the sharing of health records by consumers and clinicians via open-source, standards-based implementations.


image Creative Commons Attribution-NoDerivs 3.0 Unported.



Amendment Record

Issue Details Raiser Completed

R E L E A S E     1.1.0


SPECRM-58. Major rewrite, incorporating structure, parallelism, execution history.

T Beale

05 May 2017


SPECRM-58. Initial writing.

T Beale, B Naess, I McNicoll

26 Jan 2017


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

  • DIPS, Norway

  • Marand d.o.o., Slovenia

  • Ars Semantica, UK


  • 'openEHR' is a trademark of the openEHR Foundation

1. Preface

1.1. Purpose

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:

  • Standards bodies producing health informatics standards;

  • Academic groups using openEHR;

  • The open source healthcare community;

  • Solution vendors;

  • Medical informaticians and clinicians interested in health information.

  • Health data managers.

Prerequisite documents for reading this document include:

Related documents include:

1.3. Status

This specification is in the DEVELOPMENT state. The development version of this document can be found at

Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:

TBD: (example To Be Determined paragraph)

Users are encouraged to comment on and/or advise on these paragraphs as well as the main content. Feedback should be provided either on the technical mailing list, or on the specifications issue tracker.

1.4. Conformance

Conformance of a data or software artifact to an openEHR Reference Model 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, automated derivations from the Reference Model, ITS conformance indicates RM conformance.

2. Background

2.1. Functional Needs

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'. The general concept is usually known as a task list, and is used to concretely specify actions to be performed by actors (usually human, but potentially machine as well) providing care.

A list of planned tasks need not all relate to a single order, or indeed any order. The general picture is that a task list 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 lists 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.

The model described here considers task lists as the lower part of an overall information architecture that includes entities at multiple cognitive levels, i.e.:

  • care pathway - a model of a guideline for care of a condition / ideal patient;

  • care plan - a general plan for care of an actual patient, taking into account zero or more Care Pathways and individual specificities;

  • task list - a concrete concept that defines a list of fine-grained planned tasks to perform over time to achieve a particular goal.

The model described here does not address the representation of the care pathway or care plan levels, only the task list level. It does however assume that a task list 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' thus denotes the definition of an action to be performed, and 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, OBSRVATION or potentially other Entry sub-type, unless otherwise stated.

2.2. Execution Paradigm

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 lists) 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 list facility described in this specification is relatively simple compared to some workflow tools, we can nevertheless distinguish the following entities in the environment:

  • computing environment:

    • work plan definition: a reusable definition of work to be done, consisting of tasks, potentially standardised according to a guideline or protocol;

    • work plan instance: a run-time instance of a task plan, potentially with local variations, created for execution by an actor or actors;

  • real world:

    • performing actor, i.e. a human, machine or software application that performs tasks in the real world as part of a procedure designed to achieve a goal;

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:

  • commands: signals from the work plan system to a real world actor to do something;

  • notifications: signals to and from the work plan system and the real world actors on the status of work, e.g. 'new work item', 'item completed' etc;

  • data: data collection from actors and presentation to actors from the system.

This environment can be illustrated as follows.

workflow execution paradigm
Figure 1. Work plan execution paradigm

3. Requirements

A number of commonly occurring requirements that can be addressed via the Task List concept are described below.

3.1. Planned Tasks for an Order

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 list, each task of which which can then be performed and signed off by a staff member, e.g. a shift nurse. The task list 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 order is effectively open-ended, i.e. it has no intended completion. This might be because the patient condition being treated is chronic, e.g. an insulin or Salbutamol (Ventolin) order; 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 victim.

3.2. Order Sets and Protocols

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

Drug Standard [R]-CHOP-14 or
[R]-Maxi-CHOP Mode Days


375 mg/m²

375 mg/m²

IV infusion

Day 1


750 mg/m²

1200 mg/m²

IV infusion

Day 1


50 mg/m²

75 mg/m²

IV bolus

Day 1


1.4 mg/m² (max. 2 mg)

2 mg

IV bolus

Day 1

(P)rednisone or (P)rednisolone

40 mg/m²

100 mg

PO qd

Days 1-5

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

3.3. Lookahead Plan

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.

3.4. Checklist & Sign-off

If a task list 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 list. 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.

3.5. Teamwork and Notifications

There are at least two possible situations in which a task list might need to refer to another task list. The first is a consequence of the standard problem of the fractal nature of description of phenomena. Applied to planned actions, it is clear that 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 list, and to be able to refer to it from another task list. The general case is that any task that could be represented by a single item in a task list could also be represented by a reference to a separate detailed task list.

A second situation in which a task list might refer to another is where a team of actors performs the work, and each task list corresponds to a single actor. A typical example is acute stroke management, in which various healthcare professionals do the work. Coordination occurs when some workers inform other(s) of task completion, and/or wait for notification of completion of someone else’s task.

We can summarise these requirements as follows:

  • drill-down reuse: a task list for a given actor can refer to another self-standing task list for the same or a different actor;

  • notify completion: it should be possble for completion to be notified for tasks in a task list; where applicable the system should be able to generate notifications to other workers as required by a more general coordinated care plan describing a team-based procedure;

  • wait for completion: a task list should be able to include a task that stands for awaiting notification of completion of another task by another actor.

3.6. Task Grouping, Optionality and Execution Basis

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 list 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 list 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 list 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 list itself as a outer group of tasks for which either sequential or parallel execution can be specified.

3.7. Changes and Abandonment

Inevitably, some task lists 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:

  • cancellation of an entire task list that has been posted to the EHR or a 'planning buffer' if one exists;

  • cancellation of a particular task on a list ahead of time, with a reason;

  • marking a task as 'did not perform' after the planned time has passed, with a reason.

3.8. Rationalising Unrelated Task Lists

It is assumed that at any moment there could be multiple task lists 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 lists 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 lists as part of interfacing with or constructing a 'patient diary', i.e. rationalised list of all work to be done involving the patient.

3.9. Support Process Analytics

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:

  • time of execution - this will almost always be different, even if only by seconds;

  • performer - a task intended to be performed by a specific type of actor (say a nurse) might be performed by another (say the consultant);

  • any other modifiable detail of the order, e.g. medication dose in bedside care situations.

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.

3.10. Support for Costing and Billing Information

It should be possible to record internal costing data against task lists as a whole, and also individual tasks. Additionally, it should be possible to attach external billing information to tasks and task lists. 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.

4. Design Principles

The design approach adopted here is based on a number of ideas. Firstly, it addresses only the 'Task list' level of the three conceptual levels mentioned earlier, leaving Care Plan and Care Pathway (guideline) to be addressed elsewhere. The other design elements are described below.

4.1. Phases of Work

The design uses the notion of three potential phases of clinical work, namely 'ordering', 'planning', and 'performing'. Orders are a common way to generate tasks, but are not the only way, and many tasks are generated from a protocol or guideline or ad hoc. Corresponding to these phases, there are three possible levels of representation, the first and last of which already exist in the basic openEHR ENTRY model, as follows:

  • Order: statement of an order, if one exists, expressed in a formulaic way, e.g. corresponding to "Amoxicillin 3 times a day, orally, for 7 days";

    • represented in openEHR with the INSTRUCTION type;

    • statement of order-related actions to be performed in the future, usually expressed in a compressed algorithmic way that requires further interpretation by the performing agent to determine when individual actions occur and their details;

  • Planned task: representation of a single executable task in the order, to be performed in the future e.g. 'give 1 Amoxycillin oral tab at lunch';

    • statement of each action to be performed in the future, expressed in a direct way as to a performing agent such as the patient or a nurse;

  • Performed task: statement of the action that was actually executed by the performer, in the past, e.g. 'gave 1 Amoxycillin tab at 13:37';

    • represented in openEHR using the types ACTION, OBSERVATION etc.

    • statement of actions, observations etc that were carried out in the past; may include different details from the Planned task.

There may be a non-trivial relationship between each form of expression, as suits its different purpose: expressing an order; directing personnel to perform tasks; documenting what was done after the fact.

The model described here adds the second level of representation, which enables fine-grained lists of executable tasks to be explicitly stated and therefore stored in the EHR, displayed, and signed off.

We can visualise this conceptually with a modified version of the Clinical Investigator process diagram as follows:

clinical process planning
Figure 2. Clinical Investigator Process with Planning

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

4.2. Fractal Structure

In reality, almost every Task can be sub-divided into a smaller set of Tasks. In addition, some sets of Tasks can be performed without regard to order - i.e. in parallel - while others must be ordered. This specification accordingly supports this hierarchical structure via three structural artefacts, namely Task List, Task Group and Task. These follow naturally from the requirements above, but we need to articulate the semantics of these concepts, as follows:

  • Task: a small, separately performable unit of planned work that typically corresponds to:

    • the finest level of clinical responsibility, e.g. nurse administration of a drug, single observation of patient vital sign etc;

    • the finest level of re-imbursement / billing;

    • granularity of check-list and protocol single items, designed to be signed off as performed;

    • a particular planned time of execution;

  • Task Group: a group of Tasks within a Task List that are to be executed on some basis, e.g. sequential, parallel;

  • Task List: a logical list of Tasks whose execution is intended to achieve completion of a coarse-grained task or goal with respect to a particular subject of care, typically an intervention such as a course of medication or other therapy. May contain Task Groups.

    • Any Task Group or Task may be marked as optional or mandatory for execution.

    • Since a Task List is intended to achieve a purpose, it is assumed to have a lifecycle whose states indicate where its execution is with respect to the outcome. See below for a full explanation of the Task List lifecycle.

    • It is assumed that any number of Task Lists could be active for a given subject of care at a given moment.

The consequence of the above is that a Task List is in general a hierarchical structure consisting of Task Group nodes and Task leaves. This enables grouping of particular Task subsets, and also the fine-grained specification of execution ordering.

4.3. Single Subject, Principal Performer

A key design assumption is that a Task List is targetted at single subject and allocated to a principle performer, that is to say, a single logical actor. This is often a single person (or a device or possibly a software service, e.g. a CDS model of which questions can be asked), but might equally be a group of personnel, e.g. ward nurses, who execute the steps of a Task List during and across shift boundaries (wound dressing, turning patients, IV maintenance etc). In these cases there is an understanding by separate individuals that they constitute a common workforce with respect to the subject of care, for any given planned piece of work.

The principal performer can accordingly be specified in terms of a professional role, and optionally a specific agent. This might even in some cases be the patient.

In addition to the principal performer, other participations can be specified for the Task List or any contained step. However it is assumed that the principal performer is responsible for all actions, and is also the notifier of action completions and cancellations, as well as the target of notifications to do with linked Task Lists.

The consequences of this design principle are twofold:

  • where a team of executing actors is required to perform a logical clinical procedure, each distinct actor has his or her own Task List;

  • for a team to operate together, coordination is required between the Task Lists and relevant actors. This is described below in more detail.

4.4. Separation of Task Definition and Execution State

A Task List is essentially a definition of work to be done, or more precisely, an instance of a definition of work. When the work has been performed, the results are documented with openEHR Entries, such as Actions and Observations. However, there is usually a need to track the progress of the work between commencement and completion (or cancellation). Based on the model, it is possible to track:

  • Task execution events, which can be understood as state transitions in a notional state machine with states such as 'planned', 'completed', 'cancelled' etc;

  • Notifications to other actors of Task events, usually completion;

  • Receipt of notifications from other actors, which enable waiting Task(s) to proceed.

It would be possible to track state by representing it in the Task List definition, and relying on versioning of successive commits of each update to provide the execution picture over time. However, this is not likely to correspond to the needs of the EHR, or workflow processing that occurs as the work is performed. In the former case, the execution of a non-trivial Task List may result in hundreds of state changes, notifications, etc, which will result in a similar number of commits to the EHR. This may be mitigated by only committing at certain points in time, but then the history of progress is lost.

On the other hand, a workflow application whose job is to use Task Lists to support work being undertaken by clinical personnel does need to carefully track the history of updates, in order to know which Tasks have been done, and which have not. Since this will often occur over multiple work shifts and/or long periods (up to two weeks for some chemotherapy), persistence is required.

The approach taken here is therefore to include in the model an explicit 'execution history ', which includes every change event during progress of the actors performing the work, as an attachment to the Task List, rather than to include state within each Task. This provides a means of separation of Task List definition from Task List execution state, and enables persistence of the two parts to be handled in flexible ways that suit particular environments.

5. Task Planning Model

5.1. Overview

The following figure shows the rm.composition.task_planning package, including its relationships to existing classes.

RM composition.task planning
Figure 3. rm.composition.task_planning package

5.1.1. Compositions and Versioning

In this model a TASK_LIST inherits from CONTENT_ITEM, the abstract type of the content attribute of a COMPOSITION. A TASK_LIST and its constituent TASKs are assumed to be created within a singsle dedicated COMPOSITION which is re-versioned as changes are made to its contents. The causes of change include:

  • changes to the definition, due to error correction and / or extension of the lookahead planning window;

  • updates to Task lifecycle states at execution time;

  • additions to the execution history, corresponding to each Task or List level event, including completion or abandonment of the Task list.

As the TASK_LIST gets progressively built and executed over time, its owning COMPOSITION will undergo numerous changes, corresponding both to changes to the plan, and also execution of the actions performed to fulfill it. Typically only the former will generate new committed versions to the EHR, whereas the latter will most likely only be used by the workflow application during execution of the Task List. How changes to Task List are versioned and added to the EHR (or not) can be handled flexibly according to local needs.

5.1.2. Basic Semantics of a Task List

In the model, a Task List is specified by a number of key attributes, following the design principles described above, namely:

  • subject: the subject of the work (i.e. 'case' in workflw parlance), typically a single patient;

  • principal_performer: a definition of the responsible performer, normall in terms of role plus function;

  • description: natural language specification of what the Task List is for;

  • care_plan: a reference to a driving Care Plan, if any exists;

  • guideline_id, care_pathway: references to a guideline and/or care pathway.

  • training_level: a value that can be used to filter out fine-grained Task Lists in a chained structure only of interest to trainees;

These are described in more detail below.

5.1.3. Containment Structure

The set of Tasks in Task List is represented within a containment structure created using instances of the TASK_GROUP type. This provides a way of grouping Tasks that will be executed collectively on the same basis, via the execution_type attribute, which may be set to sequential or parallel. This includes the top-level set of Tasks. A TASK_GROUP instance is treated as a member of its enclosing TASK_GROUP in the same way as constituent TASK instances, and shares with the latter attributes for Task description, timing, and conditions for execution.

The following illustrates the Task group structure.

task grouping
Figure 4. Task grouping

5.1.4. Basic Semantics of a Task

The important semantics of the Task concept in the model are specified in the TASK_LIST_ITEM class, with further specifics appearing in the TASK_GROUP and TASK descendants. Key attributes of a TASK_LIST_ITEM include:

  • description: natural language specification of what the Task is;

  • preconditions, wait_conditions, execution_time: operational conditions for determining if a Task is ready for execution by a performer;

  • indications: clinical conditions for the Task being applicable;

  • notifications: specfication of coordinating notifications to be sent to other performer / Task contexts;

  • costing_data: fine-grained data to enable cost determination of work performed;

  • other_participations: participations other than the principal performer.

Each of these are explained in detail below.

5.1.5. Task Types

As mentioned in the requirements section, the granularity of a Task can be variable from one healthcare context to another, as per the cannulation example. This leads to two possibilities:

  • atomic representation: a Task that may in reality consist of several fine-grained steps may be represented within a Task List as a single Task, on the assumption that the performer will correctly determine how to execute it;

  • reference to composite representation: the currently executing Task List may refer out to another Task List containing numerous sub-tasks representing the detailed work of a particular Task in the original list.

The model described here thus makes no a priori assumptions about granularity of representation of a given real-world task, and both representations are possible. This first kind is thus represented as an instance of the class DEFINED_TASK, while the second is achieved with the use of an EXTERNAL_TASK which refers out to another TASK_LIST to be executed by the same performer.

The second feature gives rise to the possibility of a hierarchy of linked Task Lists, with each successive member in the chain representing a more detailed form of a given real world task. This can be visualised as follows.

task linking
Figure 5. Task list linking

A structure like the above may be used differently by performers of differing training levels - since each EXTERNAL_TASK has its own description, an expert user may reqire no further list of steps, but a trainee might make use of the full hierarchical structure. The training_level attribute on TASK_LIST can be used to control this. A higher value corresponds to a lower level of expertise, and different values can be set on different linked TASK_LISTs. The workflow application may treat different users as being of different training levels, in which case Task Lists of higher training levels can be hidden. The default value of training_level is 0.

5.1.6. Task Definition

The job of specifying the work to be done in a concrete (i.e. inline) Task definition is achieved via the DEFINED_TASK atttribute prototype, of type ENTRY, which enables a Task to be specified in terms of an instance of a descendant of the ENTRY class. This is typically an ACTION instance but could be an OBSERVATION, ADMIN_ENTRY or other descendant.

The attribute is called 'prototype' because the target Entry instance is understood as a partially populated, prototype 'planning time' copy of an Entry that will actually be created when the Task is actually performed. For example, a Task List for administering medication at 8 hourly intervals over a number of days could consist of a number of DEFINED_TASKs, each having a protoype of an ACTION instance based on the openEHR-EHR-ACTION.medication.v1 archetype or a templated version thereof. Each such instance would contain the structured description of the medication administration and time, and when the administration was actually performed, an ACTION instance would be created from the prototype, modified to reflect any divergence from the planned form of the Task, and committed to the EHR in the normal way.

The following illustrates Task definitions using prototypes.

task definition
Figure 6. Task definition

Assuming that the Task List is archetyped in the same way as Entries and other elements of the EHR, this scheme supports various modes of design-time specification. The prototype attribute in a TASK_LIST archetype will usually be represented by an archetype slot or external reference, which specifies identifiers of permitted archetypes (or templates) of the target type, i.e. ACTION or other Entry. This can be used in various ways, as follows:

  • external reference: specifies a fixed archetype identifier which will be substituted in the templated form of the Task List. This has the effect of creating ACTION or other prototype instances in the TASK_LIST structure;

  • archetype slot: specified using a slot constraint that is satisfied by one or more archetypes that may be specified by a template, or left open until runtime.

In the latter case, the slot may be filled in the Task List template with an ACTION or other Entry archetype, allowing the Tasks to be fully specified inline as in the external reference case. Alternatively, it may be left unresolved, which would allow the workflow application to choose the exact Task definition archetype at runtime.

One reason to allow a Task to contain a prototype reference that remains unresolved until runtime is if the Task represents the act of making an observation, for example, taking a blood pressure. In such cases, no prototype at all may be needed, and the Task description attribute (inherited from TASK_LIST_ITEM) may be sufficient information for the performer. On the other hand, a prototype OBSERVATION could be specified in the TASK_LIST template, which defines a particular form of the observation, e.g. a blood pressure which only records systolic pressure and cuff size.

To allow further flexibility, The multiplicity of the prototype attribute is unlimited, to allow for the possibility of one Task being prototyped by more than one Entry instance, e.g. an ACTION and an OBSERVATION, two ADMIN_ENTRY instances and so on.

A related question has to do with the granularity of Tasks with respect to the granularity of resulting ACTION, OBSERVATION and other EHR Entries. The model makes the assumption that one Task, if performed, refers to and is documented by one ACTION or other archetyped ENTRY.

ISSUE-task-entry-corr: the alternative seems to be to allow a Task to correspond to e.g. a whole Composition template, where the COMPOSITION contains a number of e.g. ACTIONs or OBSERVATIONs. Problems I see with this: a) who knows what is in the Composition template? It may change over time; b) what if only some of the items in the Composition template can be done? Is the Task half complete? Or should the performer not do any of it?

5.1.7. Coordinated Teamwork

Performing teamwork in a coordinated fashion with task planning support necessarily requires multiple Task Lists - one for each actor, and a means of coordination among them. This is achieved by the use of two special types of object that can be attached to a TASK_LIST_ITEM (i.e. any Task group or Task):

  • notifications: notifications that should be issued on a specific Task execution event, e.g. commencement, completion etc;

  • wait_conditions: conditions that specify external Task events to wait for, i.e. completions or other events performed by other actors in related Task Lists.

These two attributes enable both directions of communication between any two actors working in a coordinated workflow to be expressed. The following illustrates, using the example of an acute stroke management care process.

task coordination
Figure 7. Task coordination

5.1.8. Class Descriptions TASK_LIST Class




Logical list of Tasks in a structure defining order and conditions of execution of items of work intended to achieve a goal. A Task List consists of a top-level TASK_GROUP containing TASK_LIST_ITEMs, which are either atomic TASKs or more TASK_GROUPs.

A Task List specifies a principal_performer, representing a kind of actor who can perform the Tasks, and bounding start_time and completion_time information.

It has an associated execution_history that can be used to record work events in time.

The attributes care_plan and guideline_id provide a way of associating a Task List with an operational care plan, and also a published guideline or protocol on which the Task List may be based.







subject: PARTY_PROXY

Optional indicator of subject of Task, which is normally the subject of the EHR. If this is not the case, this attribute states who the Task is to be performed on.



Nominal start time for the Task list as a whole. The timings of individual Tasks may be specified as offsets from this time, via PLANNED_TIME.relative_offset.


completion_time: PLANNED_EVENT_TIME

Maximal completion date/time by which this Task list should be considered obsolete. If not set, the Task list would normally be inferred to be obsolete after a discharge from acute care, but in primary or social care situations, no value may be assumed to indicate that the Tasks are still to be performed, depending on the times specified in the execution_time attribute of TASKs in the list.


description: DV_TEXT

Human-understandable description of the Task list, which may be specific to the work items and patient.


care_plan: LOCATABLE_REF

Care plan object from which this Task list is derived.


principal_performer: TASK_PARTICIPATION

Specification of principle performer of this Task List as a Participation, typically with role and function set.


guideline: DV_IDENTIFIER

Identifier of guideline on which this Task List is based, if such exists. A 'guideline' is understood here as a published standard for performing a detailed Task.

It is currently assumed that there is no reliable machine identifier system for guidelines. A DV_IDENTIFIER allows things like:

  • issuer = "NICE";

  • id = ""

  • type = "NHS guideline for Atrial fibrillation: management"


definition: TASK_GROUP

The Tasks for this Task List.


execution_history: EXECUTION_HISTORY

History of execution events for an execution of this Task List.


care_pathway: DV_IDENTIFIER

Identifier of care pathway etc, on which this Task List is based, if such exists. A 'care pathway' is understood here as a published standard for performing care for a major condition or presenting complaint, e.g. sepsis, MI etc.

It is currently assumed that there is no reliable machine identifier system for care pathways. A DV_IDENTIFIER allows things like:

  • issuer = "NICE";

  • id = ""

  • type = "NICE Sepsis care pathway"


training_level: Integer

An integer value representing the training level for which this Task List is designed. A high value corresponds to a lower level of expertise. The default value is zero.




lifecycle_state: TASK_LIFECYCLE

Lifecycle state of Task List, derived as a copy of the lifecycle_state() of the top-level TASK_GROUP. TASK_PARTICIPATION Class




Class defining a participation in Task(s), minimally in terms of function. Optionally, the role and mode may also be specified. The performer attribute enables a specific actor to be specified.







function: DV_TEXT

The function of the Party in this participation (note that a given party might participate in more than one way in a particular activity). This attribute should be coded, but cannot be limited to the HL7v3:ParticipationFunction vocabulary, since it is too limited and hospital-oriented.


role: DV_TEXT

Organisational role, i.e. the professional type of participant in the activity. Preferably coded.



Optional field for recording the 'mode' of the performer / activity interaction, e.g. present, by telephone, by email etc.


performer: PARTY_PROXY

The id and possibly demographic system link of the party participating in the activity.


optionality: VALIDITY_KIND

Condition for participation in the Plan item. PLANNED_EVENT_TIME Class




Represents a time or time interval at which a single future event or action should take place.

TODO: probably need an option for coded times like 'afternoon', 'midday' etc.

ISSUE-generic-planned_time: The class PLANNED_TIME should probably be made generic and added to the BASE component. Needs to take into account some of the other models of time specification. See e.g. openEHR-EHR-CLUSTER.timing_daily.v0.0.1 for other design concepts.





execution_time: Interval<Date_time>

Time window during which the action should start. May be a point time or an interval. If set, relative_offset and relative_time_qualifier are not set.


relative_offset: Duration

Relative time offset with respect to origin nominated in relative_time_qualifier.


relative_time_qualifier: DV_CODED_TEXT

Indicates what time origin to use for this action in terms of other actions. May take values such as:

  • with_previous: at the same time as the previous action in a list; order is assumed not to matter;

  • after_previous: after the previous action in a list, by the offset duration if any;

  • after_start: after the start of the list, by the offset duration if any.


event_alignment: DV_CODED_TEXT

A qualifier that indicates that the action should be aligned with a real world event. Typical values: before_meal, with_meal, after_meal, before_sleeping, etc. TASK_LIST_ITEM Class


TASK_LIST_ITEM (abstract)


Abstract parent of any type of the TASK_LIST member types TASK_GROUP and TASK.

Supports definition of optionality, pre-conditions, wait conditions, indications and notifications with any Task Group or Task.

Provides a place to record fine-grained costing data.

Informal other participations can also be recorded for any Task Group or Task, although these do not replace the Task List principal_performer.







other_participations: List<TASK_PARTICIPATION>

List of participations for task item.


task_group_id: Integer

Integer indicating the ordinal number of this Task within its Task group. Used for referencing from other objects. Required to be unique with respect to other siblings in the same Task group.

Identification of any Task in a Task list is done using paths of the form /task_group_id/task_group_id.


description: DV_TEXT

Human-readable form of the task directive.


costing_data: TASK_COSTING

Costing data related to this Task item.


preconditions: List<TASK_PRECONDITION>

Condition which must be met for the PLANNED_TASK to be available in a runtime execution context.


indications: List<DV_TEXT>

Causal drivers or applicability of this Task item to subject of work, e.g. 'pregnancy', 'lymphoma' etc. May be derived from a governing guideline. May be displayed as a safety precaution to human performer.


notifications: List<TASK_NOTIFICATION>

List of notifications to be generated on a state change of this Task during execution.


wait_conditions: List<TASK_WAIT_CONDITION>

Set of wait conditions for this Task, expressed in terms of external actors and Tasks that need to complete before this Task may be commenced.


optionality: VALIDITY_KIND

Condition of execution (typically according to governing protocol): mandatory | recommended | optional | expression .


other_details: ITEM_STRUCTURE

Archetypable structure for recording non hard-modelled information.


execution_time: PLANNED_EVENT_TIME

Optional specifier of time at which the Task of Task Group should be performed. If not provided, the Task is assumed to be available to perform immediately following completion of the previous members of the parent Task Group.

The Task may be performed earlier or later than this time; it is understood as a guide only. TASK_GROUP Class




Grouping structure that defines the execution basis for a collection of Tasks, which may include more Task groups.

The execution_type attribute defines the mode of execution. If not set, sequential execution is assumed.







members: List<TASK_LIST_ITEM>

Set of Tasks to perform. Sequencing is either the natural order of the tasks list, or may be controlled by


execution_type: EXECUTION_TYPE

Basis for executing the Task items contained in this Task Group.




lifecycle_state: TASK_LIFECYCLE

Effective lifecycle state, computed from the states of members of the group. EXECUTION_TYPE Enumeration




Enumeration specifying types of execution for a set of Tasks.





Items execute in order, one after the other.


Items may be executed in parallel, with no regard to order in the representation. TASK Class


TASK (abstract)


Abstract parent of various types of planned Task, which may be real work items (DEFINED_TASK) or references to another Task List (EXTERNAL_TASK).







lifecycle_state: TASK_LIFECYCLE

Current lifecycle_state of this Task. EXTERNAL_TASK Class




Task type that represents a dispatch to another Task List to be executed by the current performer.







target: TASK_LIST

UID of target TASK_LIST object. DEFINED_TASK Class




Type of Task that represents concrete tasks, i.e. real work items. The definition of the work of the Task is expressed in terms of archetype of an ENTRY (usually an ACTION) that will be used to record the Task’s execution.

The entry_instance attribute can be used to record a forward reference to an ACTION or other ENTRY when it has been recorded.

May be specialised in order to add attributes required by the Task form of specific Entry subtypes, hence, ACTION_TASK etc.







prototype: List<ENTRY>

Prototype instance of one or more Entries that express the Task specifics.

5.2. Conditions for Task Execution

According to the model, a Task is available for execution by a performer if:

  • its preconditions, if any, are met;

  • it is not waiting on any external Task being (i.e. being performed by another actor) to complete;

  • previous Tasks in the same Task List, if any, are in a terminal lifecycle state, i.e. have been completed, cancelled or aborted.

The first two characteristics are represented respectively by the TASK_LIST_ITEM attributes preconditions: TASK_PRECONDITION and wait_conditions: TASL_WAIT_CONDITION.

TBD: To be continued

TASK_LIST_ITEM also includes an optional execution_time attribute which indicates the intended time of execution. This time is understood as a guide, enabling Tasks to be placed on a schedule timeline, and is useful for time-dependent activities such as medication administration. A performer may execute the Task earlier or later than the indicated time.

5.2.1. Class Descriptions TASK_PRECONDITION Class




Conditions expressing when the Task is executable with respect to the principal performer and subject. Coordination with other actors and Task lists are represented as Wait conditions.





description: List<DV_TEXT>

Textual representation of preconditions for this Task to be performed, according to governing protocol. May be displayed as a safety check for human performer.


expression: DV_PARSABLE

In the case that required_status /= mandatory; a Boolean expression that can be evaluated at runtime to determine inclusion. TASK_WAIT_CONDITION Class




Represents a wait state for a notification from an external Actor and Task.

TODO: determine how to formally represent wait condition, and how a workflow application could match it.









Object representing a notification to another party at a defined Task event, e.g. commencement, completion.






The target party, expressed in terms of role and/or function.


trigger_state: TASK_LIFECYCLE

Task lifecycle state that triggers notification.

5.3. Task Execution Tracking

Following the design principle of separation of Task definition and execution state, the model represents the history and state of execution of a Task List as a separate high-level part of the model, via the execution_history attribute of TASK_LIST. The execution of a Task List is represented in terms of a state lifecycle model for each Task, and transitions over time between the states, along with associated information.

5.3.1. Task Lifecycle

Each TASK in a TASK_LIST has a lifecycle consisting of various states it may pass through in time. The lifecycle is simple, since it only has to take account of the states a Task - understood as a task definition - can pass through, with documentation of the Task execution occurring in the form of separate openEHR ACTION or other Entry objects. The states are as follows:

  • initial: initial pseudo-state, not used in operation;

  • planned: defined, but not available for execution;

  • available: available for execution, due to previous Tasks having been performed;

  • cancelled: cancelled prior to being performed;

  • completed: performed to completion;

  • aborted: execution was commenced but stopped before completion.

The corresponding state machine is shown below.

RM TaskStateMachine
Figure 8. Task lifecycle state machine

The state for each Task is recorded in the lifecycle_state attribute.

This is the only execution time related attribute in the Task List definition. If it is necessary to record the final lifecycle states of Tasks in a completed Task List, the TASK_LIST will need to be re-committed to the EHR as a new version in order to achieve this.

Since a Task List is a hierarchical structure consisting of one or more Task Groups, a way of rolling up Task state is needed. The following algorithm is used to compute the effective lifecycle state of a TASK_GROUP from the set of states of its members (which may include other TASK_GROUPs).

// Infer the state of a collection whose members have states in sourceStates.
// The order of if/else evaluation determines the correct result.
TaskState inferredState (Set<TaskState> sourceStates) {
    TaskState inferredStateValue;
    if (sourceStates.contains(Available))
        return Available;
    else if (sourceStates.contains(Planned))
        return Planned;
    else if (sourceStates.contains(Completed))
        return Completed;
    else if (sourceStates.contains(Aborted))
        return Aborted;
    else if (sourceStates.contains(Cancelled))
        return Cancelled;
        return Initial;

Since the Task Group is also the top level structure of the Task List, the inferred state of the List as a whole is also provided by this algorithm.

5.3.2. Execution History

The history of execution events is represented in the class EXECUTION_HISTORY. This is a history of real world execution events that accumulate over the duration of workflow processing of the Task List. Two types of event are used:

  • TASK_EVENT_RECORD: type representing a change to one consitutent Task. Thus, if the performer cancels a particular Task within the list, a TASK_EVENT_RECORD will be added to the history, including Task id, time, and reason; notifications can also be recorded on such events;

  • LIST_EVENT_RECORD: type representing any kind of execution event not linked to a specific Task, for example 'list abandonment'.

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 will clearly grow and might become quite long for some Task List executions. How it may be persisted in various ways. The following possibilities are all compatible with both the model, and typical EHR requirements:

  • In workflow application persistence:

    • persist the full history, delete or archive once the Task List is fully completed;

  • In the EHR:

    • persist the full history in some or all cases, if useful in the EHR environment (e.g. for teaching);

    • persist a partial / filtered version of the history, e.g. retain only cancel and abort events, on the basis that completed Tasks will show up as ACTIONs elsewhere in the EHR;

    • don’t persist any of the history - rely on the workflow application persistence for it during execution, and forget afterward.

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

5.3.3. Class Descriptions TASK_LIFECYCLE Enumeration




Enumeration representing possible lifecycle states for a Task.





Task is planned for the future.


Task is available for execution by performer.


Task was cancelled without commencing.


Task was aborted after commencement, i.e. ended prematurely without meeting normal conditions of completion.


Task was completed in the intended way. EXECUTION_HISTORY Class




History of Task execution events and notifications. May be used by a workflow application to record all events during execution.

May be persisted in the EHR in partial or complete form, or not at all.





task_events: List<TASK_EVENT_RECORD>

Task-level execution time events.


list_events: List<LIST_EVENT_RECORD>

Execution time events that occurred at the Task List level, i.e. not to a particular task. These include events such as Task list abandonment. EVENT_RECORD Class


EVENT_RECORD (abstract)


Abstract parent of types representing execution time events on a Task List.





time: Date_time

Time the event occurred.


description: String

Optional description associated with the event. Would typically be populated for Cancel and Abort events. LIST_EVENT_RECORD Class




Record of an execution time event to a Task List.







details: Hash<String, String>

Other details as a name/value list. TASK_EVENT_RECORD Class




Record of an event for a single Task. Records task identifier, time, resulting lifecycle state and optional reason.







task_id: String

Identification of Task in the Task list structre using a path of the form /task_group_id/task_group_id.


lifecycle_state: TASK_LIFECYCLE

The lifecycle state that was reached due to this event.



Notifications that were performed as part of this Task Event.


entry_instances: Hash<OBJECT_REF,ENTRY>

Forward references to Entry (e.g. ACTION, OBSERVATION etc) that was recorded as a result of this Task being performed. If this is set, it indicates that the planned Task is 'done' i.e. checked off the list.

ISSUE-fwd-refs: entry_instance is a forward reference - which requires updating the Task List after the Tasks have beed performed and relevant Entries committed. Is this complication worth the benefit obtained, i.e. directly followable links rather than querying, to find Entries from the Task List items? Is being able to determine the resulting Entries starting from the Task List even useful? TASK_NOTIFICATION_RECORD Class




Record of a notification to another party (i.e. performer).





reciever: PARTY_PROXY

Identification of the receiver party


receiver_task_list: String

Identifier of receiving Task List.


details: Hash<String, String>

Other details as a name/value list.

5.4. Relationship with other openEHR Artefacts

The model enables a flexible relationship between a Task List and orders, i.e. openEHR INSTRUCTIONs. In simple cases, a Task List will just be the list of Tasks to fulfill one order, i.e. a single INSTRUCTION, such as a prescription for a course of antibiotics. The general case however is that the Task List corresponds to a clinical goal which implicates multiple orders, for example the CHOP chemotherapy mentioned above.

It may also be the case that not every Task is associated with an order. 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). There is also no reason why a Task List 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 List isn’t in general an order, but a guideline or protocol which usually includes orders. In simple cases, no formal protocol is used, and the orders (i.e. INSTRUCTIONs) may be de facto drivers, or the Task List may be created ad hoc, such an in-patient pain medication administration plan by nursing staff. At the other extreme, a Task List may be created with no corresponding orders (and therefore no INSTRUCTIONs) at all.

The following figure shows the correspondences between the various type of openEHR artefact for the general case of Task Lists. The arrows indicate causal relationships.

planning artefacts
Figure 9. openEHR Planning Artefact Relationships

In the above, items in yellow are driven solely by the guideline and have no corresponding order; planned items with a red cross have been cancelled and have no corresponding performed Action or Observation.

One of the side-effects of distinct state machines for INSTRUCTIONs and Task Lists is that not all careflow steps and states in the former need to be represented as Tasks in a Task List. For example, a significant number of careflow steps defined in ACTION archetypes are for non-Active states, i.e. Planning, Postponement, Suspension etc. These steps do not need to have Tasks defined for them, since by definition they are nearly all unplanned.

As a consequence, most Tasks in a Task List correspond only to Active-state careflow steps of constituent order INSTRUCTIONs.

5.5. Cost Tracking

TBD: describe cost tracking.

5.5.1. Class Descriptions TASK_COSTING Class




Costing information for a Task.

TODO: to be developed.

5.6. Transactional Micro-service

The information structures required to represent planned Tasks and references at runtime are likely to be non-trivial. For this reason, a Micro-service is defined, with a transactional interface that converts transactional calls to correct underlying information structures.


5.6.1. Class Descriptions TASK_PLANNING_MS Interface




Task planning micro-service: a service that knows how to create and maintain correct Task Planning information structures.










5.7. Execution-time EHR Structures

The model described here provides significant power when used with openEHR Instructions, Actions and Observations to represent clinical work driven by guidelines and order sets. This section describes the relationship of information instances that correspond to the various phases of work described earlier, as follows:

  • ordering: creation of INSTRUCTIONs;

  • task planning: creation of TASK_LIST(s) representing a plan of individual tasks that achieve the order intention;

  • execution: creation of ACTION and other Entry types that document the Tasks as they were performed.

The model supports logical linking between these items to support workflow traceability. The following figure illustrates both aspects, which are further described below.

planning runtime structures
Figure 10. Runtime planning structures

Various links can be recorded at execution time, as follows:

  • planned Task to Order reference: the TASK_EVENT_RECORD.entry_instances attribute is used to record reverse reference(s) from a TASK to an ACTIVITY within an INSTRUCTION that records a corresponding order, if one exists (shown on the diagram as a logical link from DEFINED_TASK to ACTIVITY instances);

  • planned Task to performed Task reference: the TASK_EVENT_RECORD.entry_instances attribute is used to record a forward reference to the Entry instance that was created when this Task was performed, i.e. some ACTION, OBSERVATION etc (shown on the diagram as a logical link from DEFINED_TASK to ACTION instances);

  • performed Task to planned Task reference: the ENTRY.workflow_id attribute may be used to record a reverse reference from an ACTION, OBSERVATION etc to a causing TASK instance.

6. Scenarios

6.1. Protocol-driven Plan

This section to be rewritten.

The following UML instance diagram shows a partial state of an EHR containing orders and a related Task List. The upper part shows a COMPOSITION containing a number of INSTRUCTIONs that express the orders for Cyclophosphamide, Hydroxydaunorubicin (Doxorubicin), etc, that make up the order set for a CHOP chemotherapy protocol (to be more complete, Rituximab would also be included). It is assumed that the orders contain the correct dosages for the patient, i.e. that they have been calculated in advance for the patient’s body weight, surface area and other specifics. A few elements of an ACTIVITY for the Cyclophosphamide drug are shown here.

In the lower part of the part of the diagram is a COMPOSITION containing a TASK_LIST structure representing the list of work items to perform in order to administer the chemotherapy to the patient. It is assumed that a specialised chemotherapy application has been used to created this structure. The first DEFINED_TASK is shown in some detail, and includes a reference back to the related Instruction Activity, enabling an application to retrieve and display the details of the order. As a precaution, it also has the description attribute set to the value "Cyclophosphamide 1400 mg IV", copied (or generated) from the INSTRUCTION when the TASK_LIST was created. The other attributes of the DEFINED_TASK object indicate when to execute the Task, what professional role should do it (participations), the Careflow step ('administer') and the target state machine state (active).

Each of the DEFINED_TASK protype instances in the TASK_LIST should logically speaking be almost a copy of the ACTION that would result from performing the Task. This is not literally true, since there are fields representing various kinds of links, identifiers and other protocol and care plan information, but for the core information of what to do, and when to do it the instance data for a Planned action should be a tight constraint version of the intended Action to result.

Planning typical instance
Figure 11. Typical Task List - CHOP Chemotherapy

It is worth considering some of the differences between how an order represents the Task and how it may be represented in a DEFINED_TASK and an eventual ACTION. Consider the fourth drug in the CHOP regimen, a choice of Prednisone or Prednisolone. In the form expressed in the order, i.e. the INSTRUCTION, it may be expressed in the following form:

  • administer 80mg orally every day for 5 days

This could be expressed as a single ACTIVITY with the INSTRUCTION.timing attribute set to represent 'once a day for 5 days'.

In the TASK_LIST however, it will be expressed as 5 separate DEFINED_TASK instances, each with an associated prototype ACTION instance. Each of these indicates a single dose for one day. This corresponds to how the drug is actually administered and enables the system (and openEHR data) to represent each action individually, as well as deviations such as not performing one or more of the administrations. The information displayed representing each Task to the human agent will therefore be somewhat different to the form in which it is expressed in the generating order.

However, the order INSTRUCTION could have been created using a series of 5 ACTIVITY objects each representing a single day’s administration. In this case, the form defined in each ACTIVITY is very close to the form required to represent each Task in the Task list.

It is assumed that determining how to populate the details of the DEFINED_TASK is up to an intelligent application that knows the relationship between the relevant orders or order sets, and the exact form of Task lists to implement them.

6.2. Check-list and Sign-off


6.3. Changes during Execution


6.4. Abandonment


7. Implementation Guidance

7.1. Workflow Application Design


7.2. Versioning

The information structures described in this specification may in some cases become non-trivial in size and complexity, and some attention as to when changing states of a Task List are committed to the EHR is likely to be needed. When a Task List is first instantiated, it may be committed to the EHR in order to act as a shared, visible statement of outstanding work, particularly work to be done by teams and/or across shift boundaries. When the work is underway, although it would be possible to commit changes due to changing lifecycle states of each Task, it may be preferable to allow these changes to be tracked only by the workflow application and for the Task List to only be recommitted once completed or abandoned, or possibly at strategic points in time prior to this, for example nursing shift changes.

It does not appear likely that any single rule for when to commit the changed state of a Task List to the EHR can be established for all possible situations, but it is recommended that the commit points are chosen carefully so that their meaning is clear.

Interim commits of a Task List to a persistent store for workflow management or some other application may of course be useful.



  1. [Anderson_1996] Ross Anderson. Security in Clinical Information Systems. Available at

  2. [Baretto_2005] Barretto S A. Designing Guideline-based Workflow-Integrated Electronic Health Records. 2005. PhD dissertation, University of South Australia. Available at

  3. [Beale_2000] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. Available at .

  4. [Beale_2002] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the Customer (Seattle, Washington, USA, November 4, 2002). Edited by Kenneth Baclawski and Haim Kilov. Northeastern University, Boston, 2002, pp. 16-32. Available at .

  5. [Beale_Heard_2007] Beale T, Heard S. An Ontology-based Model of Clinical Information. 2007. pp760-764 Proceedings MedInfo 2007, K. Kuhn et al. (Eds), IOS Publishing 2007. See

  6. [Booch_1994] Booch G. Object-Oriented Analysis and Design with applications. 2nd ed. Benjamin/Cummings 1994.

  7. [Browne_2005] Browne E D. Workflow Modelling of Coordinated Inter-Health-Provider Care Plans. 2005. PhD dissertation, University of South Australia. Available at

  8. [Cimino_1997] Cimino J J. Desiderata for Controlled Medical vocabularies in the Twenty-First Century. IMIA WG6 Conference, Jacksonville, Florida, Jan 19-22, 1997.

  9. [Eiffel] Meyer B. Eiffel the Language (2nd Ed). Prentice Hall, 1992.

  10. [Elstein_1987] Elstein AS, Shulman LS, Sprafka SA. Medical problem solving: an analysis of clinical reasoning. Cambridge, MA: Harvard University Press 1987.

  11. [Elstein_Schwarz_2002] Elstein AS, Schwarz A. Evidence base of clinical diagnosis: Clinical problem solving and diagnostic decision making: selective review of the cognitive literature. BMJ 2002;324;729-732.

  12. [Fowler_1997] Fowler M. Analysis Patterns: Reusable Object Models. Addison Wesley 1997

  13. [Fowler_Scott_2000] Fowler M, Scott K. UML Distilled (2nd Ed.). Addison Wesley Longman 2000.

  14. [Gray_reuter_1993] Gray J, Reuter A. Transaction Processing Concepts and Techniques. Morgan Kaufmann 1993.

  15. [Hein_2002] Hein J L. Discrete Structures, Logic and Computability (2nd Ed). Jones and Bartlett 2002.

  16. [Hnìtynka_2004] Hnìtynka P, Plášil F. Distributed Versioning Model for MOF. Proceedings of WISICT 2004, Cancun, Mexico, A volume in the ACM international conference proceedings series, published by Computer Science Press, Trinity College Dublin Ireland, 2004.

  17. [Ingram_1995] Ingram D. The Good European Health Record Project. Laires, Laderia Christensen, Eds. Health in the New Communications Age. Amsterdam: IOS Press; 1995; pp. 66-74.

  18. [Kifer_Lausen_Wu_1995] Kifer M, Lausen G, Wu J. Logical Foundations of Object-Oriented and FrameBased Languages. JACM May 1995. See See

  19. [Kilov_1994] Kilov H, Ross J. Information Modelling - an object-oriented approach. Prentice Hall 1994.

  20. [Maier_2000] Maier M. Architecting Principles for Systems-of-Systems. Technical Report, University of Alabama in Huntsville. 2000. Available at

  21. [Martin] Martin P. Translations between UML, OWL, KIF and the WebKB-2 languages (For-Taxonomy, Frame-CG, Formalized English). May/June 2003. Available at as at Aug 2004.

  22. [Meyer_OOSC2] Meyer B. Object-oriented Software Construction, 2nd Ed. Prentice Hall 1997

  23. [Müller_2003] Müller R. Event-oriented Dnamic Adaptation of Workflows: Model, Architecture, and Implementation. 2003. PhD dissertation, University of Leipzig. Available at

  24. [Object_Z] Smith G. The Object Z Specification Language. Kluwer Academic Publishers 2000. See .

  25. [GLIF] Lucila Ohno-Machado, John H. Gennari, Shawn N. Murphy, Nilesh L. Jain, Samson W. Tu, Diane E. Oliver, Edward Pattison-Gordon, Robert A. Greenes, Edward H. Shortliffe, and G. Octo Barnett. The GuideLine Interchange Format - A Model for Representing Guidelines. J Am Med Inform Assoc. 1998 Jul-Aug; 5(4): 357–372.

  26. [Rector_1994] Rector A L, Nowlan W A, Kay S. Foundations for an Electronic Medical Record. The IMIA Yearbook of Medical Informatics 1992 (Eds. van Bemmel J, McRay A). Stuttgart Schattauer 1994.

  27. [Rector_1999] Rector A L. Clinical terminology: why is it so hard? Methods Inf Med. 1999 Dec;38(4-5):239-52. Available at .

  28. [Richards_1998] Richards E G. Mapping Time - The Calendar and its History. Oxford University Press 1998.

  29. [Sowa_2000] Sowa J F. Knowledge Representation: Logical, philosophical and Computational Foundations. 2000, Brooks/Cole, California.

  30. [Sottile_1999] Sottile P.A., Ferrara F.M., Grimson W., Kalra D., and Scherrer J.R. The holistic healthcare information system. Toward an Electronic Health Record Europe. 1999. Nov 1999; 259-266.

  31. [Van_de_Velde_Degoulet_2003] Van de Velde R, Degoulet P. Clinical Information Systems: A Component-Based Approach. 2003. Springer-Verlag New York.

  32. [Weed_1969] Weed LL. Medical records, medical education and patient care. 6 ed. Chicago: Year Book Medical Publishers Inc. 1969.



  1. [cov_contra] Wikipedia. Covariance and contravariance. See .

e-Health Standards

  1. [Corbamed_PIDS] Object Management Group. Person Identification Service. March 1999. See .

  2. [Corbamed_LQS] Object Management Group. Lexicon Query Service. March 1999. .

  3. [hl7_cda] HL7 International. HL7 version Clinical Document Architecture (CDA). Available at

  4. [HL7v3_ballot2] HL7 International. HL7 version 3 2nd Ballot specification. Available at

  5. [HL7v3_data_types] Schadow G, Biron P. HL7 version 3 deliverable: Version 3 Data Types. (2nd ballot 2002 version).

  6. [hl7_v3_rim] HL7 International. HL7 v3 RIM. See .

  7. [hl7_arden] HL7 International. HL7 Arden Syntax. See .

  8. [hl7_gello] HL7 International. GELLO Decision Support Language. .


  10. [NLM_UML_list] National Library of Medicine. UMLS Terminologies List.

  11. [ISO_13606-1] ISO 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. CEN TC251 Health Informatics Technical Committee. Available at .

  12. [ISO_13606-2] ISO 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. CEN TC251 Health Informatics Technical Committee. Available at .

  13. [ISO_13606-3] ISO 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. CEN TC251 Health Informatics Technical Committee.

  14. [ISO_13606-4] ISO 13606-4 - Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. CEN TC251 Health Informatics Technical Committee.

  15. [ISO_18308] Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. (ISO TC 215/SC N; ISO/WD 18308). International Standards Organisation, Australia, 2002.

  16. [ISO_20514] ISO. The Integrated Care EHR. See .

e-Health Projects

  1. [EHCR_supA_14] Dixon R, Grubb P A, Lloyd D, and Kalra D. Consolidated List of Requirements. EHCR Support Action Deliverable 1.4. European Commission DGXIII, Brussels; May 2001 59pp Available from

  2. [EHCR_supA_35] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 3.5: "Final Recommendations to CEN for future work". Oct 2000. Available at

  3. [EHCR_supA_24] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 2.4 "Guidelines on Interpretation and implementation of CEN EHCRA". Oct 2000. Available at

  4. [EHCR_supA_31_32] Lloyd D, et al. EHCR Support Action Deliverable 3.1&3.2 “Interim Report to CEN”. July 1998. Available at

  5. [GEHR_del_4] Deliverable 4: GEHR Requirements for Clinical Comprehensiveness. GEHR Project 1992. Available at .

  6. [GEHR_del_7] Deliverable 7: Clinical Functional Specifications. GEHR Project 1993.

  7. [GEHR_del_8] Deliverable 8: Ethical and legal Requirements of GEHR Architecture and Systems. GEHR Project 1994. Available at .

  8. [GEHR_del_19_20_24] Deliverable 19,20,24: GEHR Architecture. GEHR Project 30/6/1995. Available at .

  9. [GeHR_AUS] Heard S, Beale T. The Good Electronic Health Record (GeHR) (Australia). See .

  10. [GeHR_Aus_gpcg] Heard S. GEHR Project Australia, GPCG Trial. See .

  11. [GeHR_Aus_req] Beale T, Heard S. GEHR Technical Requirements. See .

  12. [Synapses_req_A] Kalra D. (Editor). The Synapses User Requirements and Functional Specification (Part A). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1a. 6 chapters, 176 pages.

  13. [Synapses_req_B] Grimson W. and Groth T. (Editors). The Synapses User Requirements and Functional Specification (Part B). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1b.

  14. [Synapses_odp] Kalra D. (Editor). Synapses ODP Information Viewpoint. EU Telematics Application Programme, Brussels; 1998; The Synapses Project: Final Deliverable. 10 chapters, 64 pages. See .

  15. [synex] University College London. SynEx project. .

General Standards

  1. [OCL] The Object Constraint Language 2.0. Object Management Group (OMG). Available at .

  2. [IEEE_828] IEEE. IEEE 828-2005: standard for Software Configuration Management Plans.

  3. [ISO_8601] ISO 8601 standard describing formats for representing times, dates, and durations. See

  4. [ISO_2788] ISO. ISO 2788 Guide to Establishment and development of monolingual thesauri.

  5. [ISO_5964] ISO. ISO 5964 Guide to Establishment and development of multilingual thesauri.

  6. [Perl_regex] Perl Regular Expressions. Available at .

  7. [rfc_2396] Berners-Lee T. Universal Resource Identifiers in WWW. Available at This is a World-Wide Web RFC for global identification of resources. In current use on the web, e.g. by Mosaic, Netscape and similar tools. See for a starting point on URIs.

  8. [rfc_2440] RFC 2440: OpenPGP Message Format. See and

  9. [rfc_3986] RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. IETF. See .

  10. [rfc_4122] RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace. IETF. See .

  11. [rfc_2781] IETF. RFC 2781: UTF-16, an encoding of ISO 10646 See

  12. [rfc_5646] IETF. RFC 5646. Available at

  13. [sem_ver] Semantic Versioning. .

  14. [Xpath] W3C Xpath 1.0 specification. 1999. Available at

  15. [uri_syntax] Uniform Resource Identifier (URI): Generic Syntax, Internet proposed standard. January 2005. see .

  16. [w3c_owl] W3C. OWL - the Web Ontology Language. See .

  17. [w3c_xpath] W3C. XML Path Language. See .