openEHR logo

Task Planning Model Specification

Issuer: openEHR Specification Program

Release: latest

Status: TRIAL

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

1.0.1

SPECPROC-2 Fix various typos; add missed BOOLEAN_CONTEXT_EXPRESSION; Remove duplicate attribute WORK_PLAN.events.

M Kejžar

24 Oct 2017

1.0.0

SPECPROC-1 Further documentation improvements; Added explanations for resume semantics; added RESUME_ACTION class.

T Beale

17 Oct 2017

0.9.0

SPECPROC-1 Restructure document; Various refactoring of Event classes; global calendar, timeline.

T Beale

12 Oct 2017

0.8.2

SPECPROC-1 Workshop Sep 25-28 and follow-up calls;
Significant updates to model;
Include event-based design;
Moved spec to new PROC openEHR component.

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

10 Oct 2017

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

Primary Author

  • Thomas Beale, Ars Semantica (UK); openEHR Foundation Management Board.

Contributors

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

  • Borut Fabjan, Program Manager, Marand, Slovenia

  • Matija Kejžar, Marand, Slovenia

  • Bostjan Lah, Architect, Marand, Slovenia

  • Eugeny Leonov, Solit Clouds, Moscow, Russia

  • Ian McNicoll MD, FreshEHR, UK

  • Bjørn Næss, DIPS, Norway

  • Pablo Pazos Gutierrez, CaboLabs, Uruguay

  • Pekka Pesola, Engineer, Tieto, Finland

  • Vladimir V Makarov, Department of Information Technologies, City of Moscow

Support

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

  • City of Moscow

  • Marand d.o.o., Slovenia

  • DIPS, Norway

  • Ars Semantica, UK

Intellectual Origins

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

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

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

Trademarks

  • 'openEHR' is a trademark of the openEHR Foundation.

  • 'OMG' is a trademark of the Object Management Group.

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 TRIAL state. The development version of this document can be found at http://www.openehr.org/releases/PROC/latest/task_planning.html.

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

TBD: (example To Be Determined paragraph)

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

1.4. Conformance

Conformance of a data or software artifact to an openEHR Reference Model specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal, automated derivations from the Reference Model, ITS conformance indicates RM conformance.

2. Background

2.1. Survey of Requirements

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

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

  • 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 item corresponds to a set of openEHR Instructions, while the second is a candidate for representation in openEHR via the Task Planning facility documented in this specification. Hence, the addition of Task Planning to openEHR provides an important element enabling the order set notion to be formalised in openEHR.

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

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

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

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

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

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

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

2.2. Limitations of 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.

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

2.4. Task Plans versus Task Lists (TODO Lists)

The specification is based around the concept of a task plan, which is designed to achieve a goal, and at execution time is applied to a subject, i.e. human or other subject of care. The plan notion is thus goal- and subject-centric.

A related concept is that of the task list (aka 'TODO list'), which is a logical list of tasks for a worker to perform. The task list is thus worker-centric, not subject-centric, and as such, task lists must be derived from task plans. Conceptually this is done by processing all extant task plans for some organisational unit (say a hospital department) and allocating particular tasks to particular actors. Allocation may happen in a just-in-time fashion, and may be modified (e.g. due to unforeseen unavailability of workers), such that a task list is essentially a dynamic personal calendar view for the short term (typically days or weeks) whereas task plans may correspond to any length of time, from a few minutes to years.

This specification does not cover the model of worker task lists or extracted calendar views, although it provides some guidance on how to generate task lists for workers.

2.5. Execution Paradigm

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

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

  • computing environment:

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

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

  • real world:

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

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

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

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

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

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

This environment can be illustrated as follows.

workflow execution paradigm
Figure 2. Work plan execution paradigm

2.6. 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). Of these, YAWL is the most comprehensive in its design and the most useful source of concepts for the current specification.

While the model described here takes ideas from these languages, there are some key differencs as well. The primary conceptual difference is that the subject (i.e. 'case') here is assumed to be a) an intentional agent (generally a human patient) that makes choices, and b) an active biological organism, which reacts to drugs and other interventions. In other words, an entity that cannot be considered a passive object (such as a package or blood sample), as is the case for most logistic workflows, for which languages such as BPMN are designed. (Note that even the patient can be a passive object in some circumstances, such as radiology.) Other departures include the use of a declarative rather than prescriptive means of defining the plan graph structure, and the formalisation of all elements of a plan and its execution.

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

3. Requirements

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

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

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

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

  • dialysis - recurrent therapeutic procedure;

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

  • surgery planning - one time event;

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

Within these and many other similar clinical procedures, a number of commonly occurring generic requirements appear, as described below.

3.1. Planned Tasks for an Order

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

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

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

3.2. Order Sets and Protocols

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

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

(R)ituximab

375 mg/m²

375 mg/m²

IV infusion

Day 1

(C)yclophosphamide

750 mg/m²

1200 mg/m²

IV infusion

Day 1

(H)ydroxydaunorubicin

50 mg/m²

75 mg/m²

IV bolus

Day 1

(O)ncovin

1.4 mg/m² (max. 2 mg)

2 mg

IV bolus

Day 1

(P)rednisone or (P)rednisolone

40 mg/m²

100 mg

PO qd

Days 1-5

(Extract from Wikipedia.)

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

3.3. Lookahead Plan

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Design Principles

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

4.1. Computational Basis

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

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

4.2. Computational Context

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

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

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

The overall context is shown below.

computational environment
Figure 4. Computational Environment

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

4.3. Conceptual Basics

4.3.1. Work Plan

The top-level formal concept defined is the Work Plan, which consists of one or more Task Plans. The Work Plan is a definition of work to be performed by one or more workers in order to achieve a defined goal with respect to a 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, by a 'principal performer' and possibly other participants. Multiple Task Plans occur for two reasons:

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

  • sub-plans subordinate to a parent Task 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. A Work Plan will often be limited to a single enterprise, but this need not be the case, as long as all of its Task Plans communicate within the same Plan execution context.

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

4.3.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 Task lists occur commonly (and will be the top-level structure in simple cases). The formal construct provided for this is the Task Group, which may contain Tasks and more Task Groups.

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 Task 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 power of the Task Group / Task structure can be significantly augmented in another dimension with the addition of conditions, to create conditional structures. These can be used to represent a variety of logical choice structures, equivalent to the following programming concepts:

  • if/elseif/else: a standard multi-branch logic chain with any condition on each branch, evaluated in order;

  • switch: a standard multi-way logic structure based on a single condition and branches for multiple value sub-ranges;

  • rule-set: a typical chained event-driven rule structure whereby each branch is defined to fire on reception of a specific kind of event.

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.

  • conditional Group types: special kinds of Task Group that enable conditional logic structures 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.

4.3.3. Graph Structure

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

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

  • at least N members must complete for group to complete

  • exit group on first succeeding task

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

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

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

The following diagram shows the taxonomy of task types.

task taxonomy
Figure 5. Task Taxonomy

4.3.6. Principal Performer

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

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

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

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

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

4.3.7. Time and Wait States

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

Time is understood in three possible ways:

  • as a relative offset from the start of the Plan timeline, when it is activated;

  • as an absolute time as marked on a calendar;

  • as the time of an event.

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

  • timer event: an event caused by a timer that expires;

  • state trigger: a condition based on one or more watched variables available from the computation environment, including subject variables (sex, vital signs, etc) and variables relating to clinical processes, e.g. 'time since emergency admission'.

  • task transition: an event generated by the state transition of a Task during execution so far, e.g. the previous Task completing;

  • callback notification: an event generated by a notification received on completion of a Task dispatched to a different Plan or an external system;

  • system notification: an external event is notified to the system by a user, e.g. receipt of a phone call.

  • manual notification: an external event is signalled manually to the system by a user, e.g. receipt of a phone call.

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

