Page History

Purpose of Document

This document defines a standard format of URIs for identifying various SNOMED CT artefacts including Components and RF2-based releases. As a specific sub-case this includes URIs for formally identifying the SNOMED CT International Edition, extension Editions, and any specific Versions thereof. It does not cover mechanisms or URIs for non-SNOMED CT based terminologies, nor does it cover RF1-based artefacts.

It provides guidance on using the SNOMED CT URI Standard in the context of key motivating use-cases, including resolvability of the URIs.

Who Should Use This Standard?

The intended audience for this document includes both technical professionals who are involved in the development or implementation of terminology systems or healthcare information systems that use SNOMED CT, as well as academics, researchers, and others who are using SNOMED CT in the context of OWL and other Semantic Web technologies. This standard should be used in cases where 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 Version thereof) is required.

Scope of Document

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. Sub-sections 1.1.4 and 3.1 have additional references and advice on this matter.

This specification relies on the semantics of SNOMED CT modules as defined in the Release Format 2 specification. Please see Section _5.4 Release Format 2 – Core Component Guide

in the separate document "SNOMED CT^® Technical Implementation Guide" for additional information on this subject.

Motivating Factors

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 The existing SCTID specification allows for the identification of a component across time (i.e., the rows in a table that represent the state of that component at a series of points in time). However, this is but one, low level, view of a component. There are other views of a component that are also useful to be able to identify. These include, for example, a Concept including its Descriptions and Relationships in a given combination of SNOMED CT International and its Extensions, , such as a concept within a specific SNOMED CT edition at a given point in time. Furthermore certain things, such as an Extension , there are other SNOMED CT artefacts, such a SNOMED CT extension module with all its dependent modules, are not themselves components, that do not have an SCTID but also need a consistent identification mechanism. This not only includes the individual 6-monthly releases of the International version of SNOMED CT, but also specific national versions 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 others additional requirements as they emerge) to avoid the proliferation of alternative conflicting schemes.

The URI space defined in this document uses the syntax defined in _IETF RFC6570 URI Templates

...

, the http scheme is used for these URIs. Furthermore, to be consistent with the W3C's TAG resolution of of ISSUE-14

, since the URIs defined in this document identify _real-world objects and not  and not information resources, resolving these URIs should should not result  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.). In the same manner, it is only possible to return a representation of the identified SNOMED CT component, and not the component itself. Further discussion around this issue can be found in Section 4.4 4 Choosing between 202 and Hash

...

of the aforementioned W3C document _Cool URIs for the Semantic Web.

Purpose

...

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.

Scope

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. Sub-sections 1.1.4 and 3.1 have additional references and advice on this matter.

This specification relies on the semantics of SNOMED CT modules as defined in the Release Format 2 specification. Please see Section _5.4 Release Format 2 – Core Component Guide

in the separate document "SNOMED CT^® Technical Implementation Guide" for additional information on this subject.

Audience

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.

Use Cases

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 concepts and Object Properties (Attributes). It has historically used its own de facto URI space for this purpose, and has not directly addressed the issues of a URI to identify the ontology itself or versioning.object properties (i.e. attributes),
2. The CTS2 specification requires all Resources resources to be identified using URIs. It too has a proposed approach with a narrower scope, relative to SNOMED CT, than we have here.
3. Within the HL7 community there is a need for a consistent mechanism to identify "versions" the SNOMED CT code system and versions of SNOMED CT. An appropriate URI space could simply address this need in an extensible fashion.

While a register of canonical names for each Edition 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 editions and, in conjunction with a timestamp, specific versions of an Edition.Section _5.4edition. Section 3.1.4. Identification of Source Module

of the Technical Implementation Guide says the following6 Module Identification from the Release File Specification 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 ) moduleIdmodule, one is able to identify all the content relevant to that ( versioned ) moduleIdmodule. Hence, a ( versioned ) moduleId module can be used to uniquely identify a ( versioned ) Editionedition.

...

Releases, Editions and Versions

In this document we capitalise use the terms Release, Edition, and Version to indicate that they are being used with  with the following specific meanings:

Release

This A release is used to mean a concrete set of files that is published by a Release Centre release centre (including SNOMED International). This may include any combination of RF2 files, be they 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

An Edition edition is the complete logical or conceptual set of terminology componentcomponents, independent of any specific version. Examples include the SNOMED CT International Edition and the SNOMED CT-AU Edition.

Version

This is used to refer to the actual A version (also known as versioned edition) is the content of an Extensionextension's modules and all the modules upon which they depend, on a specific release date. That is, the SNOMED CT content that is conceptually managed within the versioning scheme of RF2 that is based on the moduleId and effectiveTime fields of the release files. In particular, this includes content that pertains specifically to the meaning of Concepts concepts and the contents of Reference Setsreference sets. Examples include the 20130731 version of the SNOMED CT International Edition and the 20130531 version of the SNOMED CT-AU Edition.

In some cases a Release comprises the union of two (or more) parts. For example, SNOMED CT with the addition of medication terminology. In the case that these parts are truly distinct, then distinct URIs can be used to identify them individually. In the case that they are not distinct (that is, there is a dependency with respect to their content), or one part should only be used in conjunction with the other, then this logical dependency should be explicitly managed. The Module (Version) Dependency Reference Set

(see Section 1.1.5) is an appropriate mechanism for doing this and the SNOMED CT URI Guide contains additional discussion of this topic.

Statement of Impact

Additional Notes

This standard builds upon This Standard builds on a number of other elements of the SNOMED CT ecosystem. In particular its semantics are dependent on those of RF2 and the module and versioning mechanismmechanisms.

This Standard document defines a standard set of identifiers in the form of URIs. In order to maintain the integrity of the associated URI space, it is highly desirable for SNOMED International to maintain ownership of the snomed.info DNS domain. While not a requirement of this specification, it would be useful if the URIs defined by this specification, with respect to SNOMED CT Corecore, were resolvable.are resolvable through services provided by SNOMED International.

The Perl script that generates OWL (and other) representations of SNOMED CT that name things with URIs should use URIs conforming to this specification. 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. Section 3.1 , Resolving SNOMED CT URIs, covers  covers this issue in more detail.

...