openEHR logo

Task Planning Examples

Issuer: openEHR Specification Program

Release: PROC latest

Status: TRIAL

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: task, planning, examples, workflow

openEHR components
© 2017 - 2019 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.0.0

0.1.0

Initial writing.

T Beale,
B Næss

25 Apr 2019

Acknowledgements

Editors

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

  • Bjørn Næss, DIPS, Norway

Support

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

  • DIPS, Norway

  • Marand d.o.o., Slovenia

Trademarks

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

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

1. Preface

1.1. Purpose

This document contains elaborated examples of the openEHR Task Planning (TP) Model, with diagrams in TP-VML.

The intended audience includes:

  • Task Plan and workflow authors;

  • Tool vendors.

Prerequisite documents for reading this document 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/tp_examples.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 technical mailing list.

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.

2. Overview

2.1. Draw.io Tool mode

The following files can be downloaded and then imported into draw.io as libraries to provide a working palette for TP-VML diagrams.

3. Teamwork

The examples in this section illustrate the use of TP for team-based work plans, including hand-offs, callbacks and other kinds of coordination.

3.1. Out-patient Eye Clinic Encounter

This example is based on the original description of DIPS Eye encounter example.

outpatient eye clinic
Figure 1. Outpatient eye clinic encounter

3.1.1. Plan Overview

As for all Plans defined in the Task Planning formalism, it must be remembered that the Plan definition above is what the TP engine executes. It is the result of the execution (including worker allocation and communication, which is not shown in the definition) that causes workers in the real world to do things. Additionally, what the TP engine knows about the real world is limited to what it is told - many actions and events can occur outside the TP computing environment that will remain unknown to the system unless it is informed (e.g. by Manual notification).

The Work Plan consists of two top-level Task Plans, one for the patient and one for the clinic administrator / reception. The latter has two sub-plans linked by hand-off Tasks.

The purpose of the patient top-level Task Plan is to allow the system to notify the patient of the visit, via a reminder on the day of the visit, or some fixed time beforehand. The driving event is the calendar appointment, which is waited on by both the patient and the clinic admin Task Plans. It is assumed that longer term reminders, opportunities for changing appointments and so on are managed by another system that see the same calendar events, and is responsible for setting the calendar events in the first place. Thus, in the model above, the patient top-level plan is not really necessary (he/she will be notified by the appointment system), and is mainly included for purposes of demonstration.

3.1.2. Detailed Description

The main work of the Work Plan is in the other three Task Plans, which essentially encode the following logic:

Clinic Administrator:

  • clinic has a live Task Plan waiting on appointment A for patient P, at 2019-02-15 09:30:00;

  • when this calendar timepoint is reached, the TP system 'opens' the appointment via a System Request to the clinic appointment system (details not shown);

  • WAIT: the clinic Task Plan enters a new wait state for patient P, for appointment A;

Patient:

  • patient arrives at clinic (modelled as a Manual notification);

Clinic Administrator:

  • receive patient, record presence;

  • Hand-off: pass to consultation (e.g. send to waiting area);

  • WAIT: until manual notification (patient returns)

Nurse:

  • receive patient & check EMR

  • review eye function, decide on whether to send to doc or not:

    • EITHER: return to reception

    • OR: pass to doctor

Specialist:

  • receive patient and check EMR

  • perform examination

  • update EMR

  • send patient back to reception.

4. Order Management

The examples in this section illustrate the use of TP for order management, where openEHR Instructions and Actions (or other non-openEHR equivalents) are created and tracked.

4.1. Order Coordination

This example is based on a standard Moscow City clinic protocol, and covers a 12 month period.

order coordination
Figure 2. GP order coordination

4.1.1. Plan Overview

The Work Plan shown above defines the tasks for a 'standard health check' that includes a chest x-ray, a full blood panel and a hypertension checkup. The Plan executes over the periof a year, and consists of a health coordinator creating orders for the three items, via UI forms. The result of creating these orders will be the creation of a normal Composition and Instruction in the openEHR EHR for the patient. At some later point in time, the coordinator will action these orders, which will cause the EHR data to be used to create appropriate API calls / messages to the relevant target systems (radiology clinic, pathology lab, consultant) that will further cause appointments and attendances in the normal way by the patient. Each of these 'execute order' Tasks will block and wait for appropriate callbacks resulting from each of the orders being fulfilled and corresponding Actions being committed to the EHR (or else timeouts, if nothing happens). With the received results, the coordinator creates a health summary for the patient and commits that to the EHR.

4.1.2. Detailed Description

TBD