SNOMED CT URI Space
URIs for Editions and Versions
Background
A SNOMED CT edition logically consists of the complete set of members of one or more . Since the module dependency reference set (MDRS) tracks the explicit dependencies between a version of a module and all the versioned modules it depends on, a is a natural identifier for an edition. When combined with a timestamp corresponding to a sourceEffectiveTime appearing in the MDRS, the module identifier can unambiguously identify a version of an edition.
Form
The URIs that identify unversioned editions (i.e. editions) and versioned editions (i.e. versions) take the following respective forms:
http://snomed.info/sct/{sctid}
http://snomed.info/sct/{sctid}/version/{timestamp}
Note that while it would be possible to extend this pattern to support multiple root modules, each with its own sourceEffectiveTime, this would introduce non-trivial complexities. For example, the modules they each depend upon may themselves overlap but have different versions (targetEffectiveTime) in which case the implied content would be inconsistent.
Examples
The following table shows some examples of URIs for editions and versions.
Table 2.1: Examples
SNOMED CT International Edition
http://snomed.info/sct/900000000000207008
SNOMED CT International Edition, 20130731
http://snomed.info/sct/900000000000207008/version/20130731
SNOMED CT-AU
http://snomed.info/sct/32506021000036107
SNOMED CT-AU, 31 May 2013
http://snomed.info/sct/32506021000036107/version/20130531
SNOMED CT-AU, 30 Nov 2012
http://snomed.info/sct/32506021000036107/version/20121130
SNOMED CT-SE
http://snomed.info/sct/45991000052106
For a more extensive list of SNOMED CT edition URI examples, please refer to the Edition URI Examples.
URIs for Components and Reference Set Members
Background
A SNOMED CT component is a concept, description or relationship that conforms with the SNOMED CT logical model. All SNOMED CT components are identified by an SCTID.
A SNOMED CT reference set member is a uniquely identified row of a reference set. All reference set members are identified by a UUID (rather than an SCTID).
Form
URIs for components, based on the corresponding SCTID, take the following form:
http://snomed.info/id/{sctid}
URIs for members of a Reference Set, based on the corresponding UUID, take the following form:
http://snomed.info/id/{uuid}
For simplicity this document refers to either of the above forms as a component URI.
Examples
The following table shows some examples of URIs for components and reference set members.
Table 2.2: Examples
The concept 74400008 | Appendicitis|
http://snomed.info/id/74400008
The description "Appendicitis" with id=123558018
http://snomed.info/id/123558018
The relationship 74400008 | Appendicitis| 363698007 | Finding site| 66754008 | Appendix structure|
http://snomed.info/id/859910029
The reference set member that defines "Appendicitis" as preferred in the en-US language reference set
http://snomed.info/id/7c0d7d61-c571-5bf9-9329-fdbfee8747d0
Edition and Version-Relative Component URIs
Background
Edition and version-relative URIs are useful to identify characteristics of components and reference set members that are specific to an edition or version. Conceptually, they build on the idea of what one resource (e.g. the version) says about another (e.g. a component).
Form
Edition-relative URIs for components take the following form:
http://snomed.info/sct/{moduleid}/id/{sctid}
Version-relative URIs for components take the following form:
http://snomed.info/sct/{moduleid}/version/{time}/id/{sctid}
Edition-relative URIs for reference set members take the following form:
http://snomed.info/sct/{moduleid}/id/{uuid}
Version-relative URIs for reference set members take the following form:
http://snomed.info/sct/{moduleid}/version/{time}/id/{uuid}
Examples
The following table shows some examples of URIs for components in a specific SNOMED CT versioned edition.
Table 2.3: Examples
The concept 74400008 | Appendicitis| in SNOMED CT international edition, 31 January 2013
http://snomed.info/sct/900000000000207008/version/20130131/id/74400008
The concept 2771000032106 | Open reduction of fracture of ankle (procedure)| from the 20160930 Australian edition
http://snomed.info/sct/32506021000036107/version/20160930/id/2771000032106
The November 30th 2012 version of the Australian 'Emergency department findings in presenting problem reference set'
http://snomed.info/sct/32506021000036107/version/20121130/id/32570501000036104
The reference set member that defines "Appendicitis" as preferred in the international en-US language reference set, 31 January 2017
http://snomed.info/sct/900000000000207008/version/20170131/id/7c0d7d61-c571-5bf9-9329-fdbfee8747d0
URIs for Modules
Background
The URIs for Editions and Versions section defined URIs for editions and versioned editions. These URIs identify the contents of a Module plus all of the Modules it depends on (based on the module version dependencies). However, it is sometimes necessary to simply identify the contents of a single specified module only.
Form
URIs for modules come in two forms. To identify the contents of a module, independent of any particular point in time, the following form is used:
http://snomed.info/module/{sctid}
To identify the contents of a module at a particular point in time, the following form is used:
http://snomed.info/module/{sctid}/time/{timestamp}
Note that the timestamp used above is merely referencing a point in time, and does not need to coincide with a version release date.
Examples
The following table shows some examples of URIs for modules.
Table 2.4-1: Examples
The SNOMED International core module
http://snomed.info/module/900000000000207008
The SNOMED International core module at March 15 2017
http://snomed.info/module/900000000000207008/time/20170315
URIs for Properties
Background
There are a number of additional features of SNOMED CT that do not have SCTIDs or UUIDs, but which still need to be identified. URIs are required to identify these additional features to support use cases such as representing SNOMED CT in OWL (e.g. to identify certain annotations) and referring to SNOMED CT properties (e.g. characteristicTypeId) from other standards (e.g. CTS2). To address these requirements we define a general set of URIs identifying the RF2-based properties of components.
Form
The URI space for these properties follows the pattern:
http://snomed.info/field/{tableName}.{fieldName}
Valid table names include those described as possible values for the content type element in the File Naming Conventions for RF2. Note, these URIs identify the property itself, not the value or values that may be associated with the property.
Examples
Table 2.6: Examples of URIs for SNOMED CT RF2 properties.
The definitionSatusId property in the RF2 concept file
http://snomed.info/field/concept.definitionStatusId
The characteristicTypeId property in the RF2 relationship file
http://snomed.info/field/relationship.characteristicTypeId
The referencedComponentId property in a RF2 simple reference set file
http://snomed.info/field/refset.referencedComponentId
The mapTarget property in a RF2 simple map reference set file
http://snomed.info/field/sRefset.mapTarget
URIs for SNOMED Resources
Background
SNOMED CT can be combined with complementary eHealth standards to create SNOMED-specific resources. When these resources are owned by SNOMED International, they may require a URI. For example, the HL7 FHIR Specification uses URIs for various entities, including FHIR resources, profiles and implementation guides. FHIR profiles, which define recommended SNOMED CT bindings, and FHIR implementation guides, which document best practice for implementing a FHIR system using SNOMED CT, require unique SNOMED CT URIs. Similarly, SNOMED-specific modelling resources using other eHealth standards may also require unique SNOMED CT URIs.
Form
The specific URI format used to identify a SNOMED-specific resource will depend on the requirements of the relevant eHealth standard. However, they will all follow the general format:
http://snomed.info/{eHealthStandard}/{eHealthStandardSpecificURIFormat}\
For example, HL7 FHIR modelling resources will use the format:
http://snomed.info/fhir/{resourceType}/{resourceName} \
with resource types including:
StructureDefinition
ImplementationGuide
Other standard-specific formats will be defined as required.
Examples
The following table shows some examples of URIs for FHIR modelling resources.
Table 2.7: Examples
FHIR Profile
http://snomed.info/fhir/StructureDefinition/condition-with-snomed
FHIR Implementation Guide
http://snomed.info/fhir/ImplementationGuide/snomed-ig
Comparing URIs for Equality of Reference
Any two URIs from the http://snomed.info/ URI space identify the same thing if, after syntax-based normalisation as described in section 6.2.2 of , they are equal when treated as character strings. The syntax-based normalisation includes case normalization, percent-encoding normalization, and removal of dot-segments. Scheme-based and protocol-based normalisation should not be required since any URIs that would be affected by them (e.g. by including explicit port numbers or trailing slashes) fall outside of the URI space defined by the standard.
URIs for Unpublished Content
Background
The URI formats, defined in the previous sections of this document, can be used to identify SNOMED CT content that has been officially published, and may therefore be stored in an Electronic Health Record and exchanged between clinical systems. However, during the process of creating a SNOMED CT release, concepts may exist in a pre-published state. These concepts are considered to be "work in progress" and subject to change or removal, prior to their official publication. For a variety of reasons (including testing, early adoption etc), users may require a way to identify this . Note that the terminology or code system for SNOMED CT will always be specified as http://snomed.info/sct, even when the version of this terminology is unpublished, e.g. http://snomed.info/xsct/900000000000207008
SNOMED International already uses the X (eXperimental) indicator for alpha & beta releases of International and national editions of SNOMED CT, eg xSnomedCT_BelgiumExtensionRF2_PREPRODUCTION_20210315T120000Z/Snapshot/Terminology/xsct2_Concept_Snapshot_BE1000172_20210315.txt.
This additional 'x' is added to make it clear that the contents have not been "officially" published.
Form
Unpublished Editions and Versions
The URIs that identify unpublished editions (i.e. the current build) and unpublished versioned editions (i.e. versions) take the following respective forms:
http://snomed.info/xsct/{moduleId}
http://snomed.info/xsct/{moduleId}/version/{timestamp}
Unpublished SNOMED CT Components
The URIs that identify components relative to an unpublished edition or version take the following respective forms:
http://snomed.info/xsct/{moduleId}/id/{sctId}
http://snomed.info/xsct/{moduleId}/version/{timestamp}/id/{sctId}
Examples
The following table shows some examples of URIs for unpublished artefacts.
Table 2.8: Examples
SNOMED CT International Edition, current build
http://snomed.info/xsct/900000000000207008
SNOMED CT International Edition, 20220131 beta release
http://snomed.info/xsct/900000000000207008/version/20220131
The concept 1163215007 | Pressure injury| in the current build of the SNOMED CT International Edition
http://snomed.info/xsct/900000000000207008/id/1163215007
The concept 1163215007 | Pressure injury| in the 20220131 beta release of the SNOMED CT International Edition
http://snomed.info/xsct/900000000000207008/version/20220131/id/1163215007
For a more extensive list of SNOMED CT edition URI examples, please refer to Edition URI Examples
Last updated