# Terminology Change Management ## Access Details of Terminology Changes SNOMED CT has rich versioning mechanism that retains the full history of changes to every [component](https://confluence.ihtsdotools.org/display/DOCGLOSS/component) and [reference set member](https://confluence.ihtsdotools.org/display/DOCGLOSS/reference+set+member). As a result, it is possible to review the content of the terminology as it was at any time in the past and to make comparisons between two versions. In addition to tracking the state of the terminology at specific times in the past, the versioning mechanism also provides and indication of the reason for inactivation of each concept or description. In the case of concepts, there is also data linking inactive concepts to active concepts that may be used to replace them. ### Services Required to Access Details of Terminology Changes The following table shows the terminology services required to access each of these different types of versioning data.

Practical Requirement	Required Services	Dependencies	Status
Enable the selection of SNOMED CT edition and the versions of that edition to be compared REQUIRED	Select Edition and Version	N/A	REQUIRED
Identify concepts that have been added, changed or inactivated between the specified versions. REQUIRED	Identify Changes to the Terminology Concept	Get a Concept, Description or Relationship Get concept by identifier	REQUIRED
Get inactivation reason for each inactivated concept REQUIRED	Get History Data Concept inactivation reference set	Get Data from a Reference Set	REQUIRED
Identify concepts that are candidates to replace each inactivated concept REQUIRED	Get History Data Historical association reference sets	N/A	REQUIRED
Identify descriptions that have been inactivated between the specified versions. REQUIRED	Identify Changes to the Terminology Description	Get a Concept, Description, or Relationship Get description by identifier	REQUIRED
Get inactivation reason for each inactive description REQUIRED	Get History Data Description inactivation reference set	N/A	REQUIRED
Get changes to inferred definitions OPTIONAL	Identify Changes to the Terminology Relationship Get Definition of a Concept Get inferred necessary normal form definition of a concept	Get a Concept, Description or Relationship Get relationship by identifier	OPTIONAL
Get changes to stated definitions OPTIONAL	Identify Changes to the Terminology OWL reference set Get Definition of a Concept Get stated definition of a concept	Get Data from a Reference Set OWL reference set	OPTIONAL

## Integrate and Interpret Versioning Data The services described in 'Access Details of Terminology Changes' get versioning data related to the addition, modification, or inactivation of individual terminology components. Many practical uses of this data require interpretation of the overall effect of a combination of changes to a concept. Therefore, it may be useful to integrate versioning data in ways that facilitate a review of the impact of these changes. A possible way to achieve this is illustrated by the data model in the diagram below A data structure of this type could be used to assist the identification of changes relevant to managing the impact of changes on EHR applications and Extensions in two ways: * By generating a human-readable version of the change data for use in manual review of existing data * As a computer processable resource from which queries can be generated to search records, user interface templates, reporting, and analytics queries and extensions for references for changed or inactivated concepts and descriptions.

Example Data Model for Integrated Versioning Data

Each instance of the *Component Version Data* object represents the previous and new states of an identified concept, description[^1], relationship or OWL axiom reference set member that has been added, changed, inactivated or reactivated between two specified versions of the same edition. ***Component Version Data Object*** Details of the data items in the example *Component Version Data* object are shown in the following table.

Data Item	Notes
componentType	Indicates whether the component is a concept, description, relationship (part of the inferred view of the concept definition), or OWL axiom (part of the stated view of the concept definition).
action	Indicates the nature of the change: added : This component was not present in previous release changed : The active value is unchanged and change has been made to a data value inactivated : The active value of the component has been changed from 1 to 0 reactivated : The active value of the component has been changed from 0 to 1
id	The identifier of the concept, description, relationship or OWL axiom reference set member.
newComponentData	The ComponentData for the identified component in the snapshot release of the later of the two versions being compared. ComponentData refers to a representation of the data in the relevant release file row for the identified concept, description, relationship or OWL axiom. In the case of a description, the ComponentData should also include the acceptability values for that description in the language reference sets of that snapshot release. The data should be represented in a way that supports the data structure of the specified componentType. For example, the data could be represented as the string serialization of a JSON object.
previousComponentData	Represents the release file data for the identified component in the earlier of the two versions being compared. Empty if the component was not present in the earlier version of the release file.
reason	Only applicable to concepts and descriptions that are active in the previousComponentData view and inactive in the newComponentData view: In the case of a concept, the reason for inactivation as represented in the concept inactivation reference set. In the case of a description, the reason for inactivation as represented in the description inactivation reference set.
alternatives	Only applicable to concepts that inactive in the newComponentData view: An array of historically associated concepts derived by selecting active rows from most recent snapshot view the historical association reference sets with a referenceComponentId that matches the identifier of the concept. Each element of the array should include the refsetId, which indicates the type of association, and the targetComponentId, which refers to associated concept.
conceptId	The identifier of the concept with which this component is associated. This provides a link to the id of the relevant Complete Concept Version Data. In the case of a concept, this is the same as the id (i.e. same as the id data item above). In the case of a description, this is the conceptId. In the case of a relationship, this is the sourceId. In the case of an OWL axiom, this is the referencedComponentId.

