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.
item-identifiers should not be generated so as to have meaning. They should be regarded as meaningless numbers. (Recall that an item identifier precedes the namespace identifier in an SCTID.)
Generating UUIDs
Reference Set Members are identified with UUIDs instead of SCTIDs, so extension producers will also need the mechanism to generate UUIDs. UUID stands for Universally Unique Identifier, and each UUID is represented as a 128-bit number.
UUIDs are globally used to identify information in computer systems and they are for practical purposes unique, without depending on a central registration authority or coordination between the parties generating them. While the probability that a UUID will be duplicated is not zero, it is close enough to zero to be negligible.
Thus, anyone can create a UUID and use it to identify something with near certainty that the identifier does not duplicate one that has already been, or will be, created to identify something else. Information labeled with UUIDs by independent parties can, therefore, be later combined into a single database, or transmitted on the same channel, without needing to resolve conflicts between identifiers.
Several online platforms are available providing support for generating UUIDs, and for parsing their textual representation.
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.
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
An NRC may add components in their national extension and then forward a request to SNOMED International for inclusion in the International Edition
Note that, content added to an extension can later be promoted to another extension or to the International Edition. For more information, please refer to 5.4.1.1 Promotion and Demotion.
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.
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 role of NRCs related to SNOMED CT licensing.
The following pages will examine the steps involved in preparing an extension for distribution and introduce different approaches to distribution.
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.
Extension maintenance cycle
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
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 Preproduction Releases for more information.
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.
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:
Identify changes
Assess change impact
Update extension
After change management has been performed, it is important that thorough review and validation of the resulting extension is performed.
In the following sections we discuss the three phases of change management.
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.
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 | is a| 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
Principles
Inactivating Extension Relationships
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').
Inactivating Relationships from the International Release
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 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').
Process
The table below provides a summary of the process to follow when inactivating a relationship in an extension.
File Type
Process
Relationship
A new row representing a new version of the relationship being inactivated is added to the file.
The attributes of the new relationship version are set as follows:
id is set to the same relationship identifier as the relationship being inactivated
effectiveTime is set to the date the extension will be published
active is set to 0 to indicate that the relationship will become inactive at the time of publication
moduleId is set to identify a module in the extension
sourceId, destinationId, typeId, characteristicTypeId, typeId are set as per the previous version of this relationship
These concepts represent a distinct type of clinical concept
Concept Addition Rules
Subtype descendants of the top level clinical concepts may be added in an extension.
Additional Notes
Concepts added in these hierarchies should conform with:
Concept model rules applicable to the relevant concept domain
Quality standards applicable to all SNOMED CT clinical content.
These concepts should be classified to generate a set of inferred relationships in necessary normal form, for inclusion in the extension distribution files.
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.
The planning phase ensures that the requirements can be met by the extension design, resources and processes used.
The preparation phase ensures that the technical prerequisites are in place, including the namespace, module(s), module dependencies and appropriate tooling.
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.
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.
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 terminology producer themselves.
All changes made to SNOMED CT components or reference set members should be represented as new versions and assigned to a module owned by the terminology producer. No changes are permitted to content of the International Release. 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.
Any substantive improvements or corrections to the content in the International Edition that is made in an extension should be submitted to SNOMED International in a timely fashion to improve the quality of the International Edition for all users.
Reviewand Validation - SNOMED CT extension content should be validated using automated tests both at the time of authoring and before a release is packaged for distribution. In addition, manual review of the terminology content is also vital to ensure that it meets the quality standards for usability and clinical safety which cannot be tested automatically.
Distribution - This involves classifying the extension content *1 , packaging the release files, validating the distribution package, and making the release package available to terminology consumers.
Maintenance - A SNOMED CT extension must be maintained to respond to new change requests, and to ensure that the consistency and integrity with the International Edition (and other modules on which it depends) is maintained appropriately.
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.
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.
Change request reporting structure
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.
For more information about the processes in each country, please consult the relevant Member page.
SNOMED International provides the SNOMED CT Content Request Service to gather and process requests for additions and changes to the content of the SNOMED CT International Edition. This service is directly accessible by National Release Centers (NRC) in Member countries and recognized Terminology Authorities within organizations with whom SNOMED International is actively collaborating. Requests that meet inclusion criteria for the International Release are addressed by SNOMED International staff. Some of the reasons behind International content requests are described in the table below.
Table: Reasons for requesting content to be added to the International Edition
Example use case
Description
Gaps in coverage of scope
Clinical meanings that fall within the scope of the International Edition that are not currently represented by concepts in the International Edition
Changes in clinical knowledge
Evolving clinical knowledge introduces clinical meanings that require the addition of new SNOMED CT concepts
Incomplete definitions
A concept in the International Edition that is missing one or more valid defining relationships
Missing synonyms
A concept in the International Edition that is missing one or more widely used synonymous terms
If a request is deemed to have high priority, it should result in action in the next release cycle. However, requests constituting a significant change which impacts other content may take longer to implement. If a request is declined, a reason and explanation are provided to the requester, who may choose to appeal the decision to the Head of Terminology. For more information about the CRS, please refer to the CRS User Guide.
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.
Content Promotion
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.
Once promoted, a new version of the component is available in the International Edition with a new EffectiveTime , an international moduleId , and the same SNOMED CT identifier as was used in the originating extension. From that point forward, SNOMED International becomes responsible for maintaining the promoted content. Future releases of the extension content alone, which are dependent on the new version of the International Edition (that contains the promoted content), will no longer include the promoted content in their Snapshot and Delta release files.*1 The promoted content will, however, continue to appear in the Full release files of the extension Edition with an older EffectiveTime to reflect the ownership history of this content within the extension. Please note that the SNOMED CT identifiers of all promoted content will remain unchanged, and will therefore continue to include the namespace identifier of the originating organization.
Please note that it is essential that the promoted content is not inactivated in the extension from which it was promoted, as this would make it appear to users of the extension that the content is inactive. It is also important that the meaning of the content remains the same after it has been promoted, to ensure that the component identifiers permanently represent the same clinical meaning.
The diagram below illustrates how extension content is promoted to the SNOMED CT International Edition.
Promoting content to the International Edition
Content Demotion
In some circumstances it may be necessary to demote SNOMED CT components. Demotion means moving a component from a given module to a module that is dependent on it. For example, moving a concept (and its associated descriptions and stated relationships) from the International Edition to a National Extension.
Content demotion is generally not recommended, because there are several risks associated with the management of demoted content. Once demoted, a different version of the component will be seen in different editions, and this redundancy needs to be managed carefully. Consideration should, therefore, be given when making the decision to demote a component.
If content demotion is deemed necessary, then it is very important to use a safe approach. As shown in the diagram below, the recommended approach for demoting SNOMED CT content is to inactivate the component in the source module and activate the component in the destination module at a more recent effective time.
Demoting content from the International Edition to extension
Updates should also be made to the respective component inactivation reference sets to indicate that the component has been inactivated. For more information on inactivation and historical associated reference sets, see .
The following diagram shows the RF2 file changes that are required to demote an example concept from the international edition to an extension module. Please note that it is essential that the effectiveTime of the active component in the destination module is more recent than the effectiveTime of the inactive component in the source module. This is done to ensure that the demoted component is seen as active in any edition that uses the extension module to which it was demoted.
File changes required to demote a concept
Some approaches to content demotion that have previously been proposed are considered to be unsafe. The content demotion approaches that should never be used include:
Removing every instance of the component from the International Edition (or source edition)
This approach will delete the history of the component for users of the International Edition, who do not use the demoted content. The history of each SNOMED CT component should be traceable in the edition in which the component was created.
Retaining the component active in the source module, and creating a new version of the component (i.e., with a more recent effectiveTime) in the more dependent (extension) module
This approach will make the component visible and accessible in the source edition, and users of the source edition would not be aware that the component was demoted to a more dependent (extension) module
This approach may lead to inconsistency between the version of the component in the International Edition and the version in the more dependent (extension) module.
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
Principles for modifying reference sets include:
Reference sets can be modified by changing the value of the active attribute or the value of the moduleId attribute, i.e. for activating or inactivating the reference set, or moving the reference set to another module (a module on which the current module depends).
The reference set metadata concept is always primitive and the concept can therefore not be changed from primitive to fully defined, or from fully defined to primitive, i.e. the value of the definitionStatusId attribute should be primitive for all versions of the reference set
The reference set type should not be changed, i.e. the |is a| relationship, linking the reference set to the appropriate reference set type concept should not be changed
The only situation where the the reference set type may change is if the reference set was originally misplaced in the SNOMED CT hierarchy.
If the reference set needs to be changed to a different type, (for example, from a simple reference set to an ordered component type reference set) then it would require the original reference set to be inactivated and a new reference set to be created in accordance with the Descriptor for that reference set type.
Reference sets that belong to a module which is not managed by the extension producer should not be modified.
Process
Modifying a reference set created within the extension module
The process for modifying the reference set concept, is similar to the general process for modifying concepts in SNOMED CT. Therefore, please refer to Modify Concept in an Extension for further guidance.
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:
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.
Please note that this guide focuses on guidance for extension producers. Specific implementation guidance for extension consumers should be provided by the extension producer themselves, to supplement the general implementation guidance provided by SNOMED International (see ).
This concept is the supertype for all SNOMED CT metadata.
Concept Addition Rules
No new subtype children may be added in an extension.
Please refer to the following pages for guidance on the addition of subtype descendants.
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
Subhierarchy
Purpose
Link to More Information
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.
Preparing for Distribution
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
Tooling Requirements
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 .
The table below summarizes the overall tooling considerations by category and services required. These are the tools required throughout the extension lifecycle including creation, management an distribution. Please note that this is not meant to be an exhaustive list, but instead summarize some of the key tools and services required.
Management of Inactivated International Concepts within an Extension
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.
Add Description in an Extension
The main reasons for adding descriptions in an extension are:
To translate SNOMED CT into another language
To add terms that are preferred or accepted within a local setting, for example
Common clinical terms that facilitate searching for concepts
Assessing Change Impact
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
Review and Validation
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.
General Authoring Principles
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.
Used to test format and content and to gather early feedback.
Errors identified can be corrected without maintaining permanent version history.
Formerly known as technology preview releases.
May be withdrawn or replaced if significant issues are identified.
If confirmed as a production release, all updates are fully version-tracked from the beta release date.
Extension validation involves both automated and manual processes
Linkage concept (linkage concept)
Links two or more concepts together to express compositional meanings. All concept codes that can be used as a Relationship Type are included under [
Namespace concept (namespace concept)
Contains concepts that represent an assigned Extensionnamespace identifier.
OWL metadata concept (OWL metadata concept)
Contains concepts that are used in
OWL ontology reference set (OWL ontology header (OWL metadata concept) and OWL ontology namespace (OWL metadata concept))
OWL axiom reference set (Disjoint classes axiom (OWL metadata concept) and General concept inclusion axiom (OWL metadata concept))
Core metadata concept (core metadata concept)
Provides structural information required to support International Edition data. This supporting information includes sets of enumerated values that apply to attributes of concepts, descriptions and relationships.
Type of Concept : The impact of reactivation varies by concept type. For example, reactivating an administrative concept inactivated due to being out of the scope of the International Edition, may be acceptable. However, reactivating a clinical concept inactivated due to ambiguity could compromise patient safety and should be avoided.
Usage : What is the frequency of use? How will the inactivation impact users and systems? There needs to be a good clinical use case or business reason for reactivation. It may be used as an interim step whilst a more long-term solution is put into place and then the concept in question is inactivated again. If the concept is used locally or within a single country, reactivation may be possible. However, if it supports cross-border interoperability, reactivation is strongly discouraged. In such cases, creating a new concept in your extension is preferred, ensuring that any involved consumers can unambiguously interpret the meaning.
Please note that multiple extensions may choose to reactivate an inactivated concept, resulting in multiple versions with potentially conflicting interpretations or uses. Therefore, it is essential that these reactivated concepts are not used for cross-border interoperability.
The table below summarizes the actions to take when considering reactivating an inactivated concept, depending on the reason for inactivation.
Reason for inactivation
Guidance
Considerations
Ambiguous
Do not reactivate
The historical association target concepts should be considered as replacements. In the event these are not suitable then a new unambiguous concept should be created.
Classification-derived component
Content type
Guidance
Considerations
Clinical concept
Discouraged
Consider the reason for inactivation
Administrative concept
May be reactivated
An inactivated extension concept may be reactivated in more than one extension module, however prior to doing so consideration needs to be given to
The potential for the meaning of the concept to be understood differently in different jurisdictions.
The potential for the use of the concept in more than one jurisdiction.
If the concept is reactivated in multiple extensions, one might assume that the meaning of the component is the same as the SCTID is the same. If this component is then exchanged between jurisdictions, there is the possibility of inaccurate interpretation of meaning.
The January 2021 International Release included the bulk inactivation of “on examination concepts. These concepts had come from the UK as part of CTV3 and were in high usage by UK GP’s. The UK NRC reactivated these concepts in bulk to prevent disruption to users. The concepts are now being reviewed and some are being inactivated within the UK extension.
In 2021, over 2000 concepts relating to breeds were inactivated from the international release and reactivated in the veterinary extension. Examples: 64158000 |Angora goat (organism)|, 62137007 |Labrador retriever (organism)|.
51631009 |Ligation of major artery of extremity (procedure)| was inactivated as ambiguous for September 2023 release. This concept should not be reactivated in an extension due to the ambiguity of the term ‘major’ - no clear definition of this exists.
When creating a new concept to replace an inactivated concept, it’s helpful to establish a historical association between the inactivated international concept and the active extension concept.
Historical associations are important because they form the backbone for maintaining continuity and traceability of clinical data when concepts are inactivated or replaced. These associations allow systems to link inactivated concepts to their appropriate replacements or related active concepts, ensuring that the integrity of historical data is preserved.
A key reason for establishing historical associations is to facilitate the querying of historical data using the Expression Constraint Language (ECL). ECL enables the retrieval of SNOMED CT concepts based on a range of criteria, including concepts with established historical associations. When a historical association is created between an inactivated concept and its replacement or related concept, history supplements enable users to include inactivated concepts in their queries. This ensures that historical clinical information remains accessible and interpretable, even as terminology evolves.
In most cases, historical associations will already exist between the inactivated concept and an active international concept. However, to ensure complete traceability, you should also create a historical association linking the inactivated concept to the new extension concept.
Please refer to the following pages to learn more about managing concept inactivation and historical associations:
Can I reactivate inactivated international concepts in my extension?
Reason for inactivation
Reactivation in more than one extension module
Examples:
Managing historical associations for a new concept
Patient friendly terms
To support the creation of new concepts in the extension, which each require at least two descriptions
As depicted in the image below, a description in an extension may refer to any concept in the same extension (Extension B), any concept in a module upon which the extension modules depend (Extension A), or any concept in the International Edition.
Descriptions can reference concepts in other modules on which the extension modules depend
Note that the green and orange triangles pointing to the purple circle represent a situation in which a description is added to an extension that describes an international concept. These extension descriptions supplement the descriptions that are already part of the International Edition.
Descriptions in SNOMED CT are represented in a description file. At least two descriptions must be created for each new concept in an extension:
Note that all extension producers should create an unambiguous FSN in US English for each new concept. Additional FSNs may also be created to support other languages and dialects.
A description of type | Synonym| , in either English or an alternative language
The acceptability of new descriptions must be specified in a language reference set.
The following principles apply to adding FSNs in an extension.
There may be more than one active description with a typeId of | Fully specified name| (FSN).
However, only one FSN should be marked as preferred for use in a given language or dialect by a specific Language Reference Set.
Every extension concept must have an unambiguous FSN in US English.
The US English FSN is the point of reference for the meaning of all concepts in the SNOMED CT International Edition.
The US English FSN is used to facilitate sharing and to resolve potential issues related to the interpretation of the meaning.
Extensions producers are permitted to create a FSN in each of their native languages.
This means that a non-English FSN may be marked as the preferred FSN in a specific language reference set in the extension.
Consequently, a concept may have more than one FSN. However, only one may be preferred in a specific language reference set.
Where a concept has only one active description with a typeId of
Unlike FSNs, synonyms are not necessarily unique between concepts, as the same term can be used to describe more than one concept.
The preferred term is the synonym marked as preferred for use in the Language Reference Set for a given language or dialect.
There must be at least one description with a typeId of | Synonym| and an acceptabilityId value of | Preferred| for each concept associated with a description in a given language reference set.
When a description is created in an extension, as part of a translation or to provide a localized synonym for an existing concept, a new row should be added in the relevant language reference set to indicate whether the description is | Preferred| or | Acceptable| in the given language or dialect.
The table below provides a summary of the process to follow when adding new descriptions to an extension.
File Type
Process
Description
A new row which represents the new description is added to the description file.
The attributes of the new description are set as follows:
id is set to a new descriptionId allocated within the extension namespace
effectiveTime is set to the date the extension will be published
active is set to 1 to indicate that the new description will be active at the time of publication
A concept, which is referenced by a reference set member (i.e. the referencedComponentId) in the extension, has been inactivated.
Reference sets are permitted to reference inactive components as there are valid use cases for this. However, it is recommended that inactive components are not for capturing clinical data. Therefore, if the extension reference set may be used by consumers for clinical data capture, the associated reference set member should be inactivated, and a potential replacement considered. For more information please refer to . Potential replacements for the inactivated concept can be found in the relevant
A concept, which is the parent of an extension concept (i.e. it is the destinationId of a relationship of type ), has been inactivated.
To retain the referential integrity of the extension, it is important that all extension concepts are subsumed (via active concepts) by the root concept in the International Edition. When the parent of an extension concept is inactivated, the associated relationship in the extension must also be inactivated, and a new relationship created to link the concept to an alternative international parent concept. For more information please refer to and .
A concept, which is used in an extension relationship (i.e. in the sourceId , typeId or destinationId of the relationship), has been inactivated.
When a concept is inactivated, all relationships in which that concept participates in (as the sourceId, typeId or destinationId) must also be inactivated. For more information please refer to .
When an extension concept references a concept from the International Edition which has been inactivated, the extension concept should be updated to apply active concepts. This may involve updating the modeling of a concept to use the suggested active replacements as they are stated in the relevant .
Concept additions
Extension Impact
A concept has been added to the International Edition, on request by the extension producer, and a corresponding concept has been temporarily added to the extension in the interim.
If a new concept is added to the International Edition, which represents the same meaning as a concept in the extension, the extension concept should be inactivated. Any references to the inactivated extension concept should be replaced by references to the new international concept. For more information, please refer to , Authoring Relationships and Authoring Reference Sets.In general, checks should to performed ensure that no fully defined concept in the extension has the same logical definition as a concept in the International Edition (or any module on which the extension depends).
A concept has been added to the International Edition, on request by the extension producer, for use in a national reference set.
A new member of the extension reference set should be added to refer to the new international concept. For more information, please refer to in .
Description inactivations
Extension Impact
A description, which is referenced by a reference set member (i.e. the referencedComponentId) in the extension, has been inactivated. For example, the description may be used in a national language reference set.
The reference set member that references the inactive description should be inactivated. For more information, please refer to .In some situations, the inactivated reference set member may need to be replaced by a new member. For example, if the inactivated description was being used as a preferred term in a language reference set, then an alternative preferred term should be defined for the associated concept.
Description additions
Extension Impact
A new description has been added to the International Edition, and the extension specifies the acceptability of all international descriptions.
Reference set inactivations
Extension Impact
The concept identifying a reference set, which is used in the extension, is inactivated.
If the reference set is not used in the extension, then no action is required.
If the reference set is used in the extension, a decision should be made as to whether or not the reference set is still required. If the reference set is required, then a new local version of the reference set may need to be created. For more information, please refer to .
A member of a reference set, which is used in the extension, is inactivated..
If the extension uses extension reference set members to adapt an international reference set, a decision should be made as to whether or not the inactivated member is required in the extension. If it is, then the inactivated reference set member may need to be reactivated in the extension. If not, then no action is required. For more information, please refer to .
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.
Some reference sets, which belong to the International Edition (e.g. the and the ) were designed to be extended by adding new members in an extension module.
Other reference sets, which belong to the International Edition (e.g. ) may be adapted in an extension module, following the principles described in
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 module dependency reference set.
Figure 5.4.1-1: Examples of correct and incorrect module assignment in an extension
For information on how to move content from one module to another, please refer to Promotion and Demotion.
This concept is the supertype for metadata used directly by SNOMED CT components.
Concept Addition Rules
No new subtype children may be added in an extension.
See tables below for concept addition rules for each of the subtypes of .
Characteristic Type
Inactivate Description in an Extension
Inactivate Description in an Extension
Purpose
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
The description fails to comply with the current editorial guidance. For more information, please refer to Terming and Naming Conventions in the Editorial Guide.
The description contains a technical error, such as a typographic error
Descriptions created in an extension can be inactivated if necessary. This is done by inactivating both the description itself and the associated member(s) of the relevant language reference set(s). It is recommended that the reason for inactivation is specified in the see .
Descriptions which belong to the International Edition (or another module on which the extension depends) should not be inactivated in the extension. If there is a requirement to remove international descriptions from an extension, this should be accomplished by excluding the given description identifiers from the relevant language reference set(s). Two possible approaches for this are described below.
This approach involves creating a copy of one of the language reference sets distributed with the International Edition, and adding or removing members as required. All members of the new language reference set must be assigned to a module in the extension. When using this approach, the extension producer is responsible for maintaining the new language reference set. If the extension producer wants their new language reference set to incorporate future changes made to the international language reference set, they are responsible for maintaining these changes.
An extension producer may choose not to create a new copy of an international language reference set. Instead, they may use the international language reference set directly, and exclude any members of this reference set by inactivating the relevant members in their extension module. To exclude a description from an international language reference set, a new version of the reference set member is created with the following attributes:
id is set to the same value as that of the member of the international language reference set
effectiveTime is set to the release date of the extension
* Note that this date should be after the effectiveTime of the reference set member in the international release
active is set to '0' to indicate that the member is being inactived _
_
moduleId
Please note that if a new version of the reference set member is published in the International Edition, this will become the current version of that member. It may, therefore be necessary to create a new inactive version in the extension with a more recent effectiveTime.
This table describes the process of excluding descriptions in an extension.
File Type
Process
Modify-concept-in-an-extension
Modify Concept in an Extension
Purpose
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
The concept is active, but needs to be inactivated (Note - This scenario is described further in .)
If an extension producer needs to modify the definition of a concept, this will necessitate adding, modifying or inactivating the relationships for which the given concept is the source. For more information, please refer to .
If an extension producer needs to modify the terms used to describe the concept, this will necessitate adding, modifying or inactivating the descriptions associated with the concept. For more information, please refer to .
The clinical meaning of each concept in SNOMED CT is permanent, and can not be modified over time. This clinical meaning is captured by the concept's Fully Specified Name. Changing the clinical meaning of a concept therefore requires inactivating the concept, and creating a new concept that represents the new meaning.
The following changes, however, are permitted:
Modifying mutable attribute values, such as definitionStatusId.
Adding, modifying or inactivating descriptions, including changing the concept's Fully Specified Name to conform to editorial policy (as long as there is no change in clinical meaning). Please refer to .
Changing the way that a clinical meaning is formally defined. This can be done by adding, modifying or inactivating the concept's defining relationships and/or changing the definition status of the concept. Please refer to .
The attributes of a concept may be modified, as long as the change is limited to the values of its mutable attributes. The values of immutable attributes should never be modified.
The effectiveTime attribute is used to support the versioning of each concept. Permitted concept modifications therefore include:
active : Changing the concept's active attribute from active to inactive, or from inactive to active.
definitionStatusId : Changing the concept's definition status from primitive to fully defined, or from fully defined to primitive.
moduleId : Changing the concept's module. For example, this may occur when a concept is promoted. Please refer to .
It should be noted that extensions should not modify the attributes of an international concept, unless this modification is necessary to meet legitimate clinical needs or to correct identified clinical issues. Any new version of an international concept that is created by an extension producer (other than SNOMED International) and which modifies the concept's mutable attributes, should be:
Assigned to an extension module (and not an international module) to reflect the fact that the modification was not made by SNOMED International.
Submitted to SNOMED International with an explanation as to why the change was necessary.
The table below provides a summary of the process to follow when modifying a concept in an extension.
File Type
Process
Add Members to a Reference Set
Purpose
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
Principles
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 Practical Guide to Reference Sets for detailed instructions on the and for identifying the SNOMED CT components that will be referenced by the members of the reference set.
However, each reference set member will be represented in the reference set in accordance with the following principles and process.
Reference set members may be added to reference sets belonging to modules in
The producers extension
The International Edition
Other extensions (which the producers extension modules are dependent on)
Reference set members created in the extension should be created within the module of the extension producer, so that it is possible to distinguish the reference set members created within the producers extension from reference set members created by other organisations (i.e. belonging to other modules).
Even though the individual reference set members belong to the module of the extension producer, the actual components that are referenced by the reference set member, may belong to modules in
The International Edition
The extension in which the reference set and its members are produced
Other extensions (which the producers extension modules are dependent on)
The table below provides a summary of the process to follow when adding members to a reference set.
File Type
Process
Planning
Before starting the production of an extension, thorough planning is required to facilitate its successful development and subsequent use. This phase should include careful long-term and short-term planning, including consideration of the following topics:
Scope and design of the extension
Practical aspects related to extension development
Ongoing operations and maintenance
The planning phase is about ensuring a balance between the scope and magnitude of the extension and the available resources, and about selecting appropriate methods and processes for the development, implementation and maintenance of the extension. It is important to be as thorough as possible during this phase to avoid unforeseen issues and to mitigate potential issues in subsequent phases of the extension lifecycle.
Assessing Requests
Once requirements have been identified and submitted as requests for additions or changes, the extension producer need to review and assess these requests. This entails an assessment of whether the requested content is relevant for inclusion in:
The International Edition
A National extension
Another extension
Foundation Metadata Concept Hierarchy
Modify Description in an Extension
The main reasons for modifying a description in an extension are:
The description term contains an error that needs fixing
The case significance of the term needs to be changed
The acceptability of the description has changed - e.g. from acceptable to preferred, or from preferred to acceptable.
Making changes to existing descriptions requires careful consideration, because the descriptions may have been used in clinical records to represent the meaning of the associated concept. Changes are, however, permitted, as long as only mutable attributes are modified. Immutable attribute values should not be modified.
Classifying an Edition
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 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
Packaging and File Naming
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:
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.
The module dependencies used to define the contents of an edition are represented using a .
Inactivate Concept in an Extension
Concepts may be inactivated in an extension for various reasons including:
The concept is erroneous, obsolete or out of scope
The concept is ambiguous, and must be replaced with one or more concepts whose meaning is clear
The concept is redundant, because another concept has the same clinical meaning or definition
Please note that concepts that are promoted from the extension into the International Edition (or a module on which the extension module depends) are
Distribution Approaches
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.
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.
Pre-release Validation
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
Validation Type
Purpose
Examples
Modify Members of a Reference Set
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
Change the target of a map
Identifying Changes
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:
Validation During Authoring
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
Validation Type
Purpose
Examples
Authoring Reference Set Members
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.
Concept
A new row, which represents the new version of the concept, is added to the concept file.
The attributes of the new version of the concept are set as follows:
id is set to the conceptId of the concept being modified
effectiveTime is set to the date the extension will be published
active is set to indicate whether or not the concept is active at the given effective time ('1' for active and '0' for inactive)
moduleId is set to the conceptId of a module that is managed by the extension producer
definitionStatusId is set to indicate whether the concept is primitive or fully defined
across all language codes within a release, then that description can be assumed to be the FSN for all languages and dialects, and need not be explicitly included in every language reference set.
moduleId is set to the conceptId of a module that is managed by the extension producer
conceptId is set to the id of the concept to which this description applies
languageCode is set to the two character code of the language in which this term was authored
typeId is set to indicate the type of the description
The addition of at least one module concept is essential for all extensions. More than one module concept may be added to enable content to be organized into separate modules.
No new subtype descendants may be added in an extension.
Additional types permitted provided these are additive and do not replace the synonym or fully specified name values
No new subtype descendants may be added in an extension.
The addition of modules that form part of the extension is required. These new module concepts must either be direct children of or descendants of a child of that is owned by the same extension provider. It is not permitted to add modules as subtypes of modules maintained by another extension provider.
Each module concept added within an extension must have an identifier that contains the extension's namespace identifier.
is set to a module in the extension
refsetId is set to the same value as that of the international language reference set
acceptabilityId is set to the same value as in the original member of the international language reference set
Description
To exclude descriptions in an extension, a new inactive version of the description is added to the description file.
The attributes of the new version of the description are set as follows:
id is set to the descriptionId of the description being inactivated
effectiveTime is set to the date the extension will be published
active is set to '0' to indicate that the description is being inactivated
moduleId is set to identify a module in the extension
The remaining attributes are set to the same value as in the previous version of the description.
Language Reference Set
A new row, which references the description to be excluded, with the following attribute values:
id is set to the same value as the reference set member being excluded
effectiveTime is set to the date the extension will be published
active is set to '0' to indicate that the reference set member is being inactivated
moduleId is set to identify a module in the extension
The remaining attributes are set to the same value as in the previous version of the reference set member.
The represents the reason that each inactive description was inactivated.
When inactivating a description, it is good practice to specify the reason for inactivation in this reference set.
The allows extension consumers to understand the reason that each description was inactivated. Please visit for further information.
Attributes specific to the reference set type are set. For more information, please refer to the .
Reference Set
A new refset row is created with a unique id. The data type for this id is UUID and the id can be generated using a UUID generator. Note that a namespace identifier will not be part of this id.
Versioning and module identification attributes are set accordingly:
effectiveTime is set to the date the extension will be published
active is set to reflect the status of the reference set member, i.e. 1 for active
moduleId is set to identify a module concept managed by the extension producer
Attributes common for all reference set types are set accordingly:
refsetId is set to the identifier of the concept used to identify and name the reference set. Note, the value of refsetId will be the same for all members in the reference set
referencedComponentId is set to the identifier of the SNOMED CT component or reference set, which is referenced by this specific reference set member
This extension (i.e. the one being managed by this extension producer)
Requests will typically be for addition of new components (concepts, descriptions or relationships) or changes to or inactivation of existing SNOMED CT components or reference sets. However, sometimes there are requests for a completely new reference set.
As part of the assessment process to determine where the requested content belongs, these points should be taken into consideration:
The scope of various SNOMED CT Editions
Whether the request is permitted given the predefined principles around:
Editorial rules and;
Retaining the referential integrity of SNOMED CT
When a SNOMED CT Member, or Affiliate organization which maintains an extension, identifies a requirement for new content they should evaluate the request by considering the following questions:
Does the requested content fall within the defined scope of the International Edition?
Is the requested content likely to be required by, or of value to, more than one Member territory?
If the answer to both these questions is "yes", then organization should submit a request to SNOMED International for inclusion of the new content. When a request originates in an Affiliate organization, it should be submitted to a National Release Center who will then forward the request to SNOMED International. In general, this content should not be added to a National or local extension, as content that falls within the defined scope of the International Edition and is required by two or more Member territories. However, in cases where there is an urgent requirement, an extension producer may add the content to their own extension as an interim solution. Please refer to Interim Content Additions below.
Similarly, if the answer to one or both of these questions is "no", the content may be suitable for inclusion in a National Edition. In this case, the following questions should be considered:
Does the requested content fall within the defined scope of a National Edition?
Is the requested content likely to be required by, or of value to, more than one organization within the Member territory?
If the answer to both these questions is "yes", then organization should submit a request to the National Release Center for addition of the required content into the National Edition. If the answer to one or both of these questions is "no", it should be considered for inclusion in a local extension. In situation where the request is considered to be out of scope of SNOMED CT, it may be rejected. The table below provides additional detail on the various outcomes in these considerations.
Table: Considerations relating to appropriateness of content at various levels
Relevance of requested content
Description
Within the scope of the International Edition
If the content requested is within the scope of the International Edition, the organization should request that the content should be added to the International Edition.
As SNOMED CT is a global clinical terminology, the scope of the International edition of SNOMED CT is constrained by a set of principles. For inclusion in the International edition, concepts must be
Useful in more than one country
Necessary for healthcare conformance and interoperability
Within the scope of a clinical terminology
Within the scope of other extension, (National, third-party, or local extension) but outside the scope of the International Edition.
The scope of a national edition may permit the addition of content which falls outside the scope of the International Edition but is required within a country, region or territory. If the content requested is within the scope of a national edition, a request should be submitted to the relevant National Release Center.
An organization may also use an extension which was produced by another organization, such as a vendor, regional body or specialist group. In this case, requests for content which fall within the scope of these extensions should be submitted to the relevant extension producer.
When there is an urgent need for additional content, it may be added to an extension as an interim measure, pending addition to a national edition or externally maintained extension. For more information, please refer to Interim content additions below.
Outside the scope of other extensions, but relevant to the organization requesting the content.
When determining whether or not a request for additions or changes should be accepted for inclusion in any SNOMED CT edition, it is important to ensure that the addition or modification does not break the referential integrity of SNOMED CT. It is also important to assess whether the definition on new concepts has undesirable effects on the existing content. Finally, it should be ensured that every addition of or modification to SNOMED CT concepts conform to the rules specified by the concept model. The Authoring section describes key principles which ensure that referential integrity is retained and that components and reference sets are created or modified in an extension in accordance with the editorial principles.
SNOMED International does not recommend that extension producers make changes which result in modifications to the International release as this can cause interoperability issues. Substantive errors, or improvements to content in the International release which are mitigated by content in an extension, should therefore be forwarded to SNOMED International in a timely fashion to improve the quality of the International release.
In circumstances where the International release has been impacted by modifications in a national or local extension, a disclaimer notifying users of the differences between the extension release and the International release must accompany the national extension distribution files.
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
An NRC may add components in their national extension and then forward a request to SNOMED International for inclusion in the International Edition
Note that, content added to an extension can later be promoted to another extension or to the International Edition. For more information, please refer to Promotion and Demotion.
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 to 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 somes 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.
Change request reporting structure
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.
For more information about the processes in each country, please consult the relevant Member page.
SNOMED International provides the SNOMED CT Content Request Service to gather and process requests for additions and changes to the content of the SNOMED CT International Edition. This service is directly accessible by National Release Centers (NRC) in Member countries and recognized Terminology Authorities within organizations with whom SNOMED International is actively collaborating. Requests that meet inclusion criteria for the International Release are addressed by SNOMED International staff. Some of the reasons behind International content requests are described below.
Table: Reasons for requesting content to be added to the International Edition
Example use case
Description
Gaps in coverage of scope
Clinical meanings that fall within the scope of the International Edition that are not currently represented by concepts in the International Edition
Changes in clinical knowledge
Evolving clinical knowledge introduces clinical meanings that require the addition of new SNOMED CT concepts
Incomplete definitions
If a request is deemed to have high priority, it should result in action in the next release cycle. However, requests constituting a significant change which impacts other content may take longer to implement. If a request is declined, a reason and explanation are provided to the requester, who may choose to appeal the decision to the Head of Terminology. For more information about the CRS, please refer to the CRS User Guide.
Final disclaimer goes here: (proposal found here: )
Interim Content Additions
Change Request Reporting Structure
Hierarchy
Purpose
The subtype children represent reference set types. Subtype descendents represent either reference sets of the type specified by their supertype parent or groups of reference sets of a type specified by their supertype parent.
Examples
Reference set types
Concept Addition Rules
New subtype children may be added in an extension, as long as they represent a new and distinct Reference Set Type (i.e. not an individual reference set).
New subtype descendants may be added in an extension, as long as they represent a Reference Set of the type defined by its supertype ancestors.
Hierarchy
Purpose
The subtype children represent named attributes used to represent columns in reference sets.
Also includes two special subtypes: and which are separately documented.
Examples
Concept Addition Rules
Hierarchy
Purpose
These concepts represent data types associated with reference set attributes.
Examples
Concept Addition Rules
Hierarchy
Purpose
These concepts represent values that can be applied to specified columns in a reference set.
Concept Addition Rules
Additional subtype children may be added in an extension to represent values applicable to a newly added reference set or reference set type.
Subtype descendants should not be added in an extension, except where they are descendants of a subtype child added to support a newly added reference set.
The conceptId field, the languageCode field and the typeId field cannot change between different versions of the same description. If a change is required to one of these immutable attributes, then the existing description should be inactivated, and a new description with the required attribute values should will be added.
Extension producers should not modify descriptions, which are part of the International Edition. When issues with international descriptions arise, SNOMED International should be notified so the issue may be addressed in a subsequent release.
The table below lists the various description attributes and their mutability. The following modifications to the mutable attributes are permitted
Changing the term of the description. Please note that only limited changes may be made to the term field, as defined by editorial rules.
The International SNOMED CT Editorial Guide states when making a minor change to an FSN, a new description must be created and the old description must be inactivated.
Permitted changes include modifications that do not alter the meaning, for example a spelling correction. For a list of permitted changes, please refer to the appropriate section of the :
FSNs - refer to
When in doubt, an extension producer should inactivate the description and add a new description with the required term.
Table: Mutability of description attributes
Field
Data type
Purpose
Mutable
Part of Primary Key
id
SCTID
Uniquely identifies the description.
NO
An extension producer may also need to change the acceptability of a description. For example, a synonym may change from being acceptable to preferred, or from being preferred to acceptable. This type of change does not require any modifications to the Description file. Instead, the associated member of the relevant language reference set must be modified. For more information, please refer to Modify Members of a Reference Set.
The table below provides a summary of the process to follow when modifying descriptions in an extension.
File Type
Process
Description
A new row which represents a new version of the description is created.
The attributes of the new version of the description are set as follows:
id is set to the descriptionId of the description being modified
effectiveTime is set to the date the extension will be published
active is set to 1 to indicate that the new version of thedescription will be active at the time of publication
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 | is a| 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 | is a| 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.
This diagram shows the stated definition of the concept . An is a procedure in which the appendix structure is excised.
Stated definition of |Appendectomy|.
This diagram shows the stated definition of the concept . An is a procedure with a priority of emergency, in which the appendix structure is excised.
Stated definition of |Emergency appendectomy|.
This diagram shows a hierarchical view of the stated subtype relationships from the concepts above.
Stated subtype relationships.
Table: Comparison of stated definitions
This diagram shows a comparison of the stated definitions for and from above. The two definitions are identical, except for the additional defining relationship on , which states that the priority is emergency.This means that a classifier can infer that is a logical subtype of .|
Table: Deriving the inferred relationships
This diagram shows that once the relationship is inferred, the stated relationship becomes redundant.
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.
Creating inferred relationships for an extension
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
Use an effectiveTime which corresponds to the release date of the extension
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 Inactivate Relationship in an Extension.
For more information about options for packaging inferred extension relationships, please refer to Packaging and File Naming.
Some more advanced axioms (e.g. general class inclusions) can be represented in the but cannot be represented in the .
Example
Combining Modules for Classification
SNOMED CT editions can be identified using a URI that is formatted according to the SNOMED CT URI Standard. (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:
It is recommended that documentation should be removed from the release packages, and hosted separately. This allows for ongoing updates, if required.
Note that some exceptions may apply, such as the readme.txt file
The main component files (e.g. Concept, Description, Relationship) are nested under the Terminology folder
All reference sets files are nested under the Refset folder, in the relevant subfolder:
Content folder contains reference sets that represent SNOMED CT subsets
Language folder contains a language reference set, for each applicable language or dialect
Map folder contains simple, complex and extended map reference sets
Metadata folder contains supporting metadata files, including the reference set descriptor reference set, the module dependency reference set, and the machine readable concept model (MRCM) reference sets
The recommended folder structure is illustrated below.
General Release Folder Structure
Example - International Release
Full
Terminology
Refset
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 https://conf.spaces.snomed.org/wiki/spaces/RMT/pages/131956852/Release+Package+Templates
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.
Creating a SNOMED CT Edition from extension packages
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 authoring extensions.
Packaging an extension as an edition
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 Classifying an Edition .
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
A consistent versioning mechanism
A mechanism to identify the contents of a file at a high level
A mechanism to identify the type of information stored in a release file (e.g. documentation, tooling, etc.)
Guidance on file naming for release files in non-English extensions
Assurance that names will be unique across all editions and extensions over time
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 .
inactivated in the extension. For more information on concept promotion, please refer to
.
Concepts in an extension can be inactivated if necessary. This is accomplished by creating a new inactive version of the concept, and new inactive versions of any relationships in which that concept participates. This inactivation process is explained in more detail below.
Concepts which belong to the International Edition (or to a module on which the extension depends) should generally not be inactivated in an extension (please refer to Management of Inactivated International Concepts within an Extension). Extension producers should submit any requests for inactivation to SNOMED International (or the module owner). In most situations, in which an extension producer needs to exclude specific international concepts in their extension, this should be done by creating a reference set of either the 'included' or 'excluded' concepts. For more information, refer to in the Practical Guide to Reference Sets.
Please note that if a situation arises in which an error is detected in the International Edition that causes inference errors in the extension, then this must be submitted to SNOMED International for correction. If a correction in the International Edition is not available prior to the release of the extension, then the error may be corrected in the Extension Edition, as long as this is reconciled in the next version of the extension that uses the corrected International Release.
When inactivating a concept in an extension, key steps include:
Inactivating the concept
Inactivating any relationship in which the inactive concept participates
This includes any relationship in which the inactive concept is the source concept, the destination concept or the relationship type
Representing the reasons for inactivation and possible replacements in the appropriate reference sets
Please note that active descriptions should not be inactivated when a concept is inactivated. This provides a mechanism to see the terms associated with concepts that have previously been entered into a clinical record, and to support historical queries on data that was captured using a previous version of the terminology.
The table below provides a summary of the process to follow when inactivating a concept in an extension.
File Type
Process
Concept
A new row representing an inactivated version of the concept is added to the Concept file.
The attributes of the new version of the concept are set as follows:
id is set to the conceptId of the concept being inactivated
effectiveTime is set to the date the extension will be published
active is set to '0' to indicate that the concept will become inactive at the time of publication
Concepts should NOT be used for data entry once they have been inactivated. However, inactive concepts should be retained to support historical records entered prior to the inactivation.
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 Licensing.
Visit to the SNOMED International Members page at http://snomed.org/members and find your member organization
Visit your NRC’s website or contact them by email
Download the relevant release files from your NRC
Note that most NRCs will require you to register for an account before SNOMED CT can be downloaded
In some countries SNOMED CT is alternatively provided via terminology services
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).*1Service-based distribution is illustrated in the diagram below.
Service-based distribution
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:
To validate that the SNOMED CT distribution files conform structurally to the specification of the associated file type, and that the rows and columns contain values of an appropriate data type.
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
Release Type
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
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
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.
Adding or inactivating reference set members. Please refer to the guidance on or .
Modifying mutable attribute values of reference set members. To see what attributes are mutable for each reference set type, please refer to the specification of the specific reference set type in the . If the reference set type is a locally defined reference set, please consider any mutability constraints on the individual attributes.
Don't modify immutable attributes of a reference set.
In the case where the modification of an immutable attribute is required, this should be done by inactivating the reference set member and creating a new reference set member with the required, updated values.
If circumstances require you to modify reference set members that belong to another module than the producers extension, following options exist:
Inactivating the specific reference set member in your own module and create a new reference set member with the updated value
The benefit of this approach is that you retain the definition and representation of the reference set member as it was intended by its original authors, and the new reference set member will be easily identified as a local reference set member, as the identifier of that reference set member is not available in the original reference set
The table below provides a summary of the process to follow when modifying an existing member in a Reference Set.
Table: Modify reference set member
File Type
Process
Concept
The metadata concept representing the reference set is retained
Reference Set
A new reference set row is created and the id is retained from the previous version of the refset member.
These two release artifacts enable changes to be identified, and the nature of those changes understood. The delta release files provide information about all components or reference set members which have changed since the previous release. By comparing this information to the corresponding components or reference set members in the snapshot files from the previous release, stakeholders can understand which of these changes represent additions of new components or reference set members, and which represent new versions of existing components or reference set members. For more information on the different release types please refer to the
.
The table below shows how the values for the active attribute in the previous snapshot and current delta can be compared to help to determine the types of change in the release.
Row in the
DELTA view of
the CURRENT release
active = 0
The types of changes that components and reference set members can undergo are inactivate, reactivate, change or add. For example, if a row (with a given id) was not present in the snapshot from the previous release, and then was present (with the same id) in the current delta release with an active value of 1, then this means that a new component or reference set member has been added. If a row (with a given id) had a value of 1 in the previous snapshot, and now has a value of 1 in the current delta, then this means that the component or reference set member has been changed.
Please note, SNOMED International strongly recommends that extension producers perform regular alignment to the International Edition, without skipping any version. If, for some reason, an extension is not updated to align with a new version of the International Edition, additional maintenance tasks will be required. For example, the extension producer will need to generate a modified 'delta view', which contains all changes made since the last version of the International Edition that was reconciled with the extension. All components and reference set members with an effectiveTime that is more recent than the last reconciled version of the International Edition will need to be considered in this 'delta view'.
Components
To ensure that the components comply with authoring principles, at the time of authoring.
Each concept must be the source of at least one relationship of type
Each concept must have at least one FSN and at least one synonym
All attribute relationships specified for a given concept are valid to use in the given domain (based on the concept model rules defined in the MRCM)
Reference Sets
To check, at the time of authoring, that reference sets and their members are created and modified according to the associated specification and principles.
Common reference set checks
The reference set and its members comply with the reference set pattern specified in the
Reference set attribute values of type are available in either
The extension,
Map reference set checks
The map target must specify a valid code in the target code system
Every source code in a map that uses map rules must
The ability to generate UUIDs that are required for any reference set member created within the extension. For more information, see .
Author and maintain components
The ability to create concepts, descriptions and relationships in accordance with editorial principles. Note that varying levels of services and sophistication may be offered in tooling, but it is recommended to use tools which can demonstrate adherence to editorial principles. For example, a tool should ensure:
Compliance with the concept model
Component authoring rules such as concepts created with the mandatory subtype relationships and descriptions
The ability to create and maintain reference which comply with the reference set pattern as specified in the reference set descriptor and offer additional functionality such as the providing intensional definition of subset members
For more information, see .
Validation tools
Automatic validation of individual components
The ability to automatically validate that any terminology component present in the extension complies with the logical design of SNOMED CT, and that referential integrity is retained. For more information, see Review and Validation.
Automatic validation of the entire extension
The ability to automatically validate that the extension is ready for release. This includes ensuring the validity of release file structures, release file types, and referential integrity across all components and release files. For more information, see Review and Validation.
Packaging and distribution tools
Classify extensions
The ability to classify SNOMED CT to create inferred relationships. For more information, see Classifying an Edition
Package extension edition
The ability to organize and package the edition according to the recommended release file structure. For more information, see Packaging and File Naming.
File or service-based distribution
The ability to distribute the edition, so extension consumers can access the terminology, either based on file distribution techniques or dedicated services to access specific terminology parts. For more information, see Distribution.
Maintenance tools
Change request service
The ability to collect and process change requests, such as suggestions for new concepts, required synonyms for particular concepts, and new reference set members. These tools should also support the ability to forward internal change requests to SNOMED International when appropriate.
Change identification mechanism
The ability to align the extension with the International Edition when new versions are published. This tooling includes the ability to identify changes to the International Edition which may affect the extension
The historical association target concept(s) should be considered as replacements. In the event these are not suitable then a new unambiguous concept should be created.
Duplicate component
Do not reactivate
The active concept that has the same meaning as the inactivated concept should be used as the replacement.
Erroneous component
Do not reactivate
The historical association target concept(s) should be considered as replacements. In the event these are not suitable then a new unambiguous concept should be created.
Meaning of component unknown
Do not reactivate
A new unambiguous concept should be created.
Non-conformance to editorial policy
May be reactivated
The decision to reactivate depends on the type of content and usage.
Outdated component
May be reactivated
Clinically outdated (in most countries) - do not reactivateNot internationally semantically interoperable - may be considered for reactivation
Consider the reason for inactivation
Metadata concept
Discouraged
Referential integrity of the post-classification result should not be compromised
A new member of the relevant language reference set, which specifies the acceptability of the new description, may need to be created. For more information, please refer to Add Members to a Reference Set.
Extension Impact
A new reference set is added to the International Edition.
A decision should be made as to whether or not the new reference set could replace any national or locally created reference sets. If so, then this could alleviate the associated maintenance responsibilites. For more information, please refer to .
One or more members have been added to a reference set in the International Edition.
If the extension uses extension reference members to adapt an international reference set, a decision should be made as to whether or not the new reference set members should be adopted in the extension reference set. For more information, please refer 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
Review Type
Purpose
Examples
Collaborative authoring and review approaches are recommended to produce high quality content. Examples of authoring and review approaches include:
Single author with single reviewer
One author develops the terminology content. Another author reviews the changes and either accepts them or reports issues that need to be considered and resolved.
Multiple authors with multiple reviewers
Considerations In Assessing Requests
Considerations in Assessing Requests
As part of the assessment process to determine where the requested content belongs, following points are important to take into consideration:
The scope of various SNOMED CT Editions
Whether the request is permitted given the predefined principles around:
Editorial rules and;
Retaining the referential integrity of SNOMED CT
When a SNOMED CT Member, or Affiliate organization which maintains an extension, identifies a requirement for new content they should evaluate the request by considering the following questions:
Does the requested content fall within the defined scope of the International Edition?
Is the requested content likely to be required by, or of value to, more than one Member territory?
If the answer to both these questions is "yes", the organization should submit a request to SNOMED International for the inclusion of the new content. When a request originates in an Affiliate organization, it should be submitted to a National Release Center who will then forward the request to SNOMED International. In general, this content should not be added to a National or local extension, as content that falls within the defined scope of the International Edition and is required by two or more Member territories. However, in cases where there is an urgent requirement, an extension producer may add the content to their own extension as an interim solution. Please refer to Interim Content Additions below.
Similarly, if the answer to one or both of these questions is "no", the content may be suitable for inclusion in a National Edition. In this case, the following questions should be considered:
Does the requested content fall within the defined scope of a National Edition?
Is the requested content likely to be required by, or of value to, more than one organization within the Member territory?
If the answer to both these questions is "yes", then the organization should submit a request to the National Release Center for the addition of the required content into the National Edition. If the answer to one or both of these questions is "no", it should be considered for inclusion in a local extension. In a situation where the request is considered to be out of the scope of SNOMED CT, it may be rejected. The table below provides additional detail on the various outcomes in these considerations.
Table: Considerations relating to appropriateness of content at various levels
When determining whether or not a request for additions or changes should be accepted for inclusion in any SNOMED CT edition, it is important to ensure that the addition or modification does not break the referential integrity of SNOMED CT. It is also important to assess whether the definition of new concepts has undesirable effects on the existing content. Finally, it should be ensured that every addition of or modification to SNOMED CT concepts conform to the rules specified by the concept model. Section describes key principles which ensure that referential integrity is retained and that components and derivatives are created or modified in an extension in accordance with the editorial principles.
SNOMED International does not recommend that extension producers make changes which result in modifications to the International release as this can cause interoperability issues. Substantive errors, or improvements to content in the International release which are mitigated by the content in an extension, should, therefore, be forwarded to SNOMED International in a timely fashion to improve the quality of the International release.
In circumstances where the International release has been impacted by modifications in a national or local extension, a disclaimer notifying users of the differences between the extension release and the International release must accompany the national extension distribution files.
Add Relationship in an Extension
Purpose
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
Concepts which belong to the International Edition
Concepts which belong to another module on which the extension depends
A SNOMED CT relationship involves three main concepts - the source concept, the destination concept, and the relationship type concept (also known as the 'attribute'). Each of the concepts in an extension relationship may belong to either a module from the extension itself, or a module upon which the extension depends (e.g. an international module).
When adding new relationships in an extension, the following principles apply:
Source Concept : Except in exceptional cases (noted below), the relationship must represent a defining characteristic of a concept in a module for which the extension producer is responsible.
This means that the sourceId of the relationship should refer to a concept in the extension.
Attribute : The type of relationship should usually be represented by an attribute concept which is part of the SNOMED International Edition.
When using an attribute from the International Edition, concept model rules and editorial guidance should be followed. For example, relationships should comply with the rules stated in the .
In some cases, new attribute concepts may be added to an extension. While this is permitted, new attributes should be applied with caution, and concept model rules and editorial guidance should be clearly documented by the extension provider.
Destination Concept : The target of the relationship may belong to the extension module, or any module on which the extension module depends (including an international module). However, care should be taken to avoid intermediate concepts as described in ). Additionally, it is important to ensure that the added relationships do not induce any cycles, i.e. it should be ensured that the added relationships retain the SNOMED CT hierarchy as a Directed Acyclic Graph.
Cyclic Graph
Directed Acyclic Graph
The table below provides a summary of the process to follow when adding a new relationship to an extension.
File Type
Process
Release Validation
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
Validation Type
Purpose
Examples
End Support for a Reference Set
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.
A decision is made to stop maintaining a reference set, without transferring the responsibility to another organization
Linkage Concept Hierarchy
moduleId is set to the conceptId of a module that is managed by the extension producer
conceptId is set the same as the original version of the description
languageCode is set the same as the original version of the description
typeId is set the same as the original version of the description
term is set to the (possibly updated) string of characters used to describe the given concept. Note: Only limited changes, in accordance with editorial rules, can be made
caseSignificanceId is set to indicate the (possibly updated) case significance of the term
YES
(Full/Snapshot)
effectiveTime
Time
Specifies the inclusive date at which the component version's state became the then current valid state of the componentNote : In distribution files the effectiveTime should follow the short ISO date format (YYYYMM DD) and should not include the hours, minutes, seconds or timezone indicator.
YES
YES (Full)
Optional (Snapshot)
active
Boolean
Specifies whether the state of the description was active or inactive from the nominal release date specified by the effectiveTime .
YES
NO
moduleId
SCTID
Identifies the description version's module. Set to a child of 900000000000443000 | Module| within the metadata hierarchy.
Identifies the concept to which this description applies. Set to the identifier of a concept in the 138875005 | SNOMED CT Concept| hierarchy within the Concept. Note that a specific version of a description is not directly bound to a specific version of the concept to which it applies. Which version of a description applies to a concept depends on its effectiveTime and the point in time at which it is accessed.
NO
NO
languageCode
String
Specifies the language of the description text using the two character ISO-639-1 code. Note that this specifies a language level only, not a dialect or country code.
NO
NO
typeId
SCTID
Identifies whether the description is fully specified name a synonym or other description type. This field is set to a child of 900000000000446008 | Description type| in the Metadata hierarchy.
NO
NO
term
String
The description version's text value, represented in UTF-8 encoding.
YES
NO
caseSignificanceId
SCTID
Identifies the concept enumeration value that represents the case significance of this description version. For example, the term may be completely case sensitive, case insensitive or initial letter case insensitive. This field will be set to a child of 900000000000447004 | Case significance| within the metadata hierarchy.
YES
NO
If no changes to the acceptability of the description are required, then no changes to the associated language reference set members are necessary.
If changes to the acceptability of the description are required, a new version of the relevant language reference set member is added with the required acceptabilityId.
What type of content will be included in the extension? - e.g. what components and reference sets should be developed and what types of files should be produced?
What resources are required for the development and maintenance of the extension?
Note: The resources available should be determined (time, money, people) to ensure a proper balance between the resources available and the tasks involved during each phase of extension development, implementation and maintenance.
Human resources
What roles and competencies are required? For example:
Clinical experts
Terminology experts
Technical and release experts
Development approach
What methods will be used for authoring and reviewing the content in the extension and assuring the required level of quality?
What tools will be used to support extension development, distribution and maintenance processes?
Note: A suite of tools may be required to support the creation and management of an extension. The functional requirements of these tools depend on the extension's scope, content and a range of other factors.
Satisfy the criteria of being understandable, reproducible, useful
If there is an urgent need for additional content, it may be added to an extension as an interim measure, pending addition to the International Edition. For more information, please refer to Interim content additions below.
An organization which maintains an extension is responsible for defining the scope of that extension. The scope of an extension should not overlap with the scope of the International Edition or any other extension with modules on which the extension modules depend on. Note that urgent content additions may be permitted as an interim measure, even when the content is within the scope of another edition or extension. For more information. please refer to Interim content additions below.
Requested content which falls within the defined scope of an extension may be added by the organization which maintains the extension. For additional information about adding local content to an extension, please refer to Authoring.
Outside the scope of SNOMED CT
The request is rejected
A concept in the International Edition that is missing one or more valid defining relationships
Missing synonyms
A concept in the International Edition that is missing one or more widely used synonymous terms
Create a new version of the specific reference set member in your own module, and make the necessary modifications
Versioning and module identification attributes are set accordingly:
effectiveTime is set to the date the extension will be published
active is set to reflect the status of the reference set member, i.e. '1' for active and '0 'for inactive
moduleId is set to identify a module managed by the extension producer
Attributes common for all reference set types are set accordingly:
refsetId is retained as the value from the previous version of this refset member. A member cannot move from one reference set to another
referencedComponentId id retained as the value from the previous version of this refset member. A member cannot change the component which it refers to.
In this case, the existing member record should be inactivated, and a new one created.
Attributes specific to the reference set type are set accordingly:
additional attributes - may be updated with a value, of type (and possibly range) limited by the descriptor record for this Reference Set attribute
Maps
To validate that the map between each SNOMED CT component and the associated codes from the other code system is correct
Review the set of maps to ensure that:
Each mapGroup represents an appropriate set of map rules for the given referencedComponentId
The mapTarget has a sufficiently similar meaning to the referencedComponentId to meet the user requirements of the map (given the associated correlationId)
Two or more authors work on independent authoring tasks. Two or more reviewers then review the work of the authors. In most cases, the authors themselves act as the reviewers for the other authors' work.
Dual blind authoring with adjudicator
Two authors work on the same task independently. For example, the authors may both map the same set of concepts to a target code system. Any discrepancy between the work of the two authors is automatically detected, An independent adjudicator then reviews the discrepancies and decides which author's work to approve.
Components
To validate that the components created within the extension comply with editorial guidelines and are clinically correct.
Review fully specified name (FSN) to ensure that it provides an unambiguous linguistic representation of the meaning of the concept.
Review all descriptions to ensure that they each follow editorial guidelines for General Naming Conventions
Review the defining characteristics of new or updated concepts to ensure that:
They each represent a true and necessary characteristic of the meaning of the concept
If the concept is marked as fully defined, that the definition is sufficient to uniquely define the concept
The concept complies with all relevant editorial principles and concept model rules
Reference Sets
All reference set types
To validate that all reference sets meet their user requirements, such as the scope, size, functionality and user acceptance criteria. For more information, please refer to .
Review the reference set to ensure that its quality is sufficient to meet the intended use cases of the reference set
Subsets
To validate that all members of the subset are within the intended scope of that subset, and that no component is missing from the subset that is required to meet the subset's intended purpose.
Review the set of referencedComponentIds to ensure that:
All referencedComponentIds refer to a component that is in the intended scope of the subset.
No component within the intended scope of the subset is missing from the set of referencedComponentIds.
If the content requested is within the scope of the International Edition, the organization should request that the content should be added to the International Edition.
As SNOMED CT is a global clinical terminology, the scope of the International edition of SNOMED CT is constrained by a set of principles. For inclusion in the International edition, concepts must be
Useful in more than one country
Necessary for healthcare conformance and interoperability
Within the scope of a clinical terminology
Satisfy the criteria of being understandable, reproducible, useful
If there is an urgent need for additional content, it may be added to an extension as an interim measure, pending addition to the International Edition. For more information, please refer to Interim content additions below.
Within the scope of another extension, (National, third-party, or local extension) but outside the scope of the International Edition.
The scope of a national edition may permit the addition of content which falls outside the scope of the International Edition but is required within a country, region or territory. If the content requested is within the scope of a national edition, a request should be submitted to the relevant National Release Center.
An organization may also use an extension which was produced by another organization, such as a vendor, regional body or specialist group. In this case, requests for content which fall within the scope of these extensions should be submitted to the relevant extension producer.
When there is an urgent need for additional content, it may be added to an extension as an interim measure, pending addition to a national edition or externally maintained extension. For more information, please refer to Interim content additions below.
Outside the scope of other extensions, but relevant to the organization requesting the content.
An organization which maintains an extension is responsible for defining the scope of that extension. The scope of an extension should not overlap with the scope of the International Edition or any other extension with modules on which the extension modules depend on. Note that urgent content additions may be permitted as an interim measure, even when the content is within the scope of another edition or extension. For more information. please refer to Interim content additions below.
Requested content which falls within the defined scope of an extension may be added by the organization which maintains the extension. For additional information about adding local content to an extension, please refer to .
The attributes of the inferred relationships are set as follows:
id is set to a new relationship identifier allocated within the extension namespace.
effectiveTime is set to the date the extension will be published
active is set to '1' to indicate that the new relationship will be active at the time of publication
NOT ALLOWED
ALLOWED
Stated Axiom
A prerequisite for generating the relationships in the relationship file is that concepts have been authored and the defining properties stated and classified together with the SNOMED CT content it belongs to. Please see Add Concept in an Extension.
Relationship
Once authoring is complete, the contents of the extension modules, together with every module on which these depend, are classified.The resulting set of inferred relationships (i.e. the output of the classification process) is added to the Relationship file.
Principles
Overview
In cases in which it is necessary to meet legitimate clinical needs or to correct identified clinical issues, an extension producer may add additional defining relationships to a concept which belongs to an International module (or a module on which the extension module depends). However, this should be done with extreme caution due to the potential impact on the classification results. If these situations arise, SNOMED International (or the module owner) must be notified.
Attributes added in an extension can lead to inconsistent classification, where attributes overlap with or interact with attributes in the SNOMED International Edition. Furthermore, attributes created in an extension may not be well aligned with new attributes covering similar characteristics that may be included in future releases of the International Edition. Therefore, care should be exercised when adding attributes in an extension. In particular, the rationale for creating each new attribute should be well documented, with clear guidance on its consistent use. Ideally additions should also be made to the MRCM reference sets to capture the associated concept model rules in a machine processable way. If similar attributes are later added to the International Edition, the extension producer should plan to align with the International Edition as soon as possible.
When a new reference set type is defined, an appropriate set of reference set descriptor rows must be created in the reference set descriptor reference set to specify the order and format of the reference set columns. Furthermore, the intended use and format of the new reference set type must also be documented.
Appropriate documentation should also be provided to describe the specific use of each individual reference set. The addition of reference set descriptor rows for individual reference sets is also recommended. However, this is optional if there are no additional constraints over and above those specified for its reference set type.
Subtype children can be added in an extension to represent new column names for use in additional reference set type definitions.
No new subtype children or subtype descendants may be added in an extension.
If new subtypes are required these should be requested for addition to the International Edition.
Adding subtype descendant to pre-existing subtype children would have the effect of changing the permitted value set for a pre-existing reference set type and reference sets defined as having that type.
Inactivating a concept's active relationships involves adding a new row to the OWL axiom reference set file, which inactivates the member of the reference set representing the stated axiom of the concept being inactivated.
The attributes of the new version of the concept are set as follows:
id is set to the UUID of the reference set member referencing the concept being inactivated
effectiveTime is set to the date the extension will be published
active is set to '0' to indicate that the reference set member will become inactive at the time of publication
moduleId is set to identify a module in the extension
referencedComponentId is set to the concept identifier of the concept being inactivated
Inferred Relationships File
An inactive concept does not participate in any active relationships. This means that when inactivating a concept, all active relationships, in which the concept was used as the source, destination or type, must be inactivated. As a result, the inactive concept is removed from the subtype hierarchy, and will no longer have any defining relationships. This reinforces the point that an inactive concept should not be used in any new data entry, as it will not be subsumed by any other concept.
Additionally, depending on the inactivation reason, a row should be added to the relevant | Historical association reference set| . This helps to support extension consumers with the change management process, by (for example) specifying possible replacements for the inactivated concept. Please refer to for a list of historical association reference sets, and an example of the | REPLACED BY association reference set| .
Please refer to for further information.
Reference set files conform to the structure of the specific reference set type in
For files in the full release, the combination of the id and the effectiveTime is unique
For files in the snapshot and delta releases, the id is unique
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
Release Type
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
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
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
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
Reference set files conform to the structure of the specific reference set type in
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
Full release files: the combination of id and effectiveTime is unique, since each row captures a distinct historical state of a component.
Snapshot release files: the id is unique, since each component appears only once, reflecting its current (most recent) state.
Delta release files derived from two consecutive releases, or from a snapshot: the id is unique, since a component can have changed at most once between those two points.
Delta release files derived by comparing two arbitrary (non-consecutive) versions of SNOMED CT (for example, using the ) the combination of id and effectiveTime is unique, since a component may have changed more than once between the versions being compared, resulting in multiple rows sharing the same id.
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.
To validate that the SNOMED CT distribution files conform structurally to the specification of the associated file type, and that the rows and columns contain values of an appropriate data type.
Release Type Validation
For example, an organization may no longer have the resources to maintain a reference set that it created, although the reference set is still considered useful.
A decision is made to deprecate use of an existing reference set
For example, if a reference set is no longer relevant, has been superseded by a more useful reference set, or is considered inaccurate or misleading in some way.
When the owner of a reference set wants to end support for the reference set, this should be indicated by making the changes described in the process section below.
In the situation where the reference set belongs to an extension, the owner of the extension may only make these changes to a reference set that is currently in an extension module for which it is responsible. The exception to that rule is that, in the case where a responsibility for maintenance of a reference set is transferred to another organization, the organization to which responsibility is transferred is required to take some of these steps.
Prior to ending support for a reference set, it is important that the reference set producer has an overview of the extent to which the reference set is used. If a producer and owner of a reference set continues to distribute an unsupported reference set with active members, there is an inherent risk that it will continue to be used. However, deprecation formally inactivates the reference set members to minimise this possibility.
The table below provides details and considerations on the process of inactivating a reference set.
Reason for Ending Support
Organization responsible currently responsible for the reference set
Organization accepting transfer of responsibility for the reference set
Transfer of responsibility for maintenance to an organization that is responsible for a module on which the current module depends
Request the newly responsible organization to issue new versions of the reference set concept, metadata and active reference set members using the same identifiers but changing the moduleId to refer to the module in which the reference set is now being maintained.
Inform users that the reference set is now being maintained by another organization.
Do not inactivate or otherwise alter any of the existing concepts or reference set members.
Create new versions of the reference set concept and related metadata. The new versions of components must have the updated effectiveTime for the relevant release date and the moduleId of the module in which the reference set will now be maintained. However, the id and all other fields must have the same values as in the original versions.
Create new versions of all active members from of the reference set. The new versions of references set members must an updated effectiveTime for the relevant release date and the moduleId of the module in which the reference set will now be maintained. However, the id, refsetId and all other fields must have the same values as in the original versions.
Transfer of responsibility for maintenance to an organization that is not responsible a module on which the current module depends
If the extension producer wants to avoid users from needing to import a deprecated or transferred reference set in future releases, the inactivated reference set may be separated from the main extension release (e.g. it could be in a separate release package, or accessible via a separate service or from a static location). Changes in packaging must be formally notified to users of the extension in advance of the change.
Distribution of an Inactivated Reference Set and its Members
Warning
It is essential that the inactive reference set concept, metadata and reference set members are included in the first release of the original release package after the changes are made. Otherwise users applying delta updates will not be aware that the change has been made.
Hierarchy
Purpose
These concepts provide the values for Relationship.typeId and represent the type of a defining relationship.
Examples
Concept Addition Rules
Additional attributes may be added in an extension, where required to support extensions to the SNOMED CT concept model.
Hierarchy
Purpose
These concepts represent clinical assertions about relationships between instances of clinical statement in an EHR. For example, they may assert that a particular symptom is caused by something.
Extending the SNOMED CT concept model to allow sufficient definitions to be applied to concepts that are not sufficiently defined in the International Edition.
Additional Notes
Any attributes created in extensions need to be carefully managed and documented. Extension attributes may also need to be revised or inactivated to align with future changes to the concept model in the International Edition.
Additional subtype children may be added in an extension. However, it is recommended that proposed additions be submitted to the International Edition, unless they are highly specific.
Concept Addition Uses Cases
Requirements to support additional types of assertion in clinical records
Ensure that documentation explaining this change is prepared and distributed to all users of the extension.
Request the newly responsible organization to create and maintain a new reference set in their own extension module. The newly created reference set concept and metadata should replicate the and includes all all the members of the original reference set that were active immediately prior to deprecation.
Add a row to the indicating the reason for inactivation of the reference set.
Ensure that documentation explaining this change is prepared and distributed to all users of the extension.
Create a new reference set following the process described in Create a New Reference Set. The reference set must have a newly allocated id, the updated effectiveTime for the relevant release date and the moduleId of the module in which the reference set is being created. However, the name and all other fields should have the same values as in the original versions.
Create new members of the newly created reference set following the process described in Add Members to a Reference Set. A member must created matching each of the active members of original reference set.
Ensure that documentation explaining this change is prepared and distributed to all users of the extension.
.
When creating a new reference set it is important that the reference set metadata concept (which identifies and names the reference set) and the associated reference set members belongs to a module of the reference set producer. I.e. if a reference set is created as part of an extension, the reference set metadata concept should belong to a module within the namespace of the extension producer.
All reference sets follow a logical model. Each reference set type is represented by a specific data structure which enables a specific functionality. SNOMED International specifies a set of reference set types, which can be used to support a set of terminology management purposes. SNOMED CT Members (National Release Centers) and Affiliates may also create reference sets to assist with localization and effective implementation of SNOMED CT. In general, an extension producer can create a reference set within their extension, but the reference set type should be defined in either
The producers extension
The International Edition
Other extensions (which the producers extension modules are dependent on)
For more information about the different reference set types and their data structures, please refer to the .
Please note that for all reference sets, there should be guidance on what is possible and what is not possible. For some International reference sets, it is acceptable and even required to add extension rows to the International reference set. For example, the Module Dependency Refset, the MRCM Module Scope Refset, and Language Refset. This is not necessarily applicable to all reference sets. Over time, further guidance in this area will be developed.
The table below provides a summary of the process to follow when creating a new reference set.
Define the reference set in the metadata hierarchy Following steps should be taken for creating the reference set concept:
File Type
Process
Concept file
Create a concept for the reference set
Description file
2. Add up to three Descriptions for the reference set concept. I.e. the FSN, the Preferred Term and optionally the purpose, see
Language reference set
Define the reference set Attributes within the metadata hierarchy
Add new concepts for each of the reference set member attributes, if necessary. If the reference set attributes describing the pattern are adequate to describe the reference set's attributes, then these can be used instead. You may add new concepts for some of the attributes, and reuse existing concepts for other attributes, if you wish.
Concept
1. Add a concept for the attribute
Description
2. Add Descriptions for each of the new attribute.
Language Reference Set
Specify the acceptability of the descriptions in the applied Language Reference Set
Relationship
Create the Descriptor for the reference set
If the reference set does not follow an existing reference set pattern, the additional attributes specific for this customized reference set should be included in the .
Reference Set Descriptor Reference Set
A new reference set member is created in the reference set Descriptor for each attribute in the reference set pattern. For guidance on creating a reference set member, please see . For further introduction to the reference set Descriptor, please see in .
Add members to the reference set
Reference set members are added to the reference set, which includes specifying the attribute values for each reference set member, see .
For additional information, see the practical guide to reference sets: How to create a new Reference Set using an existing pattern
If new attribute values need to be created these should also be added as SNOMED CT concepts and placed as subtypes of the concept , following the process described above.
When SNOMED CT content is promoted from an extension module into a less dependent module (e.g. the international edition) to enable broader use, specific changes occur in the RF2 files of the associated SNOMED CT releases. In this section, we provide examples of how the relevant RF2 release files are changed when a concept is promoted and explain how the resulting files are used.
Distribution Approaches
SNOMED CT is distributed to users using one of two main approaches:
As a SNOMED CT edition, in which the SNOMED CT extension content is combined together with the files from the International Edition (and any other dependent module)
As a SNOMED CT extension, which contains only the new content added into the extension. To deploy a SNOMED CT extension, it must be combined with the international versioned edition that it is dependent on (and any other dependent modules), and any conflicts resolved (as explained below).
The diagram below illustrates these two approaches. In each approach, 3 release file types are distributed - the , the and the . Please refer to for more information.
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:
In the following sections, we illustrate how each of the Concept files would appear both before and after the promotion of the fictitious concept from the to the .
In these examples, we will assume that the was:
Created in the on 31st September 2018
Updated in the on 31st March 2020
Promoted to the on the 31st July 2020
We also assume the following dependencies:
Before promotion: The 31st March 2020 version of the National Extension is dependent on the 31st January 2020 International Edition
After promotion: The 31st September 2020 version of the National Extension is dependent on the 31st July 2020 International Edition
In the following section, we will first illustrate the changes using the SNOMED CT edition distribution method. And in the subsequent section, we will illustrate these changes using the SNOMED CT extension distribution method. In both cases, we will consider the impact to all three release file types - the , the and the -
In this section, we illustrate the changes to the release files when promoting a concept using the edition distribute method.
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
Changing the characteristic type of a relationship
Relationships that are used to define extension concepts can be modified. However, please note that only the values of mutable attributes may be modified. As indicated in the table below, the six mutable attributes of a relationship are:
Please note that the id, module and definitionStatusId fields in the RF2 release files contain only the SNOMED CT identifier of the relevant concept.
In the example tables below, we have included a synonym for each concept for human readability.
Full Release File
Before Promotion
After Promotion
Snapshot Release File
Before Promotion
After Promotion
Delta Release File
Before Promotion
After Promotion
Concept Promotion using Extension Distribution
Please note that the id, module and definitionStatusId fields in the RF2 release files contain only the SNOMED CT identifier of the relevant concept.
In the example tables below, we have included a synonym for each concept for human readability.
Full Release File
Before Promotion
After Promotion
Please note that the Snapshot View of the Virtual Edition (for deployment in systems) can be created by combining the two files above and then removing any superseded version of each concept. In this example, the 20200331 version of | Example Concept| must be removed from the combined snapshot file, as this has been superseded by the 20200731 version of this concept from the International Edition.
Delta Release File
Before Promotion
After Promotion
Please note that the Full View of the Virtual Edition (for deployment in systems) can be created by simply combining the rows from the files above (ie one row).
. When a change is required to the source, destination or type of the relationship, the relationship must be inactivated and a new relationship created with the required values.
All modifications to a SNOMED CT relationship should also conform to the SNOMED CT concept model rules, including relationship group cardinality constraints. For more information please refer to the Editorial Guide and the Machine Readable Concept Model.
Relationships authored by SNOMED International, which define concepts in the International Edition, should not be modified. If an error is detected in the International Edition, which requires one or more relationships to be modified, the issue should be documented and reported to SNOMED International using the Content Request Service. In situations in which an extension producer needs to modify a relationship to temporarily fix an issue, this should be done in a module owned by the extension producer, and reported to SNOMED International It is recommended that extension producers try to avoid modifying international relationships, as such modifications may affect the results of subsumption testing and therefore may have an impact on cross-edition interoperability.
Table: Mutability of relationship attributes
Field
Data type
Purpose
Mutable
Part of Primary Key
id
SCTID
Uniquely identifies the relationship.
NO
The table below provides a summary of the process to follow when modifying a relationship in an extension.
File Type
Process
Stated Axiom
Modifying a concept definition involves updating the defining properties of the concept, i.e. making changes to the axioms that represent necessary conditions for the meaning of the concept.
Once the update has been performed, the concept is classified together with the SNOMED CT content it belongs to, and a new set of relationships are inferred.
To prepare for publication, a new row representing the updated concept definition is added to the .
Specifies the inclusive date at which the component version's state became the then current valid state of the component.
Note : In distribution files the effectiveTime should follow the short ISO date format (YYYYMM DD) and should not include the hours, minutes, seconds or timezone indicator.
YES
YES (Full)Optional (Snapshot)
active
Boolean
Specifies whether the state of the relationship was active or inactive from the nominal release date specified by the effectiveTime field.
Identifies the source concept of the relationship version. That is the concept defined by this relationship. Set to the identifier of a concept.
NO
NO
destinationId
SCTID
Identifies the concept that is the destination of the relationship version.That is the concept representing the value of the attribute represented by the typeId column.Set to the identifier of a concept.Note that the values that can be applied to particular attributes are formally defined by the SNOMED CT Machine Readable Concept Model.
NO
NO
relationshipGroup
Integer
Groups together relationship versions that are part of a logically associated relationshipGroup. All activeRelationship records with the same relationshipGroup number and sourceId are grouped in this way.
YES
NO
typeId
SCTID
Identifies the concept that represent the defining attribute (or relationship type) represented by this relationship version.
That is the concept representing the value of the attribute represented by the typeId column.
A concept enumeration value that identifies the characteristic type of the relationship version (i.e. whether the relationship version is defining, qualifying, etc.) This field is set to a descendant of 900000000000449001 | Characteristic type| in the metadata hierarchy.
YES
NO
modifierId
SCTID
A concept enumeration value that identifies the type of Description Logic (DL) restriction (some, all, etc.). Set to a child of 900000000000450001 | Modifier| in the metadata hierarchy. Currently the only value used in this column is 900000000000451002 | Some| and thus in practical terms this column can be ignored. For further clarification please see .
YES
NO
The attributes of the reference set member representing the stated axiom are set as follows:
id is set to the UUID of the reference set member representing the definition of the concept being updated.
effectiveTime is set to the date the extension will be published
active is set to '1' to indicate that the new relationship will be active at the time of publication
moduleId is set to identify a module concept from the extension
referencedComponentId is set to the identifier of the concept being updated
owlExpression is set to the text of the OWL expression representing the updated defining properties of the new concept
Relationship
Depending on the nature of the change made, updates to the inferred relationship file will be made to reflect the changes.
This may involve:
Inactivating relationships that are no longer valid for the concept
Concepts may be added to an extension to provide new clinical ideas which are not represented in the International Edition. The primary reason for adding concepts to an extension is to represent meanings which are outside the scope of the International Edition, yet within the scope of SNOMED CT. These might be concepts which have local relevance, within a single country, territory or organization. Concepts may also be added to an extension to represent metadata about the extension, for example module concepts, reference set concepts, or new attributes.
For a more detailed introduction on the purposes for adding concepts to an extension, please refer to the Purpose section.
Principles
Overview
Key principles for authoring concepts in an extension include
Concepts added to an extension must have a moduleId that includes the namespace identifier assigned to that extension producer by SNOMED International
An extension concept must comply with the logical design of SNOMED CT components and maintain referential integrity
Concepts added to an extension should conform to the policies stated in
Use caution when authoring an intermediate concept in an extension, i.e. a concept which is a supertype of a concept in the International Edition
A concept created in an extension must conform to the logical design of SNOMED CT concepts. An overview of the logical model is provided in the image below. This means that every concept created in an extension must have:
At least one relationship
At least one description of type
At least one description of type
Concepts created in an extension may also have additional descriptions and defining relationships.
Additional defining relationships may include relationships and attribute relationships. When specifying attribute relations for an extension concept it is important to ensure compliance with the SNOMED CT concept model. The concept model specifies the attributes that can be applied to particular types of concepts and it specifies the permitted values for each of these attributes. There are also additional rules on the cardinality and grouping of particular types of relationships. Please see the and the for details on the concept model rules.
As discussed in , all extensions have modules which depend on the modules in the International Edition. Extensions may also have modules which depend on the modules from other extensions. Despite the dependencies between modules from various editions, all concepts in an extension must be a subtype of the root concept, . This ensures that a concept in an extension can be queried and retrieved in a similar way to any concept in the International Edition. Put another way, queries which use subsumption should be able to identify a concept which belongs to a module in an extension because it is a subtype of a concept from the International Edition.
Extension concepts must be a subtype of the SNOMED CT root concept
When an extension producer creates a new concept and states one or more relationships to define that concept the immediate effect is to make the new concept a leaf concept in the SNOMED CT subtype hierarchy. That is to say the new concept at this point has no known subtypes.
There are several situations in which this new concept may acquire new subtypes:
Other concepts in the same extension module may be stated to be a subtypes of the new concept
The organization responsible for another module that depends on this extension module may, in the future, state that some concepts in their module are subtypes of this new concept
When a Description logic classifier is applied to the contents of the module (and the set of modules it depends upon), the defining relationships associated with a new fully defined concept may lead to additional subtype relationships being inferred. These inferred subtypes may be concepts in the extension module itself or in any module on which the extension module depends (including International Edition modules).
Situations 1 and 2 above both result in the subtypes of the new concept either belong to the extension module or a module that depends on the extension module. This does not create any exceptions.
In contrast, situations 3 and 4 can result in the new concept becoming an intermediate concept that sits between two concepts from the International Edition (or from another module on which the extension module depends). This means that the new concept is inferred to be a supertype of a concept from the International Edition (or another module that the extension module depends on). Since, all extension concepts are a subtype of a concept from the International Edition, the new concept represents an intermediate node in the inferred hierarchy between two International Edition concepts. This intermediate concept is only present in the editions that include the extension, so it does not directly alter the International Edition. However, it does create a situation in which the inferred view of the International Edition hierarchy seen by those using the extension differs from the view seen by other users of the International Edition.
Situation 3 does not impact the logical definition of the inferred subtypes in the International Edition since concepts will only be inferred as subtypes if they already share the logical definition of a fully-defined supertype. However, if (as in situation 4) an International Edition concept is stated to be a subtype of the new extension concept, the impact can be more profound. In this case, the logical inference is that all defining attribute relationships of the new concept must also apply to the subtype concepts. Finally, situation 5 directly changes the logical definition of a concept from a module published by another organization. This can have a profound effect not only on that concept itself, but also on subtypes of that concept and on the inferred subtype hierarchy of the International Edition as seen by users of the extension.
In summary, extension producers should try to avoid the authoring scenarios described in situations 3, 4, and 5 above. Doing so will prevent unexpected or undesirable behaviour, which can be directly attributed to modifying the definitions of International concepts. These situations are, however, permitted if they are necessary to meet legitimate clinical needs or to correct identified clinical issues.
A good way to assess the impact of a change is to compare the transitive closure of subtype ( ) relationships after classifying the terminology with and without the extension. As a general rule, the transitive closure of the International Edition should not be modified by classifying it together with an extension.
The following 3 examples illustrate the impact of adding extension concepts as leaf concepts or intermediate concepts (after classification). The impact is considered in terms of how each addition effects subsumption testing using an example international concept 'G'.
Table: Example 1 - Primitive Extension Concept as a Leaf Concept
Table: Example 2 - Extension Concept as an Intermediate Concept (No impact on subsumption)
Table: Example 3 - Extension Concept as an Intermediate Concept (Impact on subsumption)
Concepts added to an extension are represented in a concept file. These concepts are part of a module which includes the namespace identifier assigned to the extension producer by SNOMED International. Each concept also requires additional components and reference set members to be defined. At a minimum, the following components and derivatives should be created:
The concept component, which represents the actual clinical meaning required in the extension
At least one description component of type
At least one description component of type
At least one relationship of type , which ensures that the concept is a descendant of
The table below provides a summary of the process to follow when adding a new concept to an extension.
It is also possible (although caution is advised) that the creator of the new concept might state that the concept is a supertype of a concept in the International Edition or in another module on which the extension module depends .
it is also possible (although caution is advised) that an extension producer might add a defining relationship to a concept in the International Edition (or in another module on which the extension module depends), and this new defining relationship may lead to a variety of new relationships (including subtype relationships) being inferred by a Description logic classifier.
A language reference set row for each new description to specify the acceptability of the description within the relevant language or dialect
To prepare for publication, a new row representing the concept definition is added to the
The attributes of the reference set member representing the stated axiom are set as follows:
id is set to the new relationship identifier allocated within the extension namespace.
effectiveTime is set to the date the extension will be published
active is set to '1' to indicate that the new relationship will be active at the time of publication
Description
A description of type of and at least one description of type of is added.
For more information on creating descriptions, please refer to
Language reference set
The new descriptions of the concept are referenced in at least one language refset to indicate language preferences.
The diagram illustrates how all concepts from Extension B are related to concepts in the International Edition. This is because the concept is either a direct child of a concept in the International Edition or because it is subsumed by concepts in the International Edition through subtype relationships defined by concepts in Extension A.
Illustration
Impact on hierarchy
A primitive extension concept, which is created as a leaf concept, must always be a subtype of an international edition concept, and will not be classified as a supertype of an international concept.
Impact on subsumption
The addition of this type of content does not impact subsumption testing of concepts in the international edition, because it will remain distal in the hierarchy to all International content after classification.
In this case, the transitive closure of the International Edition will stay the same, except for the addition of the new inferred | is a| relationship associated with the concept from the extension.
Illustration
Impact on hierarchy
The definition of a concept in an extension module may result in it being classified as an intermediate concept in the SNOMED CT polyhierarchy, as illustrated in the diagram above.
This scenario results in the creation of two new inferred | is a| relationships in the extension, i.e. the relationships G | is a | X and X | is a | E. The inferred relationship G | is a | E (green dotted line), which is present in the international edition, becomes redundant when classified together with the extension (therefore marked grey in the diagram).
Impact on subsumption
This type of intermediate extension concept does not change the results of subsumption testing between international concepts. It does, however, have an impact on which relationships from the international edition are non-redundant in the extension edition. In this example, the inferred relationship G |is a| E becomes redundant when combined with the inferred relationships from the extension.
Extension producers can handle this redundancy by:
Inactivating the inferred relationship from the International Edition, i.e. inactivate the relationship G | is a | E. For more information, see Inactivate Relationship in an Extension.
Illustration
Impact on hierarchy
The definition of a concept in an extension module may result in it being classified as an intermediate concept in the SNOMED CT polyhierarchy, as illustrated in the diagram above.
This scenario results in the creation of three new inferred | is a| relationships in the extension, i.e. the relationships G | is a | X and X | is a | D and X | is a | E. The inferred relationshipG | is a | E (green dotted line), which is present in the international edition, becomes redundant when combined with the inferred relationships from the extension. Furthermore, the definition of the extension concept X results in a modification of the definition of the international concept G, as G is now a subtype of the international concept D.
Impact on subsumption
This type of intermediate extension concept may change the results of subsumption testing for particular international concepts, when used within the local edition. Extension producers should therefore exercise extreme caution when introducing this type of concept addition.
When using the International Edition on its own, the concept G will not be treated as a subtype of the concept D. However, users of this example extension edition will see the international concept G as a subtype of the international concept D. This means that queries over international concepts stored in clinical data will lead to different results, depending on which edition is used. Therefore, intermediate concepts of this type may have serious consequences on the comparability and interoperability across SNOEMD CT Editions.
Concept
A new concept identifier is allocated within the extension namespace.
The attributes of the new concept are set as follows:
id is set to the new concept identifier allocated within the extension namespace
effectiveTime is set to the date the extension will be published
active is set to 1 to indicate that the new concept will be active at the time of publication
moduleId is set to the conceptId of a module that is managed by the extension producer
definitionStatusId is set to state whether the concept is primitive or fully defined
If an extension producer makes any changes or additions within their extension, which result in modification of the transitive closure of the International Edition, they must report this to SNOMED International. This will allow the issue that necessitated the change to be assessed and where appropriate resolved in the Internation Edition.
Authoring the concept definition involves specifying the defining properties of the concept, i.e. stating the axioms that represent necessary conditions for the meaning of the concept. For more information, see and .
