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

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