Stream: terminology
Topic: best practice when SNOMED codes are retired
Craig Newman (Mar 31 2020 at 15:14):
Is there a best practice to follow when a SNOMED term used in a published IG is retired and replaced by a new code? Should the IG be updated sooner rather than later to use the new code?
In our specific case, a CDA observation template in the published birth defect reporting CDA IG is using SNOMED code 249135009 (Meconium stained liquor (finding)) as the observation code value. However, it looks like this code has been retired. There is a new code (168092006 (Amniotic fluid -meconium stain (finding)) which seems to be appropriate to use instead.
Should the IG be updated via an errata or dot release ("sooner" update) or is it valid for an already published IG to continue to use a retired code (presumably this would be changed when the document is balloted next ("later" update))?
Robert McClure (Mar 31 2020 at 18:22):
@Craig Newman Is this code a result value or is it a identifying a template? Can you send the snippit where it's used in the IG? I ask because if it is used to identify a template we have a bigger issue I believe. Thankfully this is a rare situation but unfortunately that means we don't have a lot of experience on impacts with different approaches.
Craig Newman (Mar 31 2020 at 18:25):
@Robert McClure It's the Observation/code (not the value of the observation)
Robert McClure (Mar 31 2020 at 18:27):
SO the template is specific to this observation only, correct?
Craig Newman (Mar 31 2020 at 19:45):
yes
Peter Jordan (Mar 31 2020 at 19:46):
Assuming that the relevant binding in your IG relates to a specific edition, but not version, of SNOMED CT, there is a practical consideration here. SNOMED concepts, even when their status is changed in inactive, are still permanent and a deactivated concept may well have been used in an EHR. From that perspective, due consideration should be given before removing an inactive concept from a FHIR Profile or IG.
Robert McClure (Mar 31 2020 at 20:09):
@Craig Newman I think you might agree that changing the code so that it is using the current active code would be a breaking change and require an updated IG. Peter's solution of locking the IG to the version of SNOMED CT where that code is still active I think could be considered an errata, but I'd ask the CDA MB. Perhaps @Lisa Nelson can give some insight into how you could update this single template so that it uses the current code and what that might mean for IG versioning and any ballot implications. Implementers could then indicate which template ID they are using.
Peter Jordan (Mar 31 2020 at 20:58):
I'm not suggesting locking an IG to a specific version of SNOMED CT; in most cases that would be impractical - particularly as SI moves to continuous releases. Many/most IGs will assume the latest version of an edition and, while new versions of an IG may add concepts, the key point I'm trying to make is they should be careful about removing inactive concepts as that may break client implementations.
Robert McClure (Apr 01 2020 at 14:21):
Well I am suggesting they could at least lock a template to a specific version. I don't know if we can do that, but it makes sense here.
Craig Newman (Apr 01 2020 at 18:27):
I agree it's potentially a breaking change. At this point, we aren't aware of any production implementations. It would be interesting to know if a template could be locked to a specific version of SNOMED, especially when it's a hard coded value like this.
Rob Hausam (Apr 01 2020 at 18:47):
I'm not sure if there's anything particularly wrong with just leaving it as it is, with plans (as you indicated) to update it in the next release (whenever that may occur). As Peter said, regardless of its current status the concept is still present in subsequent versions of SNOMED CT and can legitimately be referenced. And since very likely you are not expecting, on either the sending or receiving side, to rely on the hierarchical relationships of the concept (which will have changed with inactivation), then I don't think there will be any consequences for simply following whatever update cycle you otherwise would plan to have.
Robert McClure (Apr 02 2020 at 02:46):
@Rob Hausam my concern with that agreeably simple approach is the code is not active. And if someone actually searches for a "meconium" code in the current code system they will be confused. @Craig Newman can you reach out to Lisa and ask if some of the approaches we suggested are possible?
Michael Lawley (Apr 02 2020 at 10:59):
If this is Observation.code, then it is a CodeableConcept which allows for multiple Codings. Unless you've got some profiling going on that says you can only have one SNOMED code, then you could just add in the replacement code and have both there.
Rob Hausam (Apr 02 2020 at 12:15):
Craig is referring to the CDA birth defect reporting IG
Michael Lawley (Apr 02 2020 at 12:49):
ah, CDA Observation, not FHIR - that's before my time :-)
Craig Newman (Apr 02 2020 at 16:21):
In an interesting Zulip experiment, I have cross-posted to the C-CDA stream to see if that elicits any responses. If it doesn't, I'll ping Lisa more directly...
Last updated: Apr 12 2022 at 19:14 UTC
