I am looking for a way to view the deeper rationale behind concept inactivations.
While the standard release files provide the general Inactivation Reason (e.g., Duplicate, Ambiguous, Outdated) and the Historical Association (e.g., SAME AS, REPLACED BY), this structured metadata is often not enough to fully understand why a complex modeling decision was made.
I saw that the SNOMED team occasionally publishes Briefing Notes that explain rationals for some concepts, but these only seem to cover a small fraction of inactivated concepts.
I would like to know if there is a central repository, discussion forum, or archive where implementation teams can view the underlying discussions, or detailed rationales for everyday concept inactivations.
I am not certain about other authoring platforms, but the SNOMED managed services authoring platform does not allow for authors to enter a free-text explanation regarding a specific authoring decision to inactivate a concept. Even if the software allowed for the capture of such information there isn’t anywhere, at least that I am aware of, for this information to be contained in the RF2 file package.
This may be a use case for the inclusion of support for attribution within SNOMED CT, but from an authoring perspective this is a huge ask that would increase authoring overhead exponentially with information that may or may not be useful.
Let me link to something that may help a bit. Many times, seeing the inactivation in the context of all the inactivations on a particular release can shed light on the reason behind it, recognizing that it may not be an individual change but part of a larger set of similar concepts, often responding to quality improvement efforts aimed at correcting particular patterns.
We have created an inactivations report page on the Implementation demos site that provides an overall view of all concepts inactivated in a release and their replacements.
I agree that sometimes simply looking at the inactivation reason and the historical association refset is enough to understand the rationale. However, in many cases, it isn’t.
For example, the concept 30041005 |Acute angle-closure glaucoma (disorder)| was inactivated as Erroneous, with a suggested replacement of 1111451000000106 |Acute angle closure (disorder)|. Based on the metadata alone, a user would have to research the “why” on their own, leaving them uncertain if their conclusion matches the SNOMED team’s actual decision. Fortunately, the briefing notes from September 8, 2025, clarified this specific case.
In other cases, like the inactivation of 1508000 |Intracerebral hemorrhage (disorder)| due to ambiguity, I don’t fully understand the underlying logic. While I can try to guess the context, I can’t be sure it aligns with the SNOMED team’s reasoning. There must have been discussion behind a decision like this.
I assume a unified, central repository for these discussions doesn’t exist yet. However, is there anywhere I can access briefing notes prior to August 2025, or find documentation on these major modeling decisions?
Looking ahead to future developments, I propose that creating a dedicated place to review these rationales would be incredibly valuable.
Typically, the inactivation of an individual concept at the international level is initiated by a content request received through the content request system (CRS) from a member country with supporting reasoning and references.
In other cases, the inactivation of a concept may be the result of the request for a change to an existing concept. After researching the requested change, the author may determine that the concept needs to be inactivated, and in some cases replaced with new concepts to align with editorial policy.
While there are additional permutations that could result in the inactivation of a concept or description, it would be challenging to document each individual case.
If the inactivation is part of a broader scope of work, then the basis for the inactivation would be documented in a Briefing Note and/or as part of an advisory committee meeting like the EAG.
Again, there may be some technical steps that could be taken to help make the information surrounding an inactivation more transparent. That being said, requesting an author to free-text the justification for an inactivation for each individual inactivation is realistic or has a justifiable return on investment for the amount of work. I may be misunderstanding, but that seems to be what the “ask” is?
There is a already a mechanism for publishing detailed inactivation reasons. Indeed inactivation was one of the headline motivations for the ‘annotation’ work of recent years. References to ‘inactivation’ are frequently made in this MAG discussion page, and ‘Inactivation note’ is offered in the reference set example at the foot of this release file specification page. So far the ‘Inactivation note’ annotation attribute does not yet exist so this potential mechanism is not yet in use.
The combination of inactivation indicators (refset 900000000000489007) and historical targets (specified in refsets < 900000000000522004) go some way to answering the questions ‘why was this concept inactivated?’ and ‘what should I use instead?’ However, whilst some inactivations (in particular duplicates) are, for the most part understandable without deeper inquiry, other inactivation patterns and cases are less straightforward to understand, and it is reasonable for the SNOMED community to expect (at least for more ‘recent’ changes) to be able to discover the deeper, background story.
Currently background material sits in many places including briefing notes (and surrounding discussions), early visibility notifications, release notes, JIRA project tickets, change request and helpdesk request systems, as well as Spaces and Forums entries (distributed across multiple project groups). Making sense of these is going to require work and effort somewhere - we need to agree how to distribute this work between SNOMED developers and SNOMED users. I agree with @jsnyder that “…requesting an author to free-text the justification for an inactivation…” would be undesirable, but I do still think that steps could be taken to persist and simplify a traceable path between changes and more detailed background materials held in any of the documents/artefacts mentioned above.
Personally I feel that this is most noticeable for concepts carrying an inactivation indicator of 723277005 |Nonconformance to editorial policy component|. Given that there are thousands of editorial policy clauses (which are themselves liable to change) the published data offers little or no indication as to why such concepts are no longer active. It is notable that 723277005 |Nonconformance to editorial policy component|, since its introduction in 2017, has been used more than other reasons for inactivation (this trend can certainly be seen in the 2022-2026 year-specific filters on the Inactivation Report charts shared by @alopez) and is also the most frequent reason for inactivation that is not associated with any replacement concept (which is hopefully illustrated in this Sankey diagram) which also reduces the information that can be gleaned from the release files. These may not be the sort of inactivation examples @rpanyowat had in mind in the initial post, but perhaps they help make the case that the dormant ‘inactivation note’ annotation mechanism might be usefully implemented, in some way, to support traceability between inactive components and the deeper reasons/justification for inactivation, striking a satisfactory balance between SNOMED developer and SNOMED user work.
In our own little local CSCT extension, we asked Termspace to provide us with an annotation field where authors can attach justification material to translations or concepts, including literature references to support their authoring decisions. I agree free text alone is not workable but I strongly believe we need more than just the inactivation reason tags, we need to be able to archive the full reasoning behind decisions, be it for deactivation or for concept/description (or even sometimes relationship) creation, even if this takes up space, because it is like the patient diagnosis. Just having the diagnosis is not enough when the diagnosis is put in question to know where the reasoning might have been either justified by the context or flawed. Many decisions are take because they seem so evident in the culture of the person taking it, but another person in another culture might not use the same implicits and therefore not understand it.
We need to use annotation refsets to document editorial motivations. And I would advocate two SNOMED full editions, one for authors with all that historical reasoning evidence, and one for production, without all the detailed authoring justifications, so we would not have everyone end up with huge SCT zip files when questions of authoring have to be handled by the 2% who will really delve into maintenance and answering questions as a terminology helpdesk.