openEHR logo

Task Planning Model Specification

Issuer: openEHR Specification Program

Release: latest

Status: DEVELOPMENT

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.

Licence

image Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/

Support

Issues: https://openehr.atlassian.net/browse/SPECPR/
Web: http://www.openehr.org/

Amendment Record

Issue Details Raiser Completed

R E L E A S E     1.?.?

0.7.2

Incorporate review comments from Boštjan Lah.

B Lah, T Beale

20 Jun 2017

0.7.1

Rework runtime model.

T Beale

07 Jun 2017

Incorporate review comments from Pablo Pazos.

P Pazos,
T Beale

06 Jun 2017

0.7.0

Major rewrite, incorporating structure, parallelism, decision paths, and execution history.

T Beale

31 May 2017

0.6.0

SPECRM-58. Initial writing.

T Beale, B Naess, I McNicoll

26 Jan 2017

Acknowledgements

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

  • DIPS, Norway

  • Marand d.o.o., Slovenia

  • Ars Semantica, UK

Trademarks

  • '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 http://www.openehr.org/releases/RM/latest/task_planning.html.

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. Survey of Requirements

This specification for a Task Planning facility for openEHR addresses requirements in a number of areas in which some form of 'planning' of clinical work is required. The defining characteristic of the requirements is that they primarily relate to an active human subject, rather than a passive object, such as a parcel or tissue sample. The requirements covered include one-off scheduled tasks (e.g. surgical procedure), long-running scheduled tasks (e.g. drug administration), recurring tasks (e.g. monitoring), and coordinated teamwork (e.g. acute stroke management).

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

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

  • design time: templates or prototypes of standard task plans are developed and published;

  • runtime - planning: task plan prototypes are turned into concrete plans for specific work items for specific patients and activated;

  • runtime - work execution: task plans are executed by clinical performers and the plan maintained up to date in real time;

  • runtime - work completion: as each task is performed, standard clinical statements (openEHR Entries) are committed to the EHR to record what was done.

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

2.2. Limitations of openEHR standard Entry Model

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

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

A set of planned tasks need not all relate to a single order, or indeed any order. The general picture is that a task plan corresponds to some self-standing healthcare job to be done, which may include tasks designed to fulfill multiple orders, and also tasks not defined by orders.

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

2.3. xxx

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

  • 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 plan - a concrete concept that defines a set of fine-grained planned tasks to perform over time to achieve a particular goal.

These entities and their relationships can be envisaged as follows.

pathway plan triad
Figure 1. The care pathway / care plan / task plan triad

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

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

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

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

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

2.4. 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 plans) will be represented in the IT layer and the executing actors (generally human, although they may also be devices or software applications) exist in the real world, an account of the interaction between the computing environment and the real world is required.

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

  • 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 2. Work plan execution paradigm

2.5. Relationship to Workflow Formalisms and Systems

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

While the model described here takes many ideas from these languauges, there are some key differencs as well. The primary conceptual difference is that the subject (i.e. 'case') here is assumed to be an intentional organism (generally a human patient) that makes choices, reacts to drugs, and generally speaking, cannot be relied on to be a passive object (such as a package or blood sample), as is the case for most logistic workflows, for which languages such as BPMN are suited.

The main consequence of this is that the design of a task plan is not taken to be a highly deterministic description whose exceptions are generally knowable in advance as they would be for a logistic system whose subjects are passive objects. Instead, tasks and groups of tightly-coupled tasks are specified in a more self-standing way, using preconditions rather than logical join and split operators. Note that even the patient can be a passive object in some circumstances, such as radiology.

3. Requirements

Task planning is applicable to numerous clinical scenarios, exemplified by the following:

  • routine simple medication administration, e.g. for post-operative pain - tasks extend across worker shifts;

  • complex drug administration e.g. multi-drug chemotherapy over multiple days;

  • physiotherapy rehabilitation sessions - recurrent therapeutic procedure, with defined end-point;

  • dialysis - recurrent therapeutic procedure;

  • diet + physical activity plan for overweight treatment - recurrent tasks, patient as a performer;

  • surgery planning - one time event;

  • acute stroke management - multiple sets of tasks coordinated across multiple performers.

Within these and many other similar clinical procedures, a number of commonly occurring generic requirements appear, as 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 plan, each task of which which can then be performed and signed off by a staff member, e.g. a shift nurse. The task plan acts as a record of what has been done, and what is left to do.

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

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 plan for administering chemotherapy according to a R-CHOP protocol would implicate orders for the drugs (R)ituximab, (C)yclophosphamide, (H)ydroxydaunorubicin, (O)ncovin, and (P)rednisolone or Prednisone, and would accordingly include planned tasks for each of these drugs as they are administered according to the protocol.

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

(R)ituximab

375 mg/m²

375 mg/m²

IV infusion

Day 1

(C)yclophosphamide

750 mg/m²

1200 mg/m²

IV infusion

Day 1

(H)ydroxydaunorubicin

50 mg/m²

75 mg/m²

IV bolus

Day 1

(O)ncovin

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

3.5. Teamwork and Notifications

There are at least two possible situations in which a task plan might need to refer to another task plan. 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 plan, and to be able to refer to it from another task plan. The general case is that any task that could be represented by a single item in a task plan could also be represented by a reference to a separate detailed task plan.

A second situation in which a task plan might refer to another is where a team of actors performs the work, and each task plan 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 plan for a given actor can refer to another self-standing task plan for the same or a different actor;

  • notify completion: it should be possble for completion to be notified for tasks in a task plan; 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 plan 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 plan intended for sequential (i.e. ordered) execution by the agent, one of whose steps is actually a sub-group of tasks which can be executed in parallel (i.e. in any order).

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

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

