openEHR logo

Task Planning (TP) Specification

Issuer: openEHR Specification Program

Release: PROC Release-1.6.0

Status: TRIAL

Revision: [latest_issue]

Date: [latest_issue_date]

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

openEHR components
© 2017 - 2021 The openEHR Foundation

The openEHR Foundation is an independent, non-profit foundation, facilitating the sharing of health records by consumers and clinicians via open specifications, clinical models and open platform implementations.

Licence

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

Support

Issues: Problem Reports
Web: specifications.openEHR.org

Amendment Record

Issue Details Raiser Completed

PROC Release 1.6.0

1.6.0

SPECPROC-45. Add Process component Overview document. Remove most of Section 2 - Background and part of Section 4.1.

T Beale

21 Dec 2020

SPECPROC-44. Correct PLAN_TIME_ORIGIN enum order and add values. See Section 5.6.1.4.

M Kejžar

18 Sep 2020

SPECPROC-43. Add inheritance to separate CALLBACK_NOTIFICATION from other Plan Event types;
SPECPROC-33. Support progressive data set creation;
SPECPROC-39. Correct error in TASK_LIFECYCLE state enumeration: remove resumed state; also correct mentions of aborted state to abandoned; add enumeration Integer values; improve text.

M Polajnar,
M Kejžar,
T Beale

29 May 2020

PROC Release 1.5.0

1.5.0

SPECPROC-34. Clarify evaluate order and semantics of REPEAT_SPEC.

M Polajnar,
T Beale

05 May 2020

SPECPROC-22. Change method of 'manual notification' for callbacks; remove manually_notified: Boolean from CALLBACK_NOTIFICATION.

M Polajnar,
T Beale

16 Apr 2020

SPECPROC-12. Define lifecycle state for parallel Task Groups, including decision groups. Moved lifecycle state to 6.2.3; update 6.3.2; update Aggregate Lifecycle State section (7.3).

B Naess,
M Polajnar,
T Beale

19 Mar 2020

SPECPROC-32. Improve Introduction and Requirements Discussion.

D Santos Alves,
T Beale

26 Jan 2020

SPECPROC-30. Adjustments to Events model.
change TASK_WAIT.start_window: REMINDER[0..1] to PLAN_ITEM.reminders: REMINDER[*];
add invariant to TIMER_WAIT to prevent it having a timeout;
make REMINDER a generic EVENT_WAIT to allow it to be fired by any event, not just a timer event;
remove DELAY_EVENT; move its delay attribute to PLAN_EVENT,
SPECPROC-31. Simplifications to Conditional structures: remove BLOCKING_GROUP, BLOCKING_BRANCH.

M Polajnar,
T Beale

03 Jan 2020

1.4.2

SPECPUB-7: Convert citations to bibtex form.

T Beale

15 Dec 2019

SPECPROC-28. Improve definition of TIMELINE_MOMENT and TIMER_EVENT; add PLAN_TIME_ORIGIN enum; remove CALENDAR_TIME class. SPECPROC-29. Add guideline_step to PLAN_ITEM; make Work Plan and Task Plan guideline refs more flexible.

M Kejžar,
T Beale

09 Aug 2019

1.4.1

SPECPROC-26. Dataset improvements: make DATASET_SPEC inherit from LOCATABLE; support form sub-sections. SPECPROC-27. Add classification attribute to WORK_PLAN and PLAN_ITEM.

M Kejžar,
T Beale

22 Jul 2019

1.4.0

SPECPROC-24. Add Order tracking to model: add class ORDER_REF; add WORK_PLAN.order_list; add TASK_PLAN.order_tags.

M Kejžar,
M Polajnar,
T Beale,
B Naess

29 May 2019

1.3.0

SPECPROC-22. Enable Callbacks to be manually notified - add manually_notified: Boolean to CALLBACK_NOTIFICATION.

T Beale

01 May 2019

SPECPROC-23. Correct CLOCK_TIME.time type to Iso8601_time.

B Fabjan

25 Apr 2019

SPECPROC-20. Add period to TASK_REPEAT class.

M Kejžar,
T Beale

12 Apr 2019

SPECPROC-19. Refine model of concurrency in TASK_GROUP: add class CONCURRENCY_MODE; improve explanation of TASK_GROUP;
Add concurrency_mode = xor_one_path invariant to CHOICE_GROUP.

T Beale

18 Mar 2019

SPECPROC-18. Support custom actions for callback receipt of events;
Improve diagrams and explanation on Task wait states and Events;
Add CALLBACK_WAIT.custom_actions;
Add REMINDER.repeats;
Add TASK_WAIT.next_state

T Beale,
B Naess

11 Mar 2019

SPECPROC-17. Specialise DATASET_SPEC into Capture and Review forms.
SPECPROC-16. Change WORK_PLAN.top_level_plans and LINKED_PLAN.target to direct links.

M Kejžar,
B Naess,
T Beale

04 Jan 2019

1.2.0

SPECPROC-15. Convert DELAY_EVENT.source to a direct reference.

M Polajnar

21 Nov 2018

1.1.2

SPECPROC-2. Change date/time types to Iso8601_xxx types from Foundation Types spec.
SPECPROC-11. Add WORK_PLAN.indications;
Improve documentation of TIMELINE_MOMENT;
SPECPROC-13. Clarify Work Plan instantiation and distribution semantics:
Add section 4.4.1 Phases of Work;
Add subsection to section 2.5 on Distributed plans.

B Naess,
M Kejžar,
T Beale

31 Oct 2018

1.1.1

SPECPROC-9. Add sub-section on Time and Work in Background section.
SPECPROC-10. Add BLOCKING_GROUP and BLOCKING_BRANCH classes and EVENT_ACTION.receiver_thread_next_state.

T Beale

21 Jun 2018

1.1.0

SPECPROC-6. Adjust SYSTEM_CALL definition;
Add PARAMETER_DEF and PARAMETER_MAPPING types.
SPECPROC-7. Provide support in decision structures for automated / decision support / ad hoc modes;
Add CHOICE_GROUP, CHOICE_BRANCH, ADHOC_GROUP, ADHOC_BRANCH classes, and an attribute for marking any group as overridable at execution time.

T Beale,
M Kejžar

15 Jan 2018

1.0.4

SPECPROC-3. Context value model adjustments;
Adjust CONTEXT_EXPRESSION type to have name;
Add CONTEXT_CONSTANT, EXTERNAL_VARIABLE and LOCAL_VARIABLE types.

T Beale

04 Dec 2017

1.0.3

SPECPROC-5. Correct DECISION_BRANCH method of specifying value.

T Beale

04 Dec 2017

1.0.2

SPECPROC-4. Refine SYSTEM_CALL model, describe variable referencing.

M Kejžar,
M Polajnar,
T Beale

02 Dec 2017

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

PROC Release 1.0.0

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.

  • Danielle Santos Alves, RN, midwife, Federal University of Pernambuco (UFPE), Brazil

  • Borut Fabjan, Program Manager, Better, Slovenia

  • Matija Kejžar, Software Engineer, Better, Slovenia

  • Bostjan Lah, Senior Architect, Marand, Slovenia

  • Eugeny Leonov, Solit Clouds, Moscow, Russia

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

  • Ian McNicoll MD, FreshEHR, UK

  • Bjørn Næss, DIPS, Norway

  • Pablo Pazos Gutierrez, Senior engineer, CaboLabs, Uruguay

  • Pekka Pesola, Engineer, Tieto, Finland

  • Matija Polajnar, PhD, Software Engineer, Better, Slovenia

Support

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

  • City of Moscow

  • Better d.o.o., Slovenia (was Marand)

  • 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 is led by David Edwards and Alan James (chief architect), within the clinical quality program, under Dr Brent James, Chief Quality Officer at Intermountain Healthcare. ABD 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, Adams, & Russell, 2010) 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 specification of the openEHR Task Planning facility addresses requirements in the area of clinical process automation in which some form of granular planning of clinical work 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 subject. Plans generally have related decision logic and require a means of extracting data from back-end systems concerning the subject. These other elements and their relationship to plans are described in the openEHR Process and Planning Overview.

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 https://specifications.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)

1.4. Feedback

Feedback may be provided on the process specifications forum.

Issues may be raised on the specifications Problem Report tracker.

To see changes made due to previously reported issues, see the PROC component Change Request tracker.

1.5. Conformance

Conformance of a data or software artifact to an openEHR 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 derivations from underlying models, ITS conformance indicates model conformance.

2. Background

2.1. Scope

2.1.1. Representation of Care Management Artefacts

This specification defines a model of structured plans that when executed in an engine, provide notifications to workers relating to tasks. Plans are not standalone, and require decision logic as well as access to subject data in order to execute.

Task Plans, along with related decision logic, can be used to represent a number of artefacts used in healthcare including:

  • care pathways - complex condition-specific, outcome-oriented;

  • guidelines - condition-specific, activity-oriented;

  • order set administration plans - condition-specific;

  • patient plans - subject-specific; either derived from published care pathways and guidelines, or created locally within an institution.

They may be referred to by care plans, which provide a patient-level description of intended care and monitoring for a condition.

The openEHR Process and Planning Overview provides a comprehensive overview of these artefacts, Task Planning and its related specifications.

2.1.2. Limitations of the openEHR standard Entry Model

Task Planning addresses the inability of the openEHR EHR architecture to directly represent fine-grained tasks. The Entry model described in the openEHR EHR IM defines a way to record clinical statements representing real observations, decisions, orders and performed actions in the EHR. In this scheme, Instructions represent orders for Actions to be performed, such as 'administer 3 times a day, for 7 days, with meals'. Such orders are consumed by human actors and mentally converted to individual tasks (21 administrations), with Actions and Observations recording what was done after the fact.

There is however a common need to concretely represent the plan of Actions and Observations ahead of time, as a set of individual tasks that can be displayed, verified, performed (or not) and signed off by workers. A set of planned tasks need not all relate to a single order, or indeed any order. The general picture is that a task plan corresponds to any self-standing healthcare job to be done.

2.2. What Task Planning Does Not Do

Some common capabilities related to clinical care management are not directly addressed by this specification, as described in the following sub-sections.

2.2.1. Task Lists (TODO Lists)

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

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

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

2.2.2. Appointment Booking and Management

The planning paradigm envisaged by this specification does not try to directly address the problem of concretely creating and managing bookings for appointments, which, while conceptually simple, in real life unavoidably entails the complexity of ad hoc communication, cancellations, rebooking and so on. Instead it assumes that the existing systems designed to help perform this mostly administrative work will manage to get patients to intended appointments.

However, since the timing of visits is usually clinically determined, it would be reasonable for a task within a plan to request an appointment be created for a visit at some nominal time for some purpose, e.g. week 22 ante-natal review, in next 8 days. Another part of the same plan may have a wait state whose trigger event is the patient turning up for the nominated purpose. However, all of the administrative activity that occurs in order to ensure the patient appears is assumed to be external to the task planning system.

2.2.3. Clinical Decision Support (CDS)

While this specification covers the computable representation of decisions in a work plan, it is not intended to replace CDS systems that perform complex pure decision analysis, typically via access to specialist knowledge bases. Instead, it is assumed that the plans running in the task planning system will make requests of various CDS systems to provide specific answers, e.g. to check medications interactions for a proposed prescription, or propose a type of treatment for a hypertensive patient.

2.3. Relationship to Existing Workflow Formalisms

This specification describes a model of planning that includes support for work distribution across multiple performers, nested plans, conditional branching, timing and various other facilities. Many of these are conceptually close to the features found in standard workflow languages such as YAWL (Yet another Workflow Language) (Hofstede, van der Aalst, Adams, & Russell, 2010) and OMG BPMN (Business Process Modelling Notation), as well as emerging case-based standards such as OMG CMMN (Case Management Modelling Notation) and OMG 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 differences 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. Technical Requirements

3.1. Overview

The openEHR Process and Planning Overview describes the general requirements for Task Planning and its related formalisms, which may be summarised as follows:

  • long term clinical plans;

  • reminders / checklist items for basic actions that are often missed or forgotten due to busy workplace and fatigue;

  • complex sets of actions defined by clinical pathways;

  • decision points that determine which path from alternatives to follow;

  • actions requiring sign-off;

  • coordination of workers in a distributed team;

  • actions that result in recording something in the EHR;

  • actions of varying levels of granularity that are needed in a training mode.

