1. 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 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 components |
| 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 | |
| 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 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 | |
2 Comments
Jim Case
An additional consideration, which is being floated in the MAG, is the addition of the ability to add annotations, as allowed within the current OWL architecture. There are a number of defined annotation types that may be applicable to identified needs for additional information about concept inactivations, but are informational only. This has not been formally discussed, but may be an applicable discussion point in this subproject.
Paul Amos
Jim Case , this is very useful additional knowledge, we did comment on whether this might be a possibility in our last meeting. We will certainly explore this further.
Many thanks
Paul