Before an extension is ready for distribution it needs to be classified (if distributed as an edition), validated and packaged properly. Extension producers also need to ensure their content is aligned with the International Edition of SNOMED CT. The following pages explore several key aspects of preparing a SNOMED CT edition for distribution, including:

• Classifying an Edition

• Packaging and File Naming

• Release Validation

• Preproduction Releases

Prior to the publication of a SNOMED CT Edition or Extension, it is strongly recommended that extension producers provide stakeholders with early visibility of content changes. Early review helps implementers understand potential impacts on local systems, identify issues, and provide feedback before content is formally published and must be maintained indefinitely.

Historically, this was achieved through alpha and beta releases. While this approach is still valid and may be used by some extension producers, SNOMED International (SI) and Member Services no longer routinely produce alpha or beta releases. Instead, alternative mechanisms are now used to support prepublication content review.

Pre-production Content Review

SNOMED International no longer publishes formal alpha or beta releases for the International Edition or Member Services extensions. Instead, preproduction content review is supported through continuous visibility and communication mechanisms.

Daily Build Browser

Content changes for each monthly International Edition release can be reviewed via the Daily Build Browser, which provides early visibility of in-progress changes prior to publication.

Issue Reporting

Any potential issues identified during prepublication review should be reported to SNOMED International via:

• SNOMED International Helpdesk

Early reporting allows issues to be addressed before content is officially published and becomes part of the permanent version history.

To assess potential impacts on local extensions, extension producers and implementers are strongly encouraged to:

These channels provide advance notice of significant changes, editorial policy updates, and upcoming content releases.

Some extension producers may still choose to use alpha and/or beta releases as part of their development lifecycle.

A SNOMED CT release package made available only for initial review and testing.

A SNOMED CT release package made available for broader review and testing prior to a production release.

A beta release of an extension may function as a candidate baseline until the extension is considered mature and ready for publication.

Purpose

The purpose of the SNOMED CT packaging process is to assemble a set of SNOMED CT files into an archive of a specified structure to support easy adoption by terminology consumers. The resulting archive is a distributable package for the specific extension or edition. A SNOMED CT package uses a standard naming convention and its contents are structured in a standard format. The packaging process may begin when all the files that comprise a specific SNOMED CT extension or edition have been created, populated and validated.

Additional Packaging Notes:

1. Each SNOMED CT release package may logically consist of one or more editions, with each edition consisting of the set of components and reference set members which belong to a focus module, plus the contents of the modules on which the focus module depends.

2. The module dependencies used to define the contents of an edition are represented using a .

3. SNOMED CT editions can be identified using a URI that is formatted according to the . (For more specific information please refer to .)

SNOMED CT content in the International Edition is organized into two top level folders according to the release file types - Full and Snapshot. When packaging extensions and editions, this should be done using the same folder structure. Note that extension producers are only required to include the full release type for the extension. The snapshot release is optional, because it can be calculated from the full release. However, distribution of both release file types is recommended to simplify use by terminology consumers.

Each release file type has the same nested folder structure, with the following two subfolders:

• Terminology folder, which contains the concepts, descriptions and relationships files

• Refset folder, which contains a range of reference set files ordered into subfolders according to their usage

The following recommendations apply to the structure and format of SNOMED CT release packages:

1. It is recommended that documentation should be removed from the release packages, and hosted separately. This allows for ongoing updates, if required.

   1. Note that some exceptions may apply, such as the readme.txt file

2. The main component files (e.g. Concept, Description, Relationship) are nested under the Terminology folder

The recommended folder structure is illustrated below.

SNOMED International provides templates to support extension producers in proper packaging of the release files. These templates detail the minimum expected set of files for each release product, plus the folder structure in which they should be packaged. For more information and to download these templates, please refer to

Two main approaches to packaging exist:

• Extension: Packaging the extension modules separately from the modules in other editions or extensions

• Edition: Packaging the extension modules together with the modules from the International Release (and other modules on which the extension depends), as a single package with the terminology content available in combined release files

