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.