Page tree

Title


Narrative description

2 concepts appear to be semantically equivalent but have subtle differences:

  • Identical FSNs with slightly different logical definition
  • The FSNs have different word order but the implied meaning is the same
  • The FSNs contains word equivalents or an eponym
  • Where an organism has multiple equivalent names e.g. common and scientific name
  • The concept shares the same descriptions (synonyms) but the FSNs are slightly different
  • The FSNs are slightly different but the 2 concepts share the same modelling (implies one is primitive and one sufficiently defined)
  • Identical FSNs but with a different semantic tag

Details

What is being inactivated (concept/description/any component)?The duplicate concept is being inactivated
What is the reason for inactivation (description)?The 2 concepts are considered to be semantically equivalent
Which inactivation value should be used?Duplicate component
Which historical association reference set should be used?

SAME_AS association reference set (foundation metadata concept)

SAME_AS means A is semantically equivalent to B

Known issues

  1. Establishing semantic equivalence is key and may be difficult. If there is doubt use ambiguous as the inactivation reason.
  2. If the ancestors and descendants of the concept are inconsistent with what is implied by the FSN then inactivate as ambiguous.
  3. Ensure that the synonyms are appropriate and represented within the active concept.
  4. To reduce the impact on users/vendors, consider keeping the concept with the oldest effective date as this is likely to have had the most usage. Where the existing FSN for the older concept does not comply with current naming conventions, it may be possible to assign a newer and compliant FSN "in place" ie without inactivating the concept. However, if the newer concept already carries the ideal, compliant FSN then it will not be possible to also assign that same FSN to the older concept, and so there may be no other option than to inactivate the older concept in favour of the newer, with its better FSN.
  5. Where both concepts have subtypes ensure that they are all present as subtypes of the active concept.
  6. Where the modelling indicates significant semantic difference establish whether these differences impact other concepts and analytics. If there is doubt consider using ambiguous as the inactivation reason.
  7. Question: Where the FSN is the same but the semantic tags are: disorder and finding, procedure and regime/therapy and finding and situation is it acceptable to call these true duplicates?

Examples

Simple Example

145857006 Soft tissue X-ray abnormal (situation)
SAME_AS
168711005 Soft tissue X-ray abnormal (finding)
235998001 Perinephric abscess (disorder)
SAME_AS
80640009 Perirenal abscess (disorder)
Complex Example
136852007 Computer operator (occupation)
SAME_AS
8651002 Electronic computer operator (occupation)
232141000 Cycloplegic paralysis of accommodation (finding)
SAME_AS
68158006 Cycloplegia (disorder)
Erroneous Examples
312186009 L-Phenylalanine (substance)
SAME_AS
63004003 Phenylalanine (substance)
274374000 Endoscopic surgical procedure (procedure)
SAME_AS
363687006 Endoscopic procedure (procedure)
156240002 Primary postpartum haemorrhage (disorder)
SAME_AS
27214003 Atonic postpartum hemorrhage (disorder)

Impact

  • Authors
  • Requirement to establish true semantic equivalence
  • Ensure that the active concept has an FSN which adheres to editorial guidance
  • Ensure that all of the concepts descriptions are appropriately assigned/reassigned or inactivated
  • Release Management Team

  • Developers
  • Review and update Refsets and ECL queries
  • Where the developer makes extensive use of ECL, identify the impact of the changed modelling of the active component and loss of the concept implied by the modelling of the inactivated concept
  • End Users/NRC
  • Generally minimal, when the inactivated concept points to the duplicate.
  • The change may require terminology merging or remapping of local Refsets.
  • Recognise that any loss of descriptions which were deemed non-synonymous may impact accessibility
  • Reinstate within the local edition descriptions which were inactivated because they were deemed to be region specific

Potential improvement


No changes proposed

Supporting resources


SNOMED CT Editorial Guide guidance on creation of the Fully Specified Name<comment>

Metrics for historical inactivations

Usage over time 20020131 to 20200731 - 38,862

Most recent usage:

  • 20200731 - 312
  • 20200131 - 274
  • 20190731 - 330
  • 20190131 - 357
Link to table

Review of historical inactivations

100 inactivations reviewed

Error rate

  • No labels