3.7. Decision Pathways

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

  • decision point: a step containing a variable assignment of the form $v := expression;

  • subordinate decision paths: groups of tasks each group of which has attached a variable test of the form $v rel_op value, where rel_op is one of =, /=, <, >, <= or >=.

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

IHC stroke decision path
Figure 3. Decision pathway example (Intermountain Healthcare Acute Stroke CPM)

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

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

3.8. Changes and Abandonment

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

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

The following kinds of abandonment of tasks should be supported:

  • cancellation of an entire task plan 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.9. Rationalising Unrelated Task Plans

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

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

3.10. 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.11. Support for Costing and Billing Information

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

4. Design Principles

The design approach adopted here is based on a number of ideas. Firstly, it addresses only the 'Task Plan' 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. Levels of Model Definition

In common with typical workflow systems, this specification recognises three levels of planned task model, as follows:

  • templated definition: a Task Plan template is a definition of a Task Plan that may be used in multiple situations, where local modifications may be made; it is represented in the form of openEHR templated archetype(s);

  • specific definition: when a Task Plan templated archetype is instantiated, the result is understood as the definition of the Task Plan to be used in a specific circumstance; any modifications allowed by the archetypes may be made to achieve the specific Task Plan needed;

  • runtime instantiation: at execution time, a Task Plan definition will be wholly or partly instantiated, along with execution state specific to the 'run', i.e. the session during which some or all of the Task Plan might be performed.

In this scheme, archetypes and templates conveniently achieve the 'template' or 'prototype' level of definition that is needed to support standard models of similar but not identical kinds of Task Plan. For example, a single set of archetypes and templates could be used to represent Task Plans for hospital drug administration.

4.2. Fractal Structure

In the real world, 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 Plan, 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 Plan that are to be executed on some basis, e.g. sequential, parallel;

  • Task Plan: 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 Plan 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 Plan lifecycle.

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

The consequence of the above is that a Task Plan 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 Plan 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 Plan 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 Plan 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 Plans.

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 Plan;

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

4.4. Phases of Work

This 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 4. Clinical Investigator Process with Planning

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

4.5. Separation of Task Definition and Execution State

A Task Plan 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 Plan 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 Plan 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 Plans 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 Plan, rather than to include state within each Task. This provides a means of separation of Task Plan definition from Task Plan 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 UML diagram shows the rm.task_planning package in overview form, with the essential classes, inheritance and compositional relationships. The class TASK_PLAN is a descendant of CONTENT_ITEM, which makes it a type of content that may occur in a Composition. Compositions used for this purpose have their category attribute set to the openEHR coded term |Task Plan|. This enables Task Plans to be committed to the openEHR EHR if desired.

Structurally, a TASK_PLAN has a principal_performer, and a definition (blue classes). Individual Tasks that are DEFINED_TASKs (i.e. not references) may have a prototype whose type is an Entry descendant, that defines the Task data.

The TASK_PLAN may also have an execution_history (gold classes at bottom), which acts as a record of events that have occurred to the Task Plan during execution. At runtime, execution-related RT_XXX classes may be instantiated to track state for those parts of the definition currently being processed (central orange classes).

RM task planning overview
Figure 5. rm.task_planning package overview

The key structural relationships are shown in the following instance diagram. On the left is the definition of a Task Plan, consisting of a Task Group and various Defined Tasks. Each of these Tasks may have a prototype Entry attached, which represents the intended data of an action or observation that the Task defines.

At the upper right is an Executing Task Plan, which is a runtime structure consisting of elements that correspond to the currently executing parts of the static definition structure (achieved by the RT_PLAN_ITEM.definition association). This structure allows the recording of all state to do with Task execution, including instances of variables, timing information and so on. The Executing Task Plan structure is not owned by the definition structure, but rather is created at run time, and points back to its definition (owner and definition links).

At the lower right is a Task Execution History, which is a record of all events that were made during the execution of the original Task Plan.

task planning overview
Figure 6. Task planning overview

6. Task Definition Model

6.1. Overview

The following figure shows the definition part of the rm.task_planning package.

RM task planning definition
Figure 7. rm.task_planning package definition model

6.1.1. Compositions and Versioning

If a TASK_PLAN and its constituent parts is created within a COMPOSITION for committal to the EHR (or a workflow-specific part of the EHR), it may be 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;

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

As the TASK_PLAN gets progressively built and executed over time, its owning COMPOSITION will undergo numerous changes, corresponding both to changes to the plan definition, 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 Plan. How changes to Task Plan are versioned and added to the EHR (or not) can be handled flexibly according to local needs.

6.1.2. Basic Semantics of a Task Plan

A Task Plan is specified by a number of key attributes, following the design principles described earlier, namely:

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

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

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

  • care_plan: a reference to a driving Care Plan from elsewhere in the EHR, if any exists;

  • guideline_id, care_pathway: references to a guideline and/or care pathway from which this Task Plan was derived;

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

These are described in more detail below.

6.1.3. Compositional Structure

The set of Tasks in Task Plan 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 Plan structure including nested Task Groups.

task grouping
Figure 8. Task grouping

6.1.4. Basic Semantics of a Task

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

  • description: natural language specification of the work of the Task;

  • preconditions: operational conditions for determining if a Task is available for execution by a performer;

  • wait_conditions: specification of coordinating wait conditions for Task completion by another performer;

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

  • execution_time: optional timing plan for Tasks;

  • indications: clinical conditions for the Task being applicable;

  • optionality: indicates whether the Task is regarded as optional or mandatory in the overall Task plan, typically set by a guideline;

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

  • other_participations: participations other than the principal performer.

Each of these is explained in detail below.

