SNOMED CT URI Space

• URIs for Editions and Versions

• URIs for Components and Reference Set Members

• Edition and Version-Relative Component URIs

A SNOMED CT edition logically consists of the complete set of members of one or more module. 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 module identifier 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.

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.

The following table shows some examples of URIs for editions and versions.

Table 2.1: Examples

For a more extensive list of SNOMED CT edition URI examples, please refer to the .

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).

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.

The following table shows some examples of URIs for components and reference set members.

Table 2.2: Examples

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).

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}

The following table shows some examples of URIs for components in a specific SNOMED CT versioned edition.

Table 2.3: Examples

The 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.

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.

The following table shows some examples of URIs for modules.

Table 2.4-1: Examples

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.

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.

Table 2.6: Examples of URIs for SNOMED CT RF2 properties.

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

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.

The following table shows some examples of URIs for FHIR modelling resources.

Table 2.7: Examples

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 IETF RFC3986 Uniform Resource Identifier (URI): Generic Syntax , 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.

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 unpublished content. 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.

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}

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}

The following table shows some examples of URIs for unpublished artefacts.

Table 2.8: Examples

For a more extensive list of SNOMED CT edition URI examples, please refer to