Page tree

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:

  1. What happens if the concepts original ID is retained following the move to the extension - should this be permitted in the context of a concept that is explicitly flagged as MOVED_ELSEWHERE?
  2. We cannot be sure that a given concept has not been used by someone who is not the recipient of the "MOVED_TO" namespace
  3. While the namespace identifier is included as part of the wider metadata for the particular inactivation (one is given as the target of an accompanying MOVED TO association), some have requested that some other identifier be included either as well or instead that more usefully identifies the recipient organisation. For example, a module identifier.
  4. While this process has been described for "moved to" a local extension, there is a need to clarify the position regarding concepts which have been promoted from a local extension to the international release

Examples

Simple Example

305938004 Referral by GP locum (procedure)
MOVED TO 370137002 Extension Namespace {1000000} (namespace concept)
(MOVED FROM) 461401000000107 Referral by locum general practitioner (procedure)
311148003 Administrative officer secretarial - Royal Air Force (occupation)
MOVED TO 370137002 Extension Namespace {1000000} (namespace concept)
(MOVED FROM) 401371000000106 Royal Air Force administrative officer, secretarial (occupation)
Complex Example
152666007 Temp.res.<15 days claim: [FP19] or [GP19] (finding)
MOVED TO 370137002 Extension Namespace {1000000} (namespace concept)
(MOVED FROM) 27821000000105 Temp.res.<15 days claim: [FP19] or [GP19]
THEN                  SAME AS 12551000000105 Temporary resident claim (less than 15 days) (procedure)
Erroneous Example
195170003 [X]Intracerebral haemorrhage in hemisphere, unspecified (disorder)
MOVED TO 370137002 Extension Namespace {1000000} (namespace concept)
(MOVED FROM) 402531000000107 [X]Intracerebral haemorrhage in hemisphere, unspecified
BUT     SAME AS 274100004 Cerebral hemorrhage (disorder)
223190001 [X]Failure in dosage in electroshock or insulin-shock therapy (disorder)
MOVED TO 370137002 Extension Namespace {1000000} (namespace concept)
(MOVED FROM) 385961000000108 [X]Failure in dosage in electroshock or insulin-shock therapy (finding)
BUT                      MAY BE 216961002 Failure in dose in electroshock therapy (event)
BUT                      MAY BE 216962009 Failure in dose in insulin-shock therapy (event)
207019006 [D]Gangrene (situation)
MOVED TO 370137002 Extension Namespace {1000000} (namespace concept)
(MOVED FROM) 497701000000108 [D]Gangrene (situation)
BUT                      SAME AS 372070002 Gangrenous disorder (disorder)

Impact

(Describe how specific stakeholders are affected by the inactivation)

  • Authors
  • To give appropriate consideration to providing a suitable link to an existing concept from the International Edition for those who may have used the concept but are not users of the "MOVED_TO" extension
  • Release Management Team
  • SNOMED International Release Management Team:
    • Ensure appropriate consultation with the community of practice and sufficient warning for bulk changes
  • The "MOVED_TO" Release Management Team:
    • Ensure that all returned concepts receive new local conceptIDs
    • Manage the conceptID churn between existing and returned content
  • Extension Release Management Teams which were not part of the 'MOVED_TO" namespace:
    • Manage the concept inactivation and "REPLACED_BY" or "POSSIBLY EQUIVALENT_TO" content
  • Developers
  • Update Refsets and expected results of ECL queries
  • End Users
  • Update Refsets and expected results of ECL queries

Potential improvement:

  1. Provide tooling functionality to support either "POSSIBLY_EQUIVALENT_TO" or "REPLACED_BY" links to existing content from the International Edition where appropriate and WAS_A for those concepts which have no replacement
  2. Provide a text field to state the reason why the concept has been moved
  3. Consider giving the namespace identifier along with the text description
  4. Provide greater support to the recipients of the concepts we have MOVED_FROM the International Edition

Supporting resources:

<url><comment>
  • No labels

8 Comments

  1. '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.  

    1. 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.

  2. 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)

  3. 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.

    1. 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?

    2. 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?

    3. 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?

      1. 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"