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

New Task subtypes; re-design 'system request' concept; build out callback classes; remove explicit notifications from model.
Improve performer model. Add more design material. Improved Task state machine.

T Beale

25 Aug 2017

0.8.0

Incorporate changes from Workshop 28/29 July with Marand, DIPS, Lanit (Moscow). Change principal performer to Group level; add specialised Task types; add system request.

B Lah,
B Naess,
M Kejžar,
E Leonov,
T Beale

06 Jul 2017

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 {openehr_rm_task_planning}.

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. Glossary of Terms and Acronyms

The following terms and acronyms are used in this document.

Term Meaning

CDS

Clinical Decision Support

3. Background

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

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

  • a set of orders for medications and/or other therapies that are used together to achieve a particular clinical goal, e.g. the drugs for a particular chemotherapy regimen are often modelled as an order set;

  • potentially a detailed plan for administration of the items in the order set, which may be a fully planned out schedule of single administrations on particular days and times;

  • descriptive meta-data, including authors, history, evidence base, etc.

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

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

3.2. Limitations of the 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.

3.3. Care Pathways and Task Planning

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 structured description of care of a condition / ideal patient, typically including or referring to one or more guidelines that describe in detail how to deal with specific situations within the condition;

  • care plan - a general plan for care of an actual patient, possibly using published Care Pathways and/or guidelines and taking into account individual specificities;

  • task plan - a concrete definition of a set of fine-grained planned tasks for one or more actors 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 and clinical guidelines, each of which can be thought of as a basis for task plans for an ideal patient for a given condition (e.g. pregnancy, sepsis, stroke etc). Where care pathways (or parts thereof) can be represented as formal artefacts, they can act as prototypes for task pan structures. However, a care pathway for a model patient is not the same thing as a task plan(s) for an actual patient, since each real patient has his/her own specific combination of conditions, preferences and ultimately phenotypic specificities. Thus, where task plans are based on care pathways, the latter act as prototypes whose ideal form may be modified by the specific care plan and/or as the care team deems appropriate.

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

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

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

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

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

3.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 a) an intentional agent (generally a human patient) that makes choices, and b) an active biological organism, which reacts to drugs and other interventions. In other words, an entity that cannot be considered a passive object (such as a package or blood sample), as is the case for most logistic workflows, for which languages such as BPMN are designed.

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.

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

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

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

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

4.4. Recurring / Repeatable Tasks

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

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

4.6. Teamwork and Notifications

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

4.7. Sub-plans

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

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

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

4.10. Different types of Cancellation

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

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

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

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

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

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

5. Design Principles

The following sections describe some of the key ideas in the design of the Task Planning model defined in this specification.

5.1. Conceptual Basics

5.1.1. Work Plan

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

Within a Work Plan, each included Task Plan is a definition of work to be performed in a single work context, typically by a single worker. Multiple Plans occur for two reasons:

  • distinct performers working in different contexts, across which managed handoffs are required;

  • sub-plans subordinate to a parent Plan, to be performed by the same worker.

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

The entirety of the Work Plan definition is assumed to be executable within a single computational context, in which methods of notification and worker communication are available, enabling the state of progress of the work defined in the Plan to be fully represented computationally. A Work Plan will often be limited to a single enterprise, but this need not be the case, as long as all of its Task Plans communicate within the same Plan execution context. More typically, some jobs required by a Work Plan are performed in another organisational context entirely, and from the point of view of the original Work Plan, the second organsation is seen as a 'black box' to which a request can be made and a result might be returned. A common example is a hospital clinical workflow that at some point requires a laboratory result, which is processed by an external organisation.

5.1.2. Task Plan

The actual definition of work to be done, i.e. Tasks, occurs within each Task Plan. The most basic structuring notion required is that of a sequential list of Tasks, enabling the representation of the set of steps in a typical linear workflow such as making tea or cleaning a wound.

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

The Task Group provides a convenient place to state repetitions that may be required or allowed, as occurs with many routine clinical and related jobs.

With hierarchy and sequential execution semantics, a great many types of work can be represented. However, some sets of Tasks can be performed without regard to order - i.e. in parallel. The model defined here therefore includes an execution type indicator at the Task Group level, so that manner of performing the work items within a Group - with or without regard to order - can be indicated. In purely sequential Task Plans, there is only one execution path. Parallel execution enables the possibility of multiple execution paths during a Plan execution.

The availability of parallelism in a Task Plan, particularly where the parallel elements are whole Task Groups, also creates the possibility of choice. Rather than every parallel path being mandatory or arbitrarily optional, a set of parallel paths may be chosen according to a decision node within the Plan, where a variable is evaluated and various value sub-ranges correspond to multiple paths. Such groups are represented by a Decision Group within the model, and each output path by a Decision Path Group.

The leaf level constituents of a Task Plan are Tasks of various kinds, including inline-defined Tasks; requests to other contexts within the same Work Plan; requests to external contexts and requests to IT systems and services.

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

In business terms, a Task typically corresponds to:

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

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