4.4. Levels 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 model
(archetypes and templates
of definition classes)

At the model level, a Work Plan and its constituent Task Plans are represented in the form of openEHR templated archetype(s) based on the Task Planning definition model of this specification.

Multiple layers of modelling may be used to represent a range of Plan Templates from the more general to the specific, and then templated to define a near subject-specific Plan. For example a general model may be built to represent a 'chemotherapy' Plan; a specalised form of this may represent R-CHOP protocols; an even more specialised one may represent a particular institution’s form of this protocol.

Clinical time -
planning

Instantiated definition
(instances of definition
classes)

When a Work Plan model 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).

When the instantiation is performed, the model-user may provide values for particular parts of the model, such as medication dosages, that correspond to the particular patient. They may also make other limited adjustments that are compatible with the archetypes and template.

Clinical time -
plan execution

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

Close to Plan execution time, a Work Plan definition will be 'materialised', i.e. instantiated into a form that can be used for execution and tracking of the Plan. At the point of materialisation, the definition model must be published and persisted, guaranteeing the its availability as the reference model for its materialised expressions. It may be materialised any number of times, corresponding to the distinct number of instances of use required. Each materialisation

In the materialised 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.

Unreachable decision paths may be removed, and where possible decision nodes, simplifying the materialised form compared to the 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 are possible, 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, archetype- and template-based modelling is used as much as possible in order to create layers of re-usable models that are progressively more specialised, until close-to-patient models are achieved, typically as templates. This enables the power of the archetype modelling formalism, including specialisation and composition to be used freely, in a similar manner to an object-oriented programming environment.

4.4.1. Separation of Definition and Execution

According to the above, the concrete definition of a Work 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 Work 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.

4.5. Execution Concepts

4.5.1. Plan Execution Lifecycle

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 pre-allocations done of performers.

  • activated state: the materialised Plan is activated when the users want to proceed. Connections must be established between the Plan execution context and various channels or APIs via which performer allocation and communication can be achieved. Activation 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 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.

4.5.2. 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 Plan as it is in the system (e.g. as shown on a UI application, or via notifications such as instant messaging) to the real-world actors performing it is needed. Following YAWL, the architecture described here treats allocation of work to a performer as a formal activity during Plan execution.

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

  • individuals, specified in the Plan definition in terms of role and/or function within principal performer and other participations e.g. 'cardiologist';

  • a worker pool, i.e. group of equivalent workers, e.g. nurses on a particular ward; here, any one of the workers can perform a given Task, and the workers may swap over time.

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

  • the Plan or Task is assigned to a real individual or worker pool;

  • an appropriate worker claims a Plan (if Plans are posted somewhere, awaiting workers) or accepts the Task (if Plan invitations are sent to individuals).

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

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

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

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

4.5.4. Availability

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

  • Execution control flow reaches the Task;

  • External precondition, if any, is met;

  • Subject preconditions if any, are met.

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

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

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

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

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

The following diagram illustrates these concepts.

task availability
Figure 6. Task Availability

4.5.5. Adaptive Modification and Exception-handling

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

  • logical deletion: Tasks can be skipped by two types of cancellation in the lifecycle: cancelled (not needed) and aborted (abandon plan); if cancelled is used, this has the benign effect of skipping past a Task;

  • logical addition: work items that are not represented as Tasks in a Task Plan can always be done, such as making extra patient observations or performing unplanned patient actions (e.g. refit a catheter, change a dressing); in openEHR they will always be recorded in the normal manner via Observation and Action Entries;

  • overrides: various aspects of a Plan definition can be overridden at runtime, such as Task execution time and subject preconditions (such as BP < 160 mm[Hg]). Override is represented in the system as an alternative lifecycle transition that puts a Task into the available state even if not all conditions have been met for availability.

4.6. 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 7. 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 8. Clinical Investigator Process with Planning

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

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

5. Task Planning Model Overview

The following UML diagram shows the rm.task_planning package in overview form, showing the constituent packages, definition, materialised, and history. The first of these packages contains the class model for the definition model expression of a Work Plan, i.e. the workflow structure intentionally designed to achive a goal.

The materialised package contains the class model of the amterialised form of the definition, which is created prior to its use in execution. The materialised model is presented in outline only, as a way of indicating some of the general features of the materialised form, and is not intended to be normative. (At some point in the future, a skeleton materialised model may be declared normative, based on implementation experience).

The history package contains the model of audit events that have occurred to each Task Plan in a Work Plan during execution.

PROC task planning overview
Figure 9. rm.task_planning package overview

The following instance diagram illustrates the relationships among these models for one Task Plan. On the left is a Task Plan definition, consisting of a Task Group and various Defined Actions. 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. This structure allows the representation of all state to do with Plan 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 via various references. The right hand side of the diagram shows a part of the materialised structure that is currently instantiated within a user-application session.

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

task planning overview
Figure 10. Task planning overview

5.1. Identification and Referencing

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

5.2. Specifying Time

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

5.3. Plan Data Context

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

PROC task planning.definition context
Figure 11. Task planning - context values

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

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

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

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

5.4. Class Descriptions

5.4.1. PLAN_DATA_CONTEXT Class

Class

PLAN_DATA_CONTEXT

Description

Container for all variable definitions used in the Task Plan.

Attributes

Signature

Meaning

0..1

variables: List<CONTEXT_VARIABLE>

List of all variables tracked by this Plan.

0..1

expressions: List<CONTEXT_EXPRESSION>

List of all expressions used in the Plan, based on tracked variables.

5.4.2. CONTEXT_VALUE Class

Class

CONTEXT_VALUE (abstract)

Description

Any kind of value used in the Plan definition. Typed by the formal type of the value, i.e. Boolean, Integer etc. The types are represented by EXPR_TYPE_DEF descendants.

Attributes

Signature

Meaning

1..1

type: T

Type of this variable.

5.4.3. CONTEXT_VARIABLE Class

Class

CONTEXT_VARIABLE (abstract)

Description

Any kind of symbolic variable that can be used within Expressions in the Task Plan, including in pre-conditions and decision pathways.

Inherit

CONTEXT_VALUE

Attributes

Signature

Meaning

1..1

name: String

Name of variable, as used in precondition and decision expressions.

0..1

populating_request: SYSTEM_CALL

Optional specification of a system request that would populate a context variable.

5.4.4. EVENT_VARIABLE Class

Class

EVENT_VARIABLE

Description

Variable whose value is required to be the latest; ideally, updating would be implemented by listener model.

Inherit

CONTEXT_VARIABLE

5.4.5. CONTINUOUS_EVENT_VARIABLE Class

Class

CONTINUOUS_EVENT_VARIABLE

Description

Dynamically updated variable of any continuous type whose value may change by arbitrarily small amounts. The update_variation attribute may be used to control updating frequency.

Inherit

EVENT_VARIABLE

Attributes

Signature

Meaning

0..1

update_variation: Real

Minimum percentage variation from current value to be considered a change that should cause an update.

5.4.6. STATE_VARIABLE Class

Class

STATE_VARIABLE

Description

Variable that is updated by polling, and is regarded as correct as long as the last update occurred at or more recently than the required currency.

Inherit

CONTEXT_VARIABLE

Attributes

Signature

Meaning

0..1

required_currency: Duration

Required currency of data in target system (e.g. EHR) to be considered valid in the context of this Task.

5.4.7. CONTEXT_EXPRESSION Class

Class

CONTEXT_EXPRESSION

Description

