Common Attributes

Reference sets use a range of different attributes depending on the reference set type. While a detailed discussion of all reference set attributes is outside the scope of this document, this section briefly reviews some of the key attributes. Please refer to in the Practical Guide to Reference Sets for more information on reference set types and their specific attributes. Please refer to 5.4.5 Authoring Reference Sets and Authoring Reference Set Members for more information on the principles and processes for authoring reference sets and their members.

All reference sets share six common attributes:

• id

• effectiveTime

• active

• moduleId

• refsetId

• referencedComponentId

The following subsections explain how these attributes are used in an extension.

The first attribute of every extension reference set member is 'id '. Unlike the id of a SNOMED CT component, the id of a reference set member is a UUID (Universally Unique Identifier). UUIDs are 128-bit unsigned integers, which are uniquely generated using widely available algorithms. This avoids the need to track the issuing of SCTIDs for thousands of reference set rows. When used in a reference set, the id identifies the reference set member or row.

Table: Example UUIDs

The second attribute of every extension reference set member is 'effectiveTime '. This attribute specifies the date on which the specific version of the reference set member was released, using the ISO 8601 YYYYMMDD format. When a reference set member is added or modified in an extension, the effectiveTime of the member version will match the version date of the release.

The third attribute of every extension reference set member is 'active '. This attribute specifies whether or not the specific version of the reference set member is active at the given effectiveTime. The data type of this attribute is Boolean, with a value of "1" indicating that the member is active at the given effective time and a value of "0" indicating that the member is inactive at the given effectiveTime. New reference set members in an extension will use an active value of "1".

The fourth attribute in every extension reference set member is 'moduleId '. This attribute specifies the module in which the member is being maintained at the given effective time. The value of this attribute is the SCTID of a module concept that is created and maintained by the extension producer. Please refer to for more information on this topic.

The fifth attribute in every extension reference set member is 'refsetId '. This attribute refers to the id of the reference set concept that is used to represent the meaning of the reference set to which the given member belongs. The reference set concept must be a subtype of . The descriptions associated with this concept help to name the reference set. For more information, please refer to .

The sixth attribute of every extension reference set member is 'referencedComponentId '. This attribute uses a SCTID to identify the component that is referenced by this member of the reference set. For example, the referencedComponentId may refer to a member of a subset represented by a , to the description whose acceptability is being defined in a , or to the source of map in a .

All extensions must specify their extension module dependencies and language preferences. In this section, we describe the essential reference sets that support this.

• Language Reference Set

• Module Dependency Reference Set

Prior to creating the components or reference sets in an extension, some preliminary steps must be completed. These tasks include:

1. Obtaining a namespace identifier from SNOMED International

   • A namespace identifier is required to generate component identifiers (SCTIDs)

2. Acquiring the appropriate tools to support the creation, management, and distrbution of the extension

   • Which tools, functionalities and services are required will depend on the content of the extension

   • For more information please refer to

   • Note that these tools will be used to complete the steps listed below

3. Creating module(s)

   • At least one module concept is required

   • Components and reference sets which belong to the extension are assigned to the approriate module

4. Specifying module dependencies

   • These dependencies are specified using the

   • This informs the consumers of the extension as to which additional modules are required to use/process the content of the extension

The diagram below illustrates these key steps during the initial stage of extension creation.

Core Metadata Concept

All SNOMED CT metadata concepts are subtypes of and include concepts, descriptions and relationships that are used to describe or provide additional information about SNOMED CT content and reference sets.

The table below lists the subtypes of the hierarchy, and describes the content within these subhierarchies.

Table: Subhierarchies of |SNOMED CT Model Component| and their intended purpose

The following pages provide information about the subtypes of . Each page includes tables which describe the purpose of the content within one of the sub-hierarchies, with examples from the International Edition. The tables also state rules about the additions that are permitted in an extension to the respective subhierarchy. Where additions are permitted to the subhierarchy, notes are added on practical uses cases for addition, potential problems that may arise from these additions and any other relevant considerations.

The ability to tailor SNOMED CT to support specific use cases speaks to the adaptability of SNOMED CT, and any customization artifact that is beneficial to share may be useful to include in an extension. NRCs may need to configure SNOMED CT to match national requirements for reporting, analytics, language preferences etc.. Hence, following SNOMED CT reference sets may be included in an extension to meet a range of SNOMED CT use cases:

• A subset of SNOMED CT concepts or descriptions for use in a clinical speciality or practice

• Groups of concepts to support national reporting and analytics

There are a number of reasons for modifying a relationship in an extension, including:

• Changing the status of the relationship from active to inactive, or from inactive to active

• Changing the relationship group of a specific relationship

While the lifecycle of each extension will vary due to differences in requirements and scope, three main phases can typically be identified - Planning , Preparation and Production.

1. The planning phase ensures that the requirements can be met by the extension design, resources and processes used.

2. The preparation phase ensures that the technical prerequisites are in place, including the namespace, module(s), module dependencies and appropriate tooling.

3. The production phase involves the development, distribution and maintenance of the extension.

The production phase can be further divided into several key steps, including Assessing Requests, Authoring , Review , Distribution , and Maintenance.

1. Assessing Requests - Requests for new terminology products or content changes are submitted and processed to determine whether or not they will be accepted into the extension, submitted to a National Edition, submitted to the International Edition, or rejected.

2. Authoring - SNOMED CT components and reference set members are added, modified or inactivated according to the SNOMED CT editorial principles and policies. It should be noted that:

   • It is the responsibility of the extension producer to ensure that the quality and integrity of the extension is maintained, and that all content changes are made in a module that is owned by the

These key phases and steps in the lifecycle of an extension are illustrated below in the diagram below. Further details about each of these key phases and steps are provided in the subsequent sections, together with the principles that should be followed to ensure the quality and integrity of a SNOMED CT extension.