6.1.5. Task Plan Compositional Structure

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 for representing a real world Task:

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

  • reference to composite representation: a Task definition may refer out to a separate Task Plan containing further sub-tasks representing the detailed steps needed to achieve it.

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_PLAN which refers out to another TASK_PLAN to be executed by the same performer.

The EXTERNAL_PLAN type gives rise to the possibility of a hierarchy of linked Task Plans, 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 9. Task Plan linking

A structure like the above may be used differently by performers of differing training levels - since each EXTERNAL_PLAN has its own inherited description, an expert user may require no further list of steps, but a trainee might make use of the full hierarchical structure. The training_level attribute on TASK_PLAN 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_PLANs. The workflow application may treat different users as being of different training levels, in which case Task Plans of higher training levels can be hidden. In the above example, a principal performer with trainee level = 7 will see the three Task Plans on the left, but not the final one, since it has a trainee level of 10.

The default value of training_level is 0.

6.2. Task Definition

The description of the work of a Task or Task Group is stated in the description attribute, inherited from PLAN_ITEM. This applies to DEFINED_TASKs (inline definitions) and external Plan references. A detailed specification of the work to be done in concrete (i.e. inline) Task definition may be stated via the DEFINED_TASK class optional atttribute prototype, of type ENTRY, which enables the details of a Task to be specified in terms 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' partial copy of an Entry that will be created when the Task is actually performed. For example, a Task Plan 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 10. Task definition

Assuming that the Task Plan 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_PLAN 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 Plan. This has the effect of creating ACTION or other prototype instances in the TASK_PLAN 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 Plan 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 PLAN_ITEM) may be sufficient information for the performer. On the other hand, a prototype OBSERVATION could be specified in the TASK_PLAN template, which defines a particular form of the observation, e.g. a blood pressure which only records mean arterial 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.

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?

6.2.1. Coordinated Teamwork

Performing teamwork in a coordinated fashion with task planning support necessarily requires multiple Task Plans - one for each actor, and a means of coordination among them. This is achieved by the use of TASK_NOTIFICATION class and the attributes notifications and wait_conditions, which respectively represent outgoing notifications to other actors, and a 'wait state' that is unblocked by receipt of a notification from another Task Plan and actor.

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 11. Task coordination

6.2.2. Timing

In the coordinated team work situation, the timing of Tasks tends to be based on previous Tasks completing and/or receipt of completion notifications from Tasks being performed by other actors. However, for scenarios such as routine drug administration, the timing of Tasks can be specified directly.

This is achieved via the execution_time attribute, whose value at runtime is understood as a guide, enabling Tasks to be placed on a scheduled timeline. A performer may execute the Task earlier or later than the indicated time, with the final ACTION or other Entry recording the actual time.

The timing of a Task, may be expressed in three different ways, as follows:

  • clock time: the Task is to be executed at a specific clock time represented by an instance of CLOCK_TIMING; within a Task definition, this must be specified as a relative duration with respect to the origin clock time of the Task Plan, which is only known in absolute terms at execution time;

  • event-linked time: the Task is to be executed at a time related to a real world event, such as a meal or sleeping; in this case, an instance of EVENT_LINKED_TIME is used; the attributes indicate the specifics such as '1 hour before', 'with meal' etc;

  • task-link time: the Task is to be executed at a time related to the timing of another Task event, such as completion of the previous Task; this is represented by an instance of TASK_LINKED_TIME, whose attributes define the specifics.

Each of these timing specification types inherits from the TIMING_SPEC class, which provides an optional start_window attribute, enabling any time to be specified with an additional 'within x time'.

If no execution_time is specified, a Task is assumed to be available for execution if other (non-temporal) availability conditions are met and:

  • for Tasks in a sequential group, as soon as the previous Task has been completed;

  • for Tasks in a parallel group, as soon as the group becomes available.

ISSUE-time-relativity: time is somewhat complicated. In a TASK_PLAN archetype we need to use relative offsets everywhere, but at runtime, we need absolute times. We could consider setting an 'origin time' for the Task Plan as a whole when it is instantiated, and computing absolute times for each Task at that point. However, at runtime, the timings may be changed by the performer (e.g. times to admin drugs) and the intention is probably to make them 'stick', even if the notional origin time is moved. However in other cases, the idea may be to move the origin and have all the times move.

6.2.3. Pre-conditions

In addition to timing, other conditions may determine when or if a Task can be performed. These are modelled as the TASK_ITEM attribute preconditions: TASK_PRECONDITION. A precondition is formally represented as a DV_PARSABLE, which would normally contain a string in openEHR Expression Language syntax, but may contain another syntax.

Pre-conditions can be used in two ways. They may express real-world conditions containing references to EHR-available data items, such as vital signs, white cell count or other such things. Alternatively, they may be used as part of a decision group structure, in which case they reference a variable from a DECISION_GROUP instance. This is described in more detail below.

6.3. Decision Structures

A more advanced application of Task Plans includes decision structures in which Tasks are executed conditionally according to logic statements included in the Task Plan. In this model, a decision structure is represented by the classes DECISION_GROUP and DECISION_PATH_GROUP. These enable the decision points found in guidelines to be represented. The following diagram shows a typical decision structure.

decision structure
Figure 12. Decision structure

A decision point is represented by a DECISION_GROUP instance, which contains a value_expression in the form of an assignment of an expression to a variable that can be later tested, and has its execution_type set to conditional. Each pathway is represented by a DECISION_PATH_GROUP instance with a test_expression in the form of an assertion on the same variable. By this method, the workflow engine can determine which group to execute based on the runtime value of the variable.

6.4. Task Availability

