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

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

The table below provides a summary of the process to follow when adding a new concept to an extension.

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

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.

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.