We can summarise the above-described structure in reverse:

  • Task: a separately performable unit of planned work at any level of granularity; may be defined inline or

  • Task Group: a group of Tasks and/or more Task Groups within a Task Plan that are to be executed on the same basis, e.g. sequential, parallel.

  • Decision Group and Decision Path Group: two special kinds of Group that enable decision nodes to be represented in a Plan.

  • Task Plan: a logical set of Tasks for a single performer context to achieve a defined result within a larger plan.

  • Work Plan: top-level structure containing related Task Plans needed to implement an intended outcome for a subject of care.

5.1.3. Work Context

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

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

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

5.1.4. Context Switching and Forking

If work has to be stopped within one context and passed to a different work context, a context switch is required, and the first worker or team will wait for a response. If the context switch is within the same Work Plan, is termed a handoff, which entails switching Task Plans. A context change is also required to request work from an external environment. A second kind of change of control is a context fork, whereby the current performer signals to another context to start doing some work, but continues doing his own work.

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

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

5.1.5. Principal Performer

All Tasks in a Plan are defined to have 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), 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 be specified in terms of professional roles, and optionally a specific agent. This might in some cases be the patient.

The principle performer is defined to be attached to a Task Group in the model. This enables a Task Plan by default to have a single principle performer attached to the top-level Task Group, but to be overridden at lower level Groups.

In addition to the principal performer, other participations can be specified for any contained Task in a Plan. 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 procedure, a Plan may have more than one principal performer in different Group sections, or alternatively, each distinct actor has his or her own Task Plan;

  • for a team to operate together, coordination between the Task Plans and relevant actors is achieved by context switching.

A couple of subtleties are created by the design choice to allow more than one principal performer for a Plan. Firstly, where a change of principle performer is indicated in a Task Plan, a change of concrete actor is normally intended at execution time, but this need not always be so. A Plan designed for mainly nursing tasks with one or two tasks for a consultant or other specialist could be fully performed by a single professional having the specific capacities required by the Plan.

Secondly, a change in principal performer within a Task Plan is not treated as a formal context switch, i.e. one formally represented in the Plan. Instead, the switch is assumed to be undertaken by means of allocation of the relevant actors, in a seamless manner within the same cognitive context (typically managed by verbal communication).

5.1.6. Allocation

Since a Task in a Task Plan being executed at runtime represents the Plan execution system’s knowledge of some work being performed in the real world, a way to connect the Task in the system (e.g. as shown on a UI application, or via notifications such as instant messaging) to the real-world actor performing it is needed. Following YAWL, the architecture described here treats allocation of work to a performer as a formal action during Plan execution. As per YAWL, more sophisicated implementations of Task Planning may offer numerous allocation strategies, such as first-available, quickest-to-complete, least-frequently-used and so on.

5.2. Phases of Definition and Representation

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

Phase Representation Purpose

Design time

Definition template
(archetypes of definition
classes)

A Task Plan template is a 'prototypical' definition of a Task Plan that may be used in multiple situations; it is represented in the form of openEHR templated archetype(s) based on the Task Planning definition model of this specification.

Clinical time -
planning

Concrete definition
(instances of definition
classes)

When a Task Plan prototype is used, it is created as instances of the Task Planning definition model (i.e. in the technical class/instance sense), and the result is understood as a concrete definition of the Task Plan to be used in a specific situation for a specific subject (i.e. patient); any modifications allowed by the archetypes may be made to achieve the specific Task Plan needed.

Clinical time -
plan execution

Materialised form
(instances of
materialised classes,
persisted over sessions)

At Plan execution time, a Task Plan definition will be 'materialised', i.e. instantiated into a form that can be used for execution and tracking of the Plan. In this form, repeatable sections of the definition are 'unfolded' into literal sections, for as many repetitions as required by the relevant performer(s).

Accordingly, parts of the materialised expression of a Plan may have an N:1 relationship with the original definition form. The materialised form has its own class model, containing additional data items to enable run-time tracking of the Plan as it is performed. During execution time, various kinds of deletions and modifications to the materialised representation, corresponding to changes in plan that respond to unexpected events.

Clinical time -
task execution

Runtime instantiation
(instances of
materialised classes,
during session)

Since a Plan execution may run over many hours, days or longer, the materialised expression will in general correspond to something larger than the literal in-memory instantiation of (parts of) the Plan required during any given user-application the session during which some or all of the Task Plan might be performed. The part of the plan currently being displayed, performed, tracked etc, is known here as the 'run-time instantiation', and consists of a subset of the total materialised form instances.

In this scheme, archetypes and templates conveniently provide a prototype level of definition that supports 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 which can then be further customised for particular patients at the concrete definition level.

5.2.1. Separation of Definition and Execution

According to the above, the concrete definition of a Task Plan is constructed in the 'planning phase' of clinical time, to define work to be done in the near future, by the planner and/or others. As the work is performed, the results are documented with openEHR Entries, such as Actions and Observations. During the execution of the plan there is usually a need to track the progress of the work in terms of Task completions, cancellations, failures, abandonment and so on.

As per the above table, the model defined in this specification separates the definition of Task Plans from their executions. This is achieved via definition and materialised parts of the model, corresponding to the concrete definition and materialised phases described above. Instances of the former are used to represent the definition of a plan, and would accordingly be used by a tools designed for that purpose. Similarly, run-time execution tools would be built using the materialised part of the model, as well as the definition part, since the latter is referred to by the former.