An expression that references one or more context variables. At run time, Context Expressions are updated when changes to their dependent variables are detected.

Inherit

CONTEXT_VALUE

Attributes

Signature

Meaning

1..1

expression: String

Expression, in openEHR Expression syntax.

5.4.8. BOOLEAN_CONTEXT_EXPRESSION Class

Class

BOOLEAN_CONTEXT_EXPRESSION

Description

Boolean-valued form of CONTEXT_EXPRESSION.

Inherit

CONTEXT_EXPRESSION

5.4.9. SYSTEM_CALL Class

Class

SYSTEM_CALL

Description

Definition of a request to make to a 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.

This could include OS calls, e.g. to launch an application for a certain user.

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.

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

Task has been commenced.

resumed

Task has been resumed from suspend state.

5.4.11. RESUME_TYPE Enumeration

Enumeration

RESUME_TYPE

Description

Enumeration of types of resume behaviour after a callback.

Attributes

Signature

Meaning

resume_specified

Resume at a specified Task in the same thread of control.

retry_current_group

Retry Tasks starting at the top of the current Group.

new_thread

Recommence as a new thread of execution at restart_location.

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

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

5.4.14. TIME_SPECIFIER Class

Class

TIME_SPECIFIER (abstract)

Description

Abstract parent of types used to specify a point in time.

5.4.15. CLOCK_TIME Class

Class

CLOCK_TIME

Description

A point in time within a day.

Inherit

TIME_SPECIFIER

Attributes

Signature

Meaning

1..1

time: Time

Time expressed as a clock time within a day.

5.4.16. CALENDAR_TIME Class

Class

CALENDAR_TIME

Description

An absolute point in time., i.e. date + time, locatable on a calendar.

Inherit

TIME_SPECIFIER

Attributes

Signature

Meaning

1..1

time: Date_time

Time expressed as an absolute date/time.

5.4.17. CUSTOMARY_TIME Class

Class

CUSTOMARY_TIME

Description

Time specified in some customary way, such as 'morning', 'afternoon', etc, that must be interpreted to determine an equivalent format time.

Inherit

TIME_SPECIFIER

Attributes

Signature

Meaning

1..1

time: DV_CODED_TEXT

A coded term expressing a customary time in natural language.

6. Definition Model

6.1. Overview

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

PROC task planning.definition structure
Figure 12. proc.task_planning.definition model overview

The remaining classes are shown in various specialised views below.

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

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

  • context: a data context for the Plan as a whole, which enables external variables (such as patient data items) to be tracked and updated;

  • calendar: a global calendar for the Plan, into which entries may be added representing fixed events such as appointments, holidays etc;

  • timeline: the global timeline for the Plan (and hence the subject) into which planned Tasks are fixed, with times specified as offsets from the zero point;

  • event_wait_states: a reference list of all Event wait instances defined in the Plan.

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

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

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

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

6.1.1. Task Group Structure

The set of Tasks in a Task Plan is represented within a containment structure created using instances of the TASK_GROUP type, which has three key attributes. Execution of a Group is controlled by the execution_type and execution_rules attributes, which express sequential or parallel processing, and optionally other execution rules. It also has a training_level attribute which enables different visibility of Sub-Plans to users with different experience levels. This is described more fully below.

TBD: other execution rules.

The following illustrates a simple Task Plan structure including nested Task Groups.

task grouping
Figure 13. Task grouping

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

6.1.2. Class Descriptions

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

The set of all Task Plans use in this Work Plan. In general, only some of these are top-level Plans.

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

calendar: PLAN_CALENDAR

1..1

timeline: PLAN_TIMELINE

Global timeline of Work Plan, on which Tasks with planned times can be listed.

0..1

context: PLAN_DATA_CONTEXT

Global Work Plan data context.

0..1

event_wait_states: List<EVENT_WAIT>

Reference list of all defined Event Listeners.

0..1

top_level_plans: List<UID_BASED_ID>

The set of top-level Plans that correspond to the performers and work pathways of 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.

6.1.2.2. PLAN_CALENDAR Class

Class

PLAN_CALENDAR

Description

Work Plan global calendar in which all absolute-time Calendar Events are recorded.

Attributes

Signature

Meaning

0..1

entries: List<CALENDAR_ENTRY>

Entries in calendar.

6.1.2.3. PLAN_TIMELINE Class

Class

PLAN_TIMELINE

Description

List of Plan Items that have a wait_condition containing an AGENDA_MOMENT, whose times will be converted at Plan activation to fixed times on an execution calendar.

Attributes

Signature

Meaning

0..1

planned_items: List<PLAN_ITEM>

List of Plan Items that have a wait_condition containing a TIMELINE_MOMENT.

0..1

timers: List<TIMER_WAIT>

Reference list of all defined Timers.

6.1.2.4. CALENDAR_ENTRY Class

Class

CALENDAR_ENTRY

Description

A single calendar entry.

6.1.2.5. 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 conditional Groups.

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

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

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

Inherit

CONTENT_ITEM

Attributes

Signature

Meaning

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

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

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

0..1

order_set_type: DV_IDENTIFIER

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

0..1

order_set_id: DV_IDENTIFIER

Identifier of instance of an order set on which this Task Plan is based, if there is one.

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.

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.

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

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

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.

6.1.2.7. PLAN_ITEM Class

Class

PLAN_ITEM (abstract)

Description

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

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

description: DV_TEXT

Human-readable form of the task directive.

0..1

repeat_spec: TASK_REPEAT

Optional specification of repetitions.

0..1

other_details: ITEM_STRUCTURE

Archetypable structure for recording non hard-modelled information.

0..1

wait_spec: TASK_WAIT

Optional wait specification for a Task. If not set, the Task is immediately available once execution reaches it. If set, the Task becomes available when an Event linked to the wait_spec occurs.

6.1.2.8. TASK_GROUP Class

Class

TASK_GROUP

Description

Grouping structure that defines the graph structure of a Task Plan, replacing node-to-node references.

This allows Task Group to define 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

PLAN_ITEM

Attributes

Signature

Meaning

0..1

members: List<PLAN_ITEM>

Set of Tasks to perform. Execution order is defined by the execution_type setting, either sequential or parallel (no order).

0..1

execution_type: EXECUTION_TYPE

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

0..1

training_level: Integer

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

0..1

execution_rules: List<EXECUTION_RULE>

Other rules that may control execution over and above the basic sequential / parallel scheme, e.g.

  • at least N members must complete for group to complete;

  • exit group on first succeeding task.

6.1.2.9. EXECUTION_TYPE Enumeration

Enumeration

EXECUTION_TYPE

Description

Enumeration specifying types of execution for a set of Tasks.

Attributes

Signature

Meaning

sequential

Items execute in order, one after the other.

parallel

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

6.1.2.10. EXECUTION_RULE Class

Class

EXECUTION_RULE

Description

Rule controlling execution in addition to basic sequential / parallel setting.

TODO: define detail.

6.1.2.11. TASK Class

Class

TASK

Description

Atomic Task that is typed according to the kind of TASK_ACTION it includes. A TASK has a lifecycle that can be progressed in the plan execution, i.e. in the Materialised form.

Inherit

PLAN_ITEM

Attributes

Signature

Meaning

1..1

action: TA

Task Action definition.

6.1.2.12. TASK_REPEAT Class

Class

TASK_REPEAT

Description

Definition of repetition for a Task Item. 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: PLAN_EVENT

States a condition for when repetition should stop.

6.2. Task Actions

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

PROC task planning.definition actions
Figure 14. proc.task_planning.definition model - Task Actions

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

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

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

