openEHR RM times and tracking clinical process

Date/Times

There is a rich context model in openEHR (see specifications). Timing is part of this and is summarised below with some sample use cases. Other times must be explicitly archetyped.

RM Class	Attribute	Description	Lab request/referral	Lab result/report	Encounter	Consultant report
CONTRIBUTION	time	Time composition(s) were added to this system. Equals COMPOSITION commit time with locally authored compositions	Request received locally	Report received locally	Record received locally	Report received locally
COMPOSITION	Commit time (mandatory)	Time composition is saved in original system	Request sent	Report issued	Note recorded	Report issued
(Event related compositions)	EVENT CONTEXT.Start time (mandatory)	The time (or start time) of the event or process	Request created/recorded	Report created/recorded	Patient encounter begins	Report created/recorded (may relate to patient encounter if done at time of seeing patient)
	EVENT CONTEXT.End time (optional)	End time of the event or process	Not usually recorded	Not usually recorded	End time of the encounter	Not usually recorded unless at the same time as an encounter
PARTICIPATION	Start time/End time	The time that a person took a role that has been recorded	Duration of other participants' functions	Duration of other participants' functions	Duration of other participants' functions	Duration of other participants' functions
ATTESTATION	Time	The time this COMPOSITION or part thereof was signed	Time of signing the request/referral or any part thereof	Time of clinician or technician signing the report or any part thereof	Time of signing the encounter note or any part thereof	Time of signing the encounter note or any part thereof
OBSERVATION	EVENT.Start time	The clinically relevant time of the observation	N/A	Time the sample was collected	Time of the observation	Time of the observation
ACTION	Time	The time this action was completed	Time of the action * Order effective date/time (on the order set) * Quantity/timing start date/time (same as Date/time requested on the order item) * Specimen received date/time	Time of the action * Order effective date/time (on the order set) * Result report/status change date/time (on the order item - the date/time the order item status changed, or it could also be 'Report created/recorded' - the date/time the results are composed into a report and released) * Quantity/timing start date/time (same as Date/time requested on the order item) * Date/time of observation (same as observation EVENT.Start time) * Specimen received date/time	Time of this action	Time of this action
INSTRUCTION	expiry time		Time this request/referral expires	Time this request/referral expires (as per *original Instruction* if Instruction is also required in the report (otherwise refer to the Instruction in the referral/request Composition). If the Instruction has been changed by the filler, then the *changed Instruction* may be included in the report, and its expiry time will be used).

Tracking clinical process via identifiers

There is a requirement to be able to trace different types of informational entities back to a particular instance of a clinical process. The process may be executed in the real world or within a messaging environment, or within a workflow management system. This is to assist in identifying and providing the right information at the right time, and to track the progress of a particular clinical workflow.

The workflow ID attribute in the ENTRY class is currently defined in the openEHR specification in the context of a workflow engine. However, it is becoming apparent that the definition and use of this attribute needs to be extended to uniquely identify (albeit within a given environment) the clinical process instance in general - i.e., irrespective of what systems are in place to assist the execution of the workflow (e.g., messaging, workflow engine).

This means that the workflow ID (of OBJECT_REF type) can use different identifiers depending on the context/implementation. The OBJECT_REF type can allow for this. This is usually a system generated identifier - e.g., openEHR system such as OceanEHR assigning identifier to an Instruction, or an instance ID assigned by an external workflow engine, or the placer ID in a messaging environment. Once assigned, other informational entities such as ACTIONs, OBSERVATIONs, EVALUATIONs and ADMIN_ENTRIES that are recorded as part of a process instance will share the same workflow ID and may relate back to an INSTRUCTION with the same workflow ID that defines the process. Actions, Observations, Evaluations and Admin_Entries may have a workflow ID, but may not necessarily be associated with any Instruction, if the process is defined elsewhere or the definition is not known in the EHR.

The table below shows an example of the types of identifiers that may be used to populate the workflow ID in the ENTRY depending on the environment/context. From a single EHR system environment, it is useful to know what's related to what, and the status of a running process given a workflow ID. In a distributed environment, the workflow ID will be different for each EHR system, but this is where 'external workflow IDs' (i.e. workflow ID from a different EHR system) will need to be explicitly archetyped (e.g., in protocol, otherwise within the data structure for an ADMIN_ENTRY) to be able to relay the information back to the original Instruction.

If the workflow/process is modified or a new version of the process is created, then the Instruction Index by default will need to update all references to the latest workflow/process (any synchronisation conflicts will be revealed through inspection of the system audit trail and relevant time stamps).

One of the benefits of a workflow ID being a logical and externally assigned identifier for a process instance is that you can record something that's part of a "process" without necessarily having an Instruction that has the definition. Further, while LINKs can be used to associate Observations, Evaluations and so on to an Instruction, this approach relies on the use of URIs which are difficult to maintain when new version of the Composition that contain the entries are created. The use of a workflow ID described here provides a simpler solution.

RM Class	Attribute	Description	Lab request/referral & results/report	Medication Order	Encounter
ENTRY	workflow ID	Unique logical identifier for the running process instance, which may be executed in the real world or within a messaging environment, or within a workflow management system. This is usually a system generated identifier (e.g. openEHR system such as OceanEHR assigning the identifier within a 'Workflow Object' to an Instruction, or an instance ID assigned by an external workflow engine, or the placer ID in a messaging scenario).	Usually the Placer ID (Filler ID may also be used)	Prescription number (if from an ordering system), or a Job number (if from a dispensing system).	Encounter ID

Change requests

Change the 'workflow ID' ENTRY attribute definition in the openEHR IM specification.
Add 'version ID' as part of the workflow ID in situations where the process/workflow has been modified???