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	audit. time_committed	Time COMPOSITION(s) were committed to local EHR system. Equals ORIGINAL_VERSION. commit_audit. time_committed with locally authored COMPOSITIONs.	Request received locally	Report received locally	Record received locally	Report received locally
ORIGINAL _VERSION	commit_audit. time_committed (mandatory)	Time at which data, usually a COMPOSITION, is committed in original EHR system	Request sent	Report issued	Note committed to EHR system	Report issued
(Event related COMPOSITIONs) COMPOSITION	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)
	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	time.lower, time.upper	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_committed	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	data.origin	The clinically relevant start time of the observed event	N/A	Time the sample was collected	Time of the observation	Time of the observation
	data.events(n).time	The clinically relevant time of a given observation in a series. For 1 event, origin and event time usually the same.	N/A	= origin	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

Referral and Report content

Referrer sends referral with INSTRUCTION + ACTION (on the request)
Filler sends tracker INSTRUCTION + ACTION
Filler sends report with OBSERVATION + ACTION
- +/- changed INSTRUCTION OR
- +/- original INSTRUCTION via "Citation" cluster archetype that contains the following 3 elements:
  1. Citation (DV_PARSABLE)
  2. URI to original data (DV_URI) - in this case EHR_URI to the original INSTRUCTION in the referral composition.
  3. Comment (DV_TEXT)

Order tracker receives INSTRUCTION and ACTION. This covers the manual entry of the INSTRUCTION.

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

The clinically relevant time of the observation