TBD: subject precondition could potentially move to PERFORMABLE_ACTION.

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

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

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

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

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

  • DEFINED_ACTION: an inline-defined Task to be performed by the principal performer of the Group (see below for details);

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

  • 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);

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

6.2.1. Performable Actions

6.2.1.1. 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 15. 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_ACTION 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.

6.2.1.2. Inline Defined Actions

Tasks whose definitions are stated within a Task Plan are modelled using the DEFINED_ACTION type. A detailed specification of the work to be done in a Defined Action 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.

PROC task planning.definition defined task
Figure 16. proc.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_ACTIONs, 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 17. 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.

6.2.1.3. Data-sets and Application Interaction

Within the definition of a Defined Action, one or more data-sets may be specified for review and / or capture purposes (DEFINED_ACTION.review_dataset and capture_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.

6.2.2. Dispatchable Actions

The type DISPATCHABLE_ACTION is the abstract parent of various Action subtypes that represent work requested to be done by some other agent, i.e. external to the current Task Plan. The general execution scheme for such Actions is as follows:

  • dispatch the work request to a target actor or service;

  • block or continue, according to the wait flag, which determines switch or fork behaviour; and

  • process any callback notification, specified via the callback attribute.

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

6.2.2.1. Hand-offs and Coordinated Teamwork

Work Plans may be designed to contain multiple Task Plans, each corresponding to a team worker. In the execution of such a Work Plan, the performer of any Task Plan may at some point need to hand off to another performer, i.e. one of the other Task Plans in the same Work Plan. As described above, the original worker may wait or continue, and in both cases, receipt of a callback notification from the other Task Plan may cause a change in the execution path of the first Plan.

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

task coordination
Figure 18. 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; callback wait resumes at the next Task) and the second an asynchronous fork (wait = False).

6.2.2.2. External Request

The Task sub-type EXTERNAL_REQUEST represents a request by the current performer to an external entity completely outside of the current Work Plan computation context to perform some work on behalf of the performer. This is normally an organisation of which routine requests can be made (e.g. pathology laboratory). 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.

6.2.2.3. 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, such as a logging facility or a decision support system. The request is defined in terms of a SYSTEM_CALL instance.

6.2.3. Class Descriptions

6.2.3.1. TASK_ACTION Class

Class

TASK_ACTION (abstract)

Description

Abstract parent of Task Action types, which define the specifics of the work of a Task. All Task Actions may have subject preconditions (i.e. preconditions on the state of the subject) that must be met or overridden before proceeding; costing information; and one or more review data sets to display in the application environment.

Performable Actions have further properties.

Inherit

LOCATABLE

Attributes

Signature

Meaning

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

instruction_activity: LOCATABLE_REF

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

TODO: may be movable to PERFORMABLE_ACTION.

0..1

subject_preconditions: List<SUBJECT_PRECONDITION>

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

0..1

costing_data: TASK_COSTING

Costing data related to this Task item.

6.2.3.2. SUBJECT_PRECONDITION Class

Class

SUBJECT_PRECONDITION

Description

Clinical preconditions expressing when the Task is safely executable with respect to the principal performer and subject.

Attributes

Signature

Meaning

1..1

description: String

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

Evaluated when encountered.

0..1

expression: BOOLEAN_CONTEXT_EXPRESSION

A Boolean expression that can be evaluated at runtime to determine availability.

6.2.3.3. DATASET_SPEC Class

Class

DATASET_SPEC

Description

Specification of a related data-set and/or form to use with a Task, usually by means of display and/or data entry screens in an application being used by the principal performer.

Attributes

Signature

Meaning

0..1

form_id: String

Form identifier.

0..1

template_id: String

Template identifier in String form of an ARCHETYPE_HRID. 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.

6.2.3.4. PERFORMABLE_ACTION Class

Class

PERFORMABLE_ACTION (abstract)

Description

Represents an action that can be performed by the principal performer during the Plan execution. This is either inline defined or via reference to a sub-plan.

Inherit

TASK_ACTION

Attributes

Signature

Meaning

0..1

resources: List<RESOURCE_PARTICIPATION>

Descriptions of resources required for the Task, if required to be processed at runtime as pre-conditions to Task execution.

0..1

other_participations: List<TASK_PARTICIPATION>

List of participations for task item.

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.

6.2.3.5. RESOURCE_PARTICIPATION Class

Class

RESOURCE_PARTICIPATION

Description

Description of a resource with optional external system reference.

TODO: explain external_ref.

Attributes

Signature

Meaning

1..1

resource_type: DV_TEXT

Text or coded description of resource.

0..1

external_ref: OBJECT_REF

Reference to resource, e.g. in scheduling or other system.

TODO: may need to be a more powerful reference like a SYSTEM_CALL.

6.2.3.6. DEFINED_ACTION Class

Class

DEFINED_ACTION

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

PERFORMABLE_ACTION

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

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.

This attribute is not used computationally.

6.2.3.7. 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, PERFORMABLE_ACTION

6.2.3.8. DISPATCHABLE_ACTION Class

Class

DISPATCHABLE_ACTION (abstract)

Description

Type of Task Action that is performed by another performer, system or organisation. All such Task Actions are 'dispatchable' in the sense that they consist of notifying a request to another principal_performer, or an exterior system or service of some kind, and potentially receiving a callback notification when the requested work is complete.

Inherit

TASK_ACTION

Attributes

Signature

Meaning

1..1

wait: Boolean

Flag indicating whether to wait or continue in the current Plan after the dispatch notification has been achieved. Wait = True corresponds to a context switch (block and wait) while wait = False indicates a context fork.

0..1

callback: CALLBACK_WAIT

Optional callback notification handler.

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

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

DISPATCHABLE_ACTION

Attributes

Signature

Meaning

1..1

organisation: PARTY_PROXY

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

1..1

request_id: String

Request identifier for this type request. May be used in callback notification. Other runtime instance-level identifiers may be needed as well.

0..1

other_details: ITEM_STRUCTURE

Request details.

TODO: more details needed.

6.2.3.11. SYSTEM_REQUEST Class

Class

SYSTEM_REQUEST

Description

Request to an external computational system or service.

Inherit

DISPATCHABLE_ACTION

Attributes

Signature

Meaning

1..1

system_call: SYSTEM_CALL

Definition of call to make.

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

Attributes

Signature

Meaning

1..1

target: UID_BASED_ID

UID of target TASK_PLAN object.

6.3. Conditional Structures

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

PROC task planning.definition decision
Figure 19. proc.task_planning package definition model (decision view)

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

The following diagram shows a typical condition structure.

condition structure
Figure 20. Condition structure

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

The following diagram shows a typical decision structure.

decision structure
Figure 21. Decision structure

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

event structure
Figure 22. Event structure

6.3.1. Class Descriptions

6.3.1.1. CONDITION_GROUP Class

Class

CONDITION_GROUP

Description

Special kind of Task Group whose members are all CONDITION_BRANCH instances, each of which represents a conditional expression based on context variables. Member branches are evaluated in order, which enables overlapping conditions as well as a final 'match-any' branch with a test expression of True to be used if needed.

This structure is the equivalent of a programming if/then/else statement.

Inherit

TASK_GROUP

Attributes

Signature

Meaning

0..1
(redefined)

members: List<CONDITION_BRANCH>

Set of Tasks to perform. Execution order is defined by the execution_type setting, either sequential or parallel (no order).

Invariants

Inv_no_wait_condition: wait_spec = Void

Inv_seq_execution: execution_type = EXECUTION_TYPE.sequential

6.3.1.2. CONDITION_BRANCH Class

Class

CONDITION_BRANCH

Description

A specialised kind of TASK_GROUP representing a branch in a Condition Group.