It is the materialised expression of a Plan that is used to record all Plan-related actions by Task performers. This state may be persisted for plans whose execution takes place over more than a user-application session.

The history of actions on the Plan can be understood as a set of transactions over time, and the model provides a third history part that can be used to efficiently represent this history, allowing it to be permanently recorded.

5.2.2. Model of Change

TODO: document how / when changes can be made, including during execution.

5.3. Execution Semantics

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

  • materialised state: after creation of the materialised Plan, the Plan may be modified by its user(s), and connections must be established between the Plan execution context and various channels via which performer allocation and communication can be achieved.

  • activated state: the materialised Plan is activated when the users want to proceed. This establishes the zero point of the execution clock, and will cause performer allocations and generate various kinds of notifications as time moves forward. During the work, Tasks become available (see below) as earlier Tasks are completed or cancelled. When a Task is available to be done, the performer has various options, including doing the work, cancelling the Task as not needed, completing the Task, aborting it, and abandoning the entire Plan.

  • terminated state: A Plan terminates when a path taken through the materialised Task graph terminates, either due to finishing, or due to abandonment at an intermediate Task. The Plan as a whole returns a termination status of success or fail, which may be used to control behaviour if it is part of a chain in which a context switch follows termination.

5.3.1. Task Lifecycle

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

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

5.3.2. Task Availability

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

  • Plan control flow;

  • real world time, if execution time is specified in the Plan, and;

  • subject pre-conditions.

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

Real-world execution time can be set for a Task, which means that even if it is available in terms of control flow, execution must wait until a specified time is reached. This may be simple clock time, a conventional time of day such as 'after lunch', or an event-relative time, such as 'at least 1 hour after last meal'.

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

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

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

The following diagram illustrates these concepts.

task semantics
Figure 4. Task Semantics

5.4. Relationship of Task Plans with existing openEHR Entry Types

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

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

planning artefacts
Figure 5. openEHR Planning Artefact Relationships

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

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

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

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

clinical process planning
Figure 6. 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.

5.5. Order Semantics versus Plan Semantics

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

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

6. Task Planning Model

6.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 WORK_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.

A WORK_PLAN is the outermost container for one or more TASK_PLANs that refer to each other in some way, as well as the meta-data documenting the plan.

Structurally, a TASK_PLAN has a definition (blue and green classes) consisting of various kinds of TASK. 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 prototype is a partly-defined Entry that will be cloned and populated at runtime when/if the Task is completed.

At clinical execution time, the materialsed form of the Plan is represented by M_XXX classes, which are instantiated when the plan is activated (central orange classes).

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

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

The key structural relationships are shown in the following instance diagram. On the left is a Task Plan definition, 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, Observation or other Entry that the Task defines.

In the centre is a materialised Task Plan, which is an execution-time structure used to maintain state for an executing Plan (achieved by the M_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 materialised 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). The right hand side shows a part of the materialised structure that is currently instantiated within a user-application session.

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 8. Task planning overview

6.2. Class Descriptions

The following classes are common to all sub-packages.

6.2.1. TASK_LIFECYCLE Enumeration

Enumeration

TASK_LIFECYCLE

Description

Enumeration representing possible lifecycle states for a Task lifecycle transition, for example, "not needed".

Attributes

Signature

Meaning

planned

Task is planned for the future.

available

Task is available for execution by performer.

cancelled

Task was cancelled without commencing.

abandoned

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

completed

Task was completed in the intended way.

suspended

Task is waiting for completion of a handoff or external request.

underway

6.2.2. SYSTEM_CALL Class

Class

SYSTEM_CALL

Description

Definition of a request to make to an external system (i.e. information system or device) via its API, that reads or writes information specific to the Task to which it is attached in an actual Plan.

TODO: for REST API, call spec is probably just a URI.

Attributes

Signature

Meaning

1..1

system_id: UID_BASED_ID

Identifier of target system, typically a domain name.

1..1

call_name: String

Name of call in API.

0..1

parameters: Hash<String, String>

Call parameters.

6.2.3. CALLBACK_TYPE Enumeration

Enumeration

CALLBACK_TYPE

Description

Attributes

Signature

Meaning

resume_next

Resume at the next Task.

resume_specified

Resume at a specified Task.

retry

Retry the dispatch.

7. Task Definition Model

7.1. Overview

The following figure shows the rm.task_planning.definition package in full.

RM task planning.definition
Figure 9. rm.task_planning.definition model

7.2. Principal Types and Structures

The following view of the above static model enables the key types and relationships that provide structure to be seen more easily.

RM task planning.definition tasks
Figure 10. rm.task_planning.definition - Tasks view

The top-level structure for defining plans is a WORK_PLAN, which includes one or more related TASK_PLANs making up a logical goal-oriented plan. Inclusion is achieved via UID references to Task Plans (WORK_PLAN.plans), not physical containment. This relationship allows related Task Plans to be grouped, which occurs for two reasons described earlier: re-use of Task Plans as sub-plans of other Task Plans, and team-based Plans, featuring hand-offs. How the Task Plans are linked to create these structures is enabled by particular sub-types of TASK, which may be understood by considering the model view above.

