SNOMED on FHIR

Page tree

While deprecated, codes for antecedent SNOMED versions (SNOP, SNOMED, SNOMED II, SNOMED International (3.x), and SNOMED RT) exist in records. For this legacy data to be accurately and unambiguously communicated, URIs need to be defined for these code systems, and http://snomed.info/sct is not approproptiate.

An initial proposal of http://snomed.info/srt has been made for SNOMED RT.

This page is intended to capture opinion and discussion of

  • what the URIs should be
  • whether SNOMED International should define/own them
  • where they should be specified
  • any caveats for their use (e.g. only legacy data, no new data...although it can't be enforced)

Please add your comments and thoughts below with the intent of working up a position for SI to consider.

Grahame: The FHIR community prefers a different system than http://snomed.info/sct (which is what the specification currently says), as it makes it easier to differentiate the legacy identifiers. The FHIR Community also prefers that something exist at http://snomed.info/srt (if chosen) that is able to (a) describe what codes are valid and (b) provide some search or enumeration of all valid codes 

Links to Community discussion:

Response from Linda Bird

I don't think we should be changing the SNOMED URI standard to expand its scope to non-SNOMED CT code systems (such as SNOMED RT or SNOMED 3.x), which are currently explicitly excluded from scope. These old SNOMED code systems were formally deprecated last year and are now no longer supported - so it would be a bit odd to decide now to expand this standard to formally support their use. The decision to deprecate this code system was made by the GA, and had the clinical support of the World Association of Societies of Pathology and Laboratory Medicine. My understanding is that the deprecation policy places the obligation on the sender to use the simple map we have provided to map the codes to SNOMED CT. Any move from us that may be seen to be contrary to this decision may be questioned.

In addition, the SNOMED URI standard has been specifically designed to identify SNOMED CT artefacts, and therefore the pattern http://snomed.info/id/{sctid} is specifically used for sctids. The pattern http://snomed.info/sct/{sctid} identifies a specific SNOMED CT edition .... and therefore it would not be consistent to use http://snomed.info/srt/{srtid} to identify a SNOMED RT id.

And finally, SNOMED RT identifiers (published in January 2001) are SCTIDs, and were re-released in the January 2002 version of SNOMED CT - so they can actually be treated just like SNOMED CT ids, because they are valid SCTIDs in current SNOMED CT release (even though some of them may now be inactive). The only old SNOMED identifiers that cannot be treated like SNOMED CT ids are the SNOMED 3.x identifiers ... because these are a different style of identifier. The SNOMED RT release included a column containing these legacy SNOMED 3.x identifiers (much like SNOMED CT provides a map to these) ... but these are not SNOMED RT identifiers. Also, all concepts that had a SNOMED 3.x identifier (with the exceptions that follow) also have a SNOMED CT identifier, so this map should be reasonably simple. The only exceptions to this are (1) There were some concepts in SNOMED 3.x (and possibly SNOMED RT) that were removed by CAP due to an I.P. challenge from another code system provider) (2) Some local/national codes may have been added using the SNOMED 3.x format (e.g. additions were made in the French translation of SNOMED 3.x).

I notice on this page - http://build.fhir.org/terminologies-systems.html - that FHIR uses hl7/fhir URIs for a range of different code systems that don't have URIs - e.g. http://hl7.org/fhir/sid/icpc-2 and http://hl7.org/fhir/sid/ndc. Perhaps the same can be done for SNOMED 3.x and other deprecated code systems? For example http://hl7.org/fhir/sid/s3x. The only reason that this should be necessary for SNOMED RT is if an implementation uses SNOMED RT extension codes ... but if so, then something like http://hl7.org/fhir/sid/srt could be used. The documentation should also clearly indicate the deprecated status of these code systems. It may also be useful to add something to the 'Using SNOMED CT with FHIR' (now https://terminology.hl7.org/SNOMEDCT.html ) page on the FHIR website that explains some of this history, including the deprecated nature of these code systems.

Response from SNOMED International

"IHTSDO and its Members propose to stop issuing (directly or indirectly) licenses for the use of antecedent versions including SNOP, SNOMED, SNOMED II, SNOMED International (3.x), and SNOMED RT as of April 26th 2017 except for research purposes and to enable the interpretation of historical data captured using antecedent versions."   (source) 

