Page Operations
Browse SpaceDate/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:
- Citation (DV_PARSABLE)
- URI to original data (DV_URI) - in this case EHR_URI to the original INSTRUCTION in the referral composition.
- 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
Hi Sistine - you are right - they would be the same. But lets be clear - there will at times be a need to record that you have done something and the result of the observation. I would hope that the user application would manage this.
Posted by
I can see that there could potentially be an overlap between OBSERVATION event start times and the ACTION (to have observed) times. We may need to clarify this a bit more.