Inherit

TASK_GROUP

Attributes

Signature

Meaning

1..1

test: BOOLEAN_CONTEXT_EXPRESSION

Boolean-valued test expression which if True indicates that this Branch is to be followed during execution.

Invariants

Inv_no_wait_condition: wait_spec = Void

6.3.1.3. DECISION_GROUP Class

Class

DECISION_GROUP

Description

Special kind of Task Group whose members are all DECISION_BRANCH instances, each of which represents a distinct value sub-range, and which represent together the total possible range of values of the test expression.

This structure is the equivalent of a programming switch statement. It is processed in order, and for situations that need it, the last branch may represent an 'any value', corresponding to a final 'else' at the end of the switch.

Inherit

TASK_GROUP

Attributes

Signature

Meaning

1..1

test: CONTEXT_EXPRESSION

Test expression that generates a value of any type whose sub-ranges may be assigned to the various output branches, in the manner of a switch statement.

0..1
(redefined)

members: List<DECISION_BRANCH>

Set of branches in this Decision Group.

Invariants

Inv_no_wait_condition: wait_spec = Void

Inv_seq_execution: execution_type = EXECUTION_TYPE.sequential

6.3.1.4. DECISION_BRANCH Class

Class

DECISION_BRANCH

Description

A specialised kind of TASK_GROUP representing a branch in a Decision Group.

Inherit

TASK_GROUP

Attributes

Signature

Meaning

1..1

value_constraint: Any

Constraint on result value of the owning Decision Group test expression, for this branch.

TODO: consider use of C_PRIMITIVE_OBJECT from AOM as constrainer type.

Invariants

Inv_no_wait_condition: wait_spec = Void

6.3.1.5. EVENT_GROUP Class

Class

EVENT_GROUP

Description

Special kind of Task Group whose members are EVENT_BRANCH instances each representing a mutually exclusive Event Wait, the first of which occurs determines the execution path.

Inherit

TASK_GROUP

Attributes

Signature

Meaning

0..1

timeout: TIMER_WAIT

Timer to start on entry into Event Group. If no events are received within this time, a branch with a Timer Expiry event type can be entered. If no such branch is defined, the Timer Expiry may be used to display a message to the performer.

0..1
(redefined)

members: List<EVENT_BRANCH>

Set of branches in this Event Group.

Invariants

Inv_parallel: execution_type = EXECUTION_TYPE.parallel

6.3.1.6. EVENT_BRANCH Class

Class

EVENT_BRANCH

Description

A specialised kind of TASK_GROUP representing a branch in an Event Group.

Inherit

TASK_GROUP

Invariants

Wait_spec_not_void: wait_spec /= Void

6.4. Events

6.4.1. Event Types

Work plans inevitably interact with events in the external world, as well being driven by time. In this model, points in time are modelled in terms of Events that represent the reaching of certain points in time or an entry in a calendar, as time passes. Consequently, specifying a time for a Task to be performed and waiting for certain Events before it can be performed are both specified in the latter form. The relevant part of the model, shown below, consists of various types of Events, and additionally, various types of wait states that may be used to intercept them.

PROC task planning.definition event
Figure 23. proc.task_planning model - Events

In the above, the descendants of PLAN_EVENT represent various kinds of events, which roughly divide into deterministic events, i.e. known, system-endogenous events, and non-deterministic events, i.e. events from the outside world whose receipt is not guaranteed.

The event types are as follows:

  • TIMER_EVENT: represents the expiry of a Timer that was launched at some earlier time;

  • TIMELINE_MOMENT: represents a time-point within the global Plan timeline that is specified relative to the Plan’s start time, and converted to absolute time at activation; this type expresses to what is normally understood as 'clock time' or 'diary' time in the sense of a modern calendar or diary tool, and is how time can be specified directly for Tasks;

  • CALENDAR_EVENT: represents an event in the global Plan calendar, which is specified in absolute time.

  • TASK_TRANSITION: an event corresponding to a lifecycle transition of a Task, such as being cancelled or done;

  • CALLBACK_NOTIFICATION: a callback notification connected to a dispatch call for a Dispatchable Task (Hand-off, External Request, System Request);

  • STATE_TRIGGER: an event generated by a change in a tracked variable, or an expression based on tracked variables, e.g. a value reaching a threshold;

  • MANUAL_NOTIFICATION: an event that is manually notified to the Plan execution engine by a user;

  • SYSTEM_NOTIFICATION: an event that is notified to the Plan execution engine by a system or service;

  • DELAY_EVENT: a special kind of event is used to represent any other event with an added delay.

Instances of all of these types, on their own only identify the type and source of an event. Events can be waited on in two ways.

6.4.2. Task Wait State

The first way is via the TASK_WAIT attachable to any Plan Item, via the wait_spec attribute, which refers to an instance of TASK_WAIT. The TASK_WAIT class models a wait state, and defines how to specify the details of when a Task should start with respect to any of the Event types described above. Its events attribute enables more than multiple Events to be used as a trigger, with an assumed logical OR relation among the Events. This enables the specification of triggers such as 'at 8pm on day 1, or when oxygen saturation drops below 90% (whichever comes first)'. The event_relation attribute allows the Task to be specified as commencing before, with or after the trigger event (such as a meal). The start_window attribute allows for a delay from the trigger moment, and timeout, if set, will cause a Timer to be started in cases where Event receipt is not certain. These Timers are just special cases of the EVENT_WAIT type, described below.

The combined structure of a TASK_WAIT and one or more PLAN_EVENT descendants provides a way to specify when a Task may be commenced, either in terms of time-related events, or non-deterministic events, as follows:

  • clock time: the Task is to be executed at a specific clock time represented by an instance of TIMELINE_MOMENT; 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 CALENDAR_EVENT is used; the TASK_WAIT attributes indicate the specifics such as '1 hour before', 'with meal' etc;

  • notification-linked time: the Task is to be executed at a time related to a notification, either from a system (specified with SYSTEM_NOTIFICATION) or manually notified (MANUAL_NOTIFICATION);

  • task-linked time: the Task is to be executed at a time related to the timing of another Task lifecycle transition, such as completion of the previous Task; this is represented by an instance of TASK_TRANSITION whose transition indicates the required lifecycle transition;

  • 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_TRIGGER. This uses a Boolean-valued expression attribute to state a condition which when true indicates that a Task time-to-execute has been reached.

The TIMELINE_MOMENT type allows a point in time relative to the start of the Plan to be specified, in terms of an offset and a fixed component, both optional. The offset part, if specified, establishes a point relative to the Plan zero point (converted to absolute form at activation), while the fixed part enables fixed points in time such as a particular hour of day or customary time such as 'afternoon' to be specified. A combination of the two such as +1d, 01:30:00 can thus be used to state a time like '1:30 PM on day one of the plan'.

6.4.3. Event Wait State

The second way to intercept events and subsequently perform actions is via an instance of EVENT_WAIT<T>, which is a generic class from which concrete types may be constructed based on the type of Event to be listened for. Types such as EVENT_WAIT<MANUAL_EVENT> may thus be constructed. The EVENT_WAIT<T> class has a success_action attribute of type EVENT_ACTION, which enables any of the following actions to occur on receipt of an event:

  • making system calls, if the system_call attribute is set, e.g. to cause a notification to be sent or write to a system logger;

  • displaying a message to the user, specified in the message attribute.

  • optionally indicates where execution should resume in the plan, for example at an earlier Task, via the resume_action attribute, whose value is aninstance of RESUME_ACTION, defining the resume_type and resume_location attributes.

The latter attributes are normally only for use with callbacks and are described in detail below.

