SNOMED CT URIs in Use
Resolving SNOMED CT URIs
Overview
SNOMED CT URI Space defines a set of URI spaces used to identify various SNOMED CT resources, but it does not discuss resolving these URIs. The URIs in the standard use the http scheme and the domain name snomed.info, which SNOMED International owns. This means that 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 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 Release Centre or other service providers may also want to support the resolution of 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 . It may also indicate that the service is aware of 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.
URI Use Cases
The Owl Representation of SNOMED CT
The OWL representation of SNOMED CT utilises URIs to identify concepts, the previously implicit grouping role, and the ontology itself (i.e., the set of axioms).
The old pattern used for Concepts was
http://www.snomed.org/SCT_{sctid}
which is now replaced by
http://snomed.info/id/{sctid}
The grouping role URI was
http://www.snomed.org/RoleGroup
and is now
http://snomed.info/id/609096000
For the OWL XML representation, the URI was unspecified (the empty string), while for the OWL Functional Syntax representation the URI was (via RDF:about)
http://www.snomed.org/sct.owl
and now includes explicit version information
http://snomed.info/sct/{sctid}/version/{timestamp}
When representing SNOMED CT ontologies using OWL 2, both an ontologyURI and a versionURI should be included using the following forms, :
http://snomed.info/sct/{sctid}http://snomed.info/sct/{sctid}/version/{timestamp}
The CTS2 Specification
The CTS2 specification requires that all resources be identified using URIs. This section lists, where such a thing exists, SNOMED International standard URIs for the resources that require URIs in the CTS2 implementation. This omits URIs for things such as External Code Systems and Value Sets since they are outside the scope of the SNOMED CT URI Standard. Note, however, that a Reference Set is the SNOMED CT mechanism for identifying an arbitrary set of Concepts, which is analogous to a Value Set. Thus the Reference Set URI would be the appropriate thing to use as the Value Set identifier.
SNOMED CT Edition
http://snomed.info/sct/{moduleId}
http://snomed.info/sct/900000000000207008SNOMED CT International Edition
SNOMED CT Version
http://snomed.info/sct/{moduleId}/version/{effectiveTime}
http://snomed.info/sct/900000000000207008/version/20120131SNOMED CT International January 2012 Version
Module
http://snomed.info/module/{moduleId}
http://snomed.info/module/900000000000207008SNOMED CT Core Module (only)
A specific release of a Module
http://snomed.info/module/{moduleId}/time/{timestamp}
http://snomed.info/module/900000000000207008/time/20120131SNOMED CT Core Module (only) with respect to the timestamp 20120131
SCTID
http://snomed.info/id/{sctid}
http://snomed.info/id/449650002
UUID
http://snomed.info/id/{uuid}
http://snomed.info/id/00000692-31c5-81a8-2e54b488c824
Table Field
http://snomed.info/field/{table name}.{field name}
http://snomed.info/field/Relationship.characteristicTypeId
Map
http://snomed.info/id/{map sctid}
http://snomed.info/id/900000000000498005A map is just a reference set in a specific format
Map version
http://snomed.info/sct/{moduleId}/version/{effectiveTime}/id/{map sctid}
http://snomed.info/sct/900000000000207008/version/2012013/id/900000000000498005
Refset
http://snomed.info/id/{refset sctid}
http://snomed.info/id/900000000000498005
Refset version
http://snomed.info/sct/{moduleId}/version/{effectiveTime}/id/{refset sctid}
http://snomed.info/sct/900000000000207008/version/2012013/id/900000000000498005
Role Group
http://snomed.info/id/609096000
http://snomed.info/id/609096000
Identifying SNOMED CT Versions in HL7
Traditionally, HL7 has used OIDs to identify Code Systems. The OID for SNOMED CT is 2.16.840.1.113883.6.96. This is the OID that should be used for all versions of SNOMED CT and related terminologies (such as the Australian Medicines Terminology) because it identifies the system, i.e., the set of rules for interpreting SCTIDs. Under these rules, any specific SCTID is either defined with respect to a particular SNOMED CT Version, or it is undefined (i.e. not included/mentioned in that version). Furthermore, any given SCTID always identifies the same thing in all versions in which it is defined.
The HL7 specification says: the interpretation of version strings is defined by the Code System (and not by HL7). This means we can use the URI for a Version (versioned Edition) as the version code:
http://snomed.info/sct/{sctid}/version/{timestamp}
For example, here is how an element of Data Type CD might appear in a CDA document with:
<xyz code="78835011000036104" codeSystem="2.16.840.1.113883.6.96" codeSystemName="Australian Medicines Terminology (AMT)" codeSystemVersion= "http://snomed.info/sct/900062011000036108/version/20121231" displayName="GANFORT 0.03% / 0.5% eye drops: solution, 3 mL"/> </xyz>Identifying SNOMED CT Versions in HL7 FHIR
Fast Healthcare Interoperability Resources (™) defines a set of 'resources' to represent health and healthcare administration-related information. Rather than OIDs, FHIR uses URIs to identify code systems, typically accompanied by an associated version string. The code system is intended to characterise the set of valid codes, hence the recommended URI to use for this is:
http://snomed.info/sct
and the recommended string template to use for the associated version, substituting in the appropriate module sctid and effective time, is:
http://snomed.info/sct/{sctid}/version/{timestamp}
Last updated