Overview

Section 2 above defines  defines a set of URI spaces that are used to identify a variety of SNOMED CT resources, but it does not talk about discuss resolving these URIs. The URIs in the standard use the http scheme and the domain name snomed.info, which is owned by the IHTSDOSNOMED International. This means that the IHTSDO 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 2.7 URIs for SNOMED Resources) 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.

URIs Resolved by Others

A
However, a Release Centre or other service provider providers may also want to support the resolution of these 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 might also indicate that the service knows about 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.

...