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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Principles for modifying reference sets include:

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

Purpose

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

• Changing the acceptability of a description in a language reference set

• Changing the order of subset members specified in an

Principles for modifying reference sets include:

• Reference sets can be modified by

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

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

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

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:

1. 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)

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

Concept File - Full (National Edition 20200331)

Concept File - Snapshot (National Edition 20200331)

Concept File - Snapshot (National Edition 20200931)

Concept File - Delta (National Edition 20200331)

In this section, we illustrate the changes to the release files when promoting a concept using the extension distribute method.

Concept File - Full (National Extension 20200331)

Concept File - Full (International Edition 20200131)

No rows in the International Edition reference

Concept File - Snapshot (National Extension 20200931)

Concept File - Snapshot (International Edition 20200731)

Concept File - Delta (National Extension 20200331)

Concept File - Delta (International Edition 20200131)

No rows in the International Edition reference

Concept File - Delta (National Extension 20200931)

No rows in the Extension Concept File reference

Concept File - Delta (National Extension 20200931)

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

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.

Purpose

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

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

• To correct errors in the definition of a concept

• To remove any redundant | 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

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

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

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

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

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

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

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

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

Inactivate Concept in an Extension

Purpose

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 not 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 ). 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 .

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.

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

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

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

SNOMED CT 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.

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.

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.

Purpose

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

Principles

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: effectiveTime, active, moduleId, relationshipGroup, characteristicTypeId, and modifierId. 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 and the .

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

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

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.

Purpose

Reference set members may be inactivated when

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

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

Principles

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

Process

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

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.

• General Authoring Principles

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

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

Provide Feedback

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.

Can I reactivate inactivated international concepts in my extension?

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.

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

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:

• Reference Set Practical Guide:

• Expression Constraints Specification and Guide:

Purpose

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:

1. Other concepts in the same extension module may be stated to be a subtypes of the new concept

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

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

Create New Reference Set in an Extension

Purpose

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

• Specifying a subset of components for inclusion or exclusion

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

• Specifying the acceptability of descriptions in a given language or dialect

For more information about a range of purposes for reference sets, please refer to the .

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:

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.

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 .

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

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.

Purpose

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

  • 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 references set members to mim this possibility.

The table below provides details and considerations on the process of inactivating a reference set.

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.