SNOMED Documentation Search
Page History
...
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"
| Footnote Macro |
|---|
www.snomed.org/tig?t=glsct_ss_Concept |
. 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
| 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.
...
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 Objectshttp://www.w3.org/TR/cooluris/#semweb |
, and _Designing URI Sets for the UK Public Sector
| Footnote Macro |
|---|
.
It should be further noted that, consistent with the advice of Tim Berners-Lee
| Footnote Macro |
|---|
Linked Data http://www.w3.org/DesignIssues/LinkedData.html |
, 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.
...
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. |
of the Technical Implementation Guide says the following:
...
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) moduleId, one is able to identify all the content relevant to that (versioned) moduleId. Hence, a (versioned) moduleId can be used to uniquely identify a (versioned) Edition.
| 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. |
| Anchor | ||||
|---|---|---|---|---|
|
...
This is used to mean a concrete set of files that is published by a Release Centre (including the IHTSDOSNOMED 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.
...
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
| Footnote Macro |
|---|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
(see Section 1.1.5) is an appropriate mechanism for doing this and the SNOMED CT URI Guide contains additional discussion of this topic.
...
This Standard builds on a number of other elements of the IHTSDO SNOMED CT ecosystem. In particular its semantics are dependent on those of RF2 and the module and versioning mechanism.
This Standard 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 the IHTSDO 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 Core, were resolvable.
...
Overview
Content Tools
Apps