Each new release of the SNOMED CT International Edition introduces some changes to the content in SNOMED CT. Many of these changes are additions to the breadth and depth of clinical coverage. Other changes may include new descriptions, corrections to concept definitions, and enhancements to the expressivity of the concept model. These changes are an essential characteristic of an evolving clinical terminology which seeks to support current requirements. However, each change made to the International Edition may have an impact on the content in an extension. It is therefore important to evaluate and manage these changes when reconciling an extension with a new version of the SNOMED CT International Edition (or another extension on which it depends).

The change management process can be divided into three distinct phases:

1. Identify changes

2. Assess change impact

3. Update extension

After change management has been performed, it is important that thorough of the resulting extension is performed.

In the following sections we discuss the three phases of change management.

Reference set members can be added within an extension for a variety of reasons, including:

• To add members to a subset in the extension that is used nationally or locally

• To adapt a reference set created by another organization, by adding new members that are required nationally or locally

Specifying members of a reference set can be done in different ways. It will depend on the requirements for the reference set what approach is feasible and possible. Please refer to the for detailed instructions on the and for identifying the SNOMED CT components that will be referenced by the members of the reference set.

SNOMED CT content may sometimes need to be moved from one module to another, to enable it to be published in a different edition. Moving SNOMED CT content up the module dependency chain (i.e. from a given module to a module on which it depends) is known as content promotion. This may be required to make the content accessible to a wider audience. Moving SNOMED CT content down the module dependency chain (i.e. from a given module to a module that is dependent on it) is known as content demotion. This may be required to make the content accessible to a narrower audience. In these situations, it is essential to be aware of the principles for promotion and demotion. These principles ensure the integrity and traceability of the content, in both the original module and the module to which it is moved.

SNOMED CT components may be promoted from an extension module into a less dependent module to enable broader use. For example, an extension concept may be promoted to the International Edition to enable SNOMED CT users to share the concept. Please note that a component may only be promoted to a module on which the extension module depends (as specified in the module dependency reference set).

When promoting components from an extension into the International Edition, the donating organization (i.e., the owner of the extension) should submit a promotion request to SNOMED International with the details of all components to be promoted. The SNOMED International authoring team process the request and consider whether the content is acceptable for inclusion in the International Edition.

Authoring relationships in an extension may involve creating new relationships, inactivating relationships or modifying existing relationships.

Authoring reference sets in an extension may involve adding, modifying or inactivating members of a reference set, or the reference set itself.

The sections that follow will examine the purpose, principles and process for each of these authoring tasks.

SNOMED CT is a multilingual clinical terminology that covers a broad scope. However, some users may need additional concepts, relationships, descriptions or reference sets to support national, local or organizational needs.

SNOMED CT is designed to allow the International Edition to be enhanced by creating extensions to meet national or local requirements. The extension mechanism allows SNOMED CT to be customized to address the terminology needs of a country or organization that are not met by the International Edition. Extensions are managed by SNOMED International, and Members or Affiliate Licensees who have been issued a namespace identifier by SNOMED International. A namespace identifier is used to create globally unique SNOMED CT identifiers for each component (i.e. concept, description and relationship) within a Member or Affiliate extension. This ensures that references to extension concepts contained in health record data are unambiguous and can be clearly attributed to a specific issuing organization.

An extension may contain components and/or derivatives (e.g. reference sets used to represent subsets, maps or language preferences). Since the international edition and all extensions share a common structure, the same application software can be used to enter, store and process information from different extensions. Similarly, reference sets can be constructed to refer to content from both the international release and extensions. The common structure also makes it easier for content developed by an extension producer to be submitted for possible inclusion in a National Edition or the International Edition.

The purpose of this guide is to be a practical starting point for extension producers. It is intended to help people who need to extend and configure SNOMED CT to meet national or local requirements for clinical documentation or particular business needs. It is important that extension producers are aware of the principles and processes involved in the creation and maintenance of extensions. Consistent approaches to the development and maintenance of extensions are required to avoid variation that may form a barrier to interoperability. The objective of this guide is therefore to explain the key use cases for extensions, to clarify the logical design of extensions, and to explain the key steps and principles for creating and maintaining extensions.

The Extensions Practical Guide presents the purpose, process and principles of creating, distributing and managing SNOMED CT extensions. Extension producers should be familiar with this guidance to ensure the quality and integrity of the SNOMED CT editions that they publish.

This guide has been developed to assist National Release Centers and other extension producers to develop extensions based on recommended principles.

Authoring descriptions in an extension may involve creating new descriptions, inactivating descriptions or modifying descriptions.

Provide Feedback

Updating the extension to accommodate user requests for additions or changes is an important aspect of the overall extension maintenance process. Consumers of extensions need to be able to submit requests for changes, and the extension producer is responsible for providing a mechanism to collect and process these change requests. This process in turn supports the continued relevance and quality of the extension itself.

National Release Centers (NRCs) are responsible for collecting requests for changes detected by Affiliates. Organizations in Member countries or territories should therefore submit their content requests to the relevant NRC. The NRC will subsequently make a decision as to the relevance of the content for the International or National Edition, as described in Assessing Requests.

The type of service implemented to support change requests will depend on the scope and size of the extension, the anticipated number of extension consumers, and a range of other factors. In situations in which a small number of extension consumers are expected, a simple email service may be sufficient to enable consumers to request content changes. Extension producers with a greater number of anticipated consumers may decide to implement a dedicated system to support the tracking and management of change requests. SNOMED International has a formal procedure for submitting change requests, as described in the CRS User Guide.

Provide Feedback

Authoring concepts in an extension may involve adding new concepts, inactivating concepts, or modifying existing concepts.

