In the CMAG group, there was a discussion about inactivating some children for 370159000 |Country of birth (finding)|, here. In that thread, there was also input on how to find out which concepts are used in practice. Since only CMAG members are allowed to post in the thread, I made a suggestion directly to Michael Harwood-Jones, who suggested I post it here.
Considering that SNOMED CT use is increasing and the NRCs do not have insight into which concept is used where, a manual control mechanism (for example, asking the NRC:s) before inactivation will be less and less comprehensive and more and more labour-intensive.
I suggest that a flag of some sort be added to concepts suggested for inactivation (or maybe also for major makeovers), and that it be visible in the browser and findable in a terminology server. Perhaps a third status: active, inactive, or under examination?
The concept would still be active and usable. When users validate their subsets, they will see that the concept is suggested for a makeover. More information, per concept, could be posted here or on SNOMED’s website, and users objecting to the suggested changes could raise their concerns with their NRC or other relevant group.
This is an idea; I might have missed some obstacle this would cause. My apologies if that’s the case.
I do, however, think moving to a more automatic process with broader reach would be easier and make the terminology more reliable. Perhaps it would also make improvements easier to roll out, if it decreases the concern that the changes might casue problems for some users.
I appreciate the post and understand the need to be able to communicate large blocks of concepts that are being considered for inactivation so that they can be reviewed by SNOMED users beyond just the National Release Centers.
Before we consider making tooling changes or modifying status indicators inside the terminology, can we consider falling back to existing functionality.
Authoring briefing notes typically contain ECL or ECL like statements that can be processed by an NRC to create an excel or other flat file that can be set to member organizations for review prior to sending feedback to SNOMED International.
If a better method is needed, perhaps a refset can be generated that contains the SNOMED Concept IDs for the block of concepts being considered for inactivation that is packaged as part of the Simple Refset file already included in the release package. Here again, each organization can use the refset to identify the concepts in the release that are under review for possible inactivation.
I could be entirely incorrect, but I think either or both of these options are better than trying to alter the use and meaning of the active flag across the entire terminology.
I just want to make sure we are making full use of the existing tooling before we start proposing or investigating extremely volatile changes to the tooling and/or terminology.
Thank you for raising this very interesting question and suggestion.
As you noted, it can be difficult for NRCs to determine whether a specific concept is actively in use if there is no well-defined content request and governance process in place.
Ideally, there should be a robust content request service that records who has requested a particular concept and whether that concept has been implemented in production systems. With such traceability, it would be significantly easier to manage changes and to notify relevant users in advance of upcoming modifications (something like briefing notes). In my view, this approach also may be more practical for National Release Centers (NRCs) than in a broader international context.
I agree with John that marking concepts for inactivation may not be the most appropriate strategy at scale. It is also important to remember that a terminology server is capable of managing inactivations and providing appropriate replacement concepts where available. However, in contexts where users do not utilize a terminology server and where SNOMED CT implementation maturity is low, for example, where concepts are used as a simple flat list, there needs to be a structured process to identify and manage changes to the concepts in use in the user side.
I recall that Anne Højen previously raised the issue of concepts that are inactivated without having association. This is an additional challenge that should be considered when discussing governance and change management processes.
I may be thinking entirely out of line but who knows perhaps I do have a suggestion to simplify this issue. Is it possible to create a “working list” by SNOMED International authors on what is the up and coming concepts to be a) inactivated, b) for quality improvement ..or other changes that that will impact all users. This working list would be connected to the early visibility content, and the briefing notes. This working list which can be made visible to all interested stakeholders can view what is coming and when these changes will happen and in which release they will be available. Perhaps this is just too simple.
To explain further, this would minimise extra “workload” for all respective NRCs. Since some NRCs do not have all information on how SNOMED is being used or implemented in their respective countries. By having this SNOMED International Working list or Work list visible to all, the users of SNOMED can follow the activities and monitor their internal usage and development. However, when it comes to which concepts within the local national extension are to be inactivated, the respective NRC would have to develop its own process of national concepts inactivation and communication since this will be done locally by the respective national NRC. These are two different scenarios pertaining to the inactivation done by SNOMED International and that done locally by the national NRCs. Firstly, one has to evaluate the impact on the terminology usage and the workload plus its complexity coupled to any new processes. These are just thoughts, not even a suggestion.
Thank you all for taking the time to consider my suggestion and sharing your thoughts!
I agree with John that using existing functionality is preferable for many reasons. As Maryam points out, not all users use terminology servers, but some do, and perhaps those are the users who are more likely to scan all their subsets for coming changes. Also, using a terminology server should never be a downside.
For this to work, we thus need a solution that can be used by both those who use terminology servers and those who need a list in a spreadsheet.
A refset would cater for that; it can be used in an ECL-search to compare against content in other refsets or subsets, and it can be executed and exported as a list.
I do not think it will be possible to centrally track which concepts are used in which production systems. The responsibility for knowing which concepts are used and thus keeping ahead of changes must lie with the users.
Making it easy for users to get information that changes are being considered will facilitate both timely feedback on the impact of those changes (solving the issue of asking the NRCs, who will not know the answer) and support the use of active content (especially if inactivation, as mentioned above, comes with an association).
A refset would also align with how I understand Keng-Ling’s suggestion: there could be one list (refset) for the international Edition and separate ones for extensions that wish to have one.
One outstanding question is where user feedback should be directed. Providing easily found and timely information might open the door to a storm of feedback. But that’s a happy problem.