ConceptId churn and FSN changes..

I've just started assisting a hospital with the maintenance of one of their refsets and one of the first things to jump out was was the retirement of 39355002 Hypernatremia (disorder)

This was retired as Ambiguous, and MAY BE associated with two new concepts 771115008 Hypernatremia (disorder) & 771113001 Sodium retention (disorder).

In this case, it seems that because the original concept had a synonym of "Sodium retention" it was retired (Jan 2019)...

Matt Cordell

I sympathize with your frustration and in some ways also empathize as we have been challenged for a long time over the balance between inactivation vs. replacement when changes are made to concepts.  The notion of what is a "substantive" change vs. what is a "significant" change WRT meaning of a concept has many opinions.  The historical situation of implied (i.e., contextual) meaning in existing concepts and inconsistency in FSN terming are also factors that must be considered.  I think it might be  useful to get an idea from users (i.e. CMAG) about what would be the types of changes to FSNs that are acceptable without replacement.  The issue with non-precise FSNs to date has been the variability of interpretation by users, which has lead to the recognition that we need specific and explicit FSNs.  

Suggestions from a user perspective to reduce churn yet continue improving the quality and  consistency of the terminology would be appreciated.

Matt/Jim, I have also had this problem in the past... and it might be a little different depending on the implications of the change to the name, but for me it was a bit easier if it involved downstream consequences (like a change to an ICD code map, etc.). In the past that anytime a concept was split, the original concept was retired in favor of the two (or more) new concepts, but if one of the descriptions is retired, then I would be less likely to retire the original concept.

Goodness me. Hello all, rarely comment on this work but Matt's observations raise some concerns for me. I don't want to sound heretical and I know words are critical, but I would encourage SNOMED to strongly consider (the assumed, perhaps tested?) current usage rates for concepts when making changes and not be overly focused on disambiguating the meaning of the words in the FSN and synonyms. I'd suspect that many of the concept changes made could have instead been FSN name changes which I suspect are more easily accepted by systems. I see many examples above that I think fall into this camp, such as 248540002|Constantly crying baby (finding)        Ambiguous component POSSIBLY EQUIVALENT TO                766877008|Constantly crying infant (finding). 

I suspect the specific Hypernatremia example might be thought to fail this test until we consider that the condition/finding of "Sodium retention specifically not hypernatremia" recorded in a system using SNOMED CT is I suspect is rare. Therefore one could consider changing removing the synonym from a retained 39355002 Hypernatremia concept and make a new concept of 771113001 Sodium retention (disorder). I for one would push for an outcome such as this and therefore set a very high bar for the sort of retire/replace that seems to have occurred. 

Please set me straight if I've gotten confused on what actually happened.

Some of these are probably easier to understand if you see the context/QI item in which they were changed. For instance, 

212929004|Frostbite with tissue necrosis of arm (disorder)          Ambiguous component POSSIBLY EQUIVALENT TO                771449007|Frostbite with tissue necrosis of upper limb (disorder)|

SNOMED sometimes does and sometimes does not treat 'arm' as a separate entity (excluding the hand) of upper limb, so you couldn't rename all 'arm' concepts to 'upper extremity' without creating duplicates and a semantic change. Being consistent in how you treat them involves inactivating them all and replacing where necessary.

Changing semantic tags can be a headache for countries who think they've finished translation. I only found out last release that we didn't have a QA check on changing semantic tags and that in fact we need one... So I'm quite appreciative of 

35591002|Diastema of teeth (disorder) Erroneous component   REPLACED BY     734009000|Diastema of teeth (finding)|

as this is a change we would pick up on.

And last but not least, not all of these concepts were created because of the inactivation. For instance 

428570002|Vaccination for human papillomavirus (procedure)  Duplicate component    SAME AS                761841000|Administration of human papilloma virus vaccine (procedure)|

The creation of the latter predates the inactivation of the former by two years. Clearly one of them had to be inactivated, because they were duplicate. As the Netherlands is submitting 200 - 300 such requests per year as part of our translation process, I fear we are responsible for part of your troubles...

I do agree that concept inactivation and replacement should be avoided if possible, and that it should be (and is) possible to change the FSN if the changes are superficial. Are the rules for FSN changing vs. inactivation clear, and are they followed consistently? But I don't think we can judge whether it's being done too often based on a list of examples without the context, i.e. the terminologists' motivation for inactivating and replacing them.

Thanks Feikje, I agree on all accounts. The list above was just a random assortment of examples.

And don't worry about submitting the duplicates - We've submitted just as many too 

Consensus in NZ is that the guidance regarding which changes to an FSN require retiring the concept  is pretty clear in the Editorial guide and we agree with the distinctions drawn. It looks like some changes have been made without being necessary ? Perhaps consistency is the issue

(eg- changing semantic tags within the same top level hierarchy does not necessarily require inactivation of a concept

• Semantic tag type within a single top-level hierarchy

For example,

• • • A finding tag to a disorder tag
    • A procedure tag to a regime/therapy tag)

A summary of feedback from the UK:

It’s three things really, how much data actually exists in records, the clinical complexity/use of the concept and the nature of the association between old and new.

•  How much data
  • Bit obvious but if the data isn’t in EPRs, mainly it is not an issue (unless it’s a high level parent of a load of content that is). We know that 99.9% of data is covered by the same 10,000 or so codes, at least in primary care. Drugs/substances are probably more of an issue than clinical concepts I would think. Need to factor in the next thing though…
• Clinical Complexity
• Not just how ‘full’ the surrounding hierarchies are, but how complex the interactions between elements and what are they used for;  i.e. Have you just impacted someone’s carefully crafted clinical calculator  because you’ve replaced a central concept to the whole algorithm that was previously ‘definitely a thing’ with something which you are saying is only ‘possibly equivalent too’. Which brings us to…
• Nature of the associating
• Fundamentally everyone can live with ‘same as’ and shouldn’t care about those, so if they are 90% of the changes then fine, but if you are making 10,000 codes that were previously definite, now ‘possibly equivalent to’ you’ve just made a whole swathe of existing EPR data ambiguous. Some of the ones on that list are only ‘possibly the same as’ to a terminologist. How is Deep full thickness burn (disorder) not the same as Deep full thickness burn injury (disorder) For instance? OK, you could argue on editorial principles, but to an IT system they are the same thing surely, if these were “same as” that would help.

Canadian response uploaded.

Hi all,

What has become the consensus on this issue, namely changing the FSN in function of editorial guidelines, without inactivating the concept itself? 

We also just received a comment on a non-legitimized translation in our extension that still originated from the original FSN (which has since been modified, but was not noticed by us). 

Thank you, Katrien

Hi Jim, thank you! This answer clarifies a lot. Kind regards, Katrien