Provide Feedback

Reference set members may also be added, modified or inactivated in an extension, to meet evolving requirements.

The sections that follow will examine the purpose, principles and process for each of these authoring tasks.

Provide Feedback

Provide Feedback

SNOMED CT components and reference set members are added, modified or inactivated according to the SNOMED CT editorial principles and policies.

General principles that apply to all SNOMED CT extension content include:

• Organizations may add, inactivate or modify components and reference set members, which belong to modules owned by that organization.

  • It is the responsibility of the extension producer to ensure the quality and integrity of the extension is maintained, and that all content changes are made in a module that is owned by the extension producer themselves.

  • For more information about assigning modules in extensions, please refer to the section below on Module Assignment.

• No changes are permitted to content of the International Release, except for the addition of new versions of this content in a module owned by the extension producer.

  • Any modifications resulting in changes to the classification of international content must be accompanied by a disclaimer notifying users of the differences between the extension edition and the International Edition. Please note that modifications of this kind pose a risk to the comparability and interoperability of data captured using different SNOMED CT editions.

  • Any substantive improvements or corrections to the content in the International Edition that is made in an extension should be forwarded to SNOMED International in a timely fashion to improve the quality of the International Edition for all users.

Extension producers should assign all new extension content to a module which they own. Therefore every concept, description, relationship and reference set member, which is managed within an extension, should belong to a module created and owned by the extension producer. As illustrated in the image below, this is accomplished by setting the moduleId attribute in each component and reference set file to a module concept that was created by the extension producer in the given extension. Any dependencies between components or reference set members in the extension module, and components or reference set members in other modules are specified in the .

For information on how to move content from one module to another, please refer to

Updating an extension involves creating new versions of components and reference set members that are required in the extension. Please refer to Authoring for more information about principles and process for adding, modifying and inactivating content in an extension. In some situations, content may also need to be promoted from the extension into the International Edition (or another extension on which it depends).

Update Module Dependencies

When a new version of an extension is created, new rows must be added to the module dependency reference set to reflect the dependencies of the new version of the extension. The effectiveTime and the sourceEffectiveTime of the added rows must be set to the date of the new extension release. The targetEffectiveTime must be set to the version of the module on which the extension modules depends (as identified by the referencedComponentId).

Updates to the module dependency reference set are required:

• For all existing rows in the module dependency reference set, to indicate that the dependency now applies to the new version of each module - ie the sourceEffectiveTime must be updated to the date of the extension release. If the extension module is now dependent on a new version of the target module, then the targetEffectiveTime must also be updated.

• For any module dependency that is no longer applicable. In this case, the relevant member of the module dependency reference set should be inactivated.

• For any new module dependency that applies to the new version of the extension. In this case, a new reference set member must be added to the module dependency reference set.

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

Validating the content in an extension is the process of ensuring that all components and reference sets within the extension comply with the authoring principles. As illustrated in the image below, this process involves three main steps: Validation during authoring, post-authoring review, and pre-release validation.

Effective and high quality terminology authoring processes should include thorough automated validation. This is required to ensure that all terminology components added, updated or inactivated in the extension comply with all automatically verifiable authoring principles, including concept model rules, the SNOMED CT logical design and referential integrity constraints. After the authoring process, it is important to also perform a human review of all authored content to ensure that relevant editorial guidelines and principles are followed (including those which may not be able to be automatically checked), and that the updated content is acceptable from an author and user perspective. Finally, automated validation is required before the extension is released to ensure the correctness and consistency of the release as a whole.

The following pages explain each of these key validation steps further.

Provide Feedback

Extension producers should ensure that the consumers of their extension understand how to use and implement the extension. It is therefore recommended that extension producers provide specific guidance on the:

• Purpose of the extension

• Scope and content of the extension

• Module dependencies within the extension

• Usage of the extension

Additionally, it is important that consumers of the extension can trust the quality of the extension and understand how to validate its contents. It is therefore also recommended that guidance on validating the extension is provided.

A SNOMED CT release package is a set of SNOMED CT components, reference set members and other related items that are distributed in a set of release files as a single archived unit by SNOMED International, a National Release Center or another organization authorized to maintain and distribute a SNOMED CT extension. A release package may include one or more complete SNOMED CT Editions (in which all dependencies are resolved) or a supplementary extension module that depends on separately packaged modules. While a SNOMED CT edition is a logical construct consisting of the contents of a focus module and the modules on which it depends, release packages are the physical unit in which some or all of an edition is distributed. A release package, which is distributed at a given point in time, is referred to as a release package version or a versioned release package. For more information on release packages, please refer to Packaging and File Naming.

For example, as illustrated in the image below, SNOMED International distributes the two modules of the International Edition plus the | SNOMED CT to ICD-10 rule-based mapping module| extension in a single release package, and distributes a range of other extensions (such as the 'International Classification of Nursing Practice (ICNP) to SNOMED CT' extension) as separate release packages. The National Library of Medicine (NLM) publishes the US Edition as a single release package, while NHS England (UK) currently publishes the UK Clinical Edition and the UK Drug Extension as separate release packages.

Provide Feedback

Most extensions include additional concepts, descriptions and/or relationships. It is therefore important for extension producers to understand the logical design of these components, and any extension-specific rule related to these components.

The following subsections present logical design rules and considerations for components in an extension:

• Common Attributes

• Concepts

• Descriptions

• Relationships

For information about the process of authoring extension components, please refer to . For a full list of RF2 component tables and their attributes, please refer to the .