As can be seen, the definition of a TASK_PLAN is a TASK_GROUP, which has as its members any number of PLAN_ITEMs, of which the Task Group and various Task types are descendants. (The classes DECISION_GROUP and DECISION_PATH_GROUP are also PLAN_ITEM descendants, but are not included in the above view and are explained later.) This structure means that every Task Plan definition is contained in a Task Group, which contains any combination of more Task Groups and/or descendants of TASK.

The subtypes of TASK consist of the following (reaidng from the right hand side):

  • DEFINED_TASK: an inline-defined Task to be performed by the principal performer of the Group;

  • SYSTEM_REQUEST: a kind of Task that consists of a request to a computational system, such as a data retrieval or procedure call, on behalf of the current performer;

  • EXTERNAL_REQUEST: a Task type that consists of a request to an external organisational entity that is outside the current Work Plan and its execution environment, on behalf of the current performer;

  • HAND_OFF: a kind of Task that hands off to another Task Plan in the same Work Plan, having a different performer (identified via the target attribute inherited from LINKED_PLAN);

  • SUB_PLAN: a kind of Task that stands for another Task Plan (identified by the inherited LINKED_PLAN.target attribute) to be performed by the current performer - usually a fine-grained set of steps designed to achieve the result of this Task.

Three of these - SYSTEM_REQUEST, EXTERNAL_REQUEST and HAND_OFF - require passing the flow of work to another context, involving another party, which may be another human performer, an IT system or a machine. The flow may be specified to continue in the target context and then return to the current (block and wait), or it may be specified to fork so that the current flow continues in parallel with the external flow just created. These classes inherit from the class DISPATCHABLE which defines model attributes relevant to defining and controlling context switch.

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

7.2.1. Basic Semantics of all Task Types

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;

  • execution_time: optional timing plan for Tasks;

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

  • other_participations: participations other than the principal performer;

  • training_level: level of experience of performer; higher numbers indicate more experience.

From the control flow point of view, the preconditions and execution_time attributes are the ones that matter.

7.2.2. Task Group 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 11. Task grouping

7.2.3. Sub-plans and Re-use

As described above, multiple Task Plans may be used to define a single logical plan of work. This occurs for two main reasons:

  • re-use: Task Plans that can be used on their own, e.g. 'set up IV drip', are combined within a larger plan;

  • level of granularity: a Task Plan can contain Tasks that can be represented as finer-grained Task Plans, which may potentially be used or passed over depending on the level of experience, known here as training level of the performer.

The following instance diagram illustrates.

task linking
Figure 12. Task Plan linking

This shows a Plan for dialysis with a single performer, 'dialysis nurse', and several sub-plans, each referred to by an instance of the SUB_PLAN class. Since a Sub-plan is a kind of Task, it has a description and could be performed and signed off as if it were a normal inline DEFINED_TASK by an experienced performer (training level high), or it might be entered into by a performer such as a trainee nurse. The PLAN_ITME.training_level attribute can be used to set the experience level of sub-plans if required; implementing this behaviour at execution time would rely in the Plan execution engine using these settings.

7.2.4. Hand-offs and Coordinated Teamwork

The second kind of Work Plan containing multiple Task Plans corresponds to a team work situation, where each Task Plan has a distinct principal performer, normally defined in terms of role and/or function, e.g. 'chemotherapy nurse' + 'assistant'.

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 HAND_OFF class and the attributes inherited from DISPATCHABLE, i.e. wait, which determines switch or fork behaviour, and xxx_action attributes, which determine what to do depending on whether the requested work fails, succeeds or times out, for situations where the wait flag was set to True.

The following illustrates, using the example of an acute stroke management care process.

task coordination
Figure 13. Task coordination

In this Work Plan, three Task Plans are used to perform (parts of) the clinical work coordinated for managing an acute stroke, as per a Care Pathway. There are two Hand-offs, the first synchronous (wait = True; resume_task = next) and the second an asynchronous fork (wait = False).

7.2.5. External Request

The Task sub-type EXTERNAL_REQUEST represents a request by the current performer to an external entity outside of the current Plan computation context to perform some work on behalf of the performer. This is normally an organisation of which routine requests can be made. The request is defined in terms of an organisation identifier, a request identifier (i.e. a name or type of job) and a list of other details, represented by the standard archetypable ITEM_STRUCTURE.

Since an External Request represents a context change, the EXTERNAL_REQUEST class inherits from DISPATCHABLE, which enables a switch or fork to be specified, and in the case of a switch, how to process the return of control or a timeout.

7.2.6. System Request

In a similar way to External Request, the SYSTEM_REQUEST Task sub-type represents a request to a system with a computational interface on behalf of the performer. This might be to a special logging facility or a decision support system for example. The request is modelled in terms of a SYSTEM_CALL instance. It also inherits from DISPATCHABLE to enable context change handling.

7.2.7. Inline Defined Tasks

