Lately we’ve had archetypes proposed containing bindings to SNOMED CT terms that are not in the international edition, but only in a country specific one. According to the information I’ve received, these may be made into international terms with the same SNOMED CT IDs, but they may also not.
Should terms that are not (yet) in the international SNOMED CT edition be included in international archetypes?
Thanks,
This is useful policy discussion.
This page from the SNOMED website might help orientate people.
In particular
For example, although 6811000087108 |CT guided biopsy of left lower limb| includes the namespace identifier “1000087” (allocated to Canada Health Infoway) and the partition identifier “10”, this concept belongs to the |SNOMED CT core module| in the International Edition. The presence of the Canadian namespace identifier in this SCTID indicates that this concept was originally created by Canada Health Infoway and later promoted into the International Edition.
My understanding is that originally SNOMED policy was that when a term was moved to another ;owner e.g UK orCanada to international (or sometimes the other way), that the namespace part of the code would also change. Of course when this happened, chaos ensued because the original code was no longer valid (or at any rate ‘different’) . So theplicy changed some years ago, around the time we had come to similar conclusions on archetype namespaces i.e it it tells you where it was born, not where it is now a citizen. That makes it easier to move terms and archetypes around to the most appropriate ‘current custodian’, without disrupting existing systems.
Now , of course, we should not use terms from a local SNOMED namespace that simply reflect local requirements e.g UK hospital service names or legislation but quite often new codes are born in local namespaces whose meaning is quite evidently global. I would argue that we should make use of those, since the code would not change if it is eventually moved to the international namespace.
If we do not do that, and someone wants to map e.g. a clinical frailty value to SNOMED in Norway, they will have to invent one in their own namespace (duplicate code!!) or lobby SNOMED to move the UK one , in which case, it will end up being the UK namespaced code -same result!!
I think we are actually helping keep this sort of thing aligned. Of course there needs to be a good conversation about whether particular nodes need a binding, and whether any local code/term is actually appropriate in an international setting.
Its policy changed as you pointed out.
This is helpful, and if I understand it correctly solves the issue of code permanence. However, there’s still the risk of a local term never becoming international, and how we can communicate to implementers and others that “this term only exists in the Norwegian SNOMED CT edition”?
Don’t think there is really any other option than to document in Use/misuse or in comments against the node concerned. Bindings are always optional in any case. Someone will always have to make the decision as to whether to us them or not. I’m not sure that it it will be such a common occurrence that we need to make specific changes to the AOM.
Fair enough.
Btw, what if two countries have created identical semantic terms in their local namespaces. There will have to be one that’s accepted into the international space and one that’s rejected? Are there any rules about this?
I would assume it is largely who offers the local terms to the international community first, unless another provider pops up as shows that they have done a better job!
Or in the case of some Covid coding the international community decide to do their own ) though that is probably more a matter of timing.
It will not be too different than similar challenges for archetypes.