For non-deterministic Events, the EVENT_WAIT.timeout attribute may be set to point to a TIMER_WAIT, which enables timeout actions to be specified.

6.4.4. Timers

The class TIMER_WAIT is based on the generic type EVENT_WAIT<TIMER_EVENT>, and provides a way to specify a Timer (the TIMER_EVENT instance) and listen for it (the TIMER_WAIT). Timeouts can be used on the TASK_WAIT wait state as well as any EVENT_WAIT wait state, including CALLBACK_WAIT. A TIMER_WAIT creates a separate Event wait state that listens for a Timer event launched some duration after activation, and may result in specific actions, specified via the inherited EVENT_WAIT.success_action attribute.

A specialised timer class REMINDER can be specified if needed, that consists of a TIMER_WAIT designed to generate a user notification.

6.4.5. Callbacks

A specialisation of EVENT_WAIT<CALLBACK_NOTIFICATION> is CALLBACK_WAIT, used to handle notifications of dispatched Tasks that complete, as well as timeouts if no response is received. This class adds one attribute:

  • fail_action: enables a different EVENT_ACTION to be specified on receipt of a callback with a 'fail' status;

A Callback Wait can thus have three distinct Event responders: success_action, fail_action and timeout.

6.4.6. Class Descriptions

6.4.6.1. TASK_WAIT Class

Class

TASK_WAIT

Description

Object representing time of an Task to be performed in terms of a related event. The delay attribute may be used to delay the start time by some amount. The start_window is used to add an 'acceptable delay' time within which the Task should be start with respect to the intended start time. The timeout attribute can be used for non-deterministic Events.

  • clock time: event = TIMELINE_MOMENT, CALENDAR_EVENT;

  • notification-based: event = or MANUAL_EVENT, SYSTEM_NOTIFICATION;

  • task-linked: event = TASK_TRANSITION, e.g. 1hr after previous Task done;

  • state-linked: event = STATE_TRIGGER, e.g. 'when systolic BP > 165';

  • any event with added delay: DELAY_EVENT.

Attributes

Signature

Meaning

0..1

events: List<PLAN_EVENT>

Event that defines the intended point in time.

0..1

event_relation: TEMPORAL_RELATION

Temporal relation to the event of the point or period in time being defined by this Timing Spec.

0..1

start_window: REMINDER

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

0..1

timeout: TIMER_WAIT

Timeout handler to use if no other Event is received within a certain time.

6.4.6.2. PLAN_EVENT Class

Class

PLAN_EVENT (abstract)

Description

Entity representing an Event generated during system execution. Descendants define details of each kind of Event known in the system.

Inherit

LOCATABLE

Attributes

Signature

Meaning

0..1

other_details: ITEM_STRUCTURE

6.4.6.3. DELAY_EVENT Class

Class

DELAY_EVENT

Description

Event generated at a time delay after another Event.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

1..1

source: UID_BASED_ID

Reference to source Event.

1..1

delay: IDuration

Length of the delay.

6.4.6.4. MANUAL_NOTIFICATION Class

Class

MANUAL_NOTIFICATION

Description

Event type representing the manual notification of a real-world event to the system, such as arrival of a test result, manually taken vital sign value over a threshold.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

1..1

description: String

Natural language or processable description of the event. Needs to be sufficiently detailed to distinguish it from other similar events.

6.4.6.5. SYSTEM_NOTIFICATION Class

Class

SYSTEM_NOTIFICATION

Description

Event type representing a notification from a system of some event, represented by notification type and reference identifier.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

1..1

system_id: String

Identifier of system that will generate notification.

0..1

notification_type: String

Type of notification, i.e. among types generated by the source system.

0..1

reference_id: String

Reference identifier, typically a request identifier from a previous request.

6.4.6.6. CALLBACK_NOTIFICATION Class

Class

CALLBACK_NOTIFICATION

Description

Event generated on receipt of notification of completion of a Dispatchable Task.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

1..1

task_id: UID_BASED_ID

Identifier of originating Task.

0..1

request_id: String

Identifier of original request, may be matchable with EXTERNAL_REQUEST.request_id.

6.4.6.7. STATE_TRIGGER Class

Class

STATE_TRIGGER

Description

Type of event representing an expression referring to one or more tracked variables, reaching a value or passing a threshold value.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

1..1

expression: BOOLEAN_CONTEXT_EXPRESSION

Boolean-returning expression that mentions one or more tracked variables, e.g. heart_rate > 120 bpm. Evaluation controlled by Plan variable context.

6.4.6.8. TIMER_EVENT Class

Class

TIMER_EVENT

Description

Timer expiry event generated by Task Plan engine.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

1..1

duration: IDuration

Delay from activation time to receive the event notification.

0..1

purpose: String

Optional explanatory purpose of Timer.

6.4.6.9. CALENDAR_EVENT Class

Class

CALENDAR_EVENT

Description

Specifies an event generated during execution when the Plan clock reaches a corresponding entry in the global calendar.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

0..1

entry_id: UID_BASED_ID

Identifier of entry within global Plan calendar.

1..1

time: IDate_time

Time of entry in calendar.

6.4.6.10. TIMELINE_MOMENT Class

Class

TIMELINE_MOMENT

Description

Specifies a time event generated during execution when the Plan clock reaches a specific time defined in the global Plan Timeline.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

0..1

timeline_offset: IDuration

Variable part of time specification, expressed as an offset from the zero time point of the Task Plan. Converted to absolute time at activation.

0..1

fixed_time: TIME_SPECIFIER

Fixed time specification, to be added to variable time when the latter is converted to absolute time at activation. Used to expressed fixed hours in the day, when the day is movable.

6.4.6.11. EVENT_WAIT Class

Class

EVENT_WAIT

Description

Wait state for any kind of Event, with a success Action and an optional separate timeout Event Wait state.

Attributes

Signature

Meaning

1..1

event: P

Descriptor for event on which this wait state is based.

0..1

success_action: EVENT_ACTION

Action to perform if any listened-for event returns a success result.

0..1

timeout: TIMER_WAIT

Timeout handler to use if no other Event is received within a certain time.

6.4.6.12. TIMER_WAIT Class

Class

TIMER_WAIT

Description

Event listener for a Timer event.

Inherit

EVENT_WAIT

Attributes

Signature

Meaning

1..1
(redefined)

event: TIMER_EVENT

Redefined from EVENT_WAIT.

6.4.6.13. REMINDER Class

Class

REMINDER

Description

Specialised Timer configured to generate a reminder or alert to performer or other user.

Inherit

TIMER_WAIT

6.4.6.14. CALLBACK_WAIT Class

Class

CALLBACK_WAIT

Description

Specialised descendant of EVENT_ACTION <CALL_BACK_NOTIFICATION> that adds a fail action. Used for representing post-callback actions.

Inherit

EVENT_WAIT

Attributes

Signature

Meaning

0..1

fail_action: EVENT_ACTION

Action to perform if any listened-for event returns a fail result.

1..1
(redefined)

event: CALLBACK_NOTIFICATION

Callback notification on which this Callback wait state is based.

6.4.6.15. EVENT_ACTION Class

Class

EVENT_ACTION

Description

Action(s) to perform on receipt of an event with a particular status. If resume_action is set, it dictates where execution resumes; if not, the default is to resume at the next Task in normal execution flow.

Attributes

Signature

Meaning

0..1

system_call: List<SYSTEM_CALL>

System call to perform on receipt of event

0..1

message: DV_TEXT

Optional message to display to original Task context (i.e. application, form etc) if timer expires.

0..1

resume_action: RESUME_ACTION

Optional resume action, used when the intention is to resume in a different location than the default (i.e. next available Task).

