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 Select Edition and Version).

The table below 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 the table require the client application to select the edition and version to which they require access.

Enabling Edition and Versioned Edition Access

• 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.| 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. 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.

The table below summarizes the recommended ways to identify a SNOMED CT edition or versioned edition using a URI.

Importing and Validating Release Files

When working with SNOMED CT, it is critical to ensure that release packages are correctly validated and imported. Proper validation safeguards data integrity and ensures that terminology services, applications, and users can rely on accurate and consistent content. This section outlines the general integrity checks required for all release packages, additional checks for extensions, and the requirements for importing release files.

General Release Package Integrity Checks

To validate the integrity of SNOMED CT release packages:

• Consistency of distribution files

  • All imported files must be from the same release.

  • The set of files must be complete and include all mandatory components.

• Delta releases

  • Previously imported data must be from the version immediately prior to the delta release being imported.

• Snapshot or full releases

  • Pre-existing data must be removed before import, or

  • The process must overwrite duplicates so that:

• Component identifiers

  • Must have a valid partition identifier for the type of component.

  • Must include a valid check-digit.

• Field constraints

  • All fields must comply with data type, size, and value constraints defined in the Release File Specifications.

• Concept integrity

  • All concepts must have at least two active descriptions:

    • One Synonym (900000000000013009).

• Other consistency checks

  • May be applied as needed to ensure overall data integrity.

When importing an extension, additional checks must be performed to ensure proper installation and compatibility:

• Recognition and approval

  • The extension must be recognized and formally approved by an appropriate authority.

• Compatibility

Terminology service providers must ensure that terminology services provide access to all the data in selected versioned views of a selected SNOMED CT edition.

• Applies to all editions and versioned views the service can access.

• Data must support the purposes defined in the SNOMED CT Release File Specifications, though storage format does not need to match the release file structures exactly.

• The simplest approach is to import all files from the full release and/or snapshot release of the required edition.

The data structure of each release file is defined in the SNOMED CT Release File Specifications:

Importing Release Types

Requirements

• Organizations that maintain SNOMED CT edition(s) or extension(s) must distribute one or more release package(s).

  • Each release package must contain a full release for the current version of an edition or extension for which they are responsible.

  • Optionally, each release package may also contain a snapshot release and/or delta release for the same version of the same edition or extension.

• Terminology service providers must ensure their service can import data from either a full or snapshot release of a selected edition or extension.

  • They should also consider enabling their service to update a previously imported edition or extension using a delta release.

• Healthcare application providers should ensure that their applications can work with terminology services that support importing and updating SNOMED CT using the available release types.

• Terminology service users must confirm that the healthcare applications and terminology services they procure:

  • Provide access to the SNOMED CT editions and extensions they require.

  • Support updates to more recent versions of those editions and extensions.

The following sections illustrate the differences between delta, full, and snapshot release types across five releases of a simplified example release file.

• Six components created.

• Delta, Full, and Snapshot are identical (no previous release).

Delta, Full, Snapshot:

• Component 3 changed from 3rd → third.

• Components 7 (fourth) and 8 (fifth) added.

• Component 4 inactivated.

• Component 5 inactivated.

• Component 6 changed to sixth.

• Component 9 added (seventh).

• All SNOMED CT release packages must include a set of full release files for a SNOMED CT edition or extension.

  • A full release includes the complete history of the content of that edition or extension.

  • This allows a terminology server to enable access to versioned views of the content of this edition or extension as it was at any point between its first release and the current release.

A versioned view is a set of component versions and reference set member versions defined by the characteristics of their effectiveTime.

• Versioned views and release types are closely related.

• A release type is a physical representation of a particular versioned view.

• Some versioned views are not instantiated as release types, but all valid views of a SNOMED CT edition can be generated from a full release.

• Includes the most recent version of all components and reference set members at a specified point in time.

• Uses:

  • The current snapshot view is the most important and is in constant use during daily operations.

• Includes only rows representing changes to components and reference set members since a specified date or between two dates.

• Uses:

  • When updating to a new version, delta views identify components that were added, updated, or inactivated between releases.

• Includes all versions of all components and reference set members in a full release.

• Uses:

  • Useful for organizations that do not apply every update, but still need to interpret data that references content not in the snapshot view they use.

To enable terminology services to access a full view of a SNOMED CT edition:

• Import a full release of the edition into an appropriate datastore.

• To update:

  • Import the latest full release, replacing the old data; or

To provide access to a snapshot view:

• Import the current snapshot release; or

• Selectively import data from the current full release (most recent versions only); or

• Filter the full view to include only the most recent version of each component before a specified date.

To update to a new snapshot view:

• Use any of the above methods to add or replace a snapshot view; or

• Import the latest delta release and update the snapshot accordingly.

To provide access to a delta view:

• Import the delta release for that edition; or

• Selectively import rows from the full release where effectiveTime is after the previous release date and on or before the current release date; or

• Filter a full release to generate configurable delta views between arbitrary dates.

Configurable delta views may include:

• Only the most recent change to each component within the period, or

• All changes to each component during that period.

SNOMED CT is made available to license holders in release packages containing sets of files that represent SNOMED CT components and. The content of these files provides the source data to which a terminology service provides access. This chapter provides guidance on how the structure and content of different release packages should be accessed and used to enable desired services. This chapter is important for those designing, developing, and maintaining terminology services, as they require a thorough understanding of the structure and content of different release packages and the release files they contain.

SNOMED CT terminology data is distributed in release packages containing tab-delimited release files that conform to the SNOMED CT Release Files Specification. All release files follow a consistent design pattern with the following key features:

• A versioning mechanism, which tracks additions, changes, and inactivations made in each release. This versioning mechanism enables terminology services to access the full history of every SNOMED CT component and reference set member.

• A limited range of data types, all of which are rendered as text in release files.

• Use of the Unicode UTF-8 character set for the string data type, to support the inclusion of the full range of Unicode characters.

Data from the files in SNOMED CT release packages needs to be loaded into a datastore that can be accessed by terminology services. The design of this datastore is a key design decision for developers of terminology services since it will determine the capabilities and performance characteristics of those services.

General requirements for the datastore design include:

• It must enable the representation of all the information contained in all release files types in the SNOMED CT release package(s) imported

• It must support the terminology services that are marked as Required in the subsections of

• It must deliver scalable optimization of terminology services required by the use cases in that the server is designed to support1.

Different technical options are available for implementing terminology services, for example, using a relational database, other database options (such as