Context:
I am currently writing the implementation guide for a template named ‘Assessment of fluid balance’ which consists of COMPOSITION.report-result.v1 and OBSERVATION.fluid_balance.v1, for our beloved developers. For the AQL queries, I am writing down on how to constrain the time based on the date time attributes in this template. And there are four, namely
COMPOSITION/context/start_time: When it was created or updated (no issue with it)
OBSERVATION/data/origin : I have no idea, what its purpose is and what we are supposed to do with it
OBSERVATION/events[at0002]/time: From when on the assessment applies and no issue with it
OBSERVATION/events[at0002]/width: Duration and not exactly a date, but still very important to me.
I have checked the template in the Archetype Designer in the RM attributes section where it applies, the CKM for the archetype OBSERVATION.fluid_balance.v1 and neoehr documentation for OBSERVATION (where it only states data for recording a list of historical events). In other words, I was unsuccessful figuring it out.
My question:
What is the purpose of the attribut “origin” in “OBSERVATION/data/origin”?
start_time is the startTime of the whole composition
origin is the start time of a whole Observation
time (Event Time) is the startTime of an single Event within an Observation, where there potentially multiple events
In a simple use-case e.g a simple Vital signs composition, all 3 dateTimes may well be identical, and in fact some CDRs allow you to default the origin and Event.time to start_time if not supplied explicitly.
However there are situaitons where the 3 times may differ, and be important to record explicitly.
Where the time that the Observation was recorded needs to be precise, and may be different from the overall composition.context.start_time e.g in a Lab report
Where an Observation is made multiple times e.g an Apgar score at various intervals and each needs to be timed explicitly, using multiple events.
Thank you very much for the precise clarification on the difference between these different date-time attributes.
I have a question regarding your explanation on when the 3 times may differ: As a possible situation you wrote “Where the time that the Observation was recorded needs to be precise, and may be different from the overall composition.context.start_time e.g in a Lab report”.
But wouldn’t the datetime at which the observation was recorded be primarily persisted in the RM attribute ‘Date and Time Recorded’ (RM: …/contribution/audit/commit_time) at the composition level, and not in the 3 datetime attributes discussed so far in this topic (i.e. composition.context.start_time, observation.origin and observation.events.time)?
In hospital settings yes, but as a GP I often went on house calls and updated the records when I got back to base (sometimes the following day, so the commit_time may be different from all of the other dates.
Of course, these are not particularly common scenarios but openEHR was designed to take the different contexts of care into account
An original motivation for this was real world event such as birth (‘expulsion’ for OBS / midwives etc) which is the reference point for certain measurements, e.g. Apgar 1min, 2 min, 3 min.
Another basic medicine example: ingestion of glucose challenge is the origin point for an OGTT, where the measurements that are of interest are at +1h, +2h (or similar offsets). I don’t think OGTT is actually represented this way in openEHR, but it could be.
Other examples might be ultrasound obs 1 minute after dye injection, and similar investigational situations in which there is some delay between an event and the first observational ‘sample’.
The general concept originally was to enable the observables to be indexed on the timeline with respect to some other event, which would make the first sample not be at ‘0’.