9 Comments

  1. I think that the 4th item in Narrative description section, "Where an organism has multiple equivalent names e.g. common and scientific name", may need a bit of clarification:

    • The common name should not be applicable to another organism(s). If a common name applies to more than one organism, the inactivation reason should be different (as stated in Ambiguous Component).
    • For scientific names, it is only applicable when a single species is reclassified as another species. If a single species is reclassified as multiple species, the inactivation reason would be different (see current guidelines for organism name change: https://confluence.ihtsdotools.org/display/public/WIPEG/Organism+Naming+Conventions)

    Unless of course these scenarios are implied by the word "equivalent"?

     Thanks, Farzaneh


  2. Comment on 'Known issues' section (is that the right heading for that sections). Consideration also needs to be given to:

    • the fact older FSN's may not align to current naming conventions
    • membership of a reference set

    FSN the same, semantic tags differ question: Finding - Disorders, Procedures - Regime/Therapy - yes, reasonable to accept as duplicates. Finding - Situations  - pragmatically yes I expect in a number of cases. 

    1. Thanks Cathy. I've expanded point 4 of the "known issues" section to cover what I think was your concern wrt older FSNs.

      1. Jeremy re: the point 4 above "newer conceptalreadycarries the ideal, compliant FSN then it will not be possible to also assign that same FSN to the older concept, and so there may be no other option than to inactivate the older concept in favour of the newer, with its better FSN"
        Is this a limitation of tooling or editorial policy? Assuming tooling, If the tool throws a "duplicate FSN" error, will that still occur if the new concept is retired before the original concepts FSN change?
        (duplicate FSN shouldn't be thrown for inactive concepts, all the existing inactive concepts cause havoc if true)

        1. Matt Cordell I think you're right that it may be mainly a tooling limitation.

          As you say, there are plenty of historical examples of sets of concepts sharing exactly the same FSN, but where only one code within the set remains active. And I think you may be right that the letter of current editorial policy is to prohibit only more than one active concept simultaneously sharing the same FSN.

          But I've certainly seen tooling in the past that would block creating a new active concept if its FSN would be shared with one or more inactive codes, even though not also concurrently also with any other already existing active code. The only permitted authoring option was to reanimate one of the inactive concepts.

  3. I'd consider this Reason/Association the most "reliable" of the lot, when managing longitudinal data.
    Saying two concepts are "the same", is a more confident declaration than "possibly equivalent to".

  4. Matt Cordell and Jeremy Rogers ,

    The current tooling prevents the creation of a new concept with the same FSN as an existing, but inactive concept OR another active concept.  In the former case the old concept is reactivated and remodeled to fit the needs.  As this is a relatively recent development, there are, as Jeremy suggests, a fair amount of duplicate FSNs, sometimes with one active and one inactive and sometimes with both inactive.  

    1. Thanks Jim. We had the exact same issue in our tooling, which had some very messy workarounds until we modified the restriction only consider active concepts.

      Unfortunately, it seems there's a conflict here with the logic for "ambiguous" concepts...
      There's the argument that "FSN:Model mismatch" results in a concept inactivation, as ambiguous.

      If the quality of the FSN is editorial compliant. Do you need to fudge the FSN for the new concept?
      And "the old concept is reactivated and remodelled to fit the needs" - suggests the concept could be remodelled anyway...

      I still view the FSN is the "reference/standard". If a stated/primitive ancestor is modelled incorrectly, not only is the FSN blameless, but so to the concept.
      AFAIK, Most (if not all?) implementations are using the inferred form when "using the modelling". (ie. general implementations aren't making a distinction between inferred/stated modelling)

      All queries are already at the mercy of modelling changes.
      e.g. There were 432 subtypes of 118731007|Procedure on facial bone| in January 2020. But only 337 in July 2020. Those missing 95 concepts, are all still active...

  5. Matt Cordell,

    It makes sense to use the inferred models when doing implementations as the proximal primitive parent modeling patterns result in a pretty flat list.  I agree that problems "up the chain" can make a subtype concept look "incorrect" when in fact it is, as you say, blameless.  Much of this resulted from a rather strict interpretation of "substantial change" in the past, where any change to modeling or terming resulted in a new concept.  This is where we ended up with inactive concepts that had identical FSNs to active ones.  There are also issues with inactive FSNs having been <incorrectly> added to another concept as a synonym.  We have relaxed the interpretation of "change of meaning" so that we now do more changes to concepts without inactivation and replacement, otherwise the QI project would have resulted in tens of thousands of replacements. 

    As for the issue with procedures, as we have not done much batch work on the procedures hierarchy, I would expect that the changes you see are a product of the anatomy work.  But would have to look at the "missing" concepts to make sure of that.