6.4.6.16. RESUME_ACTION Class

Class

RESUME_ACTION

Description

Type representing an execution jump to a new location in the current Plan.

Attributes

Signature

Meaning

1..1

resume_type: RESUME_TYPE

Procedure to execute when completion notification received, for example, to display a form, notify performer etc.

TODO: determine details.

0..1

resume_location: UID_BASED_ID

Reference to a resume Task in the current Plan, at which to restart when the request / handoff has completed.

If not set, the following Task is assumed. It set, is typically an earlier Task, in situations where the current Task(s) are no longer needed once the external action has been completed.

6.5. Repetition

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

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

6.7. References to Clinical Quality Artefacts

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

  • In WORK_PLAN:

    • care_plan: a reference to an underpinning 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.

6.8. Cost Tracking

TBD: describe cost tracking.

6.8.1. Class Descriptions

6.8.1.1. TASK_COSTING Class

Class

TASK_COSTING

Description

Costing information for a Task.

TODO: to be developed.

7. Definition Model Patterns

This section describes typical workflow patterns in terms of the Definition Model described above.

7.1. Timing Patterns

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

uc task timing 1
Figure 24. Timing Patterns

7.2. Callback Patterns

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

uc task callback 1
Figure 25. Timing Patterns

8. Execution Model Overview

This section describes the execution time semantics that correspond to the materialised and runtime forms of the Task Planning model.

8.1. Phases of Instantiation

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

8.1.1. Materialisation

When a Work Plan is to be executed, it will be materialised, which concretely means instantiating and usually persisting it (this might be avoided for very short run Plans). Some user input may be required, e.g. number of repetitions of repeatable sections. Conditional branches whose conditions or events will never be met can also be removed during materialisation. 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 shown below, 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. In terms of the materialised model described below, some M_TASK_GROUP instances will have their members containing additional M_XX instances. Thus, more than one M_TASK may point to the same generating TASK from the definition.

The structure created will thus mirror the structure of the original definition, with extra copies for repeatable sections and potentially 'dead branches' removed.

At materialisation time, an instance of EXECUTION_HISTORY is also created, proving a root point to accumulate Plan execution event records.

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

8.1.2. Activation

A materialised Work Plan is activated when it is ready to be used. Activation starts the timeline clock for the Work Plan; accordingly, execution times in the constituent Task Plans are converted to absolute clock times, or a form that can be related to clock time, e.g. via the use of the materialised Work Plan timeline and calendar.

As part of activation, the runtime window must be determined. This is a moving window corresponding to the section of a materialised Plan that will be actively executing at any moment. The size of the window would typically be at least a working shift (e.g. 8-12 hours), but would more typically be the number of days typically used in the organisation for lookahead planning. The part of Task Plans within a Work Plan that are inside the runtime window are in active execution, while other parts (both prior and after the window) are not currently executing but are typically available for visualisation.

When the runtime window is known, allocations for the window can be managed, as described below. To enable allocation to take place, a communication channel must be established with each potential worker or worker pool. This may consist of any technical means, including email, instant messager, a ward screen application and so on. Allocations may be filled in a 'just in time' fashion where the technical means exists to enable it (e.g. push communications from the server).

Execution starts by commencing the Work Plan’s top-level Task Plans, and putting them into their initial wait states.

For each Task Plan, execution of the Plan section within the runtime window consists approximately of:

  • Tasks being displayed within a separate or shared application for each performer, along with lifecycle state of each Task;

  • Tasks become available 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, or aborting it, which abandons the entire Plan;

  • performers interact with the visual representation to transition the lifecycle state appropriately;

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

8.1.3. Termination

A Task Plan terminates when the execution path taken through the materialised Group/Task graph completes, either due to finishing, or due to abandonment at an intermediate Task.

The Task 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 hand-off chain in which a context switch follows termination of one Task Plan.

A Work Plan terminates when all member Task Plans have terminated in the above fashion.

An event record is added to the execution history for each Task Plan termination, and for the final Work Plan termination.

8.1.4. Allowed Plan Modifications

After materialisation but prior to activation, changes may be made to any part of the materialised plan, corresponding to adjusting repeated sections and removing or adding back in condition branches according to relevancy with respect to newly evaluated subject variables (e.g. discovering that the patient is pregnant may require certain Decision Branches to be added back in).

Once activation has occurred, changes of the same type may still occur, but only ahead of the runtime window, since the parts of the Plan within the window, or already executed can’t safely or sensibly be altered.

If other kinds of changes are needed, this is generally a sign that the Plan design contains issues, and that the current version if already in use will be abandoned in favour of a newer version.

8.2. Execution Semantics

8.2.1. Performer Allocation

Before a materialised Task Plan can be executed, at least the principal_performer must be allocated, and depending on how long-running the Plan is, and where the current execution point is, some actors designated by PERFORMABLE_ACTION.other_participations for Tasks within the current runtime window (see above) need to be allocated as well.

The allocation process consists of:

  • assignment of a Plan or Task to a real actor or worker pool;

  • a claim by an individual to accept the request.

Assigning communicates a request to potential worker(s) (e.g. via application screens, personal messages, scheduling systems etc), one of which accepts the request and thereby becomes the allocated worker. This is done by user(s) authenticating to the Plan execution engine via an application 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 the allocation of a new actor.

8.2.2. Resource Allocation

TBD

8.2.3. Task Lifecycle

At runtime, it is the Tasks in a Plan that can be directly 'performed'. Accordingly, it is the Task that has a lifecycle attached to it, containing states and transitions reflecting possible actions by the performer. The lifecycle does not appear in the definition model TASK class as a data attribute since it is a runtime variable for a Task; hence it appears in the materialised model, described below.

During execution, each Task is represented by an instance of the materialised form of the Task. Each Task in the executing Plan has a lifecycle consisting of various states it may pass through in time (recorded in M_TASK.lifecycle_state in the materialised model below). The lifecycle is only has to take account of the states a Task itself can pass through; states of an order (i.e. prescription, lab request) 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 Task lifecycle 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.

PROC TaskStateMachine
Figure 26. Task lifecycle state machine

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

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 transition from plannedavailable.

8.2.4. Task Availability

Following the design principle described earlier, the execution engine executing a Task Plan can determine the availability (i.e., when the transition plannedavailable may occur) for any Task or Task Group as follows:

  • control-flow: preceding Tasks / Groups within the current Task Group reach a terminal lifecycle state;

  • wait state: any Task or Group wait state has been exited due to the arrival of the relevant events, including timeline-related events;

  • subject preconditions: subject preconditions attached to the current Task Action are satisfied.

A Task is considered according to this logic even if performer and/or resources have not been allocated.

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, causing the lifecycle transition 'override` from planned to available. A corresponding TASK_EVENT_RECORD is created recording the use of the override

8.2.5. Task Group Lifecycle State

Since a Task Plan is a hierarchical structure consisting of one or more Task Groups, a way of rolling up Task state is needed. Once a Task Group has become available and been entered, i.e. any wait state or timing (PLAN_ITEM.wait_spec) has been satisfied, a way of computing its effective lifecycle state is required, so that the Task Group can be considered as a unit within its parent for the purpose of determining cntrol flow.

The following algorithm is used to compute the effective lifecycle state of a Materialised Task Group from the set of states of its members (which may recusively may other Materialised 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(Abandoned))
        return Abandoned;
    else if (sourceStates.contains(Available))
        return Available;
    else if (sourceStates.contains(Planned))
        return Planned;
    else if (sourceStates.contains(Suspended))
        return Suspended;
    else if (sourceStates.contains(Underway))
        return Underway;
    else if (sourceStates.contains(Completed))
        return Completed;
    else if (sourceStates.contains(Cancelled))
        return Cancelled;
    else
        return Initial;
}

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

