Title | ||
---|---|---|
Narrative description: | 87009000 Fundus of abomasum (body structure) describes a part of the stomach of ruminant animals. More famously, 88495008 Hump of camel (body structure) used to be a cause for much hilarity when found by non-veterinary clinicians under 77568009 Back structure, excluding neck (body structure). Concepts describing the anatomy, clinical findings, and procedures unique to non-human animals used to be part of the SNOMED CT International Release, but were moved to an extension maintained by the Veterinary Terminology Service Laboratory (VTSL) at the Virginia-Maryland Regional College of Veterinary Medicine. A significant quantity of other content in the International Release derives from Clinical Terms Version 3 (CTV3), one of the two precursor terminologies that were originally merged in 2000 to form modern-day SNOMED. However, CTV3 contained a lot of content only relevant within the United Kingdom (e.g. 152630006 CH7 sent to: [FPC] or [HB] (finding)). Over the years, much of this UK-specific content has been expunged from the International Edition, usually by the MOVED_ELSEWHERE mechanism to transfer it back to the UK. However. some remains. Identified content may not have an agreed meaning (or utility) internationally but may still have meaning within individual regions/jurisdictions. In this situation, the content would be inactivated in the International Edition of SCT and be "moved to" another extension. In the same way, any NRC now engaged in maintaining their own national extension will likely receive requests for new codes to cover clinically legitimate expressivity that is missing from both the latest International Edition or their current NRC extension of it. However, some of that requested expressivity will obviously be also relevant internationally rather than only within the clinical jurisdiction of the particular NRC to whom the requirement was first raised. In such a situation, the NRC can choose to add the request to the international request portal, and wait. Alternatively, for reasons of expediency, they may choose to create and release a new concept within their own extension whilst simultaneously suggesting it for "promotion" to the International Release. Should that suggestion subsequently be taken up, and a new and directly equivalent concept be stood up in some later version of the International Release, then by convention the original NRC code will be made inactive, the reason for its inactivation given as 'component moved elsewhere', and a MOVED_TO association asserted pointing at the International namespace. | |
Details: | What is being inactivated (concept/description/any component)? | The identified concept is being inactivated from the International Edition of SCT and being moved to another extension namespace (This may be an actual move or an impending move, if between releases) |
What is the reason for inactivation (description)? | The concept is deemed to be inappropriate for inclusion in the International Edition of SCT | |
Which inactivation value should be used? | Component moved elsewhere | |
Which historical association reference set should be used? | MOVED_TO association reference set (foundation metadata concept) | |
Known issues: |
| |
Examples | Simple Example | 305938004 Referral by GP locum (procedure) |
Complex Example | 152666007 Temp.res.<15 days claim: [FP19] or [GP19] (finding) | |
Erroneous Example | 195170003 [X]Intracerebral haemorrhage in hemisphere, unspecified (disorder) | |
Impact(Describe how specific stakeholders are affected by the inactivation) |
|
|
|
| |
|
| |
|
| |
Potential improvement: |
| |
Supporting resources: | <url> | <comment> |
8 Comments
Cathy Richardson
'textural identifier' -Description ID?
Shouldn't this also consider extensions (beyond impact) given the plans for International content? Also national and local extensions - use should be consistent.
Jeremy Rogers
re 'textural identifier'
I think the issue is that a reference to a namespace identifier is, in an RF2 world, simultaneously both inaccurate and unhelpful: inaccurate because no new identifier in that namespace will usually in fact be created, and unhelpful because the namespace identifier is a very cryptic way of referencing some new locus of editorial control. You can resolve a namespaceID it to an organisational entity ... but only by consulting the namespace registry (which is not currently terribly machine readable).
I've rejigged the text.
Jim Case
Agree with comment that use of a namespace for the value of the MOVED_TO relationship is not useful. Namespaces in RF2 have simply taken on the role of providing component uniqueness, rather than ownership as component IDs are retained when concepts are promoted to the International release. Something that would be "owned" by an extension, such as a moduleID seems more appropriate as I do not think that these would ever move out of the originating extension (or the international release)
Matt Cordell
Yes, this has been messy since RF2. I agree that referencing the module seems most correct, however, to do so means the destination module needs to be published within the International Edition... Whereby, does the module technically become an International Module?? (It's messy)
I'm inclined to say the "moved to" should only be used when the ID persists. If the destination extension, assigned a new ID, they'd also need to assign addition historical associations... (again messy).
There have been discussions in TRAG about the idea of "edition composition" as opposed to "module dependency" (Currently the two are conflated within MDRS). That may factor into this discussion?
As an aside, we introduced Preferred Terms for NameSpace Concepts a little while back, to help with the issues Jeremy describes. We haven't done all namespaces (and unlikely to), only those we encounter (our own and those for content promoted to International). E.g. 703872000|Australian Digital Health Agency Namespace 1000168|. The main use is, terminologists can easily lookup namespaces they encounter up within the same tooling to see it's provenance.
Jeremy Rogers
Matt Cordell agree that this problem of where the moduleIds themselves would need to be published looks likely to block the proposal to change existing practice of MOVED_TO associations referencing a namespaceId with one of referencing a moduleId concept instead. Thinking more on the issue, perhaps referencing a moduleId would have also been wrong anyway:
The purpose of a MOVED_TO relationship is to point at something standing for the new locus of editorial control; the new 'owner' of the content, such as an NRC. However, within such a new and singular locus of editorial control, an NRC may choose to publish its curated content across multiple different modules. This means that a moduleId is not the same as the locus of control: it is merely one arbitrary (and no necessarily constant) partitoning of it.
What we really need to be able to point at therefore are unique identifiers that unambiguously stand for these individual loci of editorial control - the NRCs themselves. Everything else - namespace, moduleId etc - are ultimately only proxies for this more fundamental idea. For some reason we've been avoiding representing them directly within the terminology . Maybe it all finally becomes clearer if we have SNOMED codes for each release centre or other potential recipient of a moved concept, that we can then refer to directly with a MOVED_TO association?
Jim Case
Matt Cordell,
You said "I'm inclined to say the "moved to" should only be used when the ID persists. If the destination extension, assigned a new ID, they'd also need to assign addition historical associations." I totally agree since if the SCTID does not persist, then it is not a move, but a replacement and MOVED_TO would be inappropriate. Apparently we have not implemented PTs for namespaces in the International edition, but that would certainly be a useful addition as you have to get the listing of approved extensions to see the provenance currently. Was that an AU specific implementation or a recommendation from the MAG?
Jeremy Rogers
I like Matt Cordell's idea of decorating the existing set of namespace concepts with text providing a human readable description of who owns that namespace and perhaps also something of what it is used for. It could be an additional synonym that can optionally be promoted within a realm language refset to being the Preferred Term, or by means of e.g. an sRefset pattern. But could/should this enhancement be done within the International Edition itself, as a more machineable version of the current namespace registry?
Matt Cordell
The descriptive PTs for namespace concepts is specific to our extension.
I don't expect to ever encounter most of the namespaces in the wild. We check for those present in core, with a bit of REGEX against all components, and just add synonyms for those, and a little editorial guidance.
(Partly to avoid imortalising individuals within the terminology).
Jeremy Rogers, we have a collection of modules in our edition (like the UK). And as you say, the specific module could change over time. It's really "edition" we're talking about.
Perhaps the format of the "MOVED_TO" association, could use the FHIR URI's of the destination edition(or extension), string, rather than a conceptId. e.g. http://snomed.info/sct/32506021000036107/version/20200831
Version optional, but tells you when to expect it from? Machine readable. Eventually SI, could maybe provide some sort of an index services that resolves at this URL differently?
Is "Veterinary Terminology Service Laboratory (VPI&SU) Namespace 1000009" considered an edition or extension? (The one that jumps to mind).
Also, with the introduction of "community content" - Content could be moved to an extension that is shared NRCs? e.g. An "EU extension"