A workflow application or engine executing a Task Plan can determine the availability for execution of any Task Group or Task as follows:

  • timing:

    • Task execution time, if set, with respect to current time;

    • check completion status of preceding Tasks / Groups within the current Task Group;

  • validity:

    • check that Task wait notifications have been received from related Task Plans executing in the same group;

    • check Task preconditions, assessed by executing precondition expressions against the EHR.

The workflow application may provide an override capability so that a Task can be performed before it is determined to be available. This would enable a user to perform the Task anyway, with the corresponding TASK_EVENT_RECORD recording the use of override.

6.5. Class Descriptions

6.5.1. TASK_PLAN Class

Class

TASK_PLAN

Description

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

A Task Plan 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 Plan with an operational care plan, and also a published guideline or protocol on which the Task Plan may be based.

Inherit

CONTENT_ITEM

Attributes

Signature

Meaning

0..1

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.

0..1

description: DV_TEXT

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

0..1

care_plan: LOCATABLE_REF

Care plan object from which this Task Plan is derived.

0..1

guideline: DV_IDENTIFIER

Identifier of guideline on which this Task Plan 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 = "https://www.nice.org.uk/guidance/cg180"

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

0..1

principal_performer: TASK_PARTICIPATION

Specification of principle performer of this Task Plan as a Participation, in terms of role and optionally function, mode and specific performer as appropriate.

0..1

care_pathway: DV_IDENTIFIER

Identifier of care pathway etc, on which this Task Plan 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 = "https://pathways.nice.org.uk/pathways/sepsis"

  • type = "NICE Sepsis care pathway"

1..1

definition: TASK_GROUP

The Tasks for this Task Plan.

0..1

execution_history: TASK_PLAN_EXECUTION_HISTORY

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

0..1

training_level: Integer

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

0..1

best_practice_ref: DV_URI

A URI (typically a local URL) that points to the document form of any governing guideline or other best practice publication in use in the current institution. This link provides a way for a clinician to cross-check the Task Plan design and functioning against the definitive document that acts as the source of its semantics.

0..1

expiry_time: Duration

Maximal date/time by which this Task Plan should be considered obsolete. If not set, the Task Plan 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 plan.

6.5.2. TASK_PARTICIPATION Class

Class

TASK_PARTICIPATION

Description

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.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

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.

0..1

role: DV_TEXT

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

0..1

mode: DV_CODED_TEXT

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

0..1

performer: PARTY_PROXY

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

1..1

optionality: VALIDITY_KIND

Condition for participation in the Plan item.

6.5.3. PLAN_ITEM Class

Class

PLAN_ITEM (abstract)

Description

Parent type of all item types that may appear within a Task Plan structure.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

item_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 Plan is done using paths of the form /task_group_id/task_group_id.

TODO: needed?

1..1

description: DV_TEXT

Human-readable form of the task directive.

6.5.4. TASK_ITEM Class

Class

TASK_ITEM (abstract)

Description

Abstract parent type of the Task definition 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 Plan principal_performer.

Inherit

PLAN_ITEM

Attributes

Signature

Meaning

0..1

other_participations: List<TASK_PARTICIPATION>

List of participations for task item.

0..1

costing_data: TASK_COSTING

Costing data related to this Task item.

0..1

preconditions: List<TASK_PRECONDITION>

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

0..1

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.

0..1

notifications: List<TASK_NOTIFICATION>

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

0..1

wait_conditions: List<TASK_NOTIFICATION>

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.

1..1

optionality: VALIDITY_KIND

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

0..1

other_details: ITEM_STRUCTURE

Archetypable structure for recording non hard-modelled information.

0..1

execution_time: TIMING_SPEC

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.

0..1

lifecycle_state: TASK_LIFECYCLE

Attribute for recording lifecycle_state of this Task from corresponding Task in live execution model.

6.5.5. TIMING_SPEC Class

Class

TIMING_SPEC (abstract)

Description

Parent of classes representing ways to specify time of an action to be performed.

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

ISSUE-generic-planned_time: These classes 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.

Attributes

Signature

Meaning

0..1

start_window: Duration

Time window after an initial time during which the action should start. Allows for approximate times to be used operationally.

6.5.6. CLOCK_TIMING Class

Class

CLOCK_TIMING

Description

Represents a time at which a single future event or action should take place in terms of an offset from an origin.

Inherit

TIMING_SPEC

Attributes

Signature

Meaning

0..1

start_offset: Duration

Time at which the action should start, specified as an offset from the Task Plan origin time. The effective real time to start operationally can be computed from an absolute origin time plus this offset.

If start_window is set, the action may start within this a certain duration after the start_offset.

If set, relative_offset and relative_time_qualifier are not set.

6.5.7. EVENT_LINKED_TIMING Class

Class

EVENT_LINKED_TIMING

Description

Represents a time at which a single future event or action should take place in terms of a real world event such as 'meal', a relative ordering with respect to the event, e.g. 'before', and an optional time offset, e.g. 3h. This allows time specifications like:

  • with (at) sleep time

  • 3h before

Inherit

TIMING_SPEC

Attributes

Signature

Meaning

0..1

event_offset: Duration

Relative time offset with respect to origin nominated in relative_time_qualifier.

1..1

event_type: DV_CODED_TEXT

Indicates that the action should be aligned with a real world event. Typical values: meal, evening meal, sleep, toilet.

1..1

event_order: TEMPORAL_RELATION

Order of event_offset with respect to event_type.

6.5.8. TEMPORAL_RELATION Enumeration

Enumeration

TEMPORAL_RELATION

Description

Enumeration of relative temporal relations.

Attributes

Signature

Meaning

before

Before a reference event.

with

At the same time as a reference event.

after

After a reference event.

