I’m trying to represent a timeline of past states (values of some attribute with validity time spans) within a composition. The RM spec contains a section on the history package containing classes that I believe match that use case.
The only use I could find was in the OBSERVATION class. But I don’t this class matches my use case as archetypes based on it don’t seem to be used in that way. Are there any places I’ve missed and do you have any ideas I can model this type of information in a composition.
As an example: I won’t to recorded past status values of an encounter with attached time spans.
I want to be able to store past values of both the class and status elements like is done in the FHIR Encounter resource type. It pretty much boils down to some entry containing the past value and a timestamp/range of time for which the value was valid. This would enable me to represent this data in a single openEHR composition and not have to create new encounter data composition when either of these values changes. Having access to past values is useful since updates of the encounter class value reflects the progression of an encounter over time (e.g. pre-, in-, and post-inpatient phases in the case of an inpatient encounter). Same goes for the status value.
I don’t think it suits my use case since it want to record the data in the composition itself and not via its update history. That way I have access to the progression at a glance by just fetching a single composition.
At least I assume that this what you are suggesting. Please feel free to correct me if I’m misunderstanding.
I’m not an experienced modeller so I might mix up the terminology here. Anyway I was looking at some reference model classes that looked promissing imo, namely the HISTORY class.
It think it would suit my use case perfectly. Though I can only find it being used in the OBSERVATION class. And using the Archetype Designer I was not able to archetype the HISTORY class in anyway nor include it in some archetype. Whether you know how I can do that or why I can’t, I’d like to hear your answer either way.
I have to admit I’m still not sure if I understand what this information actually represents and how it would be recorded in practice. For example, would it all be recorded in one go, or step by step as the status develops over time?
That helps - I think I have got it now. So basically you want to be able to update the status and/or class codings as the person passes through the Encounter from triage→admission-Discharge?
My approach would be to create the Encounter as part of an ‘episodic persistent’ composition. EHR Information Model and quite close to @siljelb original suggestion e Change_control
This means that the commit strategy is a POST of the composition for the first instance, then a PUT for each update i.e the same composition instance is deliberately up-versioned as the status or class changes. When the Encounter is complete, and if the patient has a new Encounter, the cycle starts again with a new instance POST first, then subsequent PUTS.
The only restriction is that the PUT composition has to be a complete composition, not a differential i.e you will first re-read the current composition version (AQL will do that by default) , make the changes in memory then do the PUT composition. This might seem clunky but in complex environments, it always ensures that the current composition is accurate.
To retrieve the older versions of the composition to display your time-line, you can either use REST API calls, and some CDRs do support VERSION in AQL
SELECT v/commit_audit/time_committed FROM EHR e [ehr_id = '12345-3456-567'] CONTAINS VERSION v CONTAINS COMPOSITION c WHERE c/archetype_details/template_id = 'My Template' ORDER BY v/commit_audit/time_committed DESC
For various reasons, although you can set Composition.category to be ‘episodic’, this is not properly supported in AD, and in any case is not enforced by CDRs so ‘use Episodic persistence’ really just has to be delivered to devs as Implementation Guidance with clear rules on when an episode starts and stops.
It would be updated over time. So in during an update you would set the attribute to the new value and then append the past value to the history. For example, you might initially have information about some encounter that will take place at some point in the future. As such you would record a status such as planned. Once the the admission takes place, it would again be updated to something like ongoing. However during the timespan the patient is admitted they might be absent for some time frame. This is indicated by the `on-leave` status code (in the FHIR analog). Ideally these changes would result in updates to a single composition and past values with validity time ranges be easily accessible for querying. Having access to information on when the patient was present at the hospital and when they were absent during an encounter is useful for calculating the actual time they spent in the hospital (one of the data points I need).
Leveraging change control definitely is valid solution to the problem. However I think it would lead to more complex queries and the representation of encounter data in our CDR could not as easily be transformed into the data model we have to export to.
For instance the target data model focuses on representing different types of encounters based on the level of contact with a clinical institution. E.g. you would have a composition representing a patient being admitted to a clinical facility; during which they can have multiple contacts with different departments (each again likely represented by its own composition); and finally during each of these events the patient might still be transferred between different wards, is transferred to have medical procedures performed etc. (these events are also recorded ideally be their own composition).
I just think that having to represent all these contact levels is difficult enough as is and thus would prefer a solution that stores the historical data points at a glance in a single composition. If this is not advisable in openEHR than I guess I have to switch to the solution using the change control mechanism.
With your proposed approach, would the context/start_time (and context/end_time) attributes represent the validity range of the information in any particular version of the composition? I’m asking because as far as I can tell the versioning related change-control classes contain commit timestamps not timestamps representing the validity of the clinical event being recorded. Please correct me if I’m wrong there.
Yes - you could use the context start and end times to represent the validity period for each ‘status change’ .
Doing it this way is consistent with the way we try to do things in openEHR i.e. capturing each change in the patient state / record as it happens, rather than bundling up a series of transactions/events into a single history. Although of course there are exceptions lie the HISTory in Observations.
I still like the idea of using a persistent composition and querying across versions because it is quite likely that there will be a need to change other encounter details in the future. Querying is bit more complex but a one-off challenge.