The SNOMED CT International Edition contains some concept hierarchies that have fundamental roles in supporting the design of SNOMED CT. Additions of concepts to these hierarchies may impact the consistency and integrity of SNOMED CT. The following pages set out guidance on the addition of extension concepts within specific hierarchies. In some cases, this guidance may prohibit extensions from adding concepts in a specific hierarchy or at a particular level of a hierarchy. In other cases, the advice is provided on the use case for making particular additions and notes are included on the implications and potential risks arising from such additions.

These constraints are expressed in tables in the following pages, which are arranged to follow the overall hierarchical structure of SNOMED CT.

• Top Level Concepts and Clinical Concepts

The design of SNOMED CT specifies that all components (concepts, descriptions and relationships) are identified using SCTIDs. This is true for both components in the International Edition, and components in an extension. Extension producers therefore need a mechanism to ensure that their component identifiers are globally unique, and do not collide with the SCTIDs generated by other organizations. The SNOMED CT namespace identifier provides this mechanism. The namespace identifier ensures that all components within an extension are properly and uniquely identified, both locally and globally.

Prior to creating an extension, each organization must obtain a unique namespace identifier from SNOMED International (see ). Once the namespace identifier is issued, SNOMED International authorizes the allocated organization to generate SCTIDs within their allocated namespace to identify extension components. Each SNOMED CT namespace identifier is 7 digits in length. By including this 7 digit identifier in the appropriate position within an SCTID, and maintaining locally unique item identifiers, global uniqueness of SCTIDs can be ensured.

The table below lists some examples of namespace identifiers and the organizations to which they are allocated. These organizations include National Release Centers (or NRCs), local organizations, and commercial vendors. Note that this table is an excerpt from the SNOMED CT as of October, 2017.

Table: Examples of namespace identifiers

Authoring is the process by which content is created in an extension in accordance with a set of authoring principles. These principles ensure the quality of content and referential integrity between content in the extension and content in the International Edition. It is the responsibility of an extension producer to author concepts, descriptions and relationships in the extension while maintaining the aforementioned quality and referential integrity.

Terminology and extension producers need tools to assist with the authoring process, and many of the authoring principles described in the following sections can be automatically validated. It is therefore important to consider these principles when establishing requirements for an authoring tool. Furthermore, an extension producer should be aware of these principles and ensure that the content they develop in their extension does not directly modify any components or derivatives in a module belonging to another organization, such as the International Edition of SNOMED CT.

The following sections present key principles for authoring components and reference sets within an extension.

Depending on the type of reference set, there may be different reasons for modifying the reference set, including:

• Promoting the reference set to a parent module, for example the International Edition

• Transfer of responsibility for maintenance to an organization that is responsible for a module on which the current module depends, see

Principles for modifying reference sets include:

The following guidance is provided for organizations which have been issued namespace identifiers to create content in their own extension:

• Organizations must only generate new SCTIDs for components using a namespace identifier assigned to them by SNOMED International

• Organizations must have a mechanism in place to ensure that each SCTID is assigned only once. Generally, a single authority that generates item-identifiers in a sequential fashion for each type of component will achieve this goal.

The logical design of a SNOMED CT extension is technically consistent with that of the International Edition. Both represent and version SNOMED CT components and reference sets in release files that conform to the Release Format 2 specification. This makes it easier for consumers of the International Edition to implement extensions. The image below illustrates the logical design of a typical SNOMED CT local edition and its relationship to the associated local extension, National Edition and International Edition.

Every SNOMED CT extension includes one or more modules, and each module contains either SNOMED CT components or reference sets (or both). Modules may be dependent on other modules. A national or local extension uses a namespace identifier issued by SNOMED International to ensure that all extension components can be uniquely identified (across all extensions). A SNOMED CT edition includes the contents of a focus module together with the contents of all the modules on which it depends. This includes the modules in the International Edition and possibly other modules from a national and/or local extension.

The following subsections explain this logical design in more detail:

It is the responsibility of the extension producer to determine which requests are appropriate for their extension vs those which may be appropriate at a higher level. It is therefore important that extension producers are aware of the scope and the editorial principles for the International Edition of SNOMED CT and in some cases a national edition. This will ensure that requests for changes are forwarded to the relevant organization. Furthermore, it is important that extension producers have an established and reliable process for evaluating, processing, and overall tracking of all change requests received. The process needs to have a routing mechanism to ensure that changes applicable to the extension are made in the extension, and external change requests can be forwarded to the responsible organization, such as SNOMED International.

The image below illustrates the reporting structure for SNOMED International content requests. In general, only NRCs report to SNOMED International directly. Other extension producers will report to SNOMED International indirectly. However, in some cases, an extension producers may submit change requests directly to SNOMED International. For example, if the extension producer is an Affiliate, based in a non-Member territory.

National Release Centers are responsible for collecting requests for changes detected by Affiliates. Typically requests come from the users or consumers of the extension as they are most familiar with local requirements. Organizations within Member countries can, therefore, submit their requests for additions and changes to the National Release Center who will make an initial decision about the relevance of the content in the International Edition or the national edition of that country. The NRC may add content to their National Edition if they consider the relevance to be national rather than international. The NRC forwards requests with (what they consider to have) international relevance to SNOMED International for consideration.

A SNOMED CT extension is a set of components and reference set members that add to the SNOMED CT International Edition. An extension is created, structured, maintained and distributed in accordance with SNOMED CT specifications and guidelines. Unlike, the International Edition an extension is not a standalone terminology. The content in an extension depends on the SNOMED CT International Edition, and must be used together with the International Edition and any other extension module on which it depends.

As explained in modules, every extension must contain at least one module, and all content in an extension must belong to one of its extension modules. More than one module can be created within the same extension, if there is a business requirement to maintain or publish sets of components separately. The set of module concepts that are maintained by the same extension producer are grouped together in a single module subhierarchy. The figure below shows the module subhierarchy for the UK's National Release Center from the 20170401 UK Edition.

