Task Planning Examples
| Issuer: openEHR Specification Program | |
|---|---|
Release: PROC Release-1.5.0 |
Status: TRIAL |
Revision: [latest_issue] |
Date: [latest_issue_date] |
Keywords: task, planning, examples, workflow |
|
| © 2017 - 2020 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 |
|
Support |
Issues: Problem Reports |
Acknowledgements
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.
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
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.
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.
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.