This text states the position of SNOMED International as of 26 April 2017. Therefore SNOMED International cannot support including a URI in our specification to accommodate continued use of unlicensed, antecedent versions of SNOMED CT. Those who choose to send legacy SNOMED data have an obligation to provide a link to the appropriate SNOMED CT concept using the simple map provided by SNOMED International.

SNOMED International does not support further use of these antecedent versions of SNOMED CT in any value set or specification. If HL7 International finds it is necessary to allow these legacy SNOMED identifiers to be exchanged in FHIR resources, then a FHIR-specific URI should be created for this purpose. At the same time, it should be made clear that antecedent versions of SNOMED should not be used in any FHIR implementation that supports current data requirements.



  • No labels

9 Comments

  1. Michael Lawley

    From the above we can conclude that "SNOMED 3.x" is a separate code system (also SNOP, SNOMED, and SNOMED II).  Even though they're withdrawn, there is existing data that uses them and thus there's a requirement to identify the code system.  Whether these are in a snomed.info namespace or an hl7.org namespace seems largely immaterial. Agreed, it does seem to make sense to reference them (and the deprecated status) on the 'Using SNOMED CT with FHIR' page.  This is good.

    However, the above also indicates that there is no separate "SNOMED RT" code system since all the "RT codes" are actually valid SCTIDs.

    But, these are officially "withdrawn" by SNOMED International (https://www.snomed.org/news-articles/timetable-for-the-withdrawal-of-legacy-snomed-codes) which leaves me in a quandary.  How should I support these old codes in our terminology server?

    Specifically, here are some issues that need to be dealt with:

    1. What should be the response to GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=DD-1302A
    2. What should be the response to GET [base]/CodeSystem/$validate-code?url=http://snomed.info/sct&code=DD-1302A
    3. What should be the response to GET [base]/ValueSet/$validate-code?system=http://snomed.info/sct&code=DD-1302A&url=http://snomed.info/sct?fhir_vs
    4. Should DD-1302A be in the expansion of GET [base]/ValueSet/$expand?system=http://snomed.info/sct?fhir_vs (i.e. "All SNOMED concepts")
    5. What should be the response to GET [base]/CodeSystem/$subsumes?system=http://snomed.info/sct&codeA=DD-1302A&codeB=447395005 where 447395005 |Closed fracture of fibula| is the corresponding code to DD-1302A as per the last Identifier Reference Set der2_sRefset_SimpleMapFull_INT_20170731.txt


  2. Rob Hausam

    The same issues will also occur with the CTV3 IDs (and the same answers/solutions should work).  From what I'm gathering from this, both of these ID sets would be invalid codes in the http://snomed.info/sct namespace.  But if they are to be referenced at all, then they need to be in some code system namespace.  If SNOMED International doesn't want to define anything for this, then FHIR can do it, and maybe we should proceed with that approach.  We should also be able to provide concept maps (implicit or explicit) for them from the available refsets.

    1. Michael Lawley

      I don't think they are the same, or I am very confused as to the naming of these things.

      If I look at the old RF1 Concepts file, I see something like:

      CONCEPTID CONCEPTSTATUS FULLYSPECIFIEDNAME                  CTV3ID SNOMEDID ISPRIMITIVE
      1083004   0             Salmonella Wyldegreen (organism)    Xa8q1  L-19302  1
      100005    1             SNOMED RT Concept (special concept) XU006  G-3000   1

      My understanding is that the CTV3ID codes are actually READ version 3 codes, and not considered to be SNOMED CT codes.  For these we use a URI for a distinct code system, and probably HL7 needs to define it.

      However, there's also the column labelled SNOMEDID above, which contains the SNOMED RT codes.  Linda Bird says above:

      And finally, SNOMED RT identifiers (published in January 2001) are SCTIDs, and were re-released in the January 2002 version of SNOMED CT - so they can actually be treated just like SNOMED CT ids.

      This seems to contradict the opening sentence: "...non-SNOMED CT code systems (such as SNOMED RT or SNOMED 3.x)", but is what leads me to ask the five questions above.


      1. Daniel Karlsson

        The L-19302 code is a SNOMED <= 3.x vide, isn’t it?

  3. David Markwell

    Just to be absolutely clear about what the antecedent codes refer to (I was there at the time!!)

    CTV3ID :

    UK NHS Clinical Terms Version 3 (Read Code Version 2  and Version 3 codes are are all included here but not Read Code Version 1 (4-byte codes). These are NOT SNOMED Code in any shape or form. They were included for transitional purposes.

    SNOMEDID :

    SNOMED Version 3.x codes as Daniel says. These are therefore formally deprecated since last year so whether or although they were SNOMED codes, they are no longer sanctioned for use.

    There is an understandable point of  confusion about how these relate to SNOMED RT which I can also clear up here:

    This style of codes were included in SNOMED RT ... but so were the SNOMED CT ID's. Strictly speaking the SCTIDs had primacy in SNOMED RT (remember SNOMED RT was released just 1 year before the SNOMED CT and well into the design process. It like SNOMED CT RF1 retained the alpha-numeric codes only for transition.

    For the definitive reference on this I attach the SNOMED RT specification from November 2000 (3 months before the first and only release of SNOMED RT). See Table 3.7.1.5. SRT_CONCEPTS Table Format on page 21. Note the relationships in SNOMED RT also used the SCTID to refer to concepts. See also the discussion on identifiers on page 16.

    Old Format Identifiers Issues for Transitional Use

    To support those unable to accomodate 64-bit integers (or 18 digit strings) the SNOMEDID (and CTV3ID) were included in the files but in addition further identifiers in these formats were added for new concepts add to SNOMED CT. So some identifiers in the SnomedID and CTV3!D columns were not in the released versions of those earlier code systems.

    That process was documented from the outset as being for a limited time only. It was formally abandoned with the RF2 release but the SnomedID and CTV3ID codes in Simple Map Refsets for historical purposes. These were never documented as being supported identifiers in their own right but were useful proxies for the SCTIDs for use in legacy systems. Deprecation of antecedent versions of SNOMED means that use of these identifiers is similarly deprecated ... though the maps for support there continued interpretation in historical records.

    1. Michael Lawley

      Fantastic, thanks David & Daniel, I clearly was confused about the naming.  The crucial piece of information I was missing (not being there at the time :-) was that SNOMED RT = Union of SCTIDs and V3.x codes.

      Bringing this back around to the source questions from the FHIR community that turn on "what code system URI should be used", would it be safe to say that for SCTIDs, it is always http://snomed.info/sct for CTV3IDs it is http://hl7.org/fhir/sid/ctv3 (or some such, as chosen by HL7), and for SNOMED Version 3.x it is http://hl7.org/fhir/sid/sv3 (or some such)?

      Then, if one really wants to be able to say that a code was chosen specifically from the only ever version SNOMED RT, a ValueSet could be defined that is the union of the code systems http://hl7.org/fhir/sid/ctv3 and http://hl7.org/fhir/sid/sv3?

      1. Rob Hausam

        The CTV3IDs didn't get introduced into SNOMED until SNOMED CT, so the union of the code systems http://hl7.org/fhir/sid/ctv3 and http://hl7.org/fhir/sid/sv3 wouldn't represent SNOMED RT.  And, as David mentioned, the SCTID was the primary identifier both for SNOMED RT and then subsequently for SNOMED CT.  I don't think there is a need now to have a representation of SNOMED RT independently, though, because there would have been minimal, if any, use of it for "real" clinical data during the brief period that it was officially released prior to SNOMED CT, and then all of its SCTIDs were incorporated directly into SNOMED CT and can still be referenced using the http://snomed.info/sct namespace.  Only if someone comes forward with a need for representing the content exactly as it was published in the specific SNOMED RT "version" would we need to do anything about this - and I think that is pretty unlikely.  

  4. Rob Hausam

    Thanks for providing all of the details on that, David.  That's as I had understood it, but fully spelling it out more completely is definitely helpful.  I had mentioned the CTV3 codes because in RF1 new CTV3 codes were being created for each new SCTID, but it's a good point that they never were actually part of "SNOMED" themselves - so it makes sense that they would be off the table for this discussion.  So that still leaves us with the question of how to represent the legacy, now deprecated SNOMEDIDs whenever it still is appropriate to reference them (assuming that sometimes for existing data it still can be appropriate to do so?).  I'm wondering how much more energy we want to put into this, since no one should be using the SNOMEDIDs for any new data, and the need to exchange the existing data in its original format I would expect would be fairly minimal at this point?  Maybe if there is enough of a use case for doing it we can just let HL7/FHIR manage it, as Linda suggested.

  5. Jay Lyle

    Update: the Using SNOMED CT with FHIR page is now here: https://terminology.hl7.org/SNOMEDCT.html