6.5.9. TASK_LINKED_TIMING Class

Class

TASK_LINKED_TIMING

Description

Represents a time at which a single future event or action should take place in terms of a time relative to completion of another Task or other task-related event.

Need to specify this better.

Inherit

TIMING_SPEC

Attributes

Signature

Meaning

0..1

reference_item: TIMING_REFERENCE

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

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

0..1

relative_offset: Duration

Relative time offset with respect to origin nominated in relative_time_qualifier.

6.5.10. TIMING_REFERENCE Enumeration

Enumeration

TIMING_REFERENCE

Description

Enumeration of types of temporal reference within a Task Plan.

Attributes

Signature

Meaning

previous_task

The previous task in a series of tasks.

current_group

The start time of the current group.

6.5.11. TASK_GROUP Class

Class

TASK_GROUP

Description

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.

Inherit

TASK_ITEM

Attributes

Signature

Meaning

0..1

members: List<PLAN_ITEM>

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

0..1

execution_type: EXECUTION_TYPE

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

6.5.12. DECISION_GROUP Class

Class

DECISION_GROUP

Description

A specialised node that represents a decision point in guideline-based Task Plan definition. The decision is represented by the value_expression, which at runtime is instantiated as an ASSIGNMENT.

Instances of this class also act as a container for the subordinate decision paths which are modelled as TASK_GROUPs with execution_type = decisional, and each having a precondition representing a match expression for the value generated by the value_expression on the parent DECISION_GROUP object.

Inherit

PLAN_ITEM

Attributes

Signature

Meaning

1..1

value_expression: DV_PARSABLE

An expression in the form of a variable assignment from an expression or a plain variable reference, if no expression is required. The same variable will appear in the test_expressions of all immediate child paths.

1..1

paths: List<DECISION_PATH_GROUP>

Set of Task Groups that are also decision paths in this Decision Group.

6.5.13. DECISION_PATH_GROUP Class

Class

DECISION_PATH_GROUP

Description

A specialised kind of TASK_GROUP that corresponds to a particular decision path branch from a DECISION_GROUP.

Inherit

TASK_GROUP

Attributes

Signature

Meaning

1..1

test_expression: DV_PARSABLE

A test expression on a variable whose value is defined by the value_expression attribute of the owning DECISION_GROUP.

6.5.14. EXECUTION_TYPE Enumeration

Enumeration

EXECUTION_TYPE

Description

Enumeration specifying types of execution for a set of Tasks.

Attributes

Signature

Meaning

sequential

Items execute in order, one after the other.

parallel

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

6.5.15. TASK Class

Class

TASK (abstract)

Description

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

Inherit

TASK_ITEM

6.5.16. EXTERNAL_PLAN Class

Class

EXTERNAL_PLAN

Description

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

Inherit

TASK

Attributes

Signature

Meaning

1..1

target: TASK_PLAN

UID of target TASK_LIST object.

6.5.17. DEFINED_TASK Class

Class

DEFINED_TASK

Description

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.

Inherit

TASK

Attributes

Signature

Meaning

0..1

prototype: List<ENTRY>

Prototype instance of one or more Entries that express the specific work of the Task. Normally one Entry would be used, typically an ACTION, but more than one may sometimes make sense, e.g. an ACTION and an OBSERVATION.

6.5.18. TASK_NOTIFICATION Class

Class

TASK_NOTIFICATION

Description

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

Attributes

Signature

Meaning

1..1

target: TASK_PARTICIPATION

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

1..1

trigger_state: TASK_LIFECYCLE

Task lifecycle state that triggers notification.

6.5.19. TASK_PRECONDITION Class

Class

TASK_PRECONDITION

Description

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

Attributes

Signature

Meaning

0..1

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.

0..1

expression: DV_PARSABLE

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

7. Task Execution Model

7.1. Overview

The following figure shows the execution related part of the rm.task_planning package. The consists of two parts: the runtime part, and the 'execution history' part. The former is a partial specification of classes that could be instantiated at Task Plan execution time to track Plan execution, and is provided as a guide to how execution tracking can be done. The latter classes describe the execution history after the fact, in the form of 'event records' that can optionally be stored in the EHR after Task Plan execution has completed.

RM task planning execution
Figure 13. rm.task_planning package - execution model

7.2. Task Plan Execution Tracking

There are various aspects to Task Plan execution, some of which are complex, and not directly covered by this specification. The execution phases are as follows:

  • instantiation: create an instance of this Task Plan in the Task Plan application;

  • allocation: allocate the Plan instance to an authenticated user, as principal performer;

  • execution: the Task Plan application displays Tasks and advances the state of execution view interactions with the user;

    • each interaction, also change of principal performer, abandonment, and any other events will cause generation of Execution history events, which may be persisted;

  • commit to EHR: an updated state of the Task Plan may be committed to the EHR, containing final lifecycle states and execution history.

During a long-running Task Plan, the principal performer may change. This will usually be the case for Task Plans that run longer than a work shift.

7.2.1. Task Plan Instantiation

Initially, a Task Plan definition that has been created will have the lifecycle state value planned in each TASK_ITEM instance. When the definition is activated, it is instantiated within a Task execution application. This creates a copy of it, or part of it, along with instances of the RT_XXX classes ('RT' = runtime).

At instantiation, an instance of RT_TASK_PLAN is created and the start_time attributes set to the current time respectively. This object will normally be maintained for the lifetime of execution of the Task Plan. If there are execution times in the plan, they will be trivially convertable to absolute clock times.

The runtime form of the detailed structure of the plan may be instantiated fully, or only partially, where convenient. For example, if most of the plan has been completed, and only some steps remain, it may make sense to instantiate only the RT_XX instances corresponding to those steps. On the other hand, an applicaiton may want to display the details of the whole plan, even when only a small part remains to be executed.

