Table 3.7.3-1 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.
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. Value set bindings that use hierarchy-based constraints are more likely to include new concepts that are appropriate to the data entry context. | Review newly added concepts paying particular attention to concepts in areas of the hierarchies that are frequently used. Consider if new concepts need be added to any reference sets, search constraints, user interface terminology bindings or queries. Recommendation Mitigate the risk of excluding new concepts by using hierarchy constraints, rather than subsets or lists of individual concepts. These will automatically include new concepts that conform to the constraint minimizing the need for manual intervention. |
Inconsistent reporting and analytics may occur. This is a risk if a new concept has not been included in a reporting query criteria. | Risk is higher if reporting queries enumerate members of a reference set or specify each concept individually. Queries that use hierarchy-based constraints are more likely to include new concepts that are relevant to the report. | |||
Inactivation of a concept | HIGH | Inactive concepts may be explicitly referenced by user interface terminology bindings. This can lead to one of the following errors:
| Risk is higher if the value set binding specifies members of a reference set or individual concepts. Value set bindings that use hierarchy-based constraints will automatically exclude inactive concepts. | Check whether any inactivated concepts are used in user interface terminology bindings. Use the reason for inactivation to inform decisions on an appropriate approach to resolution. Update these bindings to remove references to inactive concepts, preferably replacing them with appropriate active concepts identified using historical associations from the replaced concept. For medicolegal reasons these changes should only affect newly entered record. |
Inactive concepts may be referenced in query criteria used for reporting and analytics. This may cause significant changes to the results of those queries, as concepts previously subsumed by (or defined by reference to) this concept may no longer be included. | Risk is higher if the reference to the concept is part of a subsumption constraint. Individual references to the inactive concept will not result in changes to the report output. | Check query criteria used for reporting and analytics for references to inactive concepts. If necessary, adjust the query criteria to delivery intended results (e.g. by excluding inactive concepts). | ||
Inactive concepts may be present in EHR record entries that were created when the concept was active. The existence of an inactive concept in earlier record entries is not an error. However, as the concept is no longer active it will not be subsumed by other concepts and will be excluded from the results of queries that formerly included it. | Use of concepts that are later inactivated. This is a particular issue if the concept is inactivate due to ambiguity because in this case there is no single equivalent active concept. | Review inactivated concepts to determine whether they were previously subsumed by queries used for reporting or analytics. Use the reason for inactivation to inform decisions on an appropriate approach to resolution. Choose an appropriate approach to resolve any potential reporting anomaly. Some possible resolutions are suggested here:
| ||
Change to a concept | NONE | The only mutable concept data attribute in the release file is definitionStatusId. If the value changes this indicates a change in the definition. However, in itself a change to the definitionStatusId is not significant1. | - | - |
Addition of a description | LOW | Makes a new display term available for a concept. This may simply be another option. However, other changes, such as inactivation of other descriptions or changes in language acceptability, may make it necessary to use the new description. | The impact of addition of a new description is minimal unless other descriptions are inactivated or are no longer marked as preferred or acceptable in the relevant language reference set. | Description added to a new concept:
Description added to an existing concept:
|
Change to a description | LOW | Changes to the term and/or caseSignificantId are possible. However, quality assurance rules should limit the range of possible changes to the term in a description. | Changes to descriptions used as display terms in data entry templates or reports. | Review data entry templates and reports that use a changed description as a display term:
In general, terms stored in existing patient records should not be updated based on terminology changes2. |
Inactivation of a description | HIGH | An inactivated description cannot be used as the source of a display term for data entry or reporting. | Review any use of terms that are associated with:
In these cases, replace the use of this term in data entry interfaces with a term for the same concept that is either preferred or acceptable in the selected language reference set. Similarly, if a term is stored with the selected concept, ensure that the term stored is also preferred or acceptable in the selected language. In general, terms stored in existing patient records should not be updated based on terminology changes2. | |
Change to the acceptability of a description in a language refset used by the application | MODERATE | A description that is not acceptable for use in one or more of the languages or dialects used in the EHR system, must not be used as the source of a display term for data entry or reporting. | ||
Additions, changes and inactivations of relationships | MODERATE | Relationships represent the inferred necessary normal form definition of a concept. OWL axiom reference set members represent the stated definitions of concepts. Additions, changes or inactivations of either of these components, represent changes to the definition of a concept. A change in the definition of a concept also affects other concepts with a definitions that refer to that concept. The impact of changes to concept definitions depends on the way these changes affect the results of expression constraints and queries used in data entry templates, reporting and analytics. | Review value set bindings, expression constraints and queries used in reports or analytics and identify the expression constraints on which these depend. For each of these constraints that may have been affected by these changes apply the steps shown in Table 3.7.3-2. Where appropriate fake the actions outlined in Table 3.7.3-3 to address any unintended or unwanted effects arising from the update. | |
Additions, changes and inactivations of OWL expression refset members | ||||
Additions, changes or inactivations of reference set members | MODERATE | Expression constraints and queries may include or exclude members of a reference set. Additions of new members or inactivation of existing members can therefore alter the results of expression constraints and queries used in data entry templates, reporting and analytics. |
Step | Input | Output Description | Output Name |
Identify snapshot views of two versions fo 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 two 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 created by the previous step to identify two subsets that containing concepts that conform to the constraint in one of the versions but do not conform in the other version. | 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 the subset of concepts that only conform to the constraint in the current version into two subsets depending on the active status of the concept 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 the subset of concepts that only conform to the constraint in the new version into three subsets depending on whether the concept is present in the current version and if so depending on the active status of the concept. | 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 | |
Check the content of the five sets of concepts generated by the last two steps using the notes in Table 3.7.3-3 |
Output Name | Description | Impact | Recommended Action |
V2-ECL-only-V1-absent | New concepts in V2 release that were not present in V1.
| 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 be included 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 concept4. |
Footnotes
Feedback