I am learning about OpenEHR specifications but cannot clearly understand about the concept behind COMPOSITION. The specification says that a COMPOSITION is a committal unit (i.e. only COMPOSITION can be committed, but not OBSERVATION etc.).
What about if the clinician take history from a patient and commit that history (using Encounter archetype) and then order a laboratory testing. The laboratory report needs to be in a different COMPOSITION (perhaps a Report archetype) because it isn’t committed in the same time as the history, right?
1 Like
Right you are!
The laboratory test order (INSTRUCTION) could be part of the encounter composition, the result does not make less sense to be part of the encounter composition, a ‘report result’ COMPOSITION would make most sense to me. Since the lab result will be committed as a ‘message’ from the lab, not an entry form by the clinician.
If a doc sees a patient, his/her application will allow the recording of various things - let’s say:
- physical exam - BP, etc
- some diagnosis, e.g. risk of uncontrolled hypertension
- update medications list, e.g. change Beta blocker or other med
- maybe a change to the care plan, if there is one
Each of these things is likely to be in its own COMPOSITION (the first two could be in the same COMPOSITION), in a well-organised EHR. When the doc hits ‘save’, these COMPOSITIONs will all be saved. Now: some of them are new (the first one), and some may already exist - the Medications List and Care Plan. So what is really being saved is Composition Versions. Any one ‘save’ action will result in what we call a Contribution - a combination of Composition versions, and maybe other changes to the EHR.
This part of the EHR spec explains in detail. It is somewhat technical (versioning is a very technical subject), so don’t feel bad if it still seems obscure, but it is standard stuff for IT systems. More on versioning here in the Architecture Overview.
1 Like
Thank you very much.
I am viewing this template: https://ckm.openehr.org/ckm/templates/1013.26.226 . Suppose that I am committing new patient data using this template and suppose that the past history data of this patient already exists in the database. Can that existing data be retrieved (or link) into the “Past history” section? (or is it a matter of implementation?)
1 Like
Well it depends. If you are updating the already existing data, i.e. it’s really the same form that you are filling, the application should retrieve the current contents of that form (i.e. that template), you will make your changes, and then save, and that will create a new version of the same logical COMPOSITION in the EHR. Here is the relevant part of the EHR API that enables that, if you are interested in the technical details.
However - it may be that what is being filled out really is intended to be a new (separate) instance of the form; in this case, an entirely new COMPOSITION would be created, distinct from any previous one, based on the same template. A template is just a ‘type’ of document, i.e. a model, or proforma, not an instance.
It could also be that you want a new instance of the form, but with some content copied over from a previous one. The application would need to arrange that - and the API will enable all the relevant retrieval and commit operations to do so.
hope this helps.
1 Like
What about the Encounter composition archetype? Isn’t it meant to be used as a group of history, physical exam, diagnosis, order, etc that are committed on a single visit? (so these items shouldn’t be in separate COMPOSITIONs).
I think we should use referencing rather than copying. Is this mentioned in the OpenEHR specs?
Yes, generally speaking, new information (obs, Dx, commentary) etc would normally go in a new Encounter COMPOSITION, for each new encounter. But the encounter may also cause the updating of some existing things like the medications list, problems list, care plan etc. These things are usually stored in ‘persistent’ COMPOSITIONs. So the total info recorded by an encounter will be in a single CONTRIBUTION, which may include one or more COMPOSITION versions, some of which may be new.
Having items in separate COMPOSITIONs for a single Encounter is fine; as long as they are saved as part of the same CONTRIBUTION (even this is not a law of physics, but if it is not done this way, it is likely to make querying and displaying previous Encounter unnecessarily annoying for application developers).
1 Like
Yes - here. We really need to improve the documentation on this feature.
However, there is a more powerful concept of linking coming, provisionally called ‘views and citations’ which will enable more structured cross-referencing. An initial UML model is here, and this wiki page talks about how ‘reports’ could be better represented.
I would expect additions to the specifications in the next 6 months to cover these needs.
1 Like
Why does medication list or problem list need to be updated in the separate COMPOSITION despite there are medication order and diagnosis/problem sections in the Encounter template? It seems for me to cause data redundancy and reduce data integrity.
If the medication list needs to be retrieved, can we only query through Medication order section (or diagnosis section in case of problem list) in every Encounter instance? (or using “special kind of COMPOSITION”, whose content will be updated based on other COMPOSITIONs)
1 Like
That is a good observation. I glossed over some details. @ian.mcnicoll , @heather.leslie and other clinical modelling experts may correct me here, but orders (Instructions) and their resulting acts (Actions) are normally stored in the Encounter Compositions corresponding to the relevant encounters. However, there is usually a Current Medications list (a persistent Composition) which contains references (just as you asked about earlier) to these primary data items. The Medication list is usually a manually curated Composition that lists current / relevant meds (= planned, active, suspended), possibly with references to diagnoses etc. Similar story for a master Problem list.
The citation / view feature we are working on will make such ‘reference lists’ easier to build and more powerful.
1 Like
Hi,
Sorry to be a little late to the party!! These are very good questions.
You are quite correct that in a fully ‘properly’ designed system we would almost certainly tease out aspects like problem lists, lab results etc into different templated compositions.
I was the primary author of the Heart Failure summary template and its primary purpose was to model the overall content requirements for a research app dataset as part of an EU academic project, modelled on a real-world registry/research application. So it was built of a vey specific purpose, and much simpler use-case than you are imagining but you might consider it to be a ‘copy’ of an outpatient letter, so might make sense as snapshot of an outgoing message.
The other NCD template you were looking at is/was based on some early work in Jamaica, really as a training exercise. I am actually working with the team in Jamaica to take this towards a real deployment and we are discussing exactly those issues that you raise - what should be split out into different compositions. I’m sure they will be no objection to sharing the outcome of the discussions. So very much work in progress.
Whether to reference or clone/copy data that originates e.g in an Encounter can be tricky - in a perfect world I would always want to reference but this can be harder to implement and manage over time.
I guess part of the issue here is that are often trying to take our customers/users on a journey from a form-based view of the world where e.g medication lists are replicated on every form, but also have to recognise that some of these lists are not truly longitudinal/holistic but may need to be maintained per patient pathway / condition.
Why does medication list or problem list need to be updated in the separate COMPOSITION despite there are medication order and diagnosis/problem sections in the Encounter template? It seems for me to cause data redundancy and reduce data integrity.
So yes, in theory I agree but sometimes we make compromises for training purposes or because the ‘customer’ is not quite ready to jump into that level of sophistication.
Good discussion.
1 Like