Two key factors determine the ability of an instance of a terminology server to provide access to a particular SNOMED CT versioned edition. 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).
Table 5.2-1 shows some of the different ways in which a terminology server may be designed and configured to enable access to a specific SNOMED CT edition or versioned edition Most of the options in Table 5.2-1 require the client application to select the edition and version to which they require access.
Table 5.2-1: Enabling Edition and Versioned Edition Access
| Versioned Edition Accessibility | Description | Versioned Edition Selection | Notes |
| Fixed versioned edition | A specific instance of a terminology server accesses a datastore that only contains data for a single versioned edition. | Referring to a server instance implicitly identifies the edition and version. | Not recommended 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 edition. | 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:
|
| 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. Datastore options Access to any version can be supported using a datastore designed in one of the following ways:
| 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 editions. | 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 full release for several editions. Datastore options Access to any version of several edition can be supported using a datastore designed in one of the following ways:
| 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. |
Table 5.2-2 summarizes the recommended ways to identify a SNOMED CT edition or versioned edition using a URI.
Table 5.2-2: Identifying SNOMED CT Editions and Versioned Editions
| Method | Terminology Resource | General form and example | Notes |
| Module identifier and version date | Edition | {moduleId} Example: | |
| Version | {versionDate} Example | 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 Time data type). | |
| Uniform Resource Identifiers | Edition | http://snomed.info/sct/{moduleId} Example: | 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). Note 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 731000124108 | US National Library of Medicine maintained module| and the two International Edition modules on which it depends ( 900000000000207008 | SNOMED CT core module| and 900000000000012004 | SNOMED CT model component module| ). |
| Versioned Edition | http://snomed.info/sct/{moduleId}/version/{versionDate} Examples: | ||
| Other Options | Edition | Key, path or alias for an edition Example: | 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. Note 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 5991000124107 | SNOMED CT to ICD-10-CM rule-based mapping module| and several other additional modules that are distributed by SNOMED International in separate release packages. The inclusion of these additional extension modules creates an extended versioned edition (see 5.2.2 Enabling Access to Extended Editions). |
| Versioned Edition | Combination key, path or alias with the version date Example: |
Feedback
Overview
Content Tools
Apps