Relationship with other openEHR EHR Artefacts

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.

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