The structure created will mirror the structure of the definition, to the extent of run-time structure creation, if it is partial. That is to say, RT_TASK_GROUP instances will have members containing further RT_XX instances, that mimic the TASK_GROUP structures within the Plan definition.

When the structure creation has been completed, the lifecycle_state attribute of one or more RT_TASK instances may be set to available, or if picking up from a previous session, to other states (i.e. completed etc), as appropriate.

At the same time, an instance of EXECUTION_HISTORY is also created, proving a root points to accumulate Task Plan execution event records.

7.2.2. Allocation

Before an instantiated Task Plan can be executed, it must be allocated. This is done by user authenticating to the Task Plan application; this user will be set as the principal_performer in the RT_TASK_PLAN instance.

7.2.3. Task Lifecycle Model

During execution, each Task is represented by an instance of RT_TASK that refers back to its TASK definition instance. Each Task in the Plan has a lifecycle consisting of various states it may pass through in time. Changes in the lifecycle are recorded in RT_TASK.lifecycle_state. The lifecycle is simple, since it only has to take account of the states a Task itself 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, preconditions being met, wait conditions having been satisfied and if there is a time specification on the Task, the current time being at or later than the stated time;

  • 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 14. Task lifecycle state machine

It may be that one or more Tasks do not evaluate to available at runtime when the principal performer wants to treat them as being available. This may happen if the performer wants to execute a Task earlier than scheduled, or decides that an unmet precondition or wait condition does not matter (for example, they may know that it is met, but the Task Plan application may not yet know). Accordingly, an override option

Since a Task Plan 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 RT_TASK_GROUP from the set of states of its members (which may include other RT_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;
    else
        return Initial;
}

Since the runtime Task Group is also the top-level structure of the runtime Task Plan, the inferred state of the Plan as a whole is also provided by this algorithm applied to the top-level runtime Task Group.

Lifecycle state values recorded in RT_TASK objects may be copied into the lifecycle_state attributes of the corresponding definition Task objects if required, for example, in order to persist a final snapshot of the Task Plan into the EHR.

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

7.2.4. Notifications

Notifications can be specified to be generated at various lifecycle state changes.

To be continued

7.2.5. Persistence

The run-time instance structure may need to be persisted to enable a partial execution of a long-running Task Plan to be recorded and picked up when later tasks become ready. In theory, this could be within the EHR, but it is recommended that either a specific EHR area be used for this, or that run-time state persistence be implemented outside the EHR proper.

issue-runtime-persistence: if within the EHR, we could create a new 'pointer' on the EHR object that points to 'task runtime state' data or similar. Is this a useful thing to do?

7.2.6. Class Descriptions

7.2.6.1. TASK_LIFECYCLE Enumeration

Enumeration

TASK_LIFECYCLE

Description

Enumeration representing possible lifecycle states for a Task.

Attributes

Signature

Meaning

planned

Task is planned for the future.

available

Task is available for execution by performer.

cancelled

Task was cancelled without commencing.

aborted

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

completed

Task was completed in the intended way.

7.2.6.2. RT_TASK_PLAN Class

Class

RT_TASK_PLAN

Description

Root object of an executing Task Plan structure.

Attributes

Signature

Meaning

0..1

start_time: Date_time

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

1..1

definition: RT_TASK_GROUP

Root of run-time Task Plan Task structure.

1..1

owner: TASK_PLAN

Owning Task Plan definition.

0..1

wait_conditions: List<RT_WAIT_CONDITIONS>

Reference list of all wait conditions in the Task Plan, and current status.

1..1

principal_performer: PARTY_PROXY

Run-time principal performer - a person or other agent.

Functions

Signature

Meaning

lifecycle_state: TASK_LIFECYCLE

Lifecycle state of Task Plan, derived as a copy of the lifecycle_state() of the definition TASK_GROUP.

7.2.6.3. RT_WAIT_CONDITIONS Class

Class

RT_WAIT_CONDITIONS

Description

Class representing the runtime tracked form of wait_conditions on a single TASK_ITEM.

Attributes

Signature

Meaning

1..1

task_item: RT_TASK_ITEM

Reference to the Task Item being tracked.

0..1

outstanding: List<TASK_NOTIFICATION>

Outstanding wait conditions of the referenced Task item.

1..1

satisfied: TASK_NOTIFICATION

Wait conditions from Task definition that have been satisfied so far by receipt of relevant notifications.

7.2.6.4. RT_PLAN_ITEM Class

Class

RT_PLAN_ITEM (abstract)

Description

Abstract parent of run-time types that correspond to design time PLAN_ITEM instances.

Inherit

LOCATABLE

Attributes

Signature

Meaning

0..1

participations: List<PARTICIPATION>

Run-time participations of this Plan Item in addition to principal performer.

1..1

definition: PLAN_ITEM

Corresponding item from Task Plan definition. Redefined in descendants to the definition type corresponding to each runtime (RT_XXX) type.

7.2.6.5. RT_TASK_ITEM Class

Class

RT_TASK_ITEM (abstract)

Description

Abstract parent of run-time types that correspond to design time TASK_ITEM instances.

Inherit

RT_PLAN_ITEM

Attributes

Signature

Meaning

1..1
(redefined)

definition: TASK_ITEM

Reference to corresponding TASK_ITEM instance in Task Plan definition. Redefined in descendants.

7.2.6.6. RT_DECISION_GROUP Class

Class

RT_DECISION_GROUP

Description

Run-time homologue of DECISION_GROUP from a Task Plan definition.

Inherit

RT_PLAN_ITEM