### Full Concept Version Data There is an instance of the *Full Concept Version Data* object for each concept to which one or more of the following conditions applies: * The *concept* has been added, changed, inactivated or reactivated * *OWL axioms* or *relationships* that contribute to the stated and/or inferred *definition* of the *concept* have been added, changed, inactivated or reactivated * *Descriptions* associated with the *concept* have been added, changed, inactivated or reactivated * *Language reference set rows* that specify the acceptability of an associated *description* have been added, changed, inactivated or reactivated. Each instance of the *Full Concept Version Data* object represents the previous and new state of a concept including all its active descriptions (with relevant language acceptability data), all its active relationships and all associated active OWL axioms. ***Full Concept Version Data Object*** Details of the data items in this object are shown in the following table.

Data Item	Notes
id	The identifier of a concept that has been affected directly or indirectly by updates between two specified versions of the same edition.
newFullConceptData	A representation of the FullConceptData for the identified concept in the snapshot release of the later of the two versions being compared. FullConceptData represents all pertinent active release file entries that describe and define a specific concept. This includes all the data in: the row of the concept snapshot release file with the relevant id value. all active rows of the description snapshot release file with a conceptId value matching the identifier of the concept and for each of these descriptions and all active rows of the language reference set snapshot release file with the a referencedComponentId value matching the identifier of that description all active rows of the relationship snapshot release file with a sourceId value matching the identifier of the concept. all active rows of the OWL reference set snapshot release file with refsetId 733073007 \| OWL axiom reference set\| and a referencedComponentId value matching the identifier of the concept. The data should be represented in a way that supports the data structures of all of the above data components. For example, the data could be represented as the string serialization of a JSON object combining representations of each of the different data items.
previousFullConceptData	A representation of the FullConceptData for the identified concept in the snapshot release of the earlier of the two versions being compared. Empty if this concept was not present in the earlier release.

Data Item

Notes

The identifier of a concept that has been affected directly or indirectly by updates between two specified versions of the same edition.

newFullConceptData

A representation of the FullConceptData for the identified concept in the snapshot release of the later of the two versions being compared.

FullConceptData represents all pertinent active release file entries that describe and define a specific concept.

This includes all the data in:
- the row of the concept snapshot release file with the relevant id value.
- all active rows of the description snapshot release file with a conceptId value matching the identifier of the concept and for each of these descriptions
  - and all active rows of the language reference set snapshot release file with the a referencedComponentId value matching the identifier of that description
- all active rows of the relationship snapshot release file with a sourceId value matching the identifier of the concept.
- all active rows of the OWL reference set snapshot release file with refsetId 733073007 | OWL axiom reference set| and a referencedComponentId value matching the identifier of the concept.
The data should be represented in a way that supports the data structures of all of the above data components. For example, the data could be represented as the string serialization of a JSON object combining representations of each of the different data items.

previousFullConceptData

A representation of the FullConceptData for the identified concept in the snapshot release of the earlier of the two versions being compared.

Empty if this concept was not present in the earlier release.

## Manage Impact of Changes on EHR Applications The table below summarizes change management issues that may affect and EHR application when moving to a new version of a SNOMED CT edition. It also outlines approaches to checking for and resolving issues of different types. ### ***Impact of Version Updates on EHR Applications***