The approach that is best for a given situation will depend on the content of the extension and the requirements of the consumers of the extension. The following subsections discuss each approach.

The figure below illustrates the idea of packaging as an extension. In this approach, the extension content is released in a separate package, which is not intended to be used on its own. Instead, the contents of the extension package must be combined with other packages (including the international release) by the terminology consumer. To determine which packages must be combined, the module dependency reference set is used to identify the dependencies for a given SNOMED CT edition (based on its focus module).

In the example below, the national content and local content have each been packaged as extensions. A terminology consumer must therefore combine the Local Extension package, the National Extension package and the International Edition package to achieve a complete terminology solution. Note that each package uses the same folder structure.

Extension producers choosing this packaging approach may package the content of the extension into release files in a variety of ways, including:

• All content for a particular type of component (e.g. Concept) that is maintained by the extension producer is released in a single file. Components in this file may have different moduleIds, where the content has been authored in separate modules. Please note that where descriptions are authored in more than one language, these are generally included in separate files, with the applicable language code included in the file name.

• All content for a particular type of component (e.g. of type Concept) is included in a set of files, with each file using a single moduleId.

Extension packaging may be appropriate when the content has the following characteristics:

• The extension is used only to distribute a translated version of the terminology

• The extension is used only to distribute reference sets and the associated metadata, and does not involve the addition of clinical concepts

• The modules in the extension are intended to be reused by multiple editions, which will each be classified with a different combined set of modules

The figure below illustrates the idea of packaging as an edition. In this approach, the package can be used on its own, without the need to combine with other packages.

When packaging an extension as an edition, the extension content is combined with the International Edition (and any other module on which the extension depends), in the standard folder structure. All content of a particular type is included in a single file, irrespective of the module it belongs to or the organization responsible for maintaining it. Care should be taken not to modify, add to or remove content that belongs to a module maintained by another organization. For more information please refer to .

Edition packaging may be appropriate when the content has the following characteristics:

• The extension includes new clinical concepts that need to be classified together with the International Edition (and other modules on which the extension depends). See .

Files in an extension should be named in accordance with the SNOMED CT file naming convention. The file naming convention can simplify implementation and provide the following benefits:

• A consistent naming convention across the International Edition and each National Edition

• Predictable file naming which provides a stable pattern for naming over time and between releases

• A standard way to identify the source and namespace by which a release file is managed

Quality assurance checks, which ensure that the naming convention has been applied, should be performed as part of the release process. For more information please refer to .

Prior to releasing a SNOMED CT extension or edition, a series of validation checks should be performed to ensure that the package is ready for release. The table below summarizes the different types of validation tasks and provides some examples of checks that can be performed prior to a release.

Table: Pre-release validation tasks

• Concept file conforms to the structure specified in the

• Description file conforms to the structure specified in the

• Relationship file conforms to the structure specified in the

To test assertions about the content of SNOMED CT data files, with respect to their release type (i.e. Full, Snapshot or Delta). This involves comparing data files for the prospective release with those of the most recently published previous release.

• New full file consists of the previously released full file and the new delta file

• New delta file consists of all rows from the new full release which has an effectiveTime equal to the new release date

• New snapshot file contains only one row for each component or reference set member

File Validation

To test file constraints and interfile dependencies (i.e. assertions about the integrity of data within and between SNOMED CT data files). This involves testing primary and foreign keys, and the cardinality of references between files. For performance reasons, testing may be limited to the set of concepts that have changed in some way in the prospective release, and components associated with them.

• Active extension descriptions are referred to in one or more language reference sets

• All concepts associated with an active description in the description file are present in the concept file of either the extension, the International Edition, or a module from another extension on which the extension modules depend.

• Primary keys are unique within each file

Component Validation

To test assertions about the integrity of SNOMED CT components. In this kind of validation, the content of each file is tested against the editorial principles and logical design of SNOMED CT.

• All active concepts must have:

  • An active description of type

  • At least one active description of type