Please note that some module concepts in the subhierarchy (e.g. | United Kingdom maintained clinical module (core metadata concept)| )serve as grouper concepts, which are never actually used as the moduleId of any content. The use of separate modules in the UK extension allow them to maintain and publish separate editions that include different content (e.g. with and without the drug extension). Using separate modules also allows module-based filters to be applied when searching content for a specific use case.

Distribution is the process of making the extension available to its consumers.

It is the responsibility of the extension provider to ensure that everyone who accesses the SNOMED CT distribution has an appropriate license to do so. The extension producer must issue Affiliates with a license to use the extension. These licenses must include a requirement for the licensee to hold a SNOMED CT Affiliate License for the International Release. For more information about Members' responsibilities in relation to licensing, please see .

The following pages will examine the steps involved in preparing an extension for distribution and introduce different approaches to distribution.

Before content is added to a national or International Edition, organizations may choose to add this content to a module they own as an interim measure. In these cases, the organization should indicate, as part of the request, that an interim addition has been made, but that the content should ultimately be promoted to the International Edition. When a request for content which is relevant at the national level is submitted to a NRC that maintains a National Edition, interim content from a local extension may be promoted to that National Edition.

For example:

• Local organizations in a country or region may add components to their local extension and then forward the request to their NRC

Overview

When implementing SNOMED CT there is often a need to link SNOMED CT to other code systems. Examples of practical uses of a map are described in the table below:

In section we explain the full set of steps for producing any extension. However, not all of these steps are required for all purposes. If producing an extension for the purpose of representing a map between SNOMED CT and other code systems, the following key steps are of particular relevance:

• Create the map reference set

  • Principle and process for creating a reference set in an extension:

• Creating reference set members to represent each map record

Purpose

There are a variety of reasons for inactivating a relationship in an extension, including:

• An extension concept has been inactivated, which requires all relationships that it participates in to be inactivated

• To correct errors in the definition of a concept

• To remove any redundant relationships, generated when classifying the extension edition

• To remove any 'temporary' relationships that were added to correct errors in the International Edition that have since been fixed in the International release

Relationships in an extension can be inactivated if required. This is done by creating a new version of the extension relationship with a more recent effectiveTime and the active attribute set to '0' (for 'inactive').

Relationships which belong to the International Edition (or to a module on which the extension depends) should not be inactivated in an extension. When relationships from the International Edition need to be excluded, this can be done by creating a simple reference set of either 'included' or 'excluded' relationships.

The only situations in which an extension producer may inactivate a relationship specified in the international edition (or a module on which the extension depends) are:

• Where an international relationship becomes redundant after classification is performed. For more information, refer to and .

• Where there exists an erroneous relationship in the International Edition (or in a module on which the extension depends), that may cause incorrect inferences in the extension edition. If this occurs, the error may need to be temporarily corrected in the extension edition. In addition, SNOMED International must be notified of the error so that it can be permanently corrected in the international edition.

In these situations, the relationship from the International Edition (or module on which the extension depends) is inactivated by creating a new version of the relationship in the extension module with a more recent effectiveTime and the active attribute set of '0' (for 'inactive').

The table below provides a summary of the process to follow when inactivating a relationship in an extension.

Overview

Representing language, dialect or specialty-specific term preferences is possible using a SNOMED CT extension. The logical design of SNOMED CT enables a single clinical idea to be associated with a range of terms or phrases from various languages, as depicted in the image below. In an extension, terms relevant for a particular country, speciality, hospital (or other organization) may be created, and different options for term preferences may be specified. Even within the same country, different regional dialects or specialty-specific languages exist may influence which synonyms are preferred. SNOMED CT supports this level of granularity for language preferences at the national or local level.

Examples of situations in which additional terms may be required together with the type of organisation that may be involved in producing these terms.

In section we explain the full set of steps for producing any extension. However, not all of these steps are required for all purposes. If producing an extension for the purpose of adding terms in languages and dialects, the following key steps are of particular relevance:

• Create descriptions

  • Principle and process for creating descriptions:

• Specify the acceptability of the created descriptions in a language reference set

Overview

Concepts can be added to an extension, either to address content gaps or to expand the scope of SNOMED CT to include concepts that are used locally. Extension concepts are distributed in a , which follows the standard RF2 release file format. For more details on the principles and processes for authoring concepts in an extension, please refer to Authoring Concepts.

Attributes

In addition to the four common attributes, extension concepts also have a definitionStatusId.

definitionStatusId

The definitionStatusId attribute specifies whether the concept is primitive or fully defined. If defining relationships are added, which sufficiently define the concept, then the definitionStatusId should be set to | Defined| . Otherwise, the extension concept is | Primative| .

Example

In the image below, a row from the concept table of the 20170901 US edition is shown, which represents the concept 5281000124103 | Persistent asthma| .

Note that the attribute values in this row have been set according to the rules previously described.

Please note the following:

• The concept id uses a namespace identifier allocated to the National Library of Medicine (NLM). This indicates that this concept was originally created by the NLM.

• The concept id uses a partition identifier of “10”. This indicates that the concept was created in an extension.

• The moduleId indicates that this concept is included in the , which is a module in the US Edition.

Maintenance of an extension is essential to ensure that the extension continues to meet emerging user requirements, and remains aligned with updates to the International Edition of SNOMED CT (and any other extension on which it depends). As illustrated in the image below, the extension maintenance period begins when a new version of the extension is published and ends when the next version of the extension is published. As such, there is a continuous cycle of maintenance.

Two key maintenance tasks should be performed by an extension producer:

• Collecting and processing changes requested by terminology consumers

• Aligning the extension to new versions of the International Edition or other extensions on which it depends