Change Type	Significance	Risks	Factors Affecting Risk Level and Likely Impact	Change Management Actions
Addition of a concept	MODERATE	The new concept may not be available in some data entry contexts. Although all new concepts will be available for ad-hoc searches, it may not be possible to enter a new concept in data entry fields with tightly defined value set bindings.	• Risk is higher if the value set binding specifies members of a reference set or individual concepts. • Hierarchy-based constraints are more likely to include new concepts automatically.	• Review newly added concepts, especially those in frequently used hierarchies. • Consider if new concepts should be added to reference sets, search constraints, UI bindings, or queries. Recommendation: Use hierarchy constraints rather than fixed concept lists to reduce manual maintenance.
Addition of a concept	MODERATE	Inconsistent reporting and analytics may occur if a new concept is omitted from reporting query criteria.	• Risk is higher when queries use fixed reference sets or lists. • Hierarchy-based queries are more likely to include relevant new concepts.	• Review and revise reporting query criteria to ensure they include the new concepts where appropriate.
Inactivation of a concept	HIGH	Inactive concepts may still be referenced by UI bindings, causing errors: • Inactive concept might still be selectable (serious error) • Or it might be blocked entirely, making it impossible to enter needed data.	• High risk with fixed value sets or individual concept lists. • Lower risk when using hierarchy-based constraints (which auto-exclude inactive concepts).	• Identify UI bindings referencing inactive concepts. • Replace references with active concepts using historical associations. • Ensure updates only apply to new entries to preserve legal record integrity.
Inactivation of a concept	HIGH	Inactive concepts in query criteria can significantly change query results.	• High risk if used in subsumption constraints. • Lower risk if referenced directly.	• Check and revise query criteria that reference inactivated concepts. • Adjust queries to continue delivering intended results.
Inactivation of a concept	HIGH	Inactive concepts may still exist in EHR records from earlier data entry. These will no longer be subsumed or included in relevant queries.	• Especially problematic if concept was inactivated due to ambiguity (no direct replacement).	• Options: – Explicitly include the inactive concept in queries – Create reference sets of formerly-included inactive concepts – Use historical associations to extend subsumption – Accept exclusion where appropriate – Add mapped active concept (as a supplement, not a replacement)
Change to a concept	NONE	Only `definitionStatusId` can change, indicating redefinition. Not significant by itself.	-	-
Addition of a description	LOW	New display term added. Minimal impact unless tied to inactivation or changes in acceptability.	• If preferred/acceptable terms are removed, the new term may need to be adopted. • By default, preferred term in target language is displayed.	• Evaluate whether the new description should be used in data entry templates or reports. • Existing records remain unaffected.
Change to a description	LOW	Term or `caseSignificanceId` might change. May affect display consistency.	• QA rules limit term changes. • Display logic might be impacted.	• Review and update data entry templates or reports that display the changed term. • Ensure correct casing per `caseSignificanceId`. Note: Stored records typically should not be changed.
Inactivation of a description	HIGH	Inactivated descriptions can't be used as display terms for data entry or reporting.	• Especially impactful if no acceptable alternative term is defined in the language reference set.	• Replace use of inactive terms in UI and reporting templates with preferred or acceptable alternatives. • Don't retroactively modify stored records.
Change to acceptability of a description	MODERATE	Description that is no longer acceptable in a language/dialect should not be used as display term.	• Impacts systems with multilingual language bindings.	• Review language reference sets used by the system. • Ensure display terms remain acceptable/preferred.
Changes to relationships or OWL expressions	MODERATE	These changes alter concept definitions, which may impact expression constraints and queries.	• Queries based on subsumption or logical definitions may behave differently.	• Review all expression constraints, value sets, and queries. • Revalidate and adjust per guidance in Tables 3.7.3-2 and 3.7.3-3.
Changes to reference set members	MODERATE	Additions or inactivations of members may change inclusion in queries and templates.	• Can affect data entry templates, reporting outputs, or analytics logic.	• Review impacted reference sets. • Update expression constraints or queries accordingly.

### ***Comparing Results of Applying an Expression Constraint to Two Versions of a SNOMED CT Edition***

Step	Input	Output Description	Output Name
Identify snapshot views of two versions of the same SNOMED CT edition	Current edition	Edition in use before planned update	V1-snapshot
	New edition	Edition to be used after planned update	V2-snapshot
