SNOMED Documentation Search
Page History
| Toc hidden headings |
|---|
...
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"
...
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
| Footnote Macro |
|---|
_ http://www.snomed.org/tig?t=trg2main_title Section number relative to July 2012 version. |
in the separate document "SNOMED CT® Technical Implementation Guide" for additional information on this subject.
...
...
Motivating Factors
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 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, at a given point in time. Furthermore certain things, such as an Extension with all its dependent modules, are not themselves components, 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 such as the Australian release, or the Swedish translation.
...
The URI space defined in this document uses the syntax defined in _IETF RFC6570 URI Templates
| Footnote Macro |
|---|
. In addition, principals of good URI design were drawn from the W3C document _Cool URIs for the Semantic Web
| Footnote Macro |
|---|
_ Specifically the section URIs for Real-World Objects http://www.w3.org/TR/cooluris/#semweb |
, and _Designing URI Sets for the UK Public Sector
| Footnote Macro |
|---|
...
, the http scheme is used for these URIs. Furthermore, to be consistent with the W3C's TAG resolution of ISSUE-14
| Footnote Macro |
|---|
, 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.). 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 Choosing between 202 and Hash
| Footnote Macro |
|---|
_ Choosing between 303 and Hash www.w3.org/TR/cooluris#choosing |
of the aforementioned W3C document _Cool URIs for the Semantic Web.
...
...
Use Cases for URIs
The following use cases have guided the specification detailed in this document:
...
Section _5.4.1.4. Identification of Source Module
| Footnote Macro |
|---|
_ http://www.snomed.org/tig?t=trg2main_gen_idsource Section number relative July 2012 version. |
...
| Footnote Macro |
|---|
In the case where a Release Centre has not organized what they consider to be an Edition to correspond to the transitive contents of a single moduleId, a single additional moduleId can be created that depends on the modules that comprise the Edition and then be subsequently used to identify that Edition. Note that it is non-conformant to release only part of a module. |
...
...
A Note on Releases, Editions and Versions
In this document we capitalise the terms Release, Edition, and Version to indicate that they are being used with the following specific meanings:
...
(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
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 mechanism.
...
Overview
Content Tools
Apps