Is is possible to add context, ie actual text or other data types, to a persistent composition. The Archetype Editor doesn’t seem to support this. The use case is entries to the Norwegian national summary records, where each entry needs to be given a code (of course using a specific, National code set) about whether this is a new entry, a change to an existing entry, a verification or an refutation. Our hypothesis is to use a specific persistent COMPOSITION archetype for these entries, with only one entry per composition, and a coded text element to hold the code for the type of entry.
Is there a better way of achieving what we need to do here?
Kind regards, Silje Ljosland Bakke
Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF
Can you tell us more about the background? Are you trying to provide the model for the message, or to store the data when it is received (or both)?
Where does the data come from and how is it managed / curated? Does it come from a single clinician (presumably GP) or from multiple sources? Is it curated/managed by the GP or is it managed by the recipient.
In the UK, all of the emergency summaries are essentially copies of summaries managed and curated by the GP, so there is no need to synchronise lists, as it appears you are trying to do here. That is pretty difficult and even with simpler, safer labs messages, my understanding is that people have stopped sending ‘diffs’ i.e just a note of updates/changes in favour of re-sending the current full version of the message again.
To the first question – technical: Is it possible to have context on a persistent composition?
Yes – I think that should be possible. Some will argue that the context is an EVENT_CONTEXT and such context should only be used for event based Compositions. I think it makes sense to have some context also for the persistent ones.
Then to Ian’s follow up –what is the underlying use-case here?
The use-case seems to be based on a distributed environment where several healthcare providers commit their data for a given EHR (subject of care). This seems to be a asynchronous messaging architecture where they send messages (as Compositions) to update a central repository.
If this is true – then I agree with Ian that the synchronization of the underlying data will be hard .
The idea seems to be to keep a clinical concept within one persistent composition. I guess the intention by this is to be able to update a single source for the information about a specific concept. Then the central service must do some bookkeeping to make sure that each concept is updated by creating a new version of the specific persistent composition.
Another approach would be a more synchronized architecture. Where you first query for the concepts and get back all the LOCATABLE’s . Then the client will be able to create new versions of each entry (by creating new versions of the surrounding container). And when doing this – why would you like to constraint the model to only have one ENTRY for each COMPOSITION? This question leads me to suggest that the context you would like to add should be on the ENTRY – being an EVALUATION, OBSERVATION, etc. Could this be a solution?
BTW: We (DIPS) are implementing openEHR FOLDER to support use-cases like this. We will use FOLDER to realize a “FOLDER DOCUMENT”. This is kind of a persistent composition – but since it is a FOLDER it can combine several autonomous COMPOSITIONS in a shared view. I think this actually is PERSISTENT COMPOSITION done the right way. I think it would be used for all use-cases where we today create a PERSISTENT Template to model i.e. Social Summary, Previous Diseases. We will post some specifications/descriptions on this soon.
Sorry,
I didn’t reply to the question about context in persistent compositions. Actually right now this is not possible because there is a rule in the rm which says that persistent compositions cannot have context. This has been recognised as unhelpful and there was a change request in to remove that rule which may now have gone through. I’ll check.
In fact it really does not matter too much right now since setting persistent does not actually do anything technically. I.e. It is still up to tbe implementer to save the data in the right way.
Actually the suggestion to store each entry in its own separate composition is very similar to what we are doing in the ripple project, albeit for slightly different reasons. Essentially we are treating the problem list as a virtual document which does mean that each entry carries its own composition context metadata.