# Categorize templates with SNOMED-CT

**Category:** [Implementation](https://discourse.openehr.org/c/implem/39)
**Created:** 2025-09-26 08:47 UTC
**Views:** 163
**Replies:** 13
**URL:** https://discourse.openehr.org/t/categorize-templates-with-snomed-ct/11427

---

## Post #1 by @jbuch

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?

---

## Post #2 by @ian.mcnicoll

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\](https://build.fhir.org/documentreference.html) 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.

---

## Post #3 by @jbuch

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?

---

## Post #4 by @ian.mcnicoll

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

[openEHR-EHR-CLUSTER.xds_metadata.v0.adl|attachment](upload://y7wMQfOEmJ2xYQpbhpxJdJnGVgM.adl) (5.7 KB)

---

## Post #5 by @damoca

That XDS metadata cluster is also used in Catalonia. I agree that this should be aligned, and published through the international CKM.

---

## Post #6 by @siljelb

That sounds like a good idea. Do we have any volunteers to run the reviews? :smile:

---

## Post #7 by @ian.mcnicoll

I’d certainly be happy to help. I do wonder if we should take this opportunity to modernise it towards the FHIR equivalent

---

## Post #8 by @linforest

I’d love to translate it into zh-CN if needed

---

## Post #9 by @jbuch

I would be happy to help as well!

---

## Post #10 by @SevKohler

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.

---

## Post #11 by @SevKohler

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 ?

---

## Post #12 by @jbuch

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?

---

## Post #13 by @ian.mcnicoll

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.

---

## Post #14 by @jbuch

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 https://build.fhir.org/documentreference.html
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|attachment](upload://kMSaK6DTUVvMdqrhrDSoHnottMb.adl) (8.6 KB)

[documentReference.xmind|attachment](upload://hVc78JKiQEALomMX3CXWwpoZiXR.xmind) (215.5 KB)

---


**Canonical:** https://discourse.openehr.org/t/categorize-templates-with-snomed-ct/11427
**Original content:** https://discourse.openehr.org/t/categorize-templates-with-snomed-ct/11427