Tasks whose definitions are stated within a Task Plan are modelled using the DEFINED_TASK type. A detailed specification of the work to be done in a Defined Task may be stated via 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 following view of the UML illustrates.

RM task planning.definition defined task
Figure 14. rm.task_planning.definition - Definition Task

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 15. 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?

7.2.7.1. Data-sets and Application Interaction

Within the definition of a Defined Task, one or more data-sets may be specified for review and / or capture purposes (DEFINED_TASK.review_dataset and caputre_dataset). A 'data-set' in openEHR is a template, normally displayed as a form within an application. Either a template or form identifier (or both) maybe be used to specify a data-set. A review data-set is specified to signal to the Task Plan runtime system to request the display of data at the start of the Task, in order to provide data needed by the user for the Task and potentially following Tasks. A capture data-set is specified when the purpose of the Task is to record data.

TBD: a single attribute may be sufficient.

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

RM task planning.definition decision
Figure 16. rm.task_planning package definition model (decision view)

The following diagram shows a typical decision structure.

decision structure
Figure 17. 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.

7.4. Plan Data Context

A Task Plan may contain various logic expressions, occurring in the following places:

  • TASK_PRECONDITION.expression;

  • DECISION_GROUP.value_expression and DECISION_PATH_GROUP.test_expression;

  • TASK_REPEAT.terminate_condition.

These expressions may mention variables that are typically related to subject state, such as patient vital signs, key demographic characteristics and so on, or the clinical care process, such as the 'time since stroke event'. In order to allow expressions to use symbolic variables such as is_female or stroke_time within logical expressions, a way of defining each variable is required. This is provided by the CONTEXT_VARIABLE type within PLAN_DATA_CONTEXT, a data context object at the Task Plan level.

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

TBD: to be continued; see also openEHR Expression language.

7.5. Detailed Plan Semantics

7.5.1. Repetition

TBD: to be described

7.5.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. The following view of the model shows the timing classes in detail.

RM task planning.definition timing
Figure 18. rm.task_planning package definition model (timing view)

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;

  • state-linked time: the Task is to be executed at a time related to the state of the subject, as specified by an instance of STATE_LINKED_TIMING. This uses a Boolean-valued condition attribute to state a condition which when true indicates that a Task time-to-execute has been reached. The test_period attribute indicates when to retest the condition.

TODO: add a max time or time-out.

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.

7.5.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 are intended to be used to express real-world conditions containing references to subject state, such as vital signs, white cell count and so on. Pre-conditions should be evaluated at the point at which the Task to which they are attached enter the lifecycle state available. If any pre-condition evaluates to False, the Task is in theory unable to be performed. A clinical professional may override at execution time, since it may always be the case that particular circumstances obviate the need for a particular pre-condition that normally applies.

7.5.4. Training Level

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

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

The default value of training_level is 0.

7.5.5. References to Design-time Artefacts

WORK_PLAN and TASK_PLAN contain various references to external artefacts that they are typically based on or relate to, as follows:

  • In WORK_PLAN:

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

    • care_pathway: references to a care pathway from which this Task Plan was derived, if any;

  • In TASK_PLAN:

    • guideline: reference to a published guideline from which this particular Task Plan was derived, if any;

    • best_practice_ref: reference to an institutional document that defines the best practice on which this Task Plan is based, if any;

    • order_set: the identifier of an Order Set which this Task Plan uses, if any;

    • workflow_id: an identifier shared among orders (INSTRUCTIONs and ACTIONs) from the Order Set instance used in this Task Plan, if any.

7.6. Interaction with the EHR

7.6.1. Versioning and EHR Committal

If a WORK_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;

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

TBD: review the following para

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.

7.7. 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:

  • control-flow: check completion status of preceding Tasks / Groups within the current Task Group;

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

  • validity:

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

7.8. Class Descriptions

7.8.1. WORK_PLAN Class

Class

WORK_PLAN

Description

Top-level object of any logical work plan. References one or more TASK_PLANs that described the work, typically of each performer, although a single TASK_PLAN may also have multiple performers.

Inherit

AUTHORED_RESOURCE, CONTENT_ITEM

Attributes

Signature

Meaning

0..1

care_pathway: DV_IDENTIFIER

Identifier of care pathway etc, on which this Work 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

plans: List<UID_BASED_ID>

0..1

care_plan: LOCATABLE_REF

Care plan in EHR from which this Work Plan is derived, if any.

0..1

order_list: List<LOCATABLE_REF>

Reference list of orders in this Work Plan.

1..1
(redefined)

description: DV_TEXT

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

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

LOCATABLE

Attributes

Signature

Meaning

1..1

description: DV_TEXT

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

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

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"

1..1

definition: TASK_GROUP

The Tasks for the main part of this Task Plan; this section of the plan may be repeatable.

0..1

execution_history: TASK_PLAN_EXECUTION_HISTORY

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

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.

0..1

due_time: Duration

Due date/time expressed as an offset, to be converted to a real date/time at activation.

0..1

order_set: DV_IDENTIFIER

Optional identifier for an order set, which is understood as a type of order set, e.g. 'R-CHOP-14'.

0..1

workflow_id: OBJECT_REF

