• Resolving SNOMED CT URIs

• URI Use Cases

Resolving SNOMED CT URIs

Overview

SNOMED CT URI Space defines a set of URI spaces used to identify various SNOMED CT resources, but it does not discuss resolving these URIs. The URIs in the standard use the http scheme and the domain name snomed.info, which SNOMED International owns. This means that SNOMED International is in control of whether or not these URIs, when treated as URLs and resolved, will result in a document being available, a 404 ("Not Found") error, or something else.

URIs Resolved by SNOMED International

SNOMED International resolves URIs for concepts from the SNOMED CT International Edition (of the form http://snomed.info/id/{SCTID}) to the public SNOMED CT browser.

URIs for modelling resources (as described in ) will, by default, be resolved to a HTML representation of the identified entity. To support machine-readability, the HTTP Accept header will be used to perform content negotiation. For example, the value "application/fhir+json" may be supplied to request a FHIR representation in JSON syntax. Following FHIR conventions, a suffix of "?_format=json" will be interpreted as equivalent to providing an Accept header of "application/fhir+json" with maximum priority. This is to facilitate access via web browsers where access to HTTP headers is not normally available.

A Release Centre or other service providers may also want to support the resolution of other URIs (e.g. those that identify resources that they maintain). A general approach to this involves deploying a resolving service with an endpoint URL such as

• http://myservice.example.com/

which is configured to resolve URLs that embed SNOMED CT URIs. Continuing the example, a URL of the following form

• (1) http://myservice.example.com/?uri=http://snomed.info/{...}

might be redirected with an HTTP response code of 303 to

• (2) http://myservice.example.com/snomed/{...}

which in turn resolves and returns an appropriate document. Conceptually, we can think of the original URL (1) as identifying what the MyService endpoint knows about the identified SNOMED CT resource, and the returned document, identified by the second URL (2), as being a representation of that knowledge.

What might such a document look like? Let us consider the example URL

• http://myservice.example.com/?uri=http://snomed.info/id/900000000000498005

The document ultimately returned by the service might be in JSON or XML or HTML or plain text format and contain information indicating that the SCTID is valid, and refers to a non-extension Concept. It may also indicate that the service is aware of one or more Editions or Versions in which this Concept is defined. It might further supply the Fully Specified Name for the Concept as given in the Version with the most recent effectiveTime. Note that the exact nature of what the service says about the Concept is up to the service itself. One service may offer a RESTful API that allows detailed querying down to the primitive/fully defined status of a versioned Concept, while another may return a representation of properties of a versioned Concept that then needs to be parsed to determine its primitive/fully defined status.

The OWL representation of SNOMED CT utilises URIs to identify concepts, the previously implicit grouping role, and the ontology itself (i.e., the set of axioms).

The old pattern used for Concepts was

• http://www.snomed.org/SCT_{sctid}

which is now replaced by

• http://snomed.info/id/{sctid}

The grouping role URI was

• http://www.snomed.org/RoleGroup

and is now

http://snomed.info/id/609096000

For the OWL XML representation, the URI was unspecified (the empty string), while for the OWL Functional Syntax representation the URI was (via RDF:about)

• http://www.snomed.org/sct.owl

and now includes explicit version information

• http://snomed.info/sct/{sctid}/version/{timestamp}

When representing SNOMED CT ontologies using OWL 2, both an ontologyURI and a versionURI should be included using the following forms, respectively :

• http://snomed.info/sct/{sctid}

• http://snomed.info/sct/{sctid}/version/{timestamp}

The CTS2 specification requires that all resources be identified using URIs. This section lists, where such a thing exists, SNOMED International standard URIs for the resources that require URIs in the CTS2 implementation. This omits URIs for things such as External Code Systems and Value Sets since they are outside the scope of the SNOMED CT URI Standard. Note, however, that a Reference Set is the SNOMED CT mechanism for identifying an arbitrary set of Concepts, which is analogous to a Value Set. Thus the Reference Set URI would be the appropriate thing to use as the Value Set identifier.

Traditionally, HL7 has used OIDs to identify Code Systems. The OID for SNOMED CT is 2.16.840.1.113883.6.96. This is the OID that should be used for all versions of SNOMED CT and related terminologies (such as the Australian Medicines Terminology) because it identifies the system, i.e., the set of rules for interpreting SCTIDs. Under these rules, any specific SCTID is either defined with respect to a particular SNOMED CT Version, or it is undefined (i.e. not included/mentioned in that version). Furthermore, any given SCTID always identifies the same thing in all versions in which it is defined.

The HL7 specification says: the interpretation of version strings is defined by the Code System (and not by HL7). This means we can use the URI for a Version (versioned Edition) as the version code:

http://snomed.info/sct/{sctid}/version/{timestamp}

For example, here is how an element of Data Type CD might appear in a CDA document with:

Fast Healthcare Interoperability Resources (FHIR™) defines a set of 'resources' to represent health and healthcare administration-related information. Rather than OIDs, FHIR uses URIs to identify code systems, typically accompanied by an associated version string. The code system is intended to characterise the set of valid codes, hence the recommended URI to use for this is:

http://snomed.info/sct

and the recommended string template to use for the associated version, substituting in the appropriate module sctid and effective time, is:

http://snomed.info/sct/{sctid}/version/{timestamp}

Background

SNOMED CT is a clinical terminology with global scope and a wide range of clinical specialties and requirements. As a result, SNOMED CT artefacts (including concepts, editions and versioned editions) are often referenced by clinical documents, health information standards, health record implementations, and a range of technical artefacts. To support unambiguous references to SNOMED CT resources, a standard approach to the identification of these resources is needed.

The existing SCTID specification allows SNOMED CT components to be identified across time. However, there are other views of a component that are also useful to identify, such as a concept within a specific SNOMED CT edition at a given point in time. Furthermore, there are other SNOMED CT artefacts, such as a SNOMED CT extension module with all its dependent modules, that do not have an SCTID but also need a consistent identification mechanism. This includes specific national editions, such as the Australian release or the Swedish translation.

A number of groups have emphasised the need to come up with an approach that addresses the broad needs of implementers and offers the opportunities for use of a ubiquitous range of services, using the URI (Uniform Resource Identifier) as a common factor in the interfaces. This document describes a URI space that is intended to meet these requirements, to avoid the proliferation of alternative conflicting schemes, and to evolve to meet additional requirements as they emerge.

The URI space defined in this document uses the syntax defined in IETF RFC6570 URI Templates . In addition, principles of good URI design were drawn from the W3C document Cool URIs for the Semantic Web, and Designing URI Sets for the UK Public Sector.

It should be further noted that, consistent with the advice of Tim Berners-Lee, the HTTP scheme is used for these URIs. Furthermore, to be consistent with the W3C's TAG resolution of ISSUE-14, since the URIs defined in this document identify real-world objects and not information resources, resolving these URIs should not result in an HTTP response code of 200 ("OK") but rather, if anything at all, result in an HTTP response code of 303 ("See Other") to redirect to another URI that identifies a representation of the identified component. The intuition here is that it is not possible to return a real-world object (e.g. "The Eiffel Tower"), but only a representation of it (a picture, a geo-location, a Wikipedia page, etc.). Similarly, it is only possible to return a representation of the identified SNOMED CT component, not the component itself. Further discussion around this issue can be found in Section 4.4 Choosing between 202 and Hash of the aforementioned W3C document Cool URIs for the Semantic Web

This document defines a standard format of URIs for identifying various SNOMED CT artefacts, including components and RF2 releases. This includes URIs for formally identifying the SNOMED CT international edition, national editions, and any specific versions thereof. It does not cover mechanisms or URIs for non-SNOMED CT code systems. Nor does it cover RF1-specific artefacts.

This document provides guidance on using the SNOMED CT URI standard in the context of key motivating use cases, including resolvability of the URIs.

This document provides a specification for the format and usage of SNOMED CT URIs. Such a URI might identify "A clinical idea to which a unique Concept Identifier has been assigned". However, it does not specify or standardise any aspect of the representation of these things. Appropriate representations may vary greatly depending on use-case requirements and services utilising the URIs specified here are free to make their own choices.

This specification relies on the semantics of SNOMED CT modules as defined in the Release Format 2 specification.

The intended audience of this document includes:

• Technical professionals who are involved in the development or implementation of terminology systems or healthcare information systems that use SNOMED CT, and

• Academics, researchers, and others who are using SNOMED CT in the context of OWL and other Semantic Web technologies.

This standard should be used when it is required to uniquely identify SNOMED CT concepts and other components in contexts where URIs are expected, or where the interpretation of a code as an SCTID may be ambiguous. It should also be used when an unambiguous interoperable (machine-readable) identifier for an edition (or a versioned edition) is required.

The following use cases have guided the specification detailed in this document:

1. The OWL representation of the stated form of SNOMED CT requires URIs to identify concepts and object properties (i.e. attributes),

2. The CTS2 specification requires all resources to be identified using URIs,

3. Within the HL7 community, there is a need for a consistent mechanism to identify the SNOMED CT code system and versions of SNOMED CT.

While a register of canonical names for each edition could be compiled and maintained, the module system developed for Release Format 2 already provides the required machinery to support unique naming of editions and, in conjunction with a timestamp, specific versions of an edition. Section 3.1.6 Module Identification from the says:

A moduleId field, assigned to each component, helps identify the origin of content and dependencies in a release. This enables Release Centres to compose a unified release from a number of different modules, yet still identify the origin of content within the release. For example, module ids may be used to differentiate SNOMED CT International content, Australian Medicines terminology and Pathology content within the Australian national release.

The module dependency reference set is used to track dependencies between versioned modules. Thus, by tracing the set of module dependencies from a specified versioned module, one is able to identify all the content relevant to that versioned module. Hence, a versioned module can be used to uniquely identify a versioned edition.

In this document, we use the terms Release, Edition, and Version with the following specific meanings:

• Release

  • A release is a concrete set of files that is published by a release centre (including SNOMED International). This may include any combination of RF2 files, whether full, snapshot, or delta, as well as documentation, cross-map files, alternate identifiers, and so forth. It may even be just the content that is additional to the SNOMED CT International Edition.

• Edition

This standard builds upon several other elements of the SNOMED CT ecosystem. In particular, its semantics are dependent on those of RF2 and the module and versioning mechanisms.

This document defines a standard set of identifiers in the form of URIs. To maintain the integrity of the associated URI space, SNOMED International retains ownership of the snomed.info DNS domain. While not a requirement of this specification, URIs defined by this specification, with respect to SNOMED CT core, are resolvable through services provided by SNOMED International.

It is important to understand that the URIs in this specification do not identify the representation of an entity, but rather identify the entity itself. covers this issue in more detail.

• 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

The SNOMED CT URI standard defines a standard format of URIs for identifying various SNOMED CT artefacts, including components and RF2-based releases. This includes standard URIs for formally identifying the SNOMED CT international edition, national editions, and any specific versions thereof. It does not cover URIs for non-SNOMED CT code systems. Nor does it cover RF1-specific artefacts.

This document provides guidance on using the SNOMED CT URI standard in the context of key motivating use cases, including resolvability of the URIs.

Provide Feedback