Overview
| User | Use Case | |
|---|---|---|
| Authors | ||
Editors of the International Edition | The requirement to consistently apply inactivation values and historical relationships to inactivated components in the International Edition |
The requirement to consistently apply inactivation values and historical relationships to reactivated components in the International Edition |
Reactivation of a previously inactivated component
Assess impact on International Refsets and update as required
Inactivation of compound statements where each element may require mapping to a separate concept e.g. "Fracture of skull with coma" maps to "Fracture of skull" and "Coma" | ||
Editors of Extensions (This includes Consultant Terminologists) | Management of historical associations from International release and possible impact on local inactivations/reactivations The requirement to consistently apply inactivation values and historical relationships to inactivated components in the Local Edition The requirement to consistently apply inactivation values and historical relationships to reactivated components in the Local Edition The requirement to properly handle content "moved to" or "moved from" the International Release of SNOMED CT | |
| Release Management Team | SNOMED International Management of inactivation | Assess the need for retrospective assessment of inactivated/reactivated components in the International Release of SNOMED CT Develop a process for retrospective correction of inactivation historical relationships |
Provision of appropriate Editorial guidance |
for |
SNOMED International and Local |
NRC editors on inactivation/reactivation Consideration of the impact on Language editions Development of quality assurance routines/algorithms Assess impact of inactivated/reactivated components on International Refsets and mappings and update as required Assess impact of inactivation of a concept within the Core Release on the International Release and Community Release Assess impact of the introduction of Concrete Domains - e.g. where a SCT concept for a number is replaced by the actual number 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 extensioncomponents |
Assess impact on national Refsets and data sets and update as required
| Local management of inactivation | Development of quality assurance routines/algorithms Assess impact of inactivated/reactivated components on national Refsets, mappings and data sets Process for notifying the community of practice about upcoming inactivation/reactivation |
Management of component inactivation with new releases of SNOMED CT
- Identifying impacts of components which have been activated
- Resolving inactivation issues (e.g. identifying replacements)
| Developers | Terminology server producers | Development of services to identify inactivated/reactivated concepts and how to manage their replacements Development of services to manage the impact of inactivated/reactivated Refsets , mappings and Datasets where these services form a part of the terminology server services |
| Producers of clinical systems | Development of queries over historical data |
...
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
Developing services to identify inactivated components and their replacements
to identify inactivated components and their replacements which can be presented to end users and systems in real time Development of robust audit trails which ensure a complete concept history which may include textual supporting information Development of appropriate notification to end users of clinical records where concept inactivation may impact the meaning of existing records | ||
| End Users | Clinical end users | How to manage the apparent loss of frequently used concepts How to manage the impact of component inactivation/reactivation on personal/local audit |
| Data analysts/Information managers | How to manage component inactivation/reactivation to ensure a robust history mechanism for traceability and data healing How to manage changes to component status as a result of inactivation/reactivation in current live data collection and discovery activities How to manage the impact of component inactivation/reactivation on mappings |
...