8.2.6. Execution Path

One of the consequences of Tasks being transitioned to terminal lifecycle states such as completed, cancelled, etc within the hierarchical Task Group structure is that an effective lifecycle state has to be computed for Task Group objects at runtime as well, as shown above. Essentially it computes the effective state for a Task Group at runtime as a terminal state if there are only Tasks in terminal states. In other words, completing, cancelling or abandoning all Tasks within a Group causes completion of the Group, and this applies when it is in parallel or seqential execution mode.

If a Task Group has more complex execution rules (TASK_GROUP.execution_rules) such as 'exit on first Task to complete', then its completion state will be affected by this, and will be calculable according to the particular rules defined. Such rules can be understood as a short-hand for cancelling Tasks that are not needed, so that the effective Group lifecycle state can still be computed in the standard way.

Completing a Group will ripple back up the Task Group hierarchy to the point where the completed Group is not the final outstanding Task or Group in the parent.

This model results in an execution path during normal processing that is effectively a traversal of the acyclic graph represented by the Task Group containment structure.

It also determines as a side effect how logical execution path 'jumps' due to the use of EVENT_ACTION.resume_action.

8.2.7. Resume Semantics

The resume_type and resume_location attributes of the RESUME_ACTION class constitute the possibility of an uncontrolled jump or 'goto' within the Task execution structure. If allowed without limitation, it is likely to lead to undecidable situations in Plan execution, and unreliable execution histories. For example, if the execution history shows that some Task Y was performed, then it would normally be assumed that the preceding Task X had also been performed (even if cancelled), and by extension that any wait state such as an Event Branch had been satisifed by the relevant event being received. If however, a jump to Task Y from some Task A on a completely separate path were allowed, no such inference can be made, without appropriate processing rules regarding such jumps.

To create workable rules, the notion of the execution path described above has to be used, i.e. the path traversed so far throught the Group / Task graph to the current point. Because the graph has no cycles, a most recent common location for the execution path actually taken and the designated resume location can always be found. This location may be somewhere back in the current path, including at the start (no real common point), or the current Task (resume location is ahead, not behind).

Making the execution valid according to the Plan while allowing an arbitrary resumption point requires finding a valid path from the most recent common location to the resume location. This can be done if the intermediate steps from the most recent common point and the resume point can be shown to be traversable. There are three situations that can occur at each node along this path:

  • normal Tasks with no wait_spec (i.e. planned or event-based timing): these may be automatically cancelled, meaning 'not done, not needed';

  • normal Tasks with a wait_spec: these can be traversed if the relevant time or other events are known to have already been received;

  • conditional Group structures: these can be traversed if the relevant conditions and/or events are known to be true, or to have already been received, respectively.

Whether the intermediate logical conditions or event wait states (including timeline events) up to the resume location are satisfiable can in general only be known at execution time. This means that at design time, no general rule can be used to limit the choice of a resume location. However, the intermediate wait states and conditions can be determined easily enough and shown in a tool to the designer, enabling at least a guess as to viability.

What actually happens at execution time depends on where the resume location is, as follows:

  • forward resume: the resume location is ahead of the current point on the execution path; getting there just requires the above algorithm of cancellation with condition and event checks;

  • alternate path: the resume location is on an alternate branch with respect to the current execution path; this may be treated as for the forward resume case;

  • current path: the resume location is earlier on the current path.

The last possibility implies the need to retry Tasks already performed, which must be in either the cancelled or completed state. Assuming that the intention of the resume location is to perform (again) the Task or Group at that location, the latter must be put back into the available state. This is enabled by the special transitions retry from cancelled to available and redo from or completed to available.

This doesn’t address what should happen at execution time when conditions or wait states at intermediate nodes from the most recent common point to the resume point cannot be met. The simplest approach is that they are manually overridden, as may already be done in normal path processing. This has the effect that such overrides are at least recorded in the execution history.

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

9. Materialised Model

9.1. Overview

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

PROC task planning.materialised
Figure 27. proc.task_planning.materialised package

9.2. Class Descriptions

9.2.1. M_WORK_PLAN Class

Class

M_WORK_PLAN

Description

Materialised form of WORK_PLAN.

Attributes

Signature

Meaning

0..1

plans: List<M_TASK_PLAN>

Member Plans.

1..1

owner: WORK_PLAN

Owning Work Plan definition.

1..1

timeline: M_TIMELINE

Materialised global timeline.

1..1

calendar: M_CALENDAR

Materialised global calendar.

1..1

context: M_PLAN_DATA_CONTEXT

Materialised global context.

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

principal_performer: M_PERFORMER_ALLOCATION

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

Functions

Signature

Meaning

lifecycle_state (): TASK_LIFECYCLE

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

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

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.

9.2.4. M_TASK_GROUP Class

Class

M_TASK_GROUP

Description

Materialised form of TASK_GROUP from a Task Plan definition.

Inherit

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

9.2.5. M_TASK Class

Class

M_TASK

Description

Materialised form of TASK type and its descendants from a Task Plan definition.

Inherit

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

9.2.6. M_TASK_ACTION Class

Class

M_TASK_ACTION

Description

Materialised form of TASK_ACTION type.

Attributes

Signature

Meaning

1..1

definition: TASK_ACTION

10. Plan Execution History

10.1. Overview

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

PROC task planning.history
Figure 28. proc.task_planning.history package

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

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

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?

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

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

10.2. Class Descriptions

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

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

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

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

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

Optional reason for lifecycle transition.

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

11. Transactional Service Model

11.1. Overview

The information structures required to represent planned Tasks and references at design and runtime are non-trivial. For this reason, an abstract service is defined, with a transactional interface that converts calls into correct underlying information structures. The following UML diagram illustrates the services.

PROC task planning.service
Figure 29. proc.task_planning.service package

11.2. Definition Interface

TBC:

11.3. Execution-time Interface

TBC:

11.4. Class Descriptions

11.4.1. I_WORK_PLAN_DEFINITION Interface

Interface

I_WORK_PLAN_DEFINITION

Description

Task planning API that converts transactional calls to correct Task Planning information structures at Work Plan level.

Functions

Signature

Meaning

plans (): List<UID_BASED_ID>

List of Task Plan ids for this Work Plan.

plan (
a_task_plan_id: UID_BASED_ID[1]
): List<I_TASK_PLAN_DEFINITION>

Obtain a Task Plan definition API interface.

11.4.2. I_TASK_PLAN_MATERIALISED Interface

Interface

I_TASK_PLAN_MATERIALISED

Description

Task planning API for materialised Task Plan level.

Functions

Signature

Meaning

materialise

activate

terminate

11.4.3. I_WORK_PLAN_DEFINITION Interface

Interface

I_WORK_PLAN_DEFINITION

Description

Task planning API that converts transactional calls to correct Task Planning information structures at Work Plan level.

Functions

Signature

Meaning

plans (): List<UID_BASED_ID>

List of Task Plan ids for this Work Plan.

plan (
a_task_plan_id: UID_BASED_ID[1]
): List<I_TASK_PLAN_DEFINITION>

Obtain a Task Plan definition API interface.

11.4.4. I_TASK_PLAN_MATERIALISED Interface

Interface

I_TASK_PLAN_MATERIALISED

Description

Task planning API for materialised Task Plan level.

Functions

Signature

Meaning

materialise

activate

terminate

12. Relationship with other openEHR EHR Artefacts

12.1. Overview

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, e.g. 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.

12.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 30. 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_ACTION 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_ACTION 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.

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.