These two maintenance tasks are explained further in and respectively.

Regular updates to SNOMED CT are essential to satisfy emerging user requirements and to improve the quality of SNOMED CT itself. An extension producer must be aware that changes in the International Edition (or another extension on which the producer's extension depends) may have an impact on their extension. Therefore, the extension should be reconciled with the International Edition (and other associated extensions) every time a new release becomes available.

The International Edition of SNOMED CT is currently released monthly. Prior to each release of the International Edition, National Release Centres have an opportunity to evaluate the pre-production releases and plan their extension reconciliation strategy. Once the International Edition has been officially released, reconciliation of the extensions based on the new release can begin. Once complete, it is recommended that extension producers allow plenty of time for an alpha and/or beta version of their extension to be validated by their users before the new release is officially published. See .

Purpose

Reference set members may be inactivated when

• The reference set member is no longer relevant or valid in the reference set in which it is being used

• The reference set to which the reference set member belongs is inactivated

Principles

Any inactivation of reference set members should be done in the module of the reference set producer.

Process

The table below provides a summary of the process to follow when removing members from a reference set.

Namespace Concept

Please see the section on for a further introduction to namespaces.

After identifying the components that have changed since the previous release, it is important to assess how these changes may affect the content of the extension. In particular, extension producers will need to ensure that the quality of the extension has not been compromised. For example, this may include checking that no relationship in the extension refers to an International Edition concept that has been inactivated, and checking for new concepts that may need to be added to reference sets in the extension.

The following table presents some examples of how changes in the International Edition may affect new versions of an extension. Please note that this list is not exhaustive, but instead provides examples of the types of maintenance tasks which are likely to be required when managing changes in an extension. Also note that extension consumers will need to assess the impact of changes in an extension edition on their implementations.

Table: Examples of terminology changes that may affect an extension

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

It is important that extension producers understand that some aspects of authoring and managing an extension are complex and will benefit from appropriate tooling.

Editions should not be handcrafted or managed using documents, files or simple spreadsheets, as these are likely to lead to technical errors and inconsistencies. Extension content needs to be reviewed in relation to its dependencies on the International Edition (and any other dependencies) which makes manual management and validation of extension content an unsustainable practice. Tools are required to maintain SNOMED CT content appropriately and to initiate automatic checks which can prevent errors.

As part of authoring and preparing for a release, all extension producers need tools capable of managing RF2 release file structures and performing necessary validation checks. Managing of RF2 files includes a mechanism for creating components and reference sets. There may be additional functionality required but this will vary depending on the content of the extension. For example, some extension producers producing new clinical concepts will need to be able to classify their extension to validate the created content and create the inferred relationships (necessary normal view) based on the stated relationships in the extension. Extensions which are merely used to distribute a translated version of SNOMED CT, or locally defined reference sets that only reference international release content will not need this classifying functionality as these extensions will only include primitive, metadata concepts. Please see the section on .

Relationships may be added in an extension for various reasons including:

• Specifying the defining characteristics of new extension concepts

• Improving the definition of an existing extension concept

• In exceptional cases, it may be permissible to add defining relationships to

Human review of all new and updated content in an extension is important to ensure the quality and correctness of the extension. This allows editorial rules that can not be automatically tested to be checked by an author who was not directly involved in the authoring of the given content. Post authoring review should be performed by individuals with both knowledge of SNOMED CT editorial principles as well as adequate clinical knowledge. In some situations, additional national linguistic or modelling guidelines also apply. A reviewer should, for example, be able to assess whether the definition of a concept has been authored correctly. The table below describes a range of different types of post authoring review, and provides some examples of each. For further information, please refer to the editorial guide.

Table: Post authoring review of components and reference sets in an extension

There are various reasons for inactivating descriptions in an extension, including:

• The description does not represent the same meaning as the fully specified name (FSN) of the concept

• The description is no longer current, useful, appropriate or acceptable

All reference sets require a concept to be created that represents the meaning of the reference set, provides the identification of the reference set, and names the reference set. These reference set concepts are created in the subhierarchy as subtypes of a reference set concept that represents the associated reference set pattern. For more information about creating a reference set concept in an extension, please refer to .

In this section, we discuss an example reference set concept ( ) from the 20170430 Canadian extension, and explain how this concept and its associated descriptions, relationships and language preferences are represented.

In the image below, a row from the concept table is shown for the concept .

Please note the following:

Given the robust versioning mechanism of SNOMED CT and the machine processable distribution format, changes made in a new version of a SNOMED CT edition are easy to identify automatically. Extension producers should ensure that they have appropriate mechanisms in place to identify changes in any edition on which their extension is dependent. To identify changes in an edition, the following release artifacts can be used:

• The delta files generated from the new release

• The snapshot files from the previous release

Please note : Delta files have been removed from the SNOMED International release package, but a Delta Generation Tool is available for those who need it. The Delta Generation Tool allows users to create their own Delta between two fixed release dates - you can find it here:

Content in one module may refer to content in another module. For example, a concept in an extension module may by the source of an relationship, whose destination is a concept in the international core module. Content dependencies may include:

• Extension concepts with an relationship whose destination is in another module

• Extension concepts with a defining attribute relationship whose destination is in another module

Extension producers should ensure that validation is performed during the authoring process to ensure that new and updated content complies with editorial principles. An authoring tool should perform validation checks for all editorial rules that can be tested automatically. Additionally, classification during authoring is recommended, as it ensures that the content within the extension sits in the SNOMED CT hierarchy as expected and that no errors have been introduced. For more information on classification, please see .

The table below provides some examples of automatic validation checks that should be performed when authoring components and reference sets. Please note that this table presents rules that are relevant for all SNOMED CT extensions, but there may be additional national linguistic and/or modelling guidelines which shoud be followed.

Table: Automatic validation of components and reference sets during authoring

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.

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.

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.

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

Foundation Metadata Concept

Reference Sets

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

Common Attributes

All components in an extension are represented using the same logical design as the International Edition. Concepts, descriptions and relationships all share four common attributes:

• id

• effectiveTime

• active

• moduleId

The following subsections explain how these attributes are used in an extension.

The first attribute of every extension component is 'id '. The id uniquely identifies the component across all extensions globally. It is therefore important that extension identifiers are structured according to agreed rules. The image below shows the four parts of an extension SNOMED CT identifier (SCTID) - item identifier, namespace identifier, partition identifier and check digit.

The table below explains the rules related to each of the four parts of a SNOMED CT identifier in an extension.

Table: Rules for each part of an extension SCTID

The second attribute of every extension component is 'effectiveTime'. This attribute specifies the date on which the specific version of the component was released, using the ISO 8601 YYYYMMDD format. When a component is added or modified in an extension, the effectiveTime of the component version will match the version date of the release.

The third attribute of every extension component is 'active '. This attribute specifies whether or not the specific version of the component is active at the given effectiveTime. The data type of this attribute is Boolean, with a value of "1" indicating that the component is active at the given effectiveTime and a value of "0" indicating that the component is inactive at the given effectiveTime. New components in an extension will use an active value of "1".

The fourth attribute in every extension component is 'moduleId '. This attribute specifies the module in which the component is being maintained at the given effective time. The value of this attribute is the SCTID of a module concept that is created and maintained by the extension producer. Please refer to for more information on this topic.

There are two main approaches to distributing SNOMED CT extensions and editions.

• File-based distribution

• Service-based distribution

Either or both of these approaches may be applied by extension producers to make their content available to consumers.

File-Based Distribution

The most common approach to distribution is using a file-based distribution approach, in which the SNOMED CT content is accessed via a distribution platform that allows a complete release package to be downloaded, as illustrated in the diagram below.

SNOMED International makes the International release available as downloadable packages, using a file-based distribution approach. The Member Licensing and Distribution Service (MLDS) is an online service for managing affiliate licenses for SNOMED International and participating Members, and for distributing SNOMED International products to affiliate licensees. An increasing number of SNOMED International Members use the MLDS to distribute their National Edition, including Denmark, Sweden, Norway, Belgium and the Netherlands. The MLDS serves two types of users:

• SNOMED International and NRC staff – Staff of organizations, including SNOMED International, who are using the MLDS to distribute SNOMED CT editions and extensions.

• Affiliates and interested parties – Individuals and organizations who agree to a license to download and use SNOMED CT in non-Member countries, and in Member countries who are using the MLDS to distribute their national extension. Please note, that when using SNOMED CT in non-Member countries, an Affiliate license is required, and use is subject to fees. For more information, please refer to SNOMED CT .

The MLDS service can be accessed at .

In some Member countries, SNOMED CT is downloaded from a local platform provided by the National Release Center (NRC) of that country. For example:

• In the US -

• In Canada -

• And in the UK -

To download SNOMED CT in a Member country:

• Visit to the SNOMED International Members page at and find your member organization

• Visit your NRC’s website or contact them by email

• Download the relevant release files from your NRC

Another option for distributing SNOMED CT is using a service-based approach. This approach allows users to access the entire release, or specific parts of the release via query services using a set of predefined Application Programming Interfaces (APIs).*¹ Service-based distribution is illustrated in the diagram below.

The extension producer may choose to provide different types of service-based distribution services, such as:

• A service that provides access to specific SNOMED CT subsets

• A service that provides access to the content within a specific set of modules (e.g. the extension modules)

• A service that provides access to the content in an entire edition, including both the extension content and the modules on which the extension depends

Using a terminology server API, extension producers can support the needs of extension consumers, without the consumer needing to download the full release files themselves. For example, the service could allow access to specific reference sets, support querying for the descendants of a particular concept, or determine the permitted range for a given attribute. Distribution services may also provide options for accessing different editions, and different versions of those editions.

As the range of possible terminology services is extensive, extension producers need to decide on an appropriate API to meet the needs of their consumers. Options include both standardized and commercial APIs, such as:

• SNOMED International's Snowstorm

• API

• HL7 Common Terminology Services 2 (CTS 2)

Extensions can be used to add content to SNOMED CT. These additions can address perceived content gaps in SNOMED CT because content is:

• Outside of the defined scope of the International Edition, and has thus been intentionally excluded

• Within the scope of the International Edition, but is not included as it relates to a new clinical knowledge or a previously unreported omission

In some cases, a content gap will be addressed by adding content directly to the International Edition, but in other cases the content will be rejected for inclusion in the International Edition. When content is outside the scope of the International edition, yet required to support national or local needs, this content may be added to an extension . For example

• Content relevant to an entire country may be relevant to include in a national extension, for example

  • Concepts used for reporting and quality metrics in a specific country or region

  • Representation of specific procedural concepts such as a technique that is used nationally for testing purposes

As illustrated in the image below, content can be added to SNOMED CT by inclusion in the International Edition or in relevant extensions. National extensions will add the content relevant for multiple Affiliates (or stakeholders) within a country or member territory, whereas highly specific content, which is only relevant for a specific vendor product or hospital may be added in a local extension.

In some circumstances, extensions can be used to extend the expressivity of SNOMED CT, for example by expanding the concept model or by specifying additional terminology characteristics and features. SNOMED CT enables the following enhancements to expressivity to be made by adding terminology metadata.

• Creating a new reference set pattern, with new attributes

• Creating a new relationship type, i.e. a new attribute

• Creating a new description type

Once the required metadata has been added, the enhancement can be used within the extension and can be applied to SNOMED CT components in the extension, the International Edition, or any other modules on which the extension depends.

Extending the expressivity of SNOMED CT does not necessarily require the creation of new clinical content in SNOMED CT. However, it does require the addition of concepts within the hierarchy of SNOMED CT and in some cases the addition of reference set members to one of the metadata reference sets.

In section we explain the full set of steps for producing any extension. However, not all of these steps are required for all purposes. If producing an extension for the purpose adding content to SNOMED CT, the following key steps are of particular relevance:

• Create components

  • Principle and process for creating concepts:

  • Principle and process for creating descriptions:

When a concept from the International Edition is inactivated but still in use nationally, action is needed to resolve this. Inactivated concepts should generally not be used in production systems and should be replaced with active concepts, typically guided by historical associations. However, in some cases, circumstances may require continued use of an inactivated concept. This document provides guidance on the principles and considerations involved in managing such scenarios.

The answer to this question is ‘sometimes’, but careful analysis is required before choosing to reactivate. Several factors need to be considered. In some cases, reactivation is strongly discouraged, while in others, it may be acceptable if handled correctly. Our overall advice is to approach reactivation cautiously, evaluating each case individually.

Before reactivating a concept, consider the following:

• Reason for Inactivation : If reactivation is discouraged for a specific reason, a new concept that reflects the intended meaning may be the best option.

There are three distinct situations in which an extension producer may end support for a reference set in an extension.

• Responsibility for maintenance of a reference set is transferred to another extension producer or to SNOMED International

  • For example, a reference set currently maintained as part of a National extension may be transferred to SNOMED International if it has recognized international value.

In SNOMED CT, modules are used to organize content for maintenance and publication purposes. All concepts, descriptions, relationships, and reference set members must belong to a module. When a module is published, as part of a release package, all concepts, descriptions, relationships and reference sets that belong to that module must be published together. According to the logical design, this association between a component or reference set member and its associated module is made using the moduleId attribute. The moduleId attribute refers to a concept that represents and names the module in which a component or reference set is currently maintained. All components and reference set members within a module are maintained by a single organization.

The International Edition includes two modules. The core clinical components of SNOMED CT belong to the . Metadata components, which support the specification of the terminology, belong to the . Both these modules are maintained by SNOMED International.

SNOMED International also maintains several other modules that supplement, rather that being part of, the International Edition. These include the and the .

Components and reference sets maintained by Members and Affiliate licensees are also organized into one or more modules. The module concepts used for this purpose must be created and maintained by the same organization. In most cases, the module concept and its associated descriptions and relationships will belong to the same module to which its identifier refers.

A description may be created in an extension as part of the process of adding a new concept, or adding a translation or alternative synonyms to an existing concept. Extension descriptions are distributed in a which follows the standard . For more details on the principles and processes for authoring descriptions in an extension, please refer to .

In addition to the four common attributes, descriptions also have a conceptId, languageCode, typeId, term and caseSignificanceId.

The conceptId attribute links the description to the concept that it describes. The conceptId may refer to a concept in the same extension module or to a concept in a module on which the extension module depends.

The languageCode is a two-character string, which specifies the language of the description using the standard (e.g. 'EN', 'ES'). Please note that the languageCode specifies only the language of the description (e.g. English or Spanish) and does not indicate the dialect (e.g. US English or GB English). Dialect preferences are represented by language reference sets. Extensions may use a languageCode not used by the International Edition.

The typeId is a SCTID that specifies the type of the description. The value of this attribute must be a descendant of

Reference sets can be added in an extension to meet specific national or local requirements. Reasons for adding a reference set include:

• Specifying a subset of components for inclusion or exclusion

• Mapping between SNOMED CT and other code systems to support data integration or communication

There are a number of reasons for modifying members of a reference set in an extension (depending on the type of reference set), including:

• Updating map records to

  • Refine map rules or map advice

The main reasons for modifying a concept in an extension are:

• The concept is marked as fully defined, but should be primitive

• The concept is marked as primitive, but has now been fully defined

• The concept is inactive but needs to be reactivated

Relationships are added in an extension to link a new concept to one of its supertypes, or to specify defining attribute relationships. Note that at least one hierarchical ( ) relationship is required for each new extension concept. Extension relationships are distributed in a , which follows the standard . For more details on the principles and processes for authoring relationships in an extension, please refer to .

In addition to the four common attributes, relationships also have a sourceId, destinationId, relationshipGroup, typeId, characteristicTypeId and modifierId.

The sourceId identifies the concept being defined by the relationship. In the case of a hierarchical ( ) relationship, the sourceId refers to the subtype/child concept.

The destinationId represents the value of the defining relationship. In the case of a hierarchical ( ) relationship, the destinationId refers to the supertype/parent concept. The destinationId may refer to a concept in the same extension module as the source concept, or any module on which this extension module depends.

The relationshipGroup is an integer that indicates whether or not the relationship is grouped together with other relationships associated with the same source concept. Any relationships with the same sourceId and relationshipGroup integer (other than zero) are considered to belong to the same relationship group. A relationshipGroup of zero (i.e. "0") indicates that the relationship was not grouped with other relationships by the terminology author. For more information on relationship groups, please refer to Relationship groups in SNOMED CT.

As part of the assessment process to determine where the requested content belongs, following points are important to take into consideration:

1. The scope of various SNOMED CT Editions

2. Whether the request is permitted given the predefined principles around:

Whenever a new description is added in an extension, the language preferences associated with that description must be specified. This is done by adding rows to a to indicate whether each description is or in the given language or dialect.

As previously mentioned, all reference sets use six common attributes. In addition to these, a also includes an acceptabilityId. The table below explains how each of these attributes is populated in a .

Table: Summary of language reference set attributes