Identifier of instance of order set from which this Task Plan is drawn, if there is one. Should match the workflow_id in all INSTRUCTION and other ENTRY instances created due to the same order set instance.

TODO: needed?

0..1

context: PLAN_DATA_CONTEXT

0..1

indications: List<DV_TEXT>

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

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

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

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

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

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.

7.8.6. TASK_PRECONDITION Class

Class

TASK_PRECONDITION

Description

Conditions expressing when the Task is executable with respect to the principal performer and subject.

Attributes

Signature

Meaning

1..1

description: 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.8.7. 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.

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

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

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

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

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

7.8.12. STATE_LINKED_TIMING Class

Class

STATE_LINKED_TIMING

Description

Timing specified relative to subject state, e.g. vital sign value.

Inherit

TIMING_SPEC

Attributes

Signature

Meaning

1..1

condition: DV_PARSABLE

Condition that when true

0..1

test_period: Duration

Time period to delay and then retest condition.

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

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

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

repeat_spec: TASK_REPEAT

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.

7.8.15. TASK_REPEAT Class

Class

TASK_REPEAT

Description

Definition of repetition for a Task Group. The repeats attribute provides a constraint on a number of times. If not set, any number of repeats is allowed. The terminate_condition attribute defines when repetition should cease in terms of a condition, typically a subject-related variable.

Attributes

Signature

Meaning

0..1

repeats: Interval<Integer>

Range of repetitions. If the lower limit is greater than zero, at least one repeat is required. A range such as 0..3 means up to 3 repeats possible, but not required.

0..1

terminate_condition: DV_PARSABLE

States a condition for when repetition should stop.

7.8.16. 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. Each of these expressions must have mutually exclusive value ranges to be valid.

1..1

paths: List<DECISION_PATH_GROUP>

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

7.8.17. 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. Must be a mutually exclusive value range with respect to sibling DECISION_PATH_GROUPs.

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

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

Attributes

Signature

Meaning

0..1

instruction_activity: LOCATABLE_REF

Optional reference back to the ACTIVITY of an INSTRUCTION that generated this TASK.

7.8.20. LINKED_PLAN Class

Class

LINKED_PLAN (abstract)

Description

Task type that represents a dispatch to another Task Plan to be executed by another performer in a Plan Group.

Inherit

TASK

Attributes

Signature

Meaning

1..1

target: UID_BASED_ID

UID of target TASK_PLAN object.

7.8.21. SUB_PLAN Class

Class

SUB_PLAN

Description

A Task referencing another Plan within the same Work Plan, to be executed by the current performer. Execution continues on from the previous Task.

For an experienced performer, the referenced Plan, which is usually more detailed may not be needed.

Inherit

LINKED_PLAN

7.8.22. HAND_OFF Class

Class

HAND_OFF

Description

A kind of Task representing a hand-off to a different performer in the current Work Plan.

Tasks of the linked Plan become available to that performer, who is also alerted to start work.

A hand-off usually involves waiting with later notification (callback), or continuation. Waiting would typically mean the Plan execution engine places this Plan on a wait list, enabling the performer to proceed with work on other subjects.

Inherit

LINKED_PLAN, DISPATCHABLE

7.8.23. EXTERNAL_REQUEST Class

Class

EXTERNAL_REQUEST

Description

Task type for representing a request to an external organisational service or actor not within the current Work Plan.

Inherit

TASK, DISPATCHABLE

Attributes

Signature

Meaning

1..1

organisation: PARTY_PROXY

Identifier of organisation to which the request or order is addressed.

1..1

request_id: String

0..1
(redefined)

other_details: ITEM_STRUCTURE

Request details.

TODO: more details needed.

7.8.24. SYSTEM_REQUEST Class

Class

SYSTEM_REQUEST

Description

Request to an external system.

Inherit

TASK, DISPATCHABLE

Attributes

Signature

Meaning

1..1

system_call: SYSTEM_CALL

7.8.25. DEFINED_TASK Class

Class

DEFINED_TASK

Description

Task sub-type that represents concretely defined 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.

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.

0..1

review_dataset: List<DATASET_SPEC>

Optional data-set to review prior to / as part of performing Task. This implies a data retrieval from the EHR or other system, which may be specified using a SYSTEM_REQUEST attached to this Task.

0..1

capture_dataset: List<DATASET_SPEC>

Associated data-set template and/or form via which data to be captured during this Task will actually be entered.

0..1

optionality: VALIDITY_KIND

Informal indication of whether Task is considered optional or not from the point of view of any guideline. If not set, the Task is treated as mandatory.

TODO: is this useful or meaningful, since it can change

7.8.26. DATASET_SPEC Class

Class

DATASET_SPEC

Description

Specification of a related data-set and/or form to use with a Task.

Attributes

Signature

Meaning

0..1

form_id: String

Form identifier.

0..1

template_id:

Template identifier. If used with no form_id, the Execution engine needs to determine how to find a form based on the template identifier.

0..1

other_details: ITEM_STRUCTURE

Other data-set related details.

8. Task Execution Model

8.1. Overview

The following figure shows the execution related parts of the rm.task_planning package. The consists of two parts: the materialised representation, 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 19. rm.task_planning package - execution model

