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 |
Request received locally |
Report received locally |
Record received locally |
Report received locally |
ORIGINAL_VERSION |
Commit time (mandatory) |
Time data, usually a COMPOSITION, is saved in original system |
Request sent |
Report issued |
Note recorded |
Report issued |
(Event related |
EVENT CONTEXT.Start time |
The time (or start time) |
Request created/recorded |
Report created/recorded |
Patient encounter begins |
Report created/recorded (may relate |
|
EVENT CONTEXT.End time |
End time of the event or |
Not usually recorded |
Not usually recorded |
End time of the |
Not usually recorded unless at the |
PARTICIPATION |
Start time/End time |
The time that a person |
Duration of other |
Duration of other |
Duration of other |
Duration of other |
ATTESTATION |
Time |
The time this COMPOSITION |
Time of signing the request/referral or any part thereof |
Time of clinician or |
Time of signing the |
Time of signing the encounter note |
OBSERVATION |
EVENT.Start time |
The clinically relevant time |
N/A |
Time the sample was |
Time of the observation |
Time of the observation |
ACTION |
Time |
The time this action was completed |
Time of the action |
Time of the action |
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). |
|
|
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. |
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 |