Hello everyone,
One of our initiatives in the Catalan Healthcare Service regarding openEHR modelling consists of the creation of a set of templates that covers the whole obstetric process of the patient. In this initiative, we have the necessity to define a unique identifier to identify that a set of templates belong to the same pregnancy (multiple events belongs to the same episode), and to identify each episode (different pregnancies).
For that purpose, we have been thinking how to solve it. We have been thinking in two different possibilities to solve this:
Create a cluster with this unique identifier and model it in the context part of the composition (context / other_context / Extension)
We have been using a Cluster from the Apperta CKM, wtih administrative information, which is called “XDS Metadata”, which includes an element called “Event code”. We were thinking to propose a change request to this cluster in add an “Episode code” as well: Cluster Archetype: XDS Metadata [Apperta UK Clinical Knowledge Manager]
We have been reviewing some possibilities from the RM itself of the compositions, to know if this could be another possibility. But nothing fits for our case. I would appreciate any other suggestion or if we think that our options are good for the situation.
The one you describe, which is to add a small Cluster archetype into each composition to allow all of the compositions associated with a particular episode of care to be identified but I would not use XDS metadata for that purpose, as it is really identified for document metadata and Event code is for documenting speciality specifc data like procedure names (not really required in openEHR).
We have used this Care Journey archetype for care planning type episodes
Folders - as Silje has suggested. (1) is simpler but (2) is probably more strategic - @joostholslag, @pieterbos and @sebastian.iancu are probably the experts in this area.
In either case you probably need an ADMIN_ENTRY archetype in a separate episode persistent composition to carry more details of the episode itself.
Firstly, thank you for your answers. As you suggested @siljelb, we have been checking the FOLDERs structure, and we might be using episodic folders also for this use case. Many thanks for the suggestion!
On the other hand, @ian.mcnicoll, I really appreciate your answer, and we will take a look at both archetypes to decide which one suits better for our situation, as we think it might be the best solution for this.
Again, I really appreciate your inputs about the topic! Kind regards,
Laura
Hmmm - this is where I start to worry when I find my name as author on two related archetypes…
I have also been using a CLUSTER with similar data elements because I needed to include them in the context of one of the screening questionnaire OBSERVATIONs - Cluster Archetype: Inpatient episode details [openEHR Clinical Knowledge Manager]. I can imaging there might be other ENTRY archetypes where this might also be reused.
So it may be good to include the CLUSTER as an include in the ADMIN archetype to prevent duplication.
I’ve been discussing this with Laura and my understanding is that because there is no ability to influence the implementation or storage design, folders are no longer an option.
So what is needed is a modelling solution that supports any downstream implementation design, hence the suggestion about Episode IDs in metadata etc.
At the risk of sharing too early, today I’ve been experimenting with trying to support explicit linkages between parts of the health record via modelling techniques. This is in response to @LauraMoral’s query in this thread, and also @ian.mcnicoll’s earlier thread re inclusion of references to protocols and clinical trials.
a new CLUSTER archetype ‘Clinical metadata’ to describe various IDs that support virtual linking to other parts of the health record eg via a health thread, to an existing care plan or to external resources such as a care protocol, pathway or guideline that may have triggered the need for the data being recorded. This archetype would be nested within COMPOSITIONs or ENTRYs to effectively act as a tag.
To demonstrate some context for how these might be used I’ve also drafted up some dummy templates to start to explore how they might be used:
a curated, persistent Health threads template for all problems and diagnoses - theoretically this goes some way to supporting Larry Weed’s POMR approach.
and some example of how the CLUSTER.clinical_metadata might be used in other typical health record COMPOSITIONS:
— Antenatal visit - where a visit might be tagged as being a part of a specific pregnancy thread and an antenatal care plan.
— Lab test result - where the result might be tagged as a part of a specific pregnancy thread, antenatal care or gestation diabetes care plan, a treatment protocol or a clinical care pathway. The CLUSTER.clinical-metadata is nested in the COMPOSITION and refers to the whole report.
— Problem list - diagnoses may be part of more than one health thread. The CLUSTER.clinical-metadata is nested in the ENTRYs and refers to each problem or diagnosis.
— a Labour record - may be part of a health thread and aligned with a care protocol
As mentioned from others there are multiple ways to connect data to an episode. This was one of our first challenges implementing openEHR in DIPS. We needed a context for the data, i.e. the collection of all body temperatures collected during a hospital stay or all data related to pregnancy.
Our implementation on this was to introduce TAG on COMPOSITION. We proposed this technical solution for the openEHR SEC and it was added to the RM 17 november 2022.
Adding such TAGs to the COMPOSITION we make it possible to query all data belonging to the same context. Context is then defined as a key/value structure.
As other mentioned above there are other ways to solve this:
a) Add a specific CLUSTER archetype on the root of the COMPOSITION. Depending on your need this might be a generic key/value structure or more specific to model the context for your data. A good reference to name the attributes of the context is CONTSYS
b) Use openEHR FOLDER to collect COMPOSITION in a shared context.
c) Other modelling approaches adding ADMIN_ENTRY data to the composition
Most likely you have to pick a solution which is supported by the vendor you have.
Thank you very much for all your inputs! As for the moment, the smartest solution for us would consist on using a cluster in our compositions, since we need to model those templates ASAP.
Very interesting the idea of creating a new composition with this information already included on it. @heather.leslie , let me know if you would like to work together either on this idea, or the creation/validation of the “Health Threads Template”, which also fits on our use case. For the moment, we will be modeling using one of the @ian.mcnicoll 's suggestions (Care journey metadata) since it seems to be the most effective solution for the moment.
I have to catch up reading carefully this thread, but in the meanwhile just quick feedback besides information from @ian.mcnicoll and @bna is that I am looking (probably together with @joostholslag) on a addition to RM for an EPISODE type; it is still on agenda of SEC to be discussed about.
I did kind of merge different ideas brought into this forum( and also in the Can a persistent list be considered the source of truth? - #18 by david.alonso ), in an attempt to find a nice system.
If a problem oriented clinical note in a longitudinal record has to be associated / related / tagged to a diagnosis, could the “Health thread” or a kind of adaptation be useful in orther NOT TO DUPLICATE a problem diagnosis ? (The diagnosis would have been created in another Template).
The idea of that is to avoid duplication of diagnosis if an AQL on problem/diagnosis arquetype is called. But maybe there is no need and we could use the same arquetype ?
Another question: Could the “Health thread” work as a way to relate diagnosis (hierarchically, cause-effect…) ?
Ischemic Heart disease
* Angina pectoris
* Heart insufficiency
Or it would be pushing to hard on semanthics ? (and there is a better way to do, even outside the modelling).
Super nice work. Both the questions, summary fro two threads and the diagram are very helpful.
One thing to note is that in my experience the problem on the problem list or especially a care plan (curated overview of managed problems with its goals and interventions) is often subtly different from the original diagnosis. At least in the environment I did the research (Dutch nursing homes) E.g. diagnosis in encounter could be “type 2 diabetes”, while the problem in the care plan could be “hypoglaecemia due to underregulated diabetes.” Now these are about the same phenomenon, but the wording is different: “diabetes” vs “type 2 diabetes” and the perspective is different: what do we want to be improved vs what is the cause and classification of the problem the patient presented.
Now: to avoid the duplication problem we could not enter a new eval.problem diagnosis in the care plan but just record a link (dvehruri). But how then do we record the new name and perspective for the problem? This linking only might work for a problem list though, where the main requirements are selection based on relevance, merging with other entry’s like procedure and ordering. But in my experience there’s quite frequently edits to the name of a problem in a problem list. E.g. by summarising multiple diagnosis into a single one. E.g. a recurring cancer where each recurrence of the cancer is a new eval. problem diagnosis summarised into a single diagnosis line in a care plan. Or stripping of too detailed info in the original diagnosis e.g. the her2neu status of a breast cancer in a GP problem list.
We could also use a different archetype for care plan problems, but I feel usually the ‘new’ care plan problem contains new information that actually describes a problem (“hypoglaecemia”) and should be returned on a AQL for problems. One other issue for problem lists is that the original diagnosis is often in another (non openehr) system and not available to link too. So it’s recorded as a new diagnosis when curating the problem list. That new recording should definitely be returned when querying for diagnosis.
My intuition says we should just work around the downsides of ‘duplicate’ records of ‘the same’ diagnosis. Mainly by facilitating careful curation by clinicians of a problem list and/or care plan with active problems.
I’m curious for which downsides of duplication you encounter in your work?
Another very interesting question. And I think it’s going the right way. I definitely feel we should records link to the ‘original diagnosis’ (in the encounter) in the entry in the problem list diagnosis, if a new entry is created instead of only a link. We should consider adding a dvehruri element to the archetype. What do you think @siljelb ?
Additionally we should record health threads using folders for each (actively managed) problem. And add every related composition to that folder. And record a link from the problem in the problem list to the folder.
So In your diagram the free text note should (also) link to the problem list entry.