Apply the Expression Constraint (ECL) to each version to identify subsets of concepts that conform to the constraint	V1-snapshot	Set of concepts in V1-snapshot that conform to the ECL	V1-ECL-result
	V2-snapshot	Set of concepts in V2-snapshot that conform to the ECL	V2-ECL-result
Compare the subsets to identify concepts that conform in one version but not the other	V1-ECL-result	Concepts in V1-ECL-result but not in V2-ECL-result	V1-ECL-only
	V2-ECL-result	Concepts in V2-ECL-result but not in V1-ECL-result	V2-ECL-only
Subdivide V1-only concepts by active status in the new version	V1-ECL-only	Concepts in V1-ECL-only that are active in V2-snapshot	V1-ECL-only-V2-active
	V1-ECL-only	Concepts in V1-ECL-only that are inactive in V2-snapshot	V1-ECL-only-V2-inactive
Subdivide V2-only concepts by status in or absence from the old version	V2-ECL-only	Concepts in V2-ECL-only that are active in V1-snapshot	V2-ECL-only-V1-active
	V2-ECL-only	Concepts in V2-ECL-only that are inactive in V1-snapshot	V2-ECL-only-V1-inactive
	V2-ECL-only	Concepts in V2-ECL-only that are absent from V1-snapshot	V2-ECL-only-V1-absent

{% hint style="info" %} Check the content of the five sets of concepts generated by the last two steps using the notes in the following table. {% endhint %} ### ***Evaluation of Differences between ECL Results***

Output Name	Description	Impact	Recommended Action
V2-ECL-only-V1-absent	New concepts in V2 release that were not present in V1. Inclusion of these concepts will not affect retrospective reports or analytics because the new concepts could not have been used previously. Inclusion of these new concepts is appropriate as they conform to the stated constraint.	NONE	None
V2-ECL-only-V1-inactive	It is unusual for concepts to be reactivated so this set will usually be empty. Concepts reactivated in V2 release after being inactive in V1 release. However, in theory this could alter the result of retrospective reports because reactivation of the concept causes these concepts to be included whereas previously they were excluded.	LOW	If this subset contains any concepts, be aware that this may affect result of rerunning an earlier reports or analytics on retrospective data. However, in most cases no action is required.
V2-ECL-only-V1-active	Concepts that only conform to the ECL in V2 although they are active in both versions. Retrospective reports will now include concepts that were previously excluded from the report.	HIGH	Concepts in this subset will be included in reports or analytics performed after upgrading to the new version but would not have been included when using the current version. This may be due to an revision of concept definitions or addition of concepts to a reference set. Assuming these changes were intentional improvements the revised result should be more accurate and more complete. In some cases, this type of change may have unintended consequences. Therefore a review of the context in which these constraints are used is recommended. If necessary the constraint can then be refined to exclude some or all of the added concepts.
V1-ECL-only-V2-active	Concepts that only conform to the ECL in V1 although they are active in both versions. Retrospective reports will now exclude concepts that were included in the report.	HIGH	Concepts in this subset will be excluded from reports or analytics performed after upgrading to the new version but would have been included when using the current version. This may be due to an revision of concept definitions or removal of concepts from a reference set. Assuming these changes were intentional improvements the revised result should be more accurate. In some cases, this type of change may have unintended consequences. Therefore a review of the context in which these constraints are used is recommended. If necessary the constraint can then be refined to specifically include some or all of the excluded concepts.
V1-ECL-only-V2-inactive	Concepts that only conform to the ECL in V1 that are inactive in V2. In this case, inactivation of the concept means that retrospective reports will exclude these concepts that were previously included in the report.	MODERATE	Concepts in this subset will be excluded from reports or analytics performed after upgrading to the new version but would have been included when using the current version. In this case, the reason for exclusion is that the concept is inactive rather than being a direct consequence of the constraint. There are two ways to enable an inactive concept to conform to a constraint. A direct reference to a concept identifier or a reference to the members or a reference set that includes that concept.