When new concepts are added to an extension, or the definitions of existing concepts are modified, it is important that the extension is classified. Classification is performed for two main reason: firstly to ensure that logic errors are identified, and secondly to make it easy for users of the terminology (who may not necessarily have access to a classifier) to identify the full set of inferred relationships.

Classifying an extension requires combining the content in the extension modules with the content from all modules on which the extension modules depend (as defined by the Module Dependency Reference Set), including the modules from the International Edition. This ensures that the logical definition of all supertypes and attribute values of extension concepts can be used by the classifier in determining its inferences. The resulting set of inferred relationships (excluding redundant | is a| relationships) is then distributed in the Relationship file of the release.

There are, however, some limited situations in which classification may not be required in order to generate the (inferred) Relationship file for an extension. For example:

• The extension contains only reference sets, metadata concepts and/or descriptions

• The extension contains only primitive concepts for which the stated and inferred definition are equivalent

  • Note: Some primitive concepts may infer new defining relationships during the classification process, so care should taken before assuming that classification is unnecessary for primitive content.

The use of description logic as the formal foundation of SNOMED CT allows the semantics of clinical concepts to be represented unambiguously. Description logic also enables logical deduction in which additional information can be inferred from the explicit statements in the terminology. Classification is the process in which the formally stated definitions of each concept are used to compute the subsumption hierarchies and defining properties of each concept.

With each new release of SNOMED CT, the stated concept definitions are represented in the OWL Expression reference set, while the Relationship file, contains the full set of relationships that can be inferred using a classifier (excluding non-redundant relationships). Most consumers of the SNOMED CT will use the Relationship file (containing the inferred relationships). The OWL reference sets are primarily used by extension producers, but may also be used by terminology consumers that have access to a description logic classifier.

A release file that follows the pattern and contains expressions that represent general statements about the SNOMED CT ontology and axioms that define SNOMED CT concepts.

• The OWL expression reference set contains two reference sets, the OWL ontology reference set and the OWL axiom reference set.

• OWL ontology reference set

• OWL axiom reference set

• Release File Specification

Inferred relationships are derived from the set of OWL axioms in the, by applying a consistent set of logical rules to the definition which take account of the definitions of related concepts.

Several semantically equivalent views may be inferred from the same set of stated relationships. However, the SNOMED CT Relationship file is distributed using an inferred view known as the necessary normal form (NNF). This standard distribution view, includes all non-redundant relationships (between each concept and its proximal supertype), and the inferred concept definition of each concept (including all non-redundant defining relationships).

In the necessary normal view (NNF) appropriate subtype and attribute relationships are created to represent non-redundant axioms that are necessarily true capable of being represented using the relationship file format.

This example is included to illustrate what happens during the classification process.

Consider the stated relationships shown below for the concepts and . The concept definitions are represented in accordance with .

Table : Example stated relationships

Table: Comparison of stated definitions

Table: Deriving the inferred relationships

Classifying an extension requires combining the content in the extension modules with the content from all modules on which the extension modules depend (as defined by the Module Dependency Reference Set), including the modules from the International Edition. This ensures that the logical definition of all supertypes and attribute values of extension concepts can be used by the classifier in determining its inferences. The resulting set of inferred

The process of combining an extension with the content of the modules on which it depends is illustrated in image below.

It is important that all inferred relationships present in the International Edition are also present in the combined inferred view. This means that the Relationship file in an extension's edition should be a superset of the Relationship file in the International Edition. In particular:

• All relationships belonging to the International Edition should be retained in the extension edition, with the same moduleId and effectiveTime values

• All new inferred relationships created when classifying the extension should

  • Be assigned to a module within the extension, and

If a situation occurs in which an inferred relationship from the International Edition becomes redundant in the extension edition (due to an intermediate concept being created in the extension), it may be necessary to inactivate the redundant international relationship in an extension module. For more information please refer to .

For more information about options for packaging inferred extension relationships, please refer to .