SNOMED Documentation Search


You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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

However, a Release Centre or other service provider may also want to support the resolution of these URIs. 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

  • http://myservice.example.com/?url=http://snomed.info/{...}

might be redirected with an HTTP response code of 303 to

  • 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/?url=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 Concept1 . 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.


Footnotes
Ref Notes
1

This information is directly discernable from the SCTID itself.


Feedback
  • No labels