Task planning is accordingly 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 specific technical requirements appear, described below.

3.2. Flexible Allocation of Workers

The varying availability of workers for a given plan execution needs to be accommodated within the planning architecture. It should be possible for the specific worker performing a task to leave and be replaced by another, whether during an active period of work, or between tasks within the plan.

3.3. Coordinated Teamwork

In many cases, a 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.4. 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 perform 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 plan, each task of which which can then be performed and signed off by a staff member, e.g. a shift nurse. The structure of such a granular plan can act as a record of what has been done (or not), 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. E.g. diabetes is a chronic condition, so insulin treatment will never be completed. Or currently no assumption can be made about the competition date, e.g. pain medication for a trauma patient.

3.5. Tracking Orders from Plans

A standard activity within any clinic context is to raise orders, e.g. for lab tests, radiology etc, and to await the results. This may commonly be done within the context of a plan representing a standard protocol, such as for an annual schedule of health checks for various categories of patient (child, adult, elderly, diabetic etc). In an openEHR context, orders are represented using Instruction EHR entries, with subsequent actions being recorded as Action entries in the EHR. Where a plan is defined to create orders, it should be possible to define tasks in the plan to create, execute (i.e. send) orders, and wait on results, for multiple simultaneous orders in the same plan.

3.6. 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 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.7. 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.8. 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.9. Checklist & Sign-off

If a 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 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.10. Sub-plans

Plans can be described at varying levels of detail, depending on how workers are intended to relate to 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 the 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 plan, and to be able to refer to it from another plan. The general case is that any task that could be represented by a single item in a plan could also be represented by a reference to a separate detailed plan.

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

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

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

3.14. Changes and Abandonment

Inevitably, some 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 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.15. Rationalising Unrelated Work Plans

It is assumed that at any moment there could be multiple 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 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 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.16. 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.17. Support for Costing and Billing Information

It should be possible to record internal costing data against plans as a whole, and also individual tasks. Additionally, it should be possible to attach external billing information to tasks and 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 key design paradigms underpinning the Task Planning model defined in this specification.

4.1. Conceptual Model

Conceptually, plans as defined in this specification are not standalone, and require decision logic as well as access to subject data in order to execute. Such logic is represented in decision logic modules, as described in the openEHR Process and Planning Overview.

One important consequence of this separation of concerns is that the Task Plan model described here uses symbolic references to refer to both proxy values (patient state, previous diagnoses etc) and decision logic functions, rather than including expressions inline, in the manner of most workflow languages. All 'expressions' are thus represented externally, either within decision logic modules or proxies. Both of the latter are maintained as independent knowledge artefacts and used by plans.

4.2. Computational Basis

A basic choice in the architecture presented here is that it is executable in the sense that Plan definitions have an objective computational meaning and can therefore be executed according to the semantics of the model defined in this specification. This does not of course mean that the resulting system performs the work (although it may contain software agents that perform some particular Tasks). Instead, the resulting executable artefacts and application(s) when executed in a real world socio-technical environment that includes human and other actors, will convert disparate workers with weak communication into an integrated, coordinated team.

This follows the YAWL approach (Hofstede, van der Aalst, Adams, & Russell, 2010), such that no Plan defined according to this specification has ambiguous meaning.

4.3. Computation Context

This specification describes the models and semantics for task plans and their execution by an abstract openEHR Task Planning execution engine ('TP engine'). The TP engine executes both Plans and related Decision support modules. It obtains information on the patient via the Subject proxy, which as described above, converts data available from the EHR and elsewhere to a virtual view of the patient. It is assumed to operate in a back-end 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 the 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 computational environment is shown below.

computational environment
Figure 2. 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.1. Separation of Definition and Execution

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

  • Plan template, representing re-usable Plans and Plan components, from which Plan 'definitions' can be generated;

  • Plan definition, the concrete representation of a particular Plan that may be directly executed;

  • Plan execution, the execution of the plan, which may be long-lived, e.g. days, months, years;

  • Task execution, the runtime execution of part(s) of a Plan during user sessions, via use of applications etc.

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

4.4. Conceptual Elements

4.4.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 single subject of care. A different subject requires a different instance of a Work Plan. Goals are often defined by published guidelines or care pathways, and the overall structure of work defined within a Work Plan and its constituent Task Plans may well be structured according to such publications.

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

  • distinct performers working in different contexts, across which managed hand-offs 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 (i.e. a 'Task Planning engine'), in which methods of notification and worker communication are available, enabling the state of progress of the work defined in the Plan to be fully represented. A Work Plan will often be limited to a single enterprise, but this need not be the case, as long as all of its Task Plans communicate within the same Plan execution context.

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

4.4.2. Task Plan

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

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

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

In business terms, a Task typically corresponds to:

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

4.4.2.1. Parallel and Sequential Execution

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.

4.4.2.2. Conditional Structures

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 multi-branch logic chain with any condition on each branch, evaluated in order;

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

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

In a purely deterministic view of workflow, the above types of conditional structures correspond to the situation where the conditions are fully defined in the Plan, and execution unequivocally follows the paths according to the evaluation results of each condition. However, in a realistic system this is only one possible mode of execution, because the condition expressions might not always correctly represent reality, due to being approximate or simply deficient. In such cases, the user may need to override the ordinary execution path. This can easily happen in a clinical scenario, where the condition structure is defined as an attempt to represent recommendations that may be overridden by better knowledge on the part of the runtime user (e.g. an oncologist).

A third possibility exists as well: conditional pathways whose conditions are not encoded at all in the Plan definition, i.e. are only known by runtime users. Such 'ad hoc' conditional structures occur where no clear or simple algorithm can be stated for choosing each path. A typical example in a clinical situation is a physician determining the complex trade-off between efficacy and side-effects for which drug regime to use for a complex condition such as cancer.

There are thus three levels of human/system interaction with respect to conditional processing:

  • fully automated: formal conditions fully express the criteria for altenate paths;

  • decision support: formal conditions are an attempt to provide support to users, but may be overridden;

  • ad hoc: alternate pathways are defined, but the criteria for entry are provided by the user at execution time.

4.4.2.3. Summary

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.

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 via sub-plan;

  • 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.4.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.4.4. Work Context

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

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

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

4.4.5. Context Switch and Fork

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

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

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

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

task taxonomy
Figure 3. Task Taxonomy

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

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

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

  • immediately - this will be the case of a radiologist reviewing an MRI for an acute stroke;

  • when the worker is ready - e.g. the case where it’s a GP working through a list of patients in a waiting room;

  • when the patient arrives - e.g. when a patient is sent for a transfusion, the transfusion unit should start on the patient as soon as he/she appears in that part of the hospital.

4.4.6. Context Continuity over Worker Shifts

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

4.4.7. Principal Performer

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

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

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

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

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

4.4.8. 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 moment at which an event occurs.

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

  • 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.5. 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
(= one subject)
(instances of definition
classes)

When a Work Plan model is used for a subject (i.e. patient), it is instantiated from its templated archetypes, creating an instance of the Work Plan definition (i.e. in the class/instance sense).

At instantiation time, Task Plans re-used by reference within a Work Plan at the archetype level are instantiated as distinct instances for each such reference.

After Work Plan instantiation, the planner may adjust it in any way that maintains conformance with its archetypes and template, e.g. to provide values for particular parts of the model such as medication dosages, that correspond to the particular subject.

Clinical time -
plan execution

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

Close to Plan execution time, a Work Plan definition will be materialised, i.e. instantiated for execution. 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.

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

4.5.1. Phases of Work

In this scheme, archetype- and template-based modelling is used as much as possible during the design phase, in order to create a hierarchy of re-usable models that are progressively more specialised, until close-to-patient models are achieved, typically as templates. This enables the power of the archetype modelling formalism, including specialisation and composition to be used freely, in a similar manner to an object-oriented programming environment.

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

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

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

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

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

tp modelling wf
Figure 4. TP Modelling Workflow

4.6. Execution Concepts

4.6.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 current Task Plan.

  • terminated state: A Work 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 Work 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.6.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.6.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 abandoned available for cases where a Task is cancelled and abandoned respectively. Here, cancelled means 'not needed', i.e. the principal performer determined Task could be cancelled before or during execution, without compromising the Plan. Conversely, the abandoned state indicates that the performer cannot do or complete the Task, or the rest of the Plan. Thus, abandoned for a Task means abandonment of the current Task Plan.

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

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

4.6.4. Availability

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

  • Execution control flow reaches the Task;

  • Any waited-on external event occurs;

  • 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, abandoned etc.

The following diagram illustrates these concepts.

task availability
Figure 5. Task Availability