Attributes

Signature

Meaning

1..1

value_expression: ASSIGNMENT

Runtime form of value_expression from ask Plan definition.

1..1
(redefined)

definition: DECISION_GROUP

Reference to corresponding DECISION_GROUP instance in Task Plan definition.

Functions

Signature

Meaning

paths: List<RT_DECISION_PATH_GROUP>

Decision path groups, computed by following definition link to the corresponding DECISION_GROUP object in Task Plan definition.

7.2.6.7. RT_TASK_GROUP Class

Class

RT_TASK_GROUP

Description

Run-time homologue of TASK_GROUP from a Task Plan definition.

Inherit

RT_TASK_ITEM

Attributes

Signature

Meaning

0..1

members: List<RT_PLAN_ITEM>

Member run-time items in group, mimicking structure of the corresponding definition group instance.

1..1
(redefined)

definition: TASK_GROUP

Reference to corresponding TASK_GROUP instance in Task Plan definition.

Functions

Signature

Meaning

lifecycle_state: TASK_LIFECYCLE

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

7.2.6.8. RT_TASK Class

Class

RT_TASK

Description

Run-time homologue of TASK type and its descendants from a Task Plan definition.

Inherit

RT_TASK_ITEM

Attributes

Signature

Meaning

1..1

lifecycle_state: TASK_LIFECYCLE

Current lifecycle state of this Task at run-time.

0..1

events: List<TASK_EVENT_RECORD>

List of references to run-time events that have occurred on this Task.

0..1

preconditions: List<ASSERTION>

Run-time form of preconditions on corresponding TASK in Task Plan definition.

1..1
(redefined)

definition: TASK

Reference to corresponding TASK instance in Task Plan definition.

7.2.6.9. RT_DECISION_PATH_GROUP Class

Class

RT_DECISION_PATH_GROUP

Description

Run-time homologue of DECISION_PATH_GROUP from a Task Plan definition.

Inherit

RT_TASK_ITEM

Attributes

Signature

Meaning

1..1

test_expression: ASSERTION

Runtime form of test_expression from ask Plan definition.

1..1
(redefined)

definition: DECISION_PATH_GROUP

Reference to corresponding DECISION_PATH_GROUP instance in Task Plan definition.

Functions

Signature

Meaning

lifecycle_state: TASK_LIFECYCLE

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

7.3. Task Plan Execution History

The history of execution events is represented in the runtime instance of EXECUTION_HISTORY. This is a history of real world execution events that accumulate over the duration of processing of the Task Plan. 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;

  • TASK_PLAN_EVENT_RECORD_: type representing any kind of execution event not linked to a specific Task, for example 'plan abandonment', 'new principal performer'.

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 Plan executions. How it may be persisted in various ways. The following possibilities are all compatible with both the model, and typical EHR requirements:

  • In the Task Plan application persistence:

    • persist the full history, delete or archive once the Task Plan 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 Plan, which should only change if changes to the plan are made, and the execution state, which is built during the work performance.

7.3.1. Class Descriptions

7.3.1.1. TASK_PLAN_EXECUTION_HISTORY Class

Class

TASK_PLAN_EXECUTION_HISTORY

Description

History of Task Plan 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.

Attributes

Signature

Meaning

0..1

task_events: List<TASK_EVENT_RECORD>

Task-level execution time events.

0..1

plan_events: List<TASK_PLAN_EVENT_RECORD>

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

7.3.1.2. EVENT_RECORD Class

Class

EVENT_RECORD (abstract)

Description

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

Attributes

Signature

Meaning

1..1

time: Date_time

Time the event occurred.

0..1

description: String

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

7.3.1.3. TASK_PLAN_EVENT_RECORD Class

Class

TASK_PLAN_EVENT_RECORD

Description

Record of an runtime event to a Task Plan.

Inherit

EVENT_RECORD

Attributes

Signature

Meaning

1..1

details: Hash<String, String>

Other details as a name/value list.

7.3.1.4. TASK_EVENT_RECORD Class

Class

TASK_EVENT_RECORD

Description

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

Inherit

EVENT_RECORD

Attributes

Signature

Meaning

1..1

task_id: String

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

1..1

lifecycle_state: TASK_LIFECYCLE

The lifecycle state that was reached due to this event.

0..1

notifications_sent: List<TASK_NOTIFICATION_RECORD>

Notifications that were performed as part of this Task Event.

0..1

entry_instances: List<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 plan.

ISSUE-fwd-refs: entry_instance is a forward reference - which requires updating the Task Plan 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 Plan items? Is being able to determine the resulting Entries starting from the Task Plan even useful?

1..1

preconditions_satisfied: Boolean

Set to True if all preconditions defined on the corresponding Task were satisfied at runtime. If set to False, and there were preconditions, this means that preconditions were overridden by the user at runtime.

1..1

wait_conditions_satisfied: Boolean

Set to True if all wait_conditions for the corresponding Task were satisfied when it was performed. If False, and there were wait_conditions, wait_conditions were overridden by the user at runtime.

7.3.1.5. TASK_NOTIFICATION_RECORD Class

Class

TASK_NOTIFICATION_RECORD

Description

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

Attributes

Signature

Meaning

1..1

reciever: PARTY_PROXY

Identification of the receiver party

1..1

receiver_task_plan: String

Identifier of receiving Task Plan.

1..1

details: Hash<String, String>

Other details as a name/value list.

7.4. Cost Tracking

TBD: describe cost tracking.

7.4.1. Class Descriptions

7.4.1.1. TASK_COSTING Class

Class

TASK_COSTING

Description

Costing information for a Task.

TODO: to be developed.

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

TBC:

7.5.1. Class Descriptions

