| Disposition | The Briefing note feedback highlights issues for implementers and end users: - These could be in production already in systems; similar content has been created within extensions.
- Addressing this aspect of the procedure lifecycle would not address the entire problem with other similar concepts that could be included in this hierarchy and even other hierarchies.
- Lastly, ICD mapping and reimbursement issues.
So after consideration, SNOMED International will refrain from pursuing inactivation of these concepts. Instead, concepts will be modeled as best as possible and will remain within the terminology. The Pre-Coordination Pattern will remain as-is with no further content will be accepted in this area. |
|---|
5 Comments
Feikje Hielkema-Raadsveld
Where can I read why a particular pattern is declared unacceptable? Should I look at the comments in PCP-224 - Getting issue details... STATUS ? From 2021:
Notes from internal ticket on why this type of content is not accepted.
There are a number of possible interpretations:
1. It is an administrative status that indicates the procedure has been completed.
2. It represents a procedure that has been successfully completed.
3. It represents a past history of a procedure having been performed.
In the first case, if "done" is part of the life cycle of a procedure, it should be recorded similarly to other states of a procedure (e.g. planned, ordered, in progress, completed, etc.).
If it represents that a procedure has been done in the past, then it should be modeled as a "history of X (situation)" (subtype of 416940007 |Past history of procedure (situation)|).
Does this mean that all situation concepts for procedures that are planned, in progress, completed etc. will also be retired? Or does it mean that if we use a concept to record a procedure has been completed, we should replace it with a 'procedure completed (situation)' instead?
I am unsure how many of these concepts are used in the Netherlands, but I see we have created 13 concepts with this pattern in the Dutch extension. I do agree they are ambiguous: most indicate that a particular procedure has been completed, but 5 of them look like patient history.
Jim Case
Feikje Hielkema-Raadsveld
In general, we are reviewing procedure concepts that pre-coordinate a "state" of the procedure to determine whether they should be inactivated. As there is not a universal state diagram for procedures and some are quite complex, it is not feasible for SNOMED to create pre-coordinated state concepts for every procedure. We encourage users to rely on the information model or use post-coordination to specify the state of a procedure in their environment. However, there is a long history of use of some of these pre-coordinated concepts so we need to take a measured approach to their inactivation.
You are correct that some of the concepts may be interpreted as "history of" procedures, but these are also problematic as any procedure could have an analogous past history, so we would not pre-emptively create them without a sufficient use case.
We currently have not stated a lack of support for procedure states explicitly in our editorial guidance as there are administrative exceptions that are of value in the medical record (e.g. Procedure refused, procedure not done). At this point we are reviewing these one state at a time.
Matt Cordell
Feedback on Proposed Retirement of ‘Procedure Done’ and Similar Situations Content in SNOMED CT
While the motivations behind this proposal are understandable, I fear the changes may have disproportionate downstream effects. Rather than full retirement, a strategy that allows continued use but limits future expansion may be a better compromise. Allowing SNOMED CT to evolve and focus on improving priority areas while respecting the investments made by its user base.
Limited Cost for Retirement, But Potentially High Cost for Implementers
The proposed retirement of this subset is relatively low cost from a content maintenance perspective, but it poses a significant cost to implementers who have already adopted these concepts in production systems. Many of the concepts, particularly those representing procedures done or not done, are used as assertions – especially within checklists, forms, or structured data capture workflows (e.g., 165007007 |Allergy testing done| vs 165008002 |Allergy testing not done|).
These concepts may not always exist in neatly matched pairs, but that likely reflects real-world documentation needs where sometimes only the negative assertion is clinically relevant.
Also note that primitive concepts are not inherently bad. Some concept will never be able to be sufficiently defined. And some might not be worth the effort. E.g. “X leaflet given (situation)” – these could be sufficiently defined with a specific procedure. But it’s probably not going to improve the classification end-result. And that procedure will still probably be primitive. And that’s OK.
Alternative Representations are Not Always Feasible
Post-coordination or use of contextual modelling in the information model is certainly more scalable in theory. However, for systems that have already implemented these concepts directly, migrating to an entirely new data capture approach is non-trivial. The burden for the proposed change falls disproportionately on implementers.
Semantic Ambiguity May Be Overstated?
I understand the concern around potential ambiguity in the interpretation of "done" concepts. However, interpretations like:
are arguably just different lenses on the same core assertion - that something was done. The assumption is generally that a procedure "done" was successful, unless stated otherwise. Notably, in the proposed retirements:
The Hierarchy Serves Its Intended Purpose
Many of the concepts proposed for inactivation serve valid use cases - namely documenting outcomes or decisions made during clinical encounters. For example:
These are meaningful and structured ways of documenting what was done or advised. The "Situations with explicit context" (SWEC) hierarchy is arguably doing what it was intended to do.
There are a few concepts that may be misplaced (e.g., 165766007 |Blood transfusion center reference number|, 394828003 |Prescription by another organization|), but these could be reviewed addressed individually rather than removing the entire subhierarchy.
Findings Already Include Many SWEC-Like Concepts
Perhaps more problematic than the SWEC hierarchy itself is the inconsistency across hierarchies. Numerous "done" or "not done" concepts appear under Clinical Findings (e.g., 270440008 |Hypertension monitoring check done|, 405747002 |Aspirin not given|). This raises the broader issue that "SWEC" modeling is already pervasive in other hierarchies and not limited to one subhierarchy.
A blanket retirement from just one place seems inconsistent. The current approach feels like “burning down the house because you saw a spider”.
Consider De-Emphasising Rather Than Retiring
If SNOMED International's intent is to discourage future use or extension of this pattern, a more constructive approach may be:
This would allow SNOMED CT to express that such content is deprecated for future development, while minimizing disruption to existing implementations.
Implementation Timelines
The proposed retirement timeline (September 2025) feels aggressive, especially compared to the handling of the Concept Non-Current Indicator, which has been under discussion for years and is currently scheduled for January 2026 despite being assessed as unlikely to be used in any implementation (an historical artefact of RF1).
Nicholas McGraw
The US NRC agrees with the proposed change to inactivate << 443938003 |Procedure carried out on subject (situation)| because it duplicates the implied soft default context of a procedure which is that the procedure was carried out on the subject of the record. The hierarchy does not appear to implicitly or explicitly indicate any contextual shift. There will be minimal impact to the US Extension.
Hanne Johansen
We support Matt's arguments regarding potentially high costs for implementers vs. low rewards for the consistency of the terminology itself.
We have reviewed the list of concepts that will be affected by this change, and while we agree that users should be encouraged to make use of information models and/or post-coordination efforts to express context for procedures where necessary, we do not believe the end users in Norway are prepared to face this change quite yet.
114 of the 516 concepts are mapped to 53 different ICD-10 codes in the Z chapter, "Factors influencing health status and contact with health services". These codes are widely used for billing and generate funding from the national government in primary care as well as specialist departments in Norway. Our national mapping team have identified that the 114 concepts in this subgroup that have been translated into Norwegian do not have logical replacements in the clinical finding hierarchy, and as such we cannot replace them with existing content in SNOMED CT to ensure that end users will be able to find SCT concepts that map to the necessary ICD-10 code. If SI are going to inactivate these concepts, we would possibly have to either reactivate the concepts in our national extension (if they comply with guidance in the Extensions Practical Guide) or create what is essentially national duplicates as replacements for them.
As Matt mentions in his comment, perhaps a more nuanced approach could satisfy the need to limit new modelling and use of this group of concepts until more decisive action can be taken at a later point in time. The proposal to review and tidy up the individual ouliers that don't comply with the stated usecases for SWEC, as well as reviewing and possibly remodelling "wrongly placed" concepts in the finding/disorder hierarchy, will yield better consistency in the terminology. Though more time consuming than inactivating an entire subgroup of concepts, it seems a good starting point for evaluating the model for SWEC as a whole.
Add Comment