I want to categorize various templates using SNOMED-CT. The SNOMED concepts (“record artifacts”) should be persisted in each created compositon, preferably automatically. I am struggling to find a good (light-weight) solution. Is there a way to avoid the creation and insertion of a cluster archetype into the other_context > Extension slot?
Hi Jonas,
Our approach has been to add an ‘XDS metadata cluster’ originally developed by Fabio at Better to carry the document category as a SNOMED code. This probably could be usefully updated to fit with the [FHIR Document Reference resource](DocumentReference - FHIR v6.0.0-ballot3) as that has utility beyond just the document category, in fitting into XDS/Record locator environments.
The alternative would be to add a Term mapping to the Composition root node but that feels a little obscure to me.
1 Like
Hi Ian,
Thanks for your reply. I had a feeling that a cluster archetype would be needed. I will look into any updates and adjustments to local requirements necessary. Has the archetype been considered for publication in the international CKM?
Not as yet - we did have it in the UK Apperta CKM but that is offline.
I think this is a good opportunity to intro a new archetype based on the FHIR DocumentReference but I’ve attached the XDS one for info
1 Like
That XDS metadata cluster is also used in Catalonia. I agree that this should be aligned, and published through the international CKM.
4 Likes
That sounds like a good idea. Do we have any volunteers to run the reviews? 
I’d certainly be happy to help. I do wonder if we should take this opportunity to modernise it towards the FHIR equivalent
5 Likes
I’d love to translate it into zh-CN if needed
2 Likes
I would be happy to help as well!
1 Like
i would rather have a clean slate using a specific category cluster, this XDS carries a lot of stone age IHE stuff.
I would propose making a specific fhir cluster for that for the composition.
Would be also useful to carry an encounter identifier e.g. where ever this will point to (implementation dependant).
Would help a lot.
There also might be other fields we want to put there.
As always i recommend first of all looking at this from an import and export view.
import:
easy: use term_mapping or add an category cluster to each of the archetypes clusters. That would be the XDS on here (which i would not recommend), still clumsy. I personally prefer term_mappings here especially for child elements (for the composition itself category could be fine).
Export:
The bigger issue is that most existing compositions have no categories. We cannot tell people now to populate all those + retrospectively. Here, dataAbsentReason in FHIR is the correct way to represent missing values.
But how do we handle this in the future ?
Adding a category field to each of the archetypes and each of our Clusters ?
Also do not the codes used implicate already what type of e.g. test category this is ?
1 Like
What do you mean by “add a category cluster to each of the archetypes clusters”. Wouldn’t it be just adding one category cluster in the context of each template?
I agree term_mappings is much cleaner, especially as the categories probably do not add much value inside the CDR but are really just there to assist integration.
1 Like
I created a first draft of a cluster archetype as a starting point for discussions. It is mainly based on the the DocumentReference FHIR resource DocumentReference - FHIR v6.0.0-ballot3
Let me know in case you are interested to collaborate on authoring/reviewing/translating, it would be great to set up a meeting to get started.
openEHR-EHR-CLUSTER.document_reference.v0.adl (8.6 KB)
documentReference.xmind (215.5 KB)
3 Likes