As described in Execution Semantics, Plan execution traverses three states: materialised, activated and terminated, as follows:

  • materialised state: at any time after creation of the materialised Plan from its definition form, the following actions are possible:

    • Various changes can be made to the materialised structure, as long as they do not violate the constraints on the definition;

    • Connection to a notification push-channel must be made for every principal participant and external system mentioned in the Plan definition; these channels do not have to be all different (i.e. multiple parties may be communicated with via a single channel that talks to say a ward screen).

    • Advance allocations of Tasks to concrete participants may be made in this phase;

  • activated state: the materialised Plan is activated at some point in time after creation.

    • This establishes the zero point of the execution clock, and will cause various kinds of notifications to occur as time moves forward.

    • The execution system then creates notifications through the various channels to indicate Tasks to be executed for each type of performer.

    • Where performers are already allocated, they may commence work and indicate back to the system the state of each Task as it proceeds through its lifecycle (below).

    • For Tasks that are not yet allocated, a notification soliciting an acceptance is posted when this is responded to by a user, work begins.

    • During the work, Tasks become available (see below) as earlier Tasks are completed or cancelled. When a Task is available to be done, the performer has various options, including doing the work, cancelling the Task as not needed, completing the Task, aborting it, and abandoning the entire Plan.

    • As the work proceeds, event records are generated and added to the execution history.

    • The Plan remains in the active state until abandoned or completed.

  • terminated state: A Plan terminates when a path taken through the materialised Task graph terminates, either due to finishing, or due to abandonment at an intermediate Task.

    • The Plan as a whole returns a termination status of success or fail, which may be used to control behaviour if it is part of a handover chain in which a context switch follows termination.

    • A final event record is added to the 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.

8.2. Materialisation

When a Work Plan is to be executed, it will be materialised. Some user input may be required, e.g. number of repetitions of repeatable sections. The materialised representation consists of:

  • A copy of the definition form of the Plan;

  • An instance of the Plan using Materialised model instances, i.e. the M_XXX classes, representing the concrete executable Tasks, each with a reference back to a definition Task. For Plans with repeatable sections, the Materialised model contains these sections 'unrolled' into as many instances as required by the Plan activator. Thus, more than one M_TASK may point to the same generating TASK from the definition form.

The structure created will this mirror the structure of the original definition, with extra copies for repeatable sections. That is to say, M_TASK_GROUP instances will have members containing further M_XX instances, that mimic the TASK_GROUP structures within the Plan definition.

TBD: Structural modifications

  • alter repeating section repeats

  • remove decision branches and Tasks whose conditions will never be met

TBD: Connection setup

TBD: Allow pre-allocations

8.3. Activation

A materialised Plan is activated when it is ready to be used. Activation 'starts the clock'; accordingly, the M_TASK_PLAN attribute start_time is set to the current time. Execution times in the Plan are converted to absolute clock times, or a form that can be related to clock time.

The materialised 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 M_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.

When the structure creation has been completed, the lifecycle_state attribute of one or more M_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 materialisation time, an instance of EXECUTION_HISTORY is also created, proving a root point to accumulate Task Plan execution event records.

8.4. Termination

TBD

8.5. Execution Time Semantics

8.5.1. Allocation and re-allocation

Before a materialised Task Plan can be executed, the principal_performers of its TASK_GROUPs must be allocated to real actors. This is done by user(s) authenticating to the Plan execution engine and signing up for specific roles and functions within the Plan. Not all performers are needed at any time, only those implicated in some defined part of the Plan to be executed, e.g. for the current day within a multi-day Plan.

At various moments during the execution of a Plan, a performer may leave and be replaced by another performer, e.g. due to worker shift changeover. This requires a de-allocation of the leaving performer from the Plan and a new allocation of a new actor.

8.5.2. Task Lifecycle Model

During execution, each Task is represented by an instance of M_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 M_TASK.lifecycle_state. The lifecycle is simple, since it only has to take account of the states a Task itself can pass through - states of any order with which the Task may be associated will be visible in the documentation of the Task execution, i.e. separate openEHR ACTION or other Entry objects. The states are as follows:

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

  • planned: defined, but not yet available for execution;

  • available: available for execution, due to previous Tasks having been performed, preconditions being met, and if there is a time specification on the Task, the current time being at or later than the stated time;

  • cancelled (T): cancelled prior or during execution as not needed for success of the Plan;

  • completed (T): performed to completion;

  • abandoned (T): execution was stopped before or after commencement due to completion being impossible.;

  • underway: indicates that a Task execution has been commenced;

  • suspended: indicates that a Task execution has been suspended.

In the above, the terminal states are marked with '(T)'. The state machine is shown below.

RM TaskStateMachine
Figure 20. Task lifecycle state machine

A key feature of the state model is that the terminal states determine whether the Plan exeuction continues or not: if the abandoned state is entered, it does not.

ISSUE: in this scheme, if a Task has been started and has to be aborted, but the Plan doesn’t need to be abandoned, a transition to cencelled is required. There are thus no distinct state for 'Task aborted (continue)' and 'Task aborted (abandon).

