Overview
| User | Use Case | |
|---|---|---|
| Authors | Authors of the International Edition | Inactivation of components in the International Edition Reactivation of a previously inactivated component Assess impact on International Refsets and update as required |
| SNOMED International Management of inactivation | Provision of appropriate Editorial guidance on inactivation for SI and Local extensions Development of quality assurance routines/algorithms Process for notifying the community of practice about upcoming inactivation/reactivation | |
Authors of Extensions | Management of historical associations from International release and possible impact on local inactivations Inactivation of local extension components Reactivation of local extension components Assess impact on national Refsets and data sets and update as required | |
| Local management of inactivation | Development of quality assurance routines/algorithms Process for notifying the community of practice about upcoming inactivation/reactivation | |
| Implementers | (health information managers) | Management of component inactivation with new releases of SNOMED CT
|
| Developers | Terminology server producers | Development of services to identify inactivated concepts and their replacements |
| Producers of clinical systems | Development of queries over historical data | |
Component Inactivation
When components of SNOMED CT are deemed out of scope or inappropriate for a particular SNOMED CT Edition, it is the responsibility of SNOMED CT authors to inactivate the component, specify an appropriate reason for inactivation and in some cases, identify proper replacements.
Prerequisites for a high quality inactivation process
- Authors of SNOMED CT content need to understand the available reasons for inactivation and be able to apply these consistently.
- Authors of SNOMED CT need to be able to prioritize inactivation values consistently in cases where multiple reasons occur.
- Authors need to identify proper replacements for specific cases of inactivation
Identifying Impact of Inactivation
Upon new releases of SNOMED CT, software systems will need updating to align with the latest release of SNOMED CT and thus comply with the continuous evolvement of the terminology. Updates to SNOMED CT enabled systems will need to take into account the changes made in SNOMED CT since the previous release (or the latest applied version), including any additions, inactivations or modifications of components or reference set members. An important part of this process is to be able to identify which components have been inactivated, and identify whether any of the inactivated components are used, or in some way, impact the particular system. Another aspect of this, is that extension producers should be able to identify if any inactivated components in the International Edition impact the components created or referenced in the extension.
Prerequisites for identifying the impact of Inactivation
- Extension producers should have
- The ability to validate the referential integrity between extension components and the International Edition
- The ability to compare if any inactivated component in the International Edition is referenced in any active Extension component or reference set member
- Consumers of any SNOMED CT Edition should have
- The ability to compare the inactivated components of the applied Edition to the components used in any part of the SNOMED CT enabled system, including components used
- within value sets for data elements
- in the binding to information model elements (model meaning binding)
- in queries used for analytics or decision support
- in any other applied models (for communication, reporting etc.)
- The ability to compare the inactivated components of the applied Edition to the components used in any part of the SNOMED CT enabled system, including components used
Note: This process is not dependent on knowledge about the reason for inactivation.
Resolving Inactivation Issues
As part of updating a SNOMED CT enabled system to align with a new SNOMED CT Edition, knowledge about the reason for inactivation becomes important to support the resolution of any issues imposed by the inactivation. Furthermore, being able to effectively identify proposed replacements for inactivated components is key to facilitate consistency across different implementation.
Examples of situations where the resolution of an inactivation issue depends on the reason for inactivation are:
- Concepts which have been inactivated because they are deemed out of scope of the particular Edition
- If required in the system, consider adding the component to an extension
- Concepts which have been ambiguous
- Replace with one or more concepts which are not ambiguous but reflect the intended meaning (which can vary between implementations)
- Concepts which have been considered redundant
- Replace by the concept which have been retained active and represents the same meaning