Two key factors determine the ability of an instance of a terminology server to provide access to a particular . Firstly, the data that forms part of that versioned edition must be loaded into a data store that the terminology service is able to access. Secondly, unless the terminology server only has access to one versioned edition, the terminology server must allow the edition and version to be specified by the client application (see 4.1 Select Edition and Version). 

 shows some of the different ways in which a terminology server may be designed and configured to enable access to a specific  or   Most of the options in  require the client application to select the edition and version to which they require access.

Enabling Edition and Versioned Edition Access


Versioned Edition AccessibilityDescriptionVersioned Edition SelectionNotes
Fixed versioned edition

A specific instance of a terminology server accesses a datastore that only contains data for a single .

Referring to a server instance implicitly identifies the edition and version.


This option does not support the requirements specified in 3.7 Terminology Change Management. To meet those requirements, a terminology service must be able to access the version edition used by a client application prior to the most recent update.


Specific versions of a single edition

A specific instance of a terminology server accesses a datastore that only contains data for several specific versions of a single .

Referring to a server instance implicitly identifies the edition.

The version can be selected from those available.

Recommended minimum for client applications only requiring access to a single edition.

The accessible versions should include:

  • The current version(s) used by its client applications
  • The version(s) its client applications were using prior to their most recent updates.
Any versions of a single edition

A specific instance of a terminology server has access a datastore that contains the data required to access any version of a single edition.

Access to any version can be supported using a datastore designed in one of the following ways:

  1. A datastore containing separate representations of every version of the edition.
  2. A datastore containing data from the latest of the edition. Access to each required version is enabled using (see 5.3.2 Supporting Versioned Views).
  3. A combination of the above options. Option 1 optimizes performance for access to the version(s) most frequently used by client applications. Option 2 enables access to other versions.


Referring to a server instance implicitly identifies the edition.

Any version of that edition can be selected by specifying the effective time for a snapshot.

Recommended for client applications that are processing, reporting, or analyzing data collected using a range of different versions of a single edition.
Specific versions of several editions

A specific instance of a terminology server accesses a datastore that only contains data for several specific versions of a several .

The edition and version can be selected from those available.Recommended for client applications that require access to multiple editions.
Any versions of several editions

A specific instance of a terminology server has access a datastore that contains data from the most recent for several .

Access to any version of several edition can be supported using a datastore designed in one of the following ways:

  1. A datastore containing separate representations of every version of all supported editions.
  2. A datastore containing separate representation of data from the latest of each edition. Access to each required version is enabled using .
  3. A datastore containing data from the latest of all required by one or more of the supported editions. Access to a required versioned edition is enabled using of the modules that are part of the selected edition (see 5.3.2 Supporting Versioned Views).
  4. A combination of the above options. Option 1 optimizes performance for access to the most frequently used by client applications. Option 2 or 3 enable access to other versioned editions.



The edition can be selected from those available.

Any version of the selected edition can be selected by specifying the effective time for a snapshot.

Recommended for client applications that are processing, reporting or analyzing data collected with using a range of different versions of more than one edition.



  summarizes the recommended ways to identify a  or  using a . 

Identifying SNOMED CT Editions and Versioned Editions


MethodTerminology ResourceGeneral form and exampleNotes
Module identifier and version dateEdition

{moduleId}

Example:
900000000000207008

The {moduleId} is an that identifies the edition. It does this by referring to the of the most dependent module in the edition. The other modules in the edition are specified by the module dependencies of that module.

Version

{versionDate}

Example
20200131

The {versionDate} is the effectiveTime of the set the set of module dependency reference set rows for this a version of this edition. This is formally represented using the format YYYYMMDD (see ).

Uniform Resource Identifiers

Edition

http://snomed.info/sct/{moduleId}

Example:
http://snomed.info/sct/900000000000207008

The SNOMED CT URI Standard defines globally unique identifiers for a wider range of terminology components. These URIs include the {moduleId} and {versionDate} noted above (for further details see URI Standard section 2.1 URIs for Editions and Versions).

The URI http://snomed.info/sct/731000124108/version/20200301 refers to the 2020-01-31 version of the US Edition, which is formally defined to include the and the two International Edition modules on which it depends ( and ).


Versioned Edition

http://snomed.info/sct/{moduleId}/version/{versionDate}

Examples:
http://snomed.info/sct/900000000000207008/version/20200131
http://snomed.info/sct/731000124108/version/20200301

Other OptionsEdition

Key, path or alias for an edition

Example:
{server-url}/MAIN/SNOMEDCT-US

A less formal approach that provides a more meaningful representation of the edition and version can be used.

The example shown here is currently used by the Snowstorm terminology server to refer to the US Edition of SNOMED CT.

This Snowstorm path refers to an extended version of the formally defined US edition. In addition to the formally defined content noted above, it also includes the and several other additional modules that are distributed by SNOMED International in separate release packages. The inclusion of these additional extension modules creates an (see 5.2.2 Enabling Access to Extended Editions).


Versioned Edition

Combination key, path or alias with the version date

Example:
{server-url}/MAIN/SNOMEDCT-US/2020-03-01