The state machine is primarily designed to allow a stateless view of the actual execution state of a Task. That is to say, the standard pathway is availablecompleted or abandoned or cancelled, which enables a user to indicate the outcome of executing a Task, but not interim states during execution. The pathways through the states underway and suspended are provided to represent in-execution states if needed, typically for longer-running atomic Tasks.

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, a user override can be used, represented by the override pathway from plannedavailable.

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 M_TASK_GROUP from the set of states of its members (which may include other M_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) {

    if (sourceStates.contains(Abandonned))
        return Abandonned;
    else if (sourceStates.contains(Available))
        return Available;
    else if (sourceStates.contains(Planned))
        return Planned;
    else if (sourceStates.contains(Completed))
        return Completed;
    else if (sourceStates.contains(Suspended))
        return Suspended;
    else if (sourceStates.contains(Suspended))
        return Suspended;
    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.

8.5.3. Notifications

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

To be continued

8.5.4. Context Switching

TBD: describe context switch for hand-off, external requests etc. The notion of resume_location implies a need to reset Task states for re-entrant processing.

8.5.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?

8.6. Class Descriptions

8.6.1. M_TASK_PLAN Class

Class

M_TASK_PLAN

Description

Root object of a materialised Task Plan structure, used in execution.

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: M_TASK_GROUP

Root of run-time Task Plan Task structure.

1..1

owner: TASK_PLAN

Owning Task Plan definition.

0..1

pending_callbacks: List<M_CALLBACK>

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

1..1

context: M_PLAN_DATA_CONTEXT

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.

8.6.2. M_PLAN_DATA_CONTEXT Class

Class

M_PLAN_DATA_CONTEXT

Description

Attributes

Signature

Meaning

1..1

definition: PLAN_DATA_CONTEXT

Definition object for this execution time context.

8.6.3. M_CALLBACK Class

Class

M_CALLBACK

Description

Class representing the runtime tracked form of a callback for currently blocked tasks.

Attributes

Signature

Meaning

1..1

task_item: M_TASK

Reference to the Task Item blocked waiting on this callback.

1..1

dispatch_info: DISPATCHABLE

Dispatch object defining actions on receipt of callback.

1..1

other_details: Hash<String, String>

8.6.4. M_PLAN_ITEM Class

Class

M_PLAN_ITEM (abstract)

Description

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

Attributes

Signature

Meaning

0..1

other_participations: List<M_ALLOCATION>

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.

8.6.5. M_TASK_ITEM Class

Class

M_TASK_ITEM (abstract)

Description

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

Inherit

M_PLAN_ITEM

Attributes

Signature

Meaning

1..1
(redefined)

definition: TASK_ITEM

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

8.6.6. M_TASK_GROUP Class

Class

M_TASK_GROUP

Description

Materialised run-time homologue of TASK_GROUP from a Task Plan definition.

Inherit

M_TASK_ITEM

Attributes

Signature

Meaning

0..1

members: List<M_PLAN_ITEM>

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

1..1

principal_performer: M_ALLOCATION

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

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.

8.6.7. M_TASK Class

Class

M_TASK

Description

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

Inherit

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

8.6.8. M_DECISION_GROUP Class

Class

M_DECISION_GROUP

Description

Materialised run-time homologue of DECISION_GROUP from a Task Plan definition.

Inherit

M_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<M_DECISION_PATH_GROUP>

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

8.6.9. M_DECISION_PATH_GROUP Class

Class

M_DECISION_PATH_GROUP

Description

Materialised run-time homologue of DECISION_PATH_GROUP from a Task Plan definition.

Inherit

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

8.6.10. M_ALLOCATION Class

Class

M_ALLOCATION

Description

Attributes

Signature

Meaning

1..1

performer: PARTY_IDENTIFIED

1..1

connection: URI

URI used to connect to performer (e.g. application, messaging channel) for notifications.

1..1

other_details: Hash<String, String>

8.7. 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 accumulates 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.

8.7.1. Class Descriptions

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

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

8.7.1.3. TASK_PLAN_EVENT_RECORD Class

Class

TASK_PLAN_EVENT_RECORD

Description

Record of an runtime event to a Task Plan, including abandonment, performer allocation and re-allocation and so on.

Inherit

EVENT_RECORD

Attributes

Signature

Meaning

1..1

details: Hash<String, String>

Other details as a name/value list.

8.7.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<LOCATABLE_REF>

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.

0..1

lifecycle_transition_reason: String

Additional reason for lifecycle

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

8.8. Cost Tracking

TBD: describe cost tracking.

8.8.1. Class Descriptions

8.8.1.1. TASK_COSTING Class

Class

TASK_COSTING

Description

Costing information for a Task.

TODO: to be developed.

8.9. 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:

8.9.1. Class Descriptions

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

9. Relationship with other openEHR EHR Artefacts

9.1. TODO

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.

9.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 21. 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.

10. Scenarios

10.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 22. 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.

10.2. Check-list and Sign-off

TBD

10.3. Changes during Execution

TBD

10.4. Abandonment

TBD

11. Implementation Guidance

11.1. Workflow Application Design

TODO:

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