## Manage Impact of Changes on Extensions The following table summarizes change management issues that may affect and EHR application when moving to a new version of a SNOMED CT edition. It also outlines approaches to checking for and resolving issues of different types. {% hint style="info" %} The changes outlined in this section must be applied when an extension module is updated to align with the new versions of the modules on which it depends. Before an updated extension module is released, updates must also be made to its module dependencies. Please refer to the [Extensions Practical Guide ](https://app.gitbook.com/o/h8Z6qGxuQrzM9vbx5bPT/s/3RKZIWpWFT0ocCgNT16E/)for more detailed information about *extension modules* and the Module Dependency Reference Set. {% endhint %} ### ***Impact of Version Updates on Extensions***

Change Type	Significance	Examples of Potential Impact	Change Management Actions
Addition of a concept	MODERATE	A new concept in a module on which the extension depends may have the same meaning as an existing concept in the extension.	Consider inactivating the extension concept and create a historical association from it to the new concept in the base module.
	MODERATE	A new concept may be a supertype of an extension concept. Classification may infer new subtype relationships. But if the extension's definition lacks necessary axioms, the new relationship won't be inferred.	Review new concepts to identify if they should subsume any extension concepts. If so, update the extension concept's definition with additional axioms to support accurate classification.
	MODERATE	If the extension includes a language reference set, additions are required for acceptability of new concept descriptions.	Add necessary descriptions in the relevant language/dialect. Update the language reference set to include the new fully specified name and preferred term.
Inactivation of a concept	HIGH	A component or reference set member in the extension may reference an inactivated concept in the base module.	Concept definitions must not reference inactive concepts. • Remove inactive concept references from OWL expressions and active relationships. • Descriptions may still reference inactive concepts for display purposes.
	HIGH	Reference sets like OWL or Mapping sets must be reviewed.	Inactivate or replace refset members that refer to inactive concepts. Update OWL reference set rows. Reclassify to confirm no active relationships point to inactive concepts.
Addition of a description	NONE	No impact unless the extension uses a language reference set.	-
	MODERATE	A new description may need to be reflected in the extension's language reference set.	Consider adding the new description as an acceptable term in the extension's language refset.
Inactivation of a description	LOW	References to inactivated descriptions in refsets may be affected.	Review and update reference sets that refer to now-inactive descriptions.
	MODERATE	If the description is referred to in a language reference set as a preferred term or FSN, updates are required.	• Inactivate reference set members pointing to inactive descriptions. • If the inactivated term was "preferred", add a new active preferred description of the same type. • Do not overwrite inactive descriptions — add replacements.
Changes to concept definitions	NONE	No impact unless the extension contains additional clinical concepts.	-
	HIGH	Changes to the base module's concept model or specific definitions may affect extension definitions.	• Review and update impacted extension concept definitions. • Align with changes in the base module. • Reclassify to maintain consistency.

Provide Feedback [^1]: To ensure that changes to the acceptability of a *description* in any language or dialect are captured, a *description* should also be included if any language reference set member that refers to it has been added, changed, inactivated or reactivated. [^2]: **If the *****active***** value has changed, the action is either *****inactivated***** or *****reactivated*****, even if a data value has also changed.** [^3]: The definitionStatusId fields has two possible values: [900000000000073002 | Sufficiently defined by necessary conditions definition status|](http://snomed.info/id/900000000000073002) or [900000000000074008 | Not sufficiently defined by necessary conditions definition status|](http://snomed.info/id/900000000000074008) . Since July 2019 the information provided by this value is primarily informative and has little practical impact on processing. It indicates whether the necessary conditions defined in the relationships file provide a sufficient definition of the concept. However, the primary representation of the concept definition now uses OWL axioms. These are used to classify the terminology and generate the relationships that represent the inferred definition and to set the definitionStatusId. The change to the OWL axiom is significant and the change to the definitionStatusId is a consequence of that change. [^4]: Concept identifiers and terms stored in patient records represent the data as entered and subsequent terminology updates should not result in changes to those original records. This does not preclude additions that reflect the effect of terminology updates on a specific record. However, these additions should be distinct from the original record [^5]: It is possible that a record containing a concept from the new version (V2) might have been received from another EHR instance that was upgraded to V2 earlier. In this case, the receiving system would not include this concept in reports it was upgraded to V2. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.snomed.org/snomed-ct-practical-guides/snomed-ct-terminology-services-guide/3-terminology-service-use-cases/terminology-change-management.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.