4.6.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 abandoned (abandon current Task 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.7. Relationship of Tasks 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 6. 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 Work Plan corresponds to a clinical goal which implicates multiple orders, such as the CHOP chemotherapy mentioned above.

Consequently, not every Task in a Work 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 7. Clinical Investigator Process with Planning

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

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

This section and the following one describe the Task Planning model in technical detail. Most of the emphasis is on the 'definition' level of expression, with most details of the 'materialised' and 'runtime' expressions left to implementers. Throughout these sections, a version of the Task Planning Visual Modelling Language (TP-VML) is used to illustrate instance structures. This visual language is designed to be formally aligned to the semantics of the model.

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 materialised 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 8. proc.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 9. 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. Plan Data Context

TBD: this section needs to be upgraded to latest EL and BMM model. The type EXPR_TYPE_DEF will be replaced by a BMM equivalent.

A Task Plan may contain logical symbolic values of various kinds, including constants, variable references and expressions, which are used in 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. Each context value has a symbolic name (CONTEXT_VALUE.name), a type from within the openEHR type system (EXPR_TYPE_DEF). The following UML diagram illustrates.

PROC task planning.definition context
Figure 10. 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 constants, or else expressions that reference such variables, respectively represented by the classes CONTEXT_VARIABLE<T>, CONTEXT_CONSTANT<T> and CONTEXT_EXPRESSION<T>. These classes and the abstract parent are generic, with the parameter being the formal type of variable or expression.

Context 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 $bp_systolic - $bp_diastolic, where $bp_systolic and $bp_diastolic are defined as single variables. The syntax of expressions is defined by the openEHR Expression language.

Two types of context variable are distinguished: external and local, represented by EXTERNAL_VARIABLE<t> and LOCAL_VARIABLE<T>. The former represent values of entities outside the task planning environment, and are written to via a populating_request which uses some method (such as EHR querying, API calls) to obtain the relevant external value. They are accordingly not writable from within the Work Plan.

There are two types of external 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.

Local variables are internal to the Work Plan, and can be read and written to by expressions used within Tasks in the Plan.

5.2.1. Class Descriptions

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

0..1

constants: List<CONTEXT_CONSTANT>

List of all constants used in the Plan.

5.2.1.2. CONTEXT_VALUE Class

Class

CONTEXT_VALUE<T> (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

name: String

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

1..1

type: T

Type of this variable.

5.2.1.3. CONTEXT_CONSTANT Class

Class

CONTEXT_CONSTANT<TT>

Description

Definition of a symbolic constant value that can be used in Context Expressions.

Inherit

CONTEXT_VALUE

Attributes

Signature

Meaning

1..1

value: Any

Value of the constant.

5.2.1.4. CONTEXT_VARIABLE Class

Class

CONTEXT_VARIABLE<TT> (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

5.2.1.5. EXTERNAL_VARIABLE Class

Class

EXTERNAL_VARIABLE<TT> (abstract)

Description

A variable that carries a value from the external environment, including patient variables, and has a method of being populated. Cannot be written to from within the TP environment.

Inherit

CONTEXT_VARIABLE

Attributes

Signature

Meaning

0..1

populating_request: SYSTEM_CALL

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

5.2.1.6. LOCAL_VARIABLE Class

Class

LOCAL_VARIABLE<TT>

Description

Variable that is used locally within the Work Plan, and can be used to transmit information to sub-plans.

Inherit

CONTEXT_VARIABLE

5.2.1.7. EVENT_VARIABLE Class

Class

EVENT_VARIABLE<TT>

Description

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

Inherit

EXTERNAL_VARIABLE

5.2.1.8. CONTINUOUS_EVENT_VARIABLE Class

Class

CONTINUOUS_EVENT_VARIABLE<TT>

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.2.1.9. STATE_VARIABLE Class

Class

STATE_VARIABLE<T>

Description

Abstraction of a real-world variable that represents a quality of a subject, e.g. patient diabetic status, date of birth etc.

The generic parameter is a model type from an accessible model.

Attributes

Signature

Meaning

0..1

history: Hash<String,VALUE_SNAPSHOT>

Local history of values.

1..1

name: String

Name of variable.

Functions

Signature

Meaning

1..1

is_available (): Boolean

Return True if there is a value in history.

0..1

unavailable_reason (): String

If is_available is False, potentially provide a reason.

0..1

value (): T

Retrieve latest value, or null if none.

5.2.1.10. CONTEXT_EXPRESSION Class

Class

CONTEXT_EXPRESSION<TT>

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.2.1.11. BOOLEAN_CONTEXT_EXPRESSION Class

Class

BOOLEAN_CONTEXT_EXPRESSION

Description

Boolean-valued form of CONTEXT_EXPRESSION.

Inherit

CONTEXT_EXPRESSION

5.3. System Calls

The SYSTEM_CALL class and its descendants provide a way to represent a call to any service or interface available within the computing environment. The class attributes are designed to carry sufficient meta-data such that a call invocation module or plug-in in the Task Planning execution environment can convert the call to a concrete form (e.g. a REST or RPC call) and then execute it.

5.3.1. Generic API calls

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

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

  • context values: context values, Work Plan built-in variables (see below);

  • fixed parameters: parameters whose value is fixed from the point of view of the Plan definition.

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

    cds_calc_risk (
        riskType:    String;
        sex:         CodedText;
        dateOfBirth: Iso8601Date;
        isSmoker:    Boolean;
    ): Real

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

    {
        "parameter_map": [
            {"context_name": "subject_sex",        "name": "sex"},
            {"context_name": "subject_dob",        "name": "dateOfBirth"},
            {"context_name": "tobacco_use_status", "name": "isSmoker"}
        ]
    }

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

TBD: we may need to allow functions, so that data type/structure conversions can be managed.

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

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

5.3.2. Query Calls

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

    // ad hoc query call
    execute_ad_hoc_query (
        query_text: String;
        parameters: Hash<String, String>;
    ): Result

    // stored query call
    execute_stored_query (
        query_id: String;
        parameters: Hash<String, String>;
    ): Result

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

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

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

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

5.3.3. Class Descriptions

5.3.3.1. SYSTEM_CALL Class

Class

SYSTEM_CALL (abstract)

Description

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

The formal signature of the call may be referenced via the definition attribute.

Attributes

Signature

Meaning

0..1

parameter_map: List<PARAMETER_MAPPING>

Map of parameter names from system call definition (i.e. argument names) to Work Plan context variable names. This may be partial if there are bound parameters.

1..1

system_id: String

Identifier of target system, typically a domain name.

1..1

call_name: String

Name of call in API.

0..1

definition: @@

Signature definition of call.

TODO: to be defined.

0..1

bound_parameters: List<PARAMETER_DEF>

Parameter values fixed for any invocation of the call. For example, a general call such as cds_check (type: String, other_args, …​) might be used from within the Task Plan in the form cds_check ("hypertension risk", other_args, …​), i.e. the first argument is always fixed.

5.3.3.2. PARAMETER_DEF Class

Class

PARAMETER_DEF

Description

Specifies a parameter with a name and type from an external API, and a value to be passed for this parameter on call invocation.

Attributes

Signature

Meaning

1..1

name: String

Name of parameter in external API call.

1..1

type: EL_TYPE_DEF

Type of parameter in external API call.

1..1

value: Any

Fixed value to pass on call invocation.

5.3.3.3. PARAMETER_MAPPING Class

Class

PARAMETER_MAPPING

Description

Mapping of an internal context value name to an external API call parameter name.

Attributes

Signature

Meaning

1..1

name: String

Name of parameter in external API call definition.

1..1

context_name: String

Name of context value definition (i.e. variable, expression, constant, including built-ins) whose value should be passed through as the named parameter on call invocation.

5.3.3.4. API_CALL Class

Class

API_CALL

Description

Type of System call targetted to a general API, which may by via any concrete technology or protocol. The parameters list will normally consist of heterogeneous types.

Inherit

SYSTEM_CALL

5.3.3.5. QUERY_CALL Class

Class

QUERY_CALL

Description

Type of System Call that is to a query service, where calls are available for executing ad hoc queries and stored queries. For the ad hoc case, the parameters are of the form:

  • query_text: String

  • query_parameters: Hash<String, String>

while for the stored query case, a query_id would be supplied instead of the query_text: String.

In the context of a Work Plan / Task Plan, query parameters supplied from three places:

  • for substitutable parameters having the same name as context variables, by implicit substitution;

  • for parameters with different names, parameter_map defines the mapping;

  • for fixed parameters, bound_parameters contains the values.

Inherit

SYSTEM_CALL

Attributes

Signature

Meaning

0..1

query_id: String

Identifier of a stored query.

0..1

query_text: String

Ad hoc query text.

5.4. Variable Referencing

Within the expressions and System calls used in Task definitions, various variables may be used. These include the context variables described above and built-in variables defined for any Work Plan context, enabling the current Plan, current Task etc to be referred to, for example in a System call. The 'camel-case' and 'snake-case' variants of a variable name are treated as equivalents, i.e. $var_name and $varName refer to the same thing. Among the context variables, some standard defaults are recommended in order to maximise reusability of Task Plan definitions.

Within expressions, defined variables are referenced using the '$' syntax, i.e. $var_name or $varName. Within System calls there are two places where variable references may appear:

  • within the parameters list, to indicate the mapping of a call parameter to a variable defined in the Work Plan context;

  • as lexical inline replaceable parameters within a call parameter that represents an ad hoc query string or similar.

For the first case, the '$' name form is used. In the second case, variables usually appear within query strings in a lexical form that depends on the particular kind of query syntax, i.e. forms such as:

  • $var_name - openEHR AQL;

  • @varName - SQL Server, Oracle, PostGres 9 or later;

  • $[varName] - some SQL implementations.

TBD: do we need another property to record the type of query syntax, e.g. 'aql', 'oracle-sql', or variable syntax, since it is not a SQL standard?

The following table describes the variables available within a typical Work Plan.

Name Type Status Description

Work plan-defined variables

$work_plan_id / $workPlanId

String

Standard

Variable referring to current WORK_PLAN.uid

$task_plan_id / $taskPlanId

String

Standard

Variable referring to current TASK_PLAN.uid

$task_group_id / $taskGroupId

String

Standard

Variable referring to current TASK_GROUP.uid

$task_id / $taskId

String

Standard

Variable referring to current TASK.uid

$subject_id / $subjectId

String

Standard

Variable referring to current WORK_PLAN.subject.external_ref.id.value

Context variables and expressions

$var_name / $varName

Any

Standard

Any variable or expression, e.g. $heart_rate;

$ehr_id / $ehrId

String

Preferred

Variable referring to EHR id of EHR of the subject of the Task Plan

$bp_systolic / $bpSystolic

Real

Preferred

Variable referring to subject current systolic arterial blood pressure

$bp_diastolic / $bpDiastolic

Real

Preferred

Variable referring to subject current diastolic arterial blood pressure

$heart_rate / $heartRate

Real

Preferred

Variable referring to subject current heart rate

5.5. 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.5.1. Class Descriptions

5.5.1.1. TIME_SPECIFIER Class

Class

TIME_SPECIFIER (abstract)

Description

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

5.5.1.2. CLOCK_TIME Class

Class

CLOCK_TIME

Description

A point in time within a day.

Inherit

TIME_SPECIFIER

Attributes

Signature

Meaning

1..1

time: Iso8601_time

Time expressed as a clock time within a day.

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

Resolution to computable times is assumed to be done via call to a service or resource available within the operational environment.

Inherit

TIME_SPECIFIER

Attributes

Signature

Meaning

1..1

time: DV_CODED_TEXT

A coded term expressing a customary time in natural language.

5.6. Enumerated Types

Various enumerated types are defined in the definitions package, for use by the definition, materialised and runtime models. The TASK_LIFECYCLE enumeration is included in Section 6.2.3.

5.6.1. Class Descriptions

5.6.1.1. 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.6.1.2. 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.6.1.3. 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.6.1.4. PLAN_TIME_ORIGIN Enumeration

Enumeration

PLAN_TIME_ORIGIN

Description

Enumeration of types of origin for time offsets within a Work Plan.

Attributes

Signature

Meaning

current_work_plan

Time offset is relative to the moment of activation of the Work Plan within which the offset occurs.

Integer value = 0.

current_task_plan

Time offset is relative to the moment of activation of the Task Plan within which the offset occurs.

Integer value = 1.

inner_repeat_section

Time offset is relative to the moment of activation of the innermost Repeat Section (Task Group or Task with a REPEAT_SPEC) within which the offset occurs.

Integer value = 2.

outer_repeat_section

Time offset is relative to the moment of activation of the outermost Repeat Section (Task Group or Task with a REPEAT_SPEC) within which the offset occurs.

Integer value = 3.

6. Definition Model

6.1. Overview

This section describes the formal model of Work Plan and Task Plan, which is presented in UML form, as well as in TP-VML definition instance form. The following figure shows the main classes in the proc.task_planning.definition package.

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

The remaining classes are shown in various specialised views below.

6.2. Plan Structure

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. Within a Work Plan, two distinct lists of Task Plans are maintained:

  • plans: references all Task Plans;

  • top_level_plans: 'entry point' Task Plans that will be unconditionally active at Work Plan activation (often limited to only one).

Non-top-level plans are those used as sub-plans within the hierarchy of a top-level Plan. A typical Work Plan / Task Plan structure is shown below in TP-VML form.

work task plans
Figure 12. Work Plan top level structure

WORK_PLAN has a number of attributes relating to formal Plan representation, 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 containing entries that relate to this Work Plan, e.g. 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;

  • order_list: a table of references to orders being tracked in the Plan (described in Section 6.8 below).

Additionally, there are the following meta-data attributes:

  • indications: record clinical indications (including codes for diagnoses) for which the Work Plan can be / should be used;

  • classification: record one or more classifications of the Work Plan as a whole, e.g. business category, administrative category etc. The most common structure is likely to be a logical list (i.e. ITEM_TREE instance of linear list form), such that the archetype_node_id attribute (inherited from LOCATABLE) acts as the name of the category (e.g. 'org unit'), and an ELEMENT containing a DV_TEXT providing the actual category value (e.g. 'inventory management').

Both WORK_PLAN and TASK_PLAN are descendants of CONTENT_ITEM, which makes them a type of content that may occur in an openEHR 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.

Plan internal structure is specified by the definition attribute of a TASK_PLAN is a TASK_GROUP, which has as its members any number of PLAN_ITEMs, which resolve either to more TASK_GROUPs (and some specialisations described below), or TASK entities.

6.2.1. The Plan Calendar

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

6.2.2. Plan Items

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

6.2.2.1. Wait States

PLAN_ITEM also has two optional attributes that control the timing behaviour of Task Plan elements: wait_spec and repeat_spec. The first enables a wait state (described above under Section 4.4.8) 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.

6.2.2.2. Repetition

The second attribute, repeat_spec of type TASK_REPEAT enables a Task or Group to be marked as repeating. This is not 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 (i.e. Task Groups) of planned Tasks are repeatable. Where repeats are specified, they will be unrolled into literal copies in the materialised expression of the Plan.

Repeat behaviour is specified in terms of the attributes repeats, terminate_condition and period. The first indicates the minimum and maximum number of repeats that may occur. Repetition occurs until the minimum number of repeats (i.e. repeats.lower) is reached. Following that, if terminate_condition is set, it is evaluated prior to each further potential iteration. Repetition will cease when terminate_condition becomes True or else when repeats.upper is reached (assuming no plan abandonment or other exceptions).

The optional period attribute defines the period of repetition. If the latter is not defined, each repetition commences according to the application of Task availability rules already defined on the individual Tasks and/or Groups; this will typically lead to each repeat executing as soon as the preceding one has completed. If set, the period will have the effect of spacing iterations out over time. Its value should be greater than the duration of a single iteration, since at execution time, a new iteration can only begin after completion of the previous one.

6.2.2.3. Other Attributes

Two archetypable structure attributes are defined on PLAN_ITEM. The first, classification, is designed to allow any Task Group or Task to be tagged with one or more classifications, and has the same structural definition at WORK_PLAN.classification.

The second, other_details is provided to support extensions, in the same manner as elsewhere in openEHR information models.

6.2.3. Lifecycle State

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

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

The state machine is shown below.

PROC TaskStateMachine
Figure 13. Task lifecycle state machine

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

Note
Task lifecycle only accounts for the states of a Task itself; states of an order (e.g. prescription, lab request) with which the Task may be associated will be visible in the documentation for those objects, e.g. openEHR ACTION or other Entry objects.

The lifecycle states are described by the TASK_LIFECYCLE enumeration below.

6.2.3.1. TASK_LIFECYCLE Enumeration

Enumeration

TASK_LIFECYCLE

Description

Enumeration representing possible lifecycle states for a Task lifecycle transition.

Integer-based values.

Attributes

Signature

Meaning

planned

Task is defined, but not yet available for execution.

Value = 0.

available

Task is available for execution by the performer, 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.

Value = 1.

cancelled

Task was cancelled prior to or during execution as not needed for success of the Plan. This is a terminal state.

Value = 2.

abandoned

Task was aborted due to completion being impossible, i.e. ended prematurely without meeting normal conditions of completion. This is a terminal state.

Value = 4.

underway

Task has been commenced or resumed from 'suspend' state.

Value = 5.

suspended

Task is put on hold, i.e. not actively being performed while in this state.

Value = 6.

completed

Task was completed in the intended way. This is a terminal state.

Value = 8.

6.2.3.2. Task Availability

Each Task in a new Plan execution starts in the initial state. 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 as follows:

  • control-flow: preceding Tasks / Groups within the owning Task Group are in the completed or cancelled state;

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

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

A Task is considered available according to this logic even if performer and/or resources have not been allocated. Availability in this sense is the equivalent of the 'enabled' state of a task within a Workflow Net, described in Hofstede van der Aalst Adams & Russell (2010), section 2.3.2.

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

6.2.3.3. Aggregate Process State

The effective state of a Task Group, Task Plan and Work Plan can be inferred from the lifecycle states of the Tasks, according to logic described in Section 7.3. This includes availability of Task Groups containing parallel paths with associated OR logic, i.e. the equivalent of the OR-join in YAWL (Hofstede van der Aalst Adams & Russell (2010), section 3.2).

6.2.4. 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_pathway: a reference to a published care pathway from which this Work Plan was derived, if any;

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

  • In TASK_PLAN:

    • guideline: reference to a published guideline (used by WORK_PLAN.care_pathway, if set) 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;

  • In PLAN_ITEM:

    • guideline_step: reference to a step within the guideline referenced by the current Task Plan or the care_pathway of the Work Plan, which is the basis of this Plan Item, i.e. single Task or Task Group.

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

  • In TASK_PLAN:

    • order_set_type: the identifier of a type of Order Set which this Task Plan uses, if any;

    • order_set_id: the identifier of a specific Order Set which this Task Plan uses, if any.

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

6.2.5. Class Definitions

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

The attribute care_pathway and `care_plan`provide a way of associating a Work Plan with a published care pathway, and an operational care plan from within the EHR, if available.

Inherit

AUTHORED_RESOURCE, CONTENT_ITEM

Attributes

Signature

Meaning

0..1

care_pathway: ITEM_STRUCTURE

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, heart attack etc.

The ITEM_STRUCTURE type is used to allow population at runtime with an archetype based on e.g. BibTex publication reference fields, such as the following:

  • title = "NICE Sepsis care pathway";

  • publisher = "National Institute of Health and Care Excellence (UK)";

  • year = 2016;

  • url = "https://pathways.nice.org.uk/pathways/sepsis".

1..1

plans: List<UID_BASED_ID>

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

1..1

calendar: PLAN_CALENDAR

Global calendar object, containing events fixed in time relevant to the Plan’s Tasks, for example appointments.

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

The set of Task Plans that are active at Work Plan activation. Does not include Task Plans referred to from HAND_OFF or SUB_PLAN.

TODO: change to computed?

0..1

indications: List<DV_TEXT>

Clinical applicability of this Work Plan to subject of work, e.g. 'acute ischaemic stroke' etc. May be derived from a governing guideline.

0..1

order_list: Hash<String,ORDER_REF>

Orders tracked by Tasks in this Work Plan.

0..1

classification: ITEM_STRUCTURE

Archetypable structure for recording classification of Work Plans, e.g. business process category, administrative category etc.

Note that the same kind of classifications can be applied to Tasks and Groups via PLAN_ITEM.classification.

6.2.5.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.2.5.3. PLAN_TIMELINE Class

Class

PLAN_TIMELINE

Description

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

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.2.5.4. CALENDAR_ENTRY Class

Class

CALENDAR_ENTRY

Description

A single calendar entry.

6.2.5.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 guideline attribute provides a way of associating a Task Plan with a published guideline on which the Task Plan may be based; this may be used by WORK_PLAN.care_pathway if set.

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 Plan, which is normally the subject of the EHR. If this is not the case, this attribute states with respect to whom the Plan is to be performed.

0..1

guideline: ITEM_STRUCTURE

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.

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, heart attack etc.

The ITEM_STRUCTURE type is used to allow population at runtime with an archetype based on e.g. BibTex publication reference fields, such as the following:

  • title = "NHS guideline for Atrial fibrillation: management";

  • publisher = "National Institute of Health and Care Excellence (UK)";

  • year = 2016;

  • url = "https://www.nice.org.uk/guidance/cg180".

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

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

0..1

due_time: Iso8601_duration

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

classification: ITEM_STRUCTURE

Archetypable structure for recording classification of Task Groups or Tasks, e.g. business process category, administrative category etc.

0..1

wait_spec: TASK_WAIT

Optional wait specification for Plan Item (Task or Group) initiation. If not set, the Plan Item is immediately available once execution reaches it. If set, it becomes available when any Event in events occurs.

0..1

review_dataset: List<REVIEW_DATASET_SPEC>

Optional data-set to review prior to / as part of performing the Plan element.

0..1

guideline_step: String

Optional reference to a step within the guideline referenced by the current Task Plan (if set) or else the care_pathway of the Work Plan, which is the basis of this Plan Item, i.e. single Task or Task Group.

The reference may take the form of a plain text section or item name within the referenced guideline, e.g. '"Check heart rate"' or be a URI or path reference, if the guideline has an online machine-representation.

0..1

other_details: ITEM_STRUCTURE

Archetypable structure for recording non hard-modelled information.

0..1

reminders: List<REMINDER>

Optional wait state(s) that may be used to remind the Task performer to do something based on a Timer or other Event. Will be cancelled by the Task transitioning to any new state from the available state, due to performer activity.

6.2.5.8. TASK_REPEAT Class

Class

TASK_REPEAT

Description

Definition of repetition for a Plan Item. The repeats attribute states the number of repeats. Here, 'repeats' means additional executions, i.e. not counting the original execution. If not set, any number of repeats is allowed. The minimum number of repeats is set by the lower bound of repeats.

If set, the terminate_condition attribute defines when repetition should cease, once the minimum number of repeats has occurred according to repeats. It is expressed in terms of a condition, typically a subject-related variable. It is tested after prior to each new potential execution following the minimum number.

If period is set, this defines the duration between the start of each iteration at execution time. It has the effect at runtime of adding a wait_spec with a TIMELINE_MOMENT event to each PLAN_ITEM copy in the materialised form, i.e. creating the same structure as would have been created if the repetitions had been manually specified.

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. If set, tested prior to each further potential repetition once the minimum number have been executed.

0..1

period: Iso8601_duration

Optional period of repetition, i.e. duration between the commencement of each PLAN_ITEM clone in the materialised form.

6.3. Task Group Structure

The set of Tasks in a Task Plan is represented within a containment structure created using instances of the TASK_GROUP class, which has three key attributes. Execution of a Group is primarily controlled by the execution_type and concurrency_mode attributes, which respectively indicate sequential or parallel processing, and for the latter case, various modes of and and or parallel processing logic (described in the next section), common to workflow formalisms. For more exotic situations, the execution_rules attribute can be used.

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

The Task Group construct enables two important ways to relate Tasks together:

  • as a module of work consisting of a series of Tasks, achieved by a Task Group with execution_type = sequential;

  • as a set of possible or mandatory concurrent threads of work, achieved by a Task Group with execution_type = parallel.

6.3.1. Sequential Task Groups

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

task group sequential
Figure 14. Sequential Task Group

6.3.2. Parallel Task Groups and Concurrency

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

task group parallel
Figure 15. Parallel Task Group

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

  • how many branches may be commenced;

  • how commencing a branches affects other branches;

  • under what conditions to consider the group has completed.

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

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

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

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

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

Concurrency mode TP-VML Logic Split
behaviour
Join
behaviour

and_all_paths

task group parallel and

AND

All branches are followed.

Group completes when all branches complete.

xor_one_path

task group parallel xor

XOR

Only one branch can be started; once a branch is commenced, the first Task in remaining branches is transitioned to cancelled.

Group completes when the started branch completes; equivalent to a sequential Group, once a branch is chosen.

or_all_started

task group parallel or all

partial AND

One or more branches may be commence.

The Group is complete when all branches commenced have completed; equivalent to an AND consisting of all commenced branches.

or_first_completed

task group parallel or first

OR

One or more branches may be commenced.

The Group is complete when one branch completes.

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

6.3.3. Hierarchical Nesting

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

task grouping
Figure 16. Nested Task grouping - sequential structure

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

task grouping2
Figure 17. Nested Task grouping - parallel chains

6.3.4. Generic Execution-time Semantics

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

6.3.5. Well-formedness

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

6.3.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.3.7. Class Definitions

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

If set to parallel, the Task Group represents a split/join pair with respect to all contained Tasks and Groups. In this case, concurrency_mode may be set to control the processing. If it is not set, 'AND' logic is assumed (i.e. and_all_paths).

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

concurrency_mode: CONCURRENCY_MODE

Mode in which to execute if execution type is parallel.

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.

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.

6.3.7.2. 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.3.7.3. CONCURRENCY_MODE Enumeration

Enumeration

CONCURRENCY_MODE

Description

Mode in which concurrent processing should proceed.

Attributes

Signature

Meaning

xor_one_path

Only one parallel path is followed.

and_all_paths

All paths are followed, and Group completes only when all complete.

or_first_completed

Group completes when any one path completes.

or_all_started

Group is complete when all paths commenced complete.

6.3.7.4. EXECUTION_RULE Class

Class

EXECUTION_RULE

Description

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

TODO: define detail.

6.4. General Task Semantics

6.4.1. Dispatchable and Performable Tasks

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

The DISPATCHABLE_TASK<T> class has two attributes to do with managing context change and callback. The wait flag indicates whether the current Task waits (i.e. blocks) while the dispatched work is performed, or whether it continues on asynchronously. The first constitutes a context switch, the second a context fork. The callback attribute attaches a special kind of Event wait state that is triggered on receipt of a callback. How callbacks function in detail is described below.

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

Task Type Description Lifecycle state

Performable

Task performed by the current performer.

Advanced by actions of performer (real world actor)

Dispatchable

A Task whose work is dispatched for execution to another performer or system.

wait = True: Advanced by receipt of callback notification
wait = False: Automatically advanced to completed

6.4.2. Class Definitions

6.4.2.1. TASK Class

Class

TASK<TA> (abstract)

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.

0..1

order_tags: List<String>

References to order(s) being created and / or tracked by this Task. The value(s) must match ORDER_REF.order_tag values from the list WORK_PLAN.order_list and be unique within the list.

Multiple tags are only required if the same Task causes creation of, or tracks, more than one order.

Invariants

Inv_order_tags: order_tags /= Void implies not order_tags.is_empy

6.4.2.2. DISPATCHABLE_TASK Class

Class

DISPATCHABLE_TASK<TA>

Description

Type of Task representing work to be performed by another actor. Such Tasks are 'dispatchable' in the sense that they consist of notifying a request for specific work to be done by another principal performer, or an external system or service. The details of the target are defined in action.

If wait is True, the Task blocks until the target work thread returns. If callback is set, specific processing can be performed on the return, before execution progresses. If it is not set, the Task completes normally on target completion, and execution continues to the next Task. In this case (wait = True, no callback), a global timer will be created for the Task to deal with the situation where the dispatch target never returns.

Inherit

TASK

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.4.2.3. PERFORMABLE_TASK Class

Class

PERFORMABLE_TASK<TA>

Description

Represents a Task that can be performed by the principal performer during the Plan execution.

Inherit

TASK

Attributes

Signature

Meaning

0..1

capture_dataset: List<CAPTURE_DATASET_SPEC>

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

6.5. 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 DISPATCHABLE_ACTION and PERFORMABLE_ACTION distinguish the dispatchable and performable flavours of Task Action, corresponding to the two TASK subtypes. The following UML diagram shows TASK_ACTION and its subtypes in detail.

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

TASK_ACTION includes two 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.

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.

Performable Actions have two 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.

The subtypes of TASK_ACTION consist of the following:

Type TP-VML Description

DEFINED_ACTION

task defined task

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

SUB_PLAN

task 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

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;

HAND_OFF

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

EXTERNAL_REQUEST

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

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

6.5.1. Performable Actions

6.5.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 19. 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 TASK_GROUP.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 this setting.

6.5.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 20. 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 21. 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.5.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 three sub-types correspond to 3 different types of other performer, i.e.:

  • HAND_OFF: another principle performer in the same Work Plan;

  • EXTERNAL_REQUEST: a performer outside the current Work Plan computational environment.

  • SYSTEM_REQUEST: a computation to be performed by a system call;

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.5.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 22. 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.5.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 computational context, to request some work on behalf of the performer. This is typically an organisation of which routine requests can be made (e.g. pathology laboratory). The request has to be defined generically, 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.5.2.3. System Request

The Task sub-type SYSTEM_REQUEST 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.5.3. Class Definitions

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

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.5.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, e.g. 'patient no allergic to penicillin'.

Evaluated when encountered.

0..1

expression: BOOLEAN_CONTEXT_EXPRESSION

An optional formal Boolean expression that can be machine-evaluated at runtime to determine availability, if the relevant variables exist.

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

6.5.3.4. 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.5.3.5. 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 openEHR EHR 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.5.3.6. 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.5.3.7. DISPATCHABLE_ACTION Class

Class

DISPATCHABLE_ACTION (abstract)

Description

Type of Task Action that is performed by another performer, system or organisation.

Inherit

TASK_ACTION

6.5.3.8. 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.5.3.9. 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.5.3.10. 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.5.3.11. 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: TASK_PLAN

Reference to target TASK_PLAN object.

6.6. Data-sets and Application Interaction

6.6.1. Overview

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

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

PROC task planning.definition dataset
Figure 23. proc.task_planning.definition model overview

6.6.2. Display and Capture Data-sets

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

  • data display: a REVIEW_DATASET_SPEC represents a template or part thereof that is to be displayed in order for the Task performer to do the work of the Task;

  • data capture: a CAPTURE_DATASET_SPEC represents a template or part thereof that is to be populated by the work of the Task.

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

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

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

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

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

6.6.3. Progressive Data Capture

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

progressive data capture
Figure 24. Progressive data capture structure

6.6.4. Class Definitions

6.6.4.1. DATASET_SPEC Class

Class

DATASET_SPEC (abstract)

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.

Inherit

LOCATABLE

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.

0..1

populating_call: SYSTEM_CALL

Optional system call that will populate this data-set.

0..1

form_section_path: String

Optional path to a sub-section of the form identified by form_id. The format of the path is the same as a template or AQL path.

Invariants

Inv_validity: form_id /= Void or template_id /= Void

6.6.4.2. CAPTURE_DATASET_SPEC Class

Class

CAPTURE_DATASET_SPEC

Description

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

Inherit

DATASET_SPEC

Attributes

Signature

Meaning

0..1

commit_group: DATASET_COMMIT_GROUP

Optional information for multi-step form fill and commit interaction with the EHR.

6.6.4.3. REVIEW_DATASET_SPEC Class

Class

REVIEW_DATASET_SPEC

Description

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

Inherit

DATASET_SPEC

Attributes

Signature

Meaning

0..1

capture_datasets: List<CAPTURE_DATASET_SPEC>

Capture data-sets (forms etc) used to obtain the data displayed in this Review data-set.

6.6.4.4. DATASET_COMMIT_GROUP Class

Class

DATASET_COMMIT_GROUP

Description

Specification of a 'commit group', i.e. a complete data set (usually a multi-part form) that is progressively built and committed in the incomplete lifecycle state, with a final complete state commit.

Attributes

Signature

Meaning

1..1

group_id: String

Unique identifier of this commit group within scope of a single Task Plan.

1..1

completion_step: Boolean

If True, the Task to which this Dataset Spec is attached is the one that puts it into the complete lifecycle state.

6.7. Decision Structures

6.7.1. Overview

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

PROC task planning.definition decision
Figure 25. proc.task_planning.choice package - decision structures

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

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

  • fully automated: three kinds of fully defined decision structures, namely the CONDITION_XX, DECISION_XX and EVENT_XX classes shown in the UML diagram;

  • decision support: where instances of the above structures should be considered recommendations only, the override_type attribute defined on CHOICE_GROUP may be used on any XX_GROUP to indicate that user override is allowed;

  • ad hoc: a dedicated variation ADHOC_GROUP and ADHOC_BRANCH are used to represent multiple branches where no criteria are defined in the Plan definition, but are instead provided by an execution-time user.

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

The three fully defined decision patterns are described below.

6.7.2. Condition Group (if/elseif/else chain)

The first is a structure in which a set of Task Groups are treated as separate branches from a common point in the Plan. Each branch is entered conditionally according to the Boolean expression included on the branch. The classes CONDITION_GROUP and CONDITION_BRANCH provide this structure, which is equivalent to an if/then/else structure in a programming language. A final 'else' branch may be defined using a CONDITION_BRANCH with an expression representing the True value. At execution time, the branches are evaluated in order, in the manner of an if/then/else structure.

The following diagram shows a typical condition structure.

condition structure
Figure 26. Condition structure

6.7.3. Decision Group (case)

The second pattern corresponds to a decision point in a workflow at which some expression is evaluated, and each outgoing branch corresponds to a sub-set of the expression’s value range (value_constraint attribute). The classes DECISION_GROUP and DECISION_BRANCH provide this structure, which is equivalent to a switch statement in a programming language. The branch sub-ranges should ideally be individually mutually exclusive, and collectively they should cover the entire value range of the expression. As with the Condition Group, the branches are processed in the order stated in the definition, which allows overlapping value constraints on successive branches. A catch-all 'else' branch may be represented as a DECISION_BRANCH with an open value_constraint (i.e. matching all values).

The following diagram shows a typical decision structure.

decision structure
Figure 27. Decision structure

6.7.4. Event Group

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

event structure
Figure 28. Event structure

6.7.5. Class Definitions

6.7.5.1. CHOICE_GROUP Class

Class

CHOICE_GROUP (abstract)

Description

Abstract precursor of root node of any decision structure. All such structures are instances of a Task Group in parallel mode, with XOR (single path) concurrency logic.

Inherit

TASK_GROUP

Attributes

Signature

Meaning

0..1

override_type: OVERRIDE_TYPE

Indicates kind of user override that would be accepted at runtime. If set to a value other than prohibited, user interaction is assumed, and runtime processing must enter a wait state.

0..1

timeout: TIMER_WAIT

Timeout handler to use if CHOICE_GROUP blocks unexpectedly, e.g. due to absent user, unavailable external data item.

0..1
(redefined)

members: List<CHOICE_BRANCH>

Set of branches in this Choice Group.

Invariants

Inv_parallel: execution_type = EXECUTION_TYPE.parallel

Inv_xor_concurrency: concurrency_mode = CONCURRENCY_MODE.xor_one_path

6.7.5.2. OVERRIDE_TYPE Enumeration

Enumeration

OVERRIDE_TYPE

Description

Enumeration expressing kinds of override that can be stated for a Plan definition decision structure.

Attributes

Signature

Meaning

allowed

Override by user is allowed.

allowed_with_reason

User override allowed with provided reason.

prohibited

Override by user is prohibited.

6.7.5.3. CHOICE_BRANCH Class

Class

CHOICE_BRANCH (abstract)

Description

Abstract precursor of any subordinate branch in a decision structure.

Inherit

TASK_GROUP

6.7.5.4. 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. The final branch may be used as a logical else (i.e. 'match-any') branch with a condition of True.

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

Inherit

CHOICE_GROUP

Attributes

Signature

Meaning

0..1
(redefined)

members: List<CONDITION_BRANCH>

Set of branches in this Condition Group.

6.7.5.5. CONDITION_BRANCH Class

Class

CONDITION_BRANCH

Description

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

Inherit

CHOICE_BRANCH

Attributes

Signature

Meaning

1..1

condition: 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.7.5.6. 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 'case' statement. It is processed in order, and for situations that need it, the last branch may use a value_constraint representing 'any value', to represent a catch-all 'else' branch.

Inherit

CHOICE_GROUP

Attributes

Signature

Meaning

1..1

value: CONTEXT_EXPRESSION

Reference to an Expression Language terminal that may be a function call or property reference. The Result value is compared to value_constraint sub-ranges in each of the various output branches, in the manner of a case statement.

0..1
(redefined)

members: List<DECISION_BRANCH>

Set of branches in this Decision Group.

6.7.5.7. DECISION_BRANCH Class

Class

DECISION_BRANCH

Description

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

Inherit

CHOICE_BRANCH

Attributes

Signature

Meaning

1..1

value_constraint: BOOLEAN_CONTEXT_EXPRESSION

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

Invariants

Inv_no_wait_condition: wait_spec = Void

6.7.5.8. ADHOC_GROUP Class

Class

ADHOC_GROUP

Description

Special kind of Task Group whose members are all ADHOC_BRANCH instances, each of which represents an outgoing branch. No conditions or rules are supplied in the model, and it is assumed that the user has a way of choosing based on the branches, and the decision context.

Inherit

CHOICE_GROUP

Attributes

Signature

Meaning

0..1
(redefined)

members: List<ADHOC_BRANCH>

Set of branches in this Adhoc Group.

6.7.5.9. ADHOC_BRANCH Class

Class

ADHOC_BRANCH

Description

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

Inherit

CHOICE_BRANCH

Invariants

Inv_no_wait_condition: wait_spec = Void

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

Note
at least one of the branches should have a timeout set, i.e. wait_spec.timeout /= Void to ensure the Event group does not block indefinitely. If no such timeout is set, the Plan global timeout will eventually fire.

Inherit

CHOICE_GROUP

Attributes

Signature

Meaning

0..1
(redefined)

members: List<EVENT_BRANCH>

Set of branches in this Event Group.

6.7.5.11. EVENT_BRANCH Class

Class

EVENT_BRANCH

Description

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

Inherit

CHOICE_BRANCH

Invariants

Wait_spec_not_void: wait_spec /= Void

6.8. Order Tracking

A small number of features in the model are designed to support the tracking of orders from a Work Plan. The following UML view shows the relevant classes and properties.

PROC task planning.definition order tracking
Figure 29. Order tracking

The facilities consist of the following:

  • the ORDER_REF class, representing an 'order reference';

  • WORK_PLAN.order_list is a table of Order Refs being tracked by the current Plan;

  • TASK.order_tags allows any Task to reference one or more ORDER_REF instances in the Work Plan order_list.

These features enable the creation and/or tracking of orders in an EHR system, according to various scenarios described below. Orders as described here are usually represented as openEHR Instructions and Actions committed to an openEHR EHR (within Compositions), but may in fact be any object(s) that can be referred to by a LOCATABLE_REF(which contains a URI). The following sub-sections assume openEHR Instructions and Actions for simplicity of explanation.

Two key attributes are used to connect Tasks in a Work Plan to Instructions in the EHR. The first is the ORDER_REF.order_ref attribute, which represents a reference to the Instruction in the EHR. Subsequent Actions that are committed for a given Instruction contain references to the Instruction, which can be matched to the order_ref value.

The second attribute is ORDER_REF.order_tag, used to logically identify an order tracking reference (i.e. an ORDER_REF) within a Work Plan. Any TASK that wants to refer to one or more orders records these same references in its TASK.order_tags attribute. An order tag may take any String value not containing white space characters. The recommended approach is to use strings meaningful and unique within the Plan context, such that every order is distinguished, including distinct instances. For example, the value "hypertension_medication" may be sufficient within one Plan to identify and track an order for such medication, but if the Plan potentially may track two or more such medications, more unique values will be required, e.g. "beta_blocker_medication", "ACE_inhibitor_medication" etc. Similarly, orders for different types of insulin (typical for diabetics) would need to be distinguished.

Multiple order tags may be used in a TASK for the case where a single Task causes creation of multiple orders, or a single Task waits on events (Action commits) from multiple orders.

For Plans in which repetition occurs (PLAN_ITEM.repeat_spec), order tags may be constructed using the format "xxxx@n", e.g. "doxorubicin@1", "doxorubicin_admin@2" to refer to the orders for Doxorubicin in two distinct cycles of chemtherapy mentioned in the same Work Plan.

6.8.1. Tracking an Existing Order

In this scenario, at Work Plan design time, an order already exists in the form of an Instruction committed to a patient EHR. This might be a standing order, e.g. for insulin. The Plan might be used to track patient or healthcare professional administrations of such a medication.

Since it is possible to construct a LOCATABLE_REF to the INSTRUCTION (and indeed, to a contained ACTIVITY), it may be referenced from a Work Plan using an ORDER_REF instance, via the order_ref property. The corresponding Instruction archetype identifier may also be recorded, enabling direct lookup by the TP engine, for use within the Plan modelling environment. The order_tag field will be set to a value that refers to the order in a sufficiently precise way as to be unique within the Work Plan.

This scheme allows Tasks to be defined within the Plan that have a Task Wait (PLAN_ITEM.wait_spec) that wait on an event (e.g. SYSTEM_NOTIFICATION or MANUAL_NOTIFICATION) that is generated due to a subsequent commit to the EHR of ACTIONs for the original order (e.g. drug administration events, cancellation or suspension of medication by the doctor etc).

TBD: could also use Dispatchable Task approach as per below, to wait on an existing order.

6.8.2. Creating and Tracking an Order

In this scenario, the Work Plan is the creator of the order(s) of interest. At Work Plan design time, there is no order (i.e. INSTRUCTION) in the EHR (this will only occur at Plan execution time), so ORDER_REF.order_ref cannot initially be populated. An ORDER_REF can nevertheless be created for the order at Plan design time, with the order_tag being used to refer to the order from within the Work Plan. A typical Plan structure in this case might contain the following, for each order:

  • a PERFORMABLE_TASK<DEFINED_ACTION> with associated capture_dataset, representing the entry of routine data and creation of the order, resulting in a commit to the EHR system of a Composition containing an Instruction for the order;

  • a subsequent DISPATCHABLE_TASK<SYSTEM_REQUEST> (or DISPATCHABLE_TASK<EXTERNAL_REQUEST>) that causes the appropriate API call or message to be generated and sent to the filler of the order (e.g. pharmacy, laboratory etc); this Task may include a callback wait state (DISPATCHABLE_TASK.callback) so that it blocks and waits for a result within a certain time-frame.

Both the Performable and Dispatchable Tasks use TASK.order_tags to logically refer to the same order. Any number of pairs of Performable and Dispatchable Tasks may be defined to create and react to different orders being processed within the same Work Plan.

A concrete callback event can be arranged to occur when an ACTION for the order of interest is committed to the EHR. This relies on the population of the relevant Work Plan CONTEXT_REF.order_ref attribute within the TP engine execution environment, at the moment the order is created in the EHR system. This then allows commits of ACTIONs for that order (among others, generally) to be matched with the Dispatchable Task(s) waiting on them. The callback processing for the Dispatchable Task follows the order tracking callback model described in Section 6.9.5.1 below.

The Dispatchable Task might be located in a repeating section of the Plan, if the intention is to await multiple Actions for the same Instruction.

An example of a Work Plan representing this scenario is available in the {openehr_tp_examples}#_order_coordination[Task Planning Examples^] document.

6.8.3. Class Definitions

6.8.3.1. ORDER_REF Class

Class

ORDER_REF

Description

An instance of this class represents a logical tracking reference to one 'order' in the real world. In an openEHR system, this will be represented by an INSTRUCTION committed to the EHR, normally followed by ACTIONs each representing the execution of an Activity or change of state of the order.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

order_tag: String

Tag that refers to this order within a Work Plan. May include an instance-level modifier such as '@1', '@2' etc, to distinguish repeats within a Plan.

0..1

instruction_archetype_id: String

Identifier of openEHR Instruction archetype that contains the order.

0..1

action_archetype_id: String

Identifier of openEHR Action archetype that defines the actions that may occur with respect to the Instruction activities used in this order.

0..1

order_ref: LOCATABLE_REF

EHR system order reference. When referencing an openEHR order, this will be a reference to the initial Instruction defining the order.

6.9. Events

6.9.1. Overview

Work plans interact with events in the external world, as well being driven by time. In this model, moments 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 terms of 'events'. 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 30. proc.task_planning model - Events

Two general classes of Events are distinguished:

  • deterministic: Events guaranteed to occur at a knowable point in time (shown on the lower left in light pink);

  • non-deterministic: Events that might never occur (shown on the lower right in magenta).

For non-deterministic events, a timeout handler is generally needed.

6.9.2. Event Types

The various Event types are described below, with their TP-VML representations.

Type TP-VML Description

Deterministic Events

TIMER_EVENT

event timer

Event generated by the expiry of a Timer that was launched at some earlier time; if attached to a Task wait state, the timer is launched at the moment execution reaches the Task.

TIMELINE_MOMENT

event timeline moment

Event generated by system clock reaching a fixed time-point on the Work Plan timeline, specified by an offset from the Work Plan origin (overridable) plus an optional fixed time in the day. The latter 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 P2D, 13:30:00 can thus be used to state a time like '13:30 on day 2 of the plan'.

CALENDAR_EVENT

event calendar event

Event generated by system clock reaching an event in the global Plan calendar, which is specified in absolute time, independent of the Work Plan timeline. The value of the time attribute is obtained from the calendar.

Non-deterministic Events

TASK_TRANSITION

event task transition

Event generated by the lifecycle transition of another Task, such as transition to cancelled or done.
NOTE: not needed for transition of the preceding Task to a terminal state, since in this case, execution automatically proceeds to the current Task.

STATE_TRIGGER

event state trigger

An event generated by a change in a tracked variable, or a Boolean expression based on tracked variables, e.g. a value reaching a threshold.

MANUAL_NOTIFICATION

event manual notification

An event that is manually notified to the Plan execution engine by a user.

SYSTEM_NOTIFICATION

event system notification

An event that is notified to the Plan execution engine by a system.

Non-deterministic Events (system)

CALLBACK_NOTIFICATION

event callback

A callback notification connected to a dispatch for a Dispatchable Task (Hand-off, External Request, System Request).

Instances of all of these types on their own only identify the type and source of an event - a wait state is required to catch an event. There are three types of wait state used in a TP definition: Task Wait, Timer Wait and Callback Wait. These are described below.

The following Event types require further explanation.

6.9.2.1. TIMELINE_MOMENT

The TIMELINE_MOMENT event type represents an event generated by the system when a point in time on the execution clock is reached. The time point is specified by two attributes, timeline_offset and fixed_time, with the time origin (default: Work Plan activation) being optionally specified by timeline_origin. At least one of the first two attributes must be set.

If fixed_time is set using an instance of CLOCK_TIME, it refers to the first moment at which the time occurs during the day, after any offset has elapsed. The following diagram shows how this works for two instances of TIMELINE_MOMENT, both having a fixed_time of 07:30 and a timeline_offset of P1d (one day), when the timeline origin is different (i.e. the Work Plan was started at different times).

timeline moment semantics
Figure 31. TIMELINE_MOMENT semantics

The fixed_time attribute may also be set using an instance of CUSTOMARY_TIME, to allow the time to be specified using coded terms like morning, afternoon, evening and so on. Such terms are assumed to define time ranges such as 07:00:00 - 11:30:00 etc, which are typically culturally specific, and/or specific to hospital or other institutional norms. Consequently, such terms have to be resolved to computable intervals by some means (e.g. a locale service API call), left up to the TP execution system. Where such an interval is used to define a time, the event is generated at the earliest time of the interval (e.g. 07:00:00 for 'morning')

If fixed_time is not set, it refers to the first moment in time directly after the offset, if any, has elapsed (i.e. a Void fixed_time is intepreted as "don’t care"). If timeline_offset is not set, fixed_time is resolved to the first occurrence of the specified time directly from the time origin.

A TIMELINE_MOMENT with neithre of timeline_offset or fixed_time set is not considered meaningful, since it is equivalent to no TIMELINE_MOMENT event at all.

The timeline origin defaults to the moment of Work Plan activiation, but may be overridden via the timeline_origin attribute to be the moment of activation of the current Task Plan, or the entry into a repeating section (a Task Group or Task with repeat_spec set).

6.9.3. General Facilities

6.9.3.1. Event Wait State

The class EVENT_WAIT<T> defines a generic model of a general-purpose event wait state that may be specialised for particular purposes. Its attributes are as follows:

  • success_action of type EVENT_ACTION, which defines possible actions to occur on receipt of an event;

  • timeout of type TIMER_WAIT, whose success_action defines possible actions when no event is received.

The EVENT_ACTION type defines a number of things the system can do on a triggering event:

  • make a system call, 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 indicate a specific lifecycle state for the Plan Item (a Task or Task Group) receiving the event, specified by receiver_thread_next_state;

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

6.9.3.2. Timers

A generic timer can be specified using TIMER_WAIT, a specialisation of EVENT_WAIT<TIMER_EVENT> based on the Event type TIMER_EVENT. This provides a way to specify a Timer (the TIMER_EVENT) and listen for it (the TIMER_WAIT). A TIMER_WAIT creates a separate Event wait state that listens for a Timer event launched some duration after Task activation, and may result in specific actions, specified via the inherited EVENT_WAIT.success_action attribute.

The timer represented by a TIMER_EVENT is started when the wait state to which it is attached is reached in the execution.

6.9.3.3. Reminder

A reminder can be specified using REMINDER, a specialisation of EVENT_WAIT<PLAN_EVENT>. Conceptually, a reminder is a wait state that is activated if a secondary event (represented by the event attribute inherited from EVENT_WAIT<T>) occurs in the absence of waited-on primary event(s), i.e. expected lifecycle transitions of the owning Task. Usually the secondary event is a TIMER_EVENT, but it could be anything else. If any of the primary events occurs, the reminder is cancelled.

6.9.4. Task Wait State

The principal way to wait for events is via the TASK_WAIT attachable to any PLAN_ITEM via the wait_spec attribute. The TASK_WAIT class represents a wait state that defines when a Task should enter the available state from the planned state in terms of descendant types of PLAN_EVENT (i.e. all Events described above other than CALLBACK_NOTIFICATION). Its events attribute enables multiple Events to be used as triggers, with an assumed logical OR relation among them. This enables the specification of triggers such as 'at 8pm on day 1, OR when oxygen saturation drops below 90% (whichever comes first)'. The optional event_relation attribute allows the Task to be specified as commencing before, with or after the trigger event (such as a meal).

The following figure illustrates typical uses of TASK_WAIT.

task wait state
Figure 32. Task wait state
6.9.4.1. Time-outs

A timeout can be set on a Task Wait state by setting TASK_WAIT.timeout with a TIMER_WAIT instance, which is activated when the Task Wait state is reached in the execution. This is useful in cases where Event receipt is not certain. The TIMER_WAIT generates a timer event if no other event is received; conversely, receipt of any other event cancels the timeout timer. The TIMER_EVENT attached to TIMER_WAIT.event indicates the duration of the timer. The success_action of the TIMER_WAIT indicates actions to execute if the timer fires. The following Plan fragment illustrates.

uc task timing 1
Figure 33. Timing patterns
6.9.4.2. Reminder

When an event specified in TASK_WAIT.events fires, it puts the Task into the available lifecycle state. In typical real world situations, the performer may not realise, or may be busy on something else. To enable the performer to be reminded, the PLAN_ITEM.reminders attribute may be used to specify one or more REMINDER wait states. Each of these will have a TIMER_EVENT (or other event) as its firing event.

TBD: what about transition to underway?

If a Reminder is activated, it will generate a notification, specified via the inherited success_action attribute. If still no activity occurs for some time, additional reminders may fire (due to Timer events with longer times), and generate new notifications. As soon as the performer progresses the Task to a new state, any reminder for which such a transition is cancelling, will be cancelled. An example is illustrated below.

task wait state reminder
Figure 34. Task wait state with reminder
6.9.4.3. Lifecycle Transition Override

In some cases, it may be necessary to progress a Task to a state other than available. This may be achieved by specifying TASK_WAIT.next_state.

6.9.5. Callbacks

A callback is the mechanism to state what happens when control returns to a Dispatchable Task (such as a Hand-off or External Request) from its target. It is defined in the model by CALLBACK_WAIT, a specialisation of EVENT_WAIT<CALLBACK_NOTIFICATION>, which represents a wait state to receive notifications of Dispatch completion, as well as timeout if no response is received. The callback event is formally represented by the CALLBACK_NOTIFICATION class. These classes are shown in the following view of the UML model.

PROC task planning.definition callback wait
Figure 35. Callback Wait

In order to define the processing on receipt of a callback event, CALLBACK_WAIT adds two attributes to EVENT_WAIT<T>:

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

  • custom_actions: enables a custom set of EVENT_ACTIONs to be specified, in the form of a Hash table, with a specific Event Action for each key; the keys are assumed to represent specific return statuses of the remote Task.

A Callback Wait thus has three standard Event responders: success_action, fail_action and timeout, and additionally any number of custom responders definable via custom_actions, described below.

Task lifecycle state processing for a Dispatchable Task occurs both at the point of dispatch and return and/or timeout. The general model is as follows:

  • the Task starts in the planned state, as for any Task in a Plan;

  • when the execution point reaches the Task, and any Task Wait state has been exited, the Task becomes available (refer above to Section 6.2.3.2);

  • the Task dispatch operation is performed either automatically, or in the case of an External Request, manually;

  • if DISPATCHABLE_TASK.wait is False:

    • the Task transitions to the completed state.

  • if DISPATCHABLE_TASK.wait is True:

    • the Task enters the underway state until a callback (or timeout) occurs, at which point the next state will depend on the details of the callback (see below);

6.9.5.1. Callback Processing for Blocking Tasks

For a DISPATCHABLE_TASK that blocks and waits in the underway state, there are three callback processing models:

  • standard: generic success | fail | timeout model;

  • order tracking: used if DISPATCHABLE_TASK.order_tags is set;

  • custom: used if DISPATCHABLE_TASK.callback.custom_actions is set.

Each model corresponds to a different set of possible callback statuses returned by the TP engine with the callback notification to represent the state of the remote Task execution. In the standard model it is a generic success | fail | timeout approach. Under the order tracking model (Section 6.8, above), the return statuses are states from the openEHR Instruction State Machine. Under the custom model, they are specific to the context.

Under each model, the next lifecycle state of the Dispatchable Task is determined by the callback status in a specific way. For each possible status under each model, a specific callback handler may be set, defined in terms of the CALLBACK properties success_action, fail_action, timeout.success_action. Any of these (see class EVENT_ACTION) if set may override the default next state, and also may generate a system call and/or a message for the performer.

TBD: It would be reasonable to design an implementation with a default message of the form "Task $task_name[id=$task_id] completed with $state", and a global flag default_messages_on to obviate the need to always set basic messages in EVENT_ACTION.

In special cases, it may also cause execution to resume in another place (see Section 7.2.4).

A common approach to timeout processing applies to all models. If no callback occurs, and CALLBACK.timeout.success_action is set, its timer will be used to generate the timeout, and also to determine the next state, message etc. If it is not set, the Work Plan global timeout will be triggered to unblock the Task and transition it to the abandoned state.

TBD: need to define Plan level timeout.

The following table describes the details of callback processing under the various models.

Callback
model
Callback
statuses
Dispatchable Task
settings
Response processing Notes

Standard

success
| fail
| timeout

no callback handlers

  • successcompleted

  • failabandoned

  • timeoutabandoned

callback handlers (success_action, fail_action, timeout.success_action)

As specified in EVENT_ACTION.
receiver_thread_next_state,
or else as above.

Use to e.g. convert fail to cancelled.

Order
tracking

Action ISM state
| timeout

no callback handlers
(except optionally timeout.success_action)

  • plannedunderway

  • cancelledcancelled

  • postponedsuspended

  • scheduledunderway

  • activeunderway

  • suspendedsuspended

  • completedcompleted

  • timeoutabandoned

May catch multiple callbacks via use of underway target state.

Only target states reachable from underway can be used.

callback handlers (custom_actions, timeout.success_action)

As specified in custom_actions[n].
receiver_thread_next_state
,
or else as above

Custom

Custom statuses
| timeout

callback handlers (custom_actions, timeout.success_action)

  • xxxunderway

  • yyycancelled

  • zzzsuspended

  • etc

  • timeoutabandoned

May catch multiple callbacks via use of underway target state.

Only target states reachable from underway can be used.

The following diagram shows the TP-VML definition for a dispatchable Task with a standard callback.

uc task callback 1
Figure 36. Standard callback example

The following TP-VML definition illustrates a custom callback.

uc task callback 2
Figure 37. Custom callback example
6.9.5.2. Callback Processing for Non-blocking Tasks

In the case of a context fork, the source Task has performed its work as soon as the dispatch has occurred, and its state is set to completed. The next Task(s) become available in the normal way, and processing continues. At some later point in time, a callback notification may be received from the remote Task, or else a timeout. These will be processed similarly to the above, with the exception that the next state processing, if explicit next states are set, is with respect to the Task Group enclosing the current point of execution, which may be the top-level Group of the Task Plan. This allows the possibility of the callback processing to cause the local execution pathway to stop with abandonment or cancellation. The default next-state processing is 'no change', i.e. the current execution path doesn’t care what happens to the remote thread. However, if EVENT_ACTION.receiver_thread_next_state is set from the return status of the remote Task, the execution of the Task Group containing the source Task may be ended (cancel) or the whole Plan abandoned (abandon). Such a transition might even be set on success, which provides a way to model 'first one wins' logic.

The following illustrates a non-blocking callback in TP-VML.

dispatchable no wait callback
Figure 38. Non-blocking callback example
6.9.5.3. Callback with Custom Resume Behaviour

The attribute EVENT_ACTION.resume_action of type RESUME_ACTION, and its attribute resume_location enable custom post-callback behaviour to be stated. The default is to process the EVENT_ACTION (e.g. post a message, make a system call etc), and then to complete the current Task and progress to the next in the normal way. A custom resume action alows a different resumption location to be specified, as defined by the enumeration RESUME_TYPE. This kind of resumption is described below in the section on Section 7.2.4.

6.9.5.4. Manually-notified Pseudo-callback

A callback at execution time is achieved via notification within the TP system. However, in some cases, the effect of a callback is required where the means of notification is the subject (i.e. the patient, in a clinical system) being sent to another department or room, and the current performer’s execution blocking for that subject until he/she returns. This effect can be achieved by the task pattern shown below, consisting of a Hand-off followed by a normal Task that waits on a Manual notification event. This pattern is not a true callback.

manual callback
Figure 39. Pattern to achieve effect of 'manual callback'

6.9.6. Class Definitions

6.9.6.1. TASK_WAIT Class

Class

TASK_WAIT

Description

Object representing time of a Task to be performed in terms of a related event. The start_window is used to add an 'acceptable delay' time within which the Task should be started 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 = MANUAL_NOTIFICATION, CALLBACK_NOTIFICATION or 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'.

Attributes

Signature

Meaning

0..1

events: List<PLAN_EVENT>

One or more events that define the intended point in time. If there are more than one, the implied logical relation is OR, i.e. any event occurring causes the wait state to complete.

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

timeout: TIMER_WAIT

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

0..1

next_state: TASK_LIFECYCLE

Override for next state to enter on receipt of any Event in events. Default processing is to enter the available state.

6.9.6.2. EVENT_WAIT Class

Class

EVENT_WAIT<P>

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

Invariants

Inv_no_timeout: timeout = Void

Inv_has_action: success_action /= Void

6.9.6.4. REMINDER Class

Class

REMINDER

Description

Specialised Event wait state activated when its event fires. This is often a TIMER_EVENT, but may be any other kind of event. Will be cancelled when/if its owning Task enters a terminal state (i.e. completes or is cancelled or the Plan abandoned).

If the reminder is activated, its success_action should be configured to generate a reminder or alert to performer or other user.

Inherit

EVENT_WAIT

Attributes

Signature

Meaning

1..1
(redefined)

event: PLAN_EVENT

The event that will generate the reminder. This could be a timer, or it may be a timeline moment, calendar time, or a non-deterministic event, e.g. state trigger.

Invariants

Inv_no_timeout: timeout = Void

Inv_has_action: success_action /= Void

6.9.6.5. CALLBACK_WAIT Class

Class

CALLBACK_WAIT

Description

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

Default processing if EVENT_ACTION.receiver_thread_next_state is not set:

  • on success_action: the owning Task lifecycle_state is progressed to the completed state.

  • on fail_action: the owning Task lifecycle_state is progressed to the abandoned state.

EVENT_ACTION.receiver_thread_next_state must be set on all

Inherit

EVENT_WAIT

Attributes

Signature

Meaning

0..1

fail_action: EVENT_ACTION

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

0..1

custom_actions: Hash<String,EVENT_ACTION>

A keyed list of specific actions to perform based on custom key values, which are understood as types of remote event more specific than just 'success' or 'fail'.

1..1
(redefined)

event: CALLBACK_NOTIFICATION

Callback notification on which this Callback wait state is based.

6.9.6.6. EVENT_ACTION Class

Class

EVENT_ACTION

Description

Action(s) to perform on receipt of an event with a particular status. Four possible things can be specified:

  • a message;

  • a system call;

  • the next state of the Task or other resume location (receiver_thread_next_state);

  • a specific resume action indicating to resume in a specific location in the Plan.

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

0..1

receiver_thread_next_state: TASK_LIFECYCLE

Next state of the receiver thread of control. In the blocking case, this is the original Task of this callback notification; in the non-blocking (context fork) case, it will be the enclosing Task Group of the original dispatching Task.

If not set, default processing will be performed, which for a Task is to enter the available state.

Invariants

Inv_custom_actions_next_state: custom_actions.for_all ((ev:EVENT_ACTION) {ev.receiver_thread_next_state /= Void})

6.9.6.7. 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.9.6.8. EVENT Class

Class

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

6.9.6.9. PLAN_EVENT Class

Class

PLAN_EVENT (abstract)

Description

Any kind of Event defined as part of a Plan definition.

Inherit

EVENT

Attributes

Signature

Meaning

0..1

delay: Iso8601_duration

Optional delay to event generation.

0..1

other_details: ITEM_STRUCTURE

Archetype-configurable extra meta-data for any event.

6.9.6.10. TIMER_EVENT Class

Class

TIMER_EVENT

Description

Timer expiry event generated by Task Plan engine, after the duration period has elapsed from the moment of execution reaching the Task to which this Event is attached.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

1..1

duration: Iso8601_duration

Delay from activation time to receive the event notification.

0..1

purpose: String

Optional explanatory purpose of Timer.

6.9.6.11. 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: Iso8601_date_time

Time of entry in calendar.

6.9.6.12. TIMELINE_MOMENT Class

Class

TIMELINE_MOMENT

Description

Specifies a time event generated during execution when the Plan clock reaches a specific point defined in the global Plan Timeline. The time of this timeline moment is calculated as the fixed_time in the day, e.g. 14:30:00, no matter when the Plan is activated.

The timeline_offset attribute can be used to specify a particular offset with respect to a time origin, by default, the origin of the Work Plan. The fixed_time then corresponds to the first occurrence of that time on the clock after the timeline_offset is passed.

This can be used to specify particular times on particular days, e.g.: 07:30:00 on day 3, 14:00:00 on day 5 and so on by setting timeline_offset to numbers of days, e.g. P3D, P5D etc. Note that a value of P1D means the first 24h period after Plan activation, whereas if timeline_offset is not set, the fixed_time is understood to specify the first moment after Plan activation that this time is reached on the Plan clock.

The timeline_origin can be set to specify another time origin, such as the start of execution of the Task Plan, or of a repeat section.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

0..1

timeline_offset: Iso8601_duration

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 specifier, used to expressed a fixed moment in the day.

0..1

timeline_origin: PLAN_TIME_ORIGIN

Relative origin for timeline_offset. If not set, Work Plan activation is assumed as the time origin.

Invariants

Inv_validity: timeline_offset /= Void or fixed_time /= Void

6.9.6.13. TASK_TRANSITION Class

Class

TASK_TRANSITION

Description

Event type for Task transitions, specified in terms of target state reached by the associated Task.

Inherit

PLAN_EVENT

Attributes

Signature

Meaning

1..1

task_id: UID_BASED_ID

Identifier of Task with which this event is associated.

1..1

transitions: List<TASK_LIFECYCLE>

One or more Task lifecycle transition(s) that defines this event; if more than one, the logical relation is 'OR'.

6.9.6.14. 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.9.6.15. 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.9.6.16. 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.9.6.17. CALLBACK_NOTIFICATION Class

Class

CALLBACK_NOTIFICATION

Description

System-generated Event created on receipt of notification of completion of the work of the target of a Dispatchable Task.

Inherit

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.

0..1

subject_id: String

Identifier of subject to which callback relates.

6.10. Cost Tracking

TBD: describe cost tracking.

6.10.1. Class Definitions

6.10.1.1. TASK_COSTING Class

Class

TASK_COSTING

Description

Costing information for a Task.

TODO: to be developed.

7. Global Semantics

This section describes the global semantics of the model in execution, taking into account all elements described above.

7.1. Control Flow

7.1.1. Graph Structure

The execution graph structure of a Work Plan consists of its top-level Task Plan(s) (WORK_PLAN.top_level_plans) and subordinate Task Plans linked from Hand-offs and sub-plans (i.e. DISPATCHABLE_TASK<HAND_OFF> and DISPATCHABLE_TASK<SUB_PLAN>) Task types. Top-level Task Plans are those that do not have prior executable Tasks, and are thus active at activation time. The following illustrates a typical structure.

wp tp hierarchy
Figure 40. Work Plan control path graph structure

7.1.2. General Scheme

When a materialised Work Plan is activated (see below), its top-level Task Plans are active, meaning that their initial Task(s) are in the available lifecycle state, as described above.

In a Task Plan, the execution path follows the chain of Tasks defined in the definition of the Plan, which is a TASK_GROUP. It descends into and exits any other TASK_GROUPs encountered within the Plan as Tasks are executed and completed or cancelled by their workers. A Task becomes available based on a combination of completion (or skipping) of previous Tasks and other conditions, according to the Task lifecycle logic described above.

The currently available Task in a Task Plan corresponds to the current execution point of the Plan. For parallel execution Task Groups, more than one Task can be available simultaneously, meaning there is more than one thread of execution. As Tasks complete, and timing and other events occur, making new Tasks available, each thread of execution advances through the Task Plan graph.

On the way, the execution path is modified by conditional nodes and also by Dispatchable Tasks, as follows.

7.1.3. Conditional Nodes

The various kinds of conditional nodes represent different ways of controlling execution of a Task Plan.

A CONDITION_GROUP / CONDITION_BRANCH structure is processed in the same way as an if-then/elseif-then/else statement in a programming language, i.e. in-order processing, with the first matching path followed. In the temporal Plan execution environment, the processing proceeds instantaneously, i.e. there is no wait state involved.

A DECISION_GROUP / DECISION_BRANCH structure is processed like a case (aka switch) statement in a programming language, i.e. evaluate the DECISION_GROUP.test, find the first branch whose value_constraint (a value range) contains the value, and follow it. This is also instantaneously processed.

The other two types of Choice Group are blocking.

An ADHOC_GROUP / ADHOC_BRANCH structure is processed using an implicit wait state, since it requires user input. It will thus block until input is supplied. The inherited CHOICE_GROUP.timeout attribute can be used to defined actions if no user input supplied. When this is not defined, a global timeout is triggered, breaking the wait state.

Finally the EVENT_GROUP / EVENT_BRANCH structure is blocking due to TASK_WAIT states set on each branch. It is processed by waiting for one of the events on the branches to occur, or else for the timeout on the group to fire. As for the Ad hoc case, a timeout may be set in order to force processing if none of the specified events occurs, and if not set, a global timeout will break the wait state if nothing else happens.

7.2. Task Dispatching

7.2.1. Hand-offs

TBD:

7.2.2. External Requests

TBD:

7.2.3. System Requests

TBD:

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

7.3. Aggregate Lifecycle State

During a Work Plan execution, the lifecycle state described above on each Task is recursively aggregated up to owning Task Groups (including Choice Groups, described below in Section 6.7), to the top Task Group (i.e. TASK_PLAN.definition). Consequently, the aggregate lifecycle state of a Task Plan as a whole is just the lifecycle state of its definition.

7.3.1. Sequential Groups

The following algorithm is used to compute the runtime lifecycle state of a Task Group for which execution_type is sequential from the set of states of its members.

//
// Aggregate lifecycle state algorithm.
// Infer the state of a collection whose members' states are in source_states.
// The order of if/else evaluation determines the correct result.
//
Task_lifecycle aggregate_state (Set<Task_lifecycle> source_states) {

    if (source_states.contains(Abandoned))
        return Abandoned;
    else if (source_states.contains(Available))
        return Available;
    else if (source_states.contains(Planned))
        return Planned;
    else if (source_states.contains(Suspended))
        return Suspended;
    else if (source_states.contains(Underway))
        return Underway;
    else if (source_states.contains(Completed))
        return Completed;
    else if (source_states.contains(Cancelled))
        return Cancelled;
    else
        return Initial;
}

Consequences of the above algorithm include:

  • a Task Group at runtime is in a terminal state only if all recursively contained Tasks and/or other Task Groups are in terminal states;

  • completing a Task Group will ripple back up the Task Group hierarchy to a point where the completing Group is not the last remaining uncompleted Task or Group in the parent;

  • if the abandoned state is entered for a Task, the effect is to cause the current run of the enclosing Task Plan to be abandoned.

7.3.2. Parallel Groups

If TASK_GROUP.execution_type is parallel, then the value of concurrency_mode will also affect computation of Task Group lifecycle state, since in some modes, some Tasks will be ignored. The following table indicates the computation for Task Group state at any time during and after execution of its branches. Note that all decision structures, i.e. CHOICE_GROUPs, are equivalent to xor_one_path Task Groups, and are thus solved by the second entry in the table below.

Concurrency mode TP-VML Lifecycle state rule

and_all_paths

task group parallel and

Apply the algorithm to each branch; re-apply the algorithm using all branch results as the input set.

xor_one_path

task group parallel xor

Apply the algorithm to the chosen branch.

or_all_started

task group parallel or all

Apply the algorithm to each commenced branch; re-apply the algorithm using these branch results as the input set.

or_first_completed

task group parallel or first

Apply the algorithm to each commenced branch; apply the OR-join algorithm below to this set.

//
// OR-join algorithm: apply to Aggregate lifcycle algorithm results
// obtained from all commenced branches.
//
Task_lifecycle or_join_state (Set<Task_lifecycle> branch_states) {

    if (branch_states.contains(Abandoned))
        return Abandoned;
    else if (branch_states.contains(Completed))
        return Completed;
    else if (branch_states.contains(Underway))
        return Underway;
    else if (branch_states.contains(Suspended))
        return Suspended;
    else if (branch_states.contains(Available))
        return Available;
    else if (branch_states.contains(Planned))
        return Planned;
    else if (branch_states.contains(Cancelled))
        return Cancelled;
    else
        return Initial;
}

The logic of the OR-join algorithm is to treat any finishing branch (abandoned or completed) as finishing the group, and otherwise to report the progress of the most advanced branch (i.e. underway, then suspended etc) as the progress of the Group.

If the Task Group has more complex execution rules (TASK_GROUP.execution_rules), then its lifecycle state will also be affected according to these rules.

7.3.3. Work Plan

The lifecycle state of a Work Plan is determined from the states of its top-level Task Plans in the same way as for a parallel AND Task Group, i.e. by re-applying the algorithm to all the Task Plans.

8. Execution

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

8.1. Phases of Processing

As described in the earlier section Section 4.6, 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 made available for use, 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 should be at least a working shift (e.g. 8-12 hours), but might be longer, e.g. the number of days used in the organisation for lookahead planning. The parts 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 should be 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 putting the Work Plan’s top-level Task Plans into an initial wait state, waiting on allocation of principal performer, and availability of the Task Plan subject (patient, related person, image, tissue sample etc).

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

  • Tasks within the runtime window 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 of each Task;

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

8.2.1. Worker Allocation

Before a materialised Work Plan can be executed, at least the principal_performer must be allocated for Task Plans containing Tasks within the current runtime window (see above). Some actors designated PERFORMABLE_ACTION.other_participations of affected Tasks may need to be allocated as well. Not all performers are needed at any time, only those implicated in the part of the Plan to be executed, e.g. for the current day within a multi-day Plan.

The allocation process consists of:

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

  • receipt by the TP engine of 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 accepting the request. This operation is likely to be done nearly invisibly to the user, who may simply open an application window or click on a notification.

The principal performer is considered to have been allocated when the work is claimed by the worker, and a live communication channel has been established between the TP engine and the worker.

8.2.2. Worker De-allocation

At various moments during the execution of a Plan, a worker may leave e.g. due to worker shift changeover, being called away, or just finishing for the day. When a worker disconnects from the communication channel, either actively (e.g. by closing an application) or by an inactivity time-out, the TP engine registers a de-allocation of the worker. For the remaining Task(s) in the Plan to be performed, the necessary worker allocations have to be repeated by the TP engine.

8.2.3. Resource Allocation

TBD

8.3. 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 41. 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: Iso8601_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

1..1

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_PERFORMER_ALLOCATION Class

Class

M_PERFORMER_ALLOCATION

Description

Tracking information for a current performer allocation.

Attributes

Signature

Meaning

1..1

performer: PARTY_IDENTIFIED

Identity of allocated performer.

1..1

connection: String

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

1..1

other_details: Hash<String, String>

Archetypable details.

9.2.4. M_PLAN_ITEM Class

Class

M_PLAN_ITEM (abstract)

Description

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

Attributes

Signature

Meaning

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

1..1

lifecycle_state (): TASK_LIFECYCLE

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

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

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

Class

M_TASK_ACTION

Description

Materialised form of TASK_ACTION type.

Attributes

Signature

Meaning

1..1

definition: TASK_ACTION

9.2.8. M_DISPATCHABLE_ACTION Class

Class

M_DISPATCHABLE_ACTION

Description

Materialised form of DISPATCHABLE_ACTION.

Inherit

M_TASK_ACTION

9.2.9. M_PERFORMABLE_ACTION Class

Class

M_PERFORMABLE_ACTION

Description

Materialised form of PERFORMABLE_ACTION.

Inherit

M_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 42. 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: Iso8601_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 43. 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

0..1

plans (): List<UID_BASED_ID>

List of Task Plan ids for this Work Plan.

0..1

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

0..1

materialise

0..1

activate

0..1

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

0..1

plans (): List<UID_BASED_ID>

List of Task Plan ids for this Work Plan.

0..1

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

0..1

materialise

0..1

activate

0..1

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

Hofstede, A. H. M. T., Aalst, W. M. P. van der, Adams, M., & Russell, N. (2010). Modern Business Process Automation: YAWL and its Support Environment. Springer-Verlag.