7.5.1.1. TASK_PLANNING_MS Interface

Interface

TASK_PLANNING_MS

Description

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

Functions

Signature

Meaning

create_task_list

add_task

remove_task

cancel_task

link_perfomed_action

etc

8. Relationship with other openEHR EHR Artefacts

8.1. Principles

The model enables a flexible relationship between a Task Plan and orders, i.e. openEHR INSTRUCTIONs. In simple cases, a Task Plan 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 Plan 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 Plan cannot consist of Tasks that define administrative work and would be documented with openEHR ADMIN_ENTRYs.

We can infer from the above that the main driver of a Task Plan isn’t in general an order, but a 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 Plan may be created ad hoc, such an in-patient pain medication administration plan by nursing staff. At the other extreme, a Task Plan 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 Plans. The arrows indicate causal relationships.

planning artefacts
Figure 15. 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 Plans is that not all careflow steps and states in the former need to be represented as Tasks in a Task Plan. 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 Plan correspond only to Active-state careflow steps of constituent order INSTRUCTIONs.

8.2. 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_PLAN(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 16. 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.

9. Scenarios

9.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 Plan. 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_PLAN 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_PLAN 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_PLAN 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 17. Typical Task Plan - 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_PLAN 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 Plan.

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 Plans to implement them.

9.2. Check-list and Sign-off

TBD

9.3. Changes during Execution

TBD

9.4. Abandonment

TBD

10. Implementation Guidance

10.1. Workflow Application Design

TODO:

10.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 Plan are committed to the EHR is likely to be needed. When a Task Plan 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 Plan 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 Plan 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 Plan to a persistent store for workflow management or some other application may of course be useful.

References

Publications

  1. [van_der_Aalst_2005a] Van der Aalst, Weske, Grunbauer. Case Handling: A New Paradigm for Business Process Support. Data and Knowledge Engineering, 53(2):129-162, 2005.

  2. [van_der_Aalst_2013a] Wil van der Aalst. Business Process Management: A Comprehensive Survey. ISRN Software Engineering, pages 1-37, 2013. doi:10.1155/2013/507984.

  3. [Baretto_2005] Barretto S A. Designing Guideline-based Workflow-Integrated Electronic Health Records. 2005. PhD dissertation, University of South Australia. Available at http://www.cis.unisa.edu.au/~cissab/Barretto_PhD_Thesis_Revised_FINAL.pdf.

  4. [Beale_2000] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. Available at http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_web_2000.pdf .

  5. [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 http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_oopsla_2002.pdf .

  6. [BPTrends_2009] Case Management: Combining Knowledge With Process. White paper in BPTrends July 2009.

  7. [Browne_2005] Eric Browne. Workflow Modelling of Coordinated Inter-Health-Provider Care Plans. PhD thesis submitted to the School of Computer and Information Science, University of South Australia. January 2005.

  8. [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.

  9. [Hull_et_al_2010a] Richard Hull et al. Introducing the Guard-Stage-Milestone Approach for Specifying Business Entity Lifecycles. Preprint from Proc. Intl. Workshop on Web Services and Formal Methods (WS-FM), 2010. To appear in Springer-VerlagLNCS 6551.

  10. [Mulyar_et_al_2007] Nataliya Mulyar, Maja Pesic, Wil M.P. van der Aalst and Mor Peleg. Declarative and Procedural Approaches for Modelling Clinical Guidelines: Addressing Flexibility Issues. Conference: Business Process Management Workshops, BPM 2007 International Workshops, BPI, BPD, CBP, ProHealth, RefMod, semantics4ws, Brisbane, Australia, September 24, 2007.

  11. [Mulyar_et_al_2008] Nataliya Mulyar, Maja Pesic, Wil M.P. van der Aalst and Mor Peleg. Towards the Flexibility in Clinical Guideline Modelling Languages.

  12. [Hofstede_van_der_Aalst_2009] Hofstede, van der Aalst et al. Modern Business Process Automation: YAWL and its Support Environment. Springer 2009.

  13. [Mei_et_al_2014] Jing MEI, Jing LI, Yiqin YU, Xiang LI, Haifeng LIU and Guotong XIE. Embracing case management for computerization of care pathways. e-Health – For Continuity of Care C. Lovis et al. (Eds.) 2014 European Federation for Medical Informatics and IOS Press. doi:10.3233/978-1-61499-432-9-3

  14. [Müller_2003] Robert Müller. Event-Oriented Dynamic Adaptation of Workflows: Model, Architecture, and Implementation. PhD thesis submitted to Fakultät für Mathematik und Informatik at the Universität Leipzig, 2003.

  15. [Pescosolido] Bernice A. Pescosolido, Indiana University, USA. Patient trajectories. Wiley Online Library

  16. [Russell_et_al_2007] N. Russell, A.H.M. ter Hofstede, and W.M.P. van der Aalst. newYAWL: Specifying a Workflow Reference Language using Coloured Petri Nets. In K. Jensen, editor, Proceedings of the Eighth Workshop on the Practical Use of Coloured Petri Nets and CPN Tools (CPN 2007), volume 584 of DAIMI, pages 107-126, Aarhus, Denmark, October 2007. University of Aarhus.

  17. [Schrijvers_et_al_2012] Guus Schrijvers, Arjan van Hoorn, Nicolette Huiskes. The Care Pathway Concept: concepts and theories: an introduction. International Journal of Integrated Care. 2012;12(6). DOI: http://doi.org/10.5334/ijic.812

  18. [Vanhaecht_et_al_2007] Vanhaecht K, De Witte K, Sermeus W. The impact of clinical pathways on the organisation of care processes. PhD dissertation, Belgium: KU Leuven; 2007.