Proposal to deprecate the Concept Non-Current (CNC) Indicators

aatkinson · September 22, 2025, 4:42pm

SOME REFINEMENTS TO THE proposal, for us to review and agree:

The Case For Removing Description Concept Non-Current Indicators

The key points of the proposal that are salient to our group are:
- Discuss whether or not there are any known users still using the CNC indicators?
- Discuss whether there are any valid use cases still in existence to retain them? (whether in use or not)
- Are there any dissenting arguments against the assertion that CNC indicators are completely
- obsolete, and that it’s more efficient and reliable to determine the relevant Concept’s state from the
- Concept record, rather than from the AttributeValue record?
- Are there any dissenting arguments against the assertion that CNC indicators cause additional work for all creators of SNOMED CT content, in terms of maintenance, packaging and validation?
- Are there any dissenting arguments against the assertion that the removal of CNC indicators will serve to simplify the understanding of SNOMED CT, + help to lower barriers to adoption?
- Discuss any impacts to the terminology, or to any users, when removing the CNC indicators? (beyond our internal impact, which is restricted solely to removing/simplifying existing code)
- Discuss who, if anyone, we should specifically target for feedback on the proposal?
- Agreement in principle of the deprecation of CNC indicators by the TRAG.
- PROPOSED TIMELINE (updated)
  - May 2024 INT Edition = Publication of an official Notice of Deprecation, and request for feedback
    - a) Inclusion of this proposal in the “Early Visibility” notes???
    - b) notes in the RF2 Specification???
    - Just mark the specification as “this content is being deprecated” but keep the spec around for some time for those lagging…
    - c) the exact plan
    - d) proposed timelines
    - e) consultation period
    - f) feedback channels, etc.
    - g) Specifics for this deprecation - (eg) whether or not the final plan included complete removal of the 108mb of data after say 18 months after inactivation?
    - At this stage, no changes will be made to any products or systems.
    - Changes should be considered to Editorial Guidance and Educational Changes?
  - July 2024 INT Edition = Inactivation of all existing CNC indicators,
    - + Removal of all code creating new CNC indicators
    - + Removal of all code relating to the display and validation of CNC indicators
  - January 2025 INT Edition = Removal of all code relating to the display and validation of CNC indicators, except in the most general structural tests for refset members eg that a referenced component id exists.
    - + Inactivation of the 900000000000495008 |Concept non-current (foundation metadata concept)| concept.
  - Future = We’re not at any point suggesting surgical extraction of the historical CNC indicators (using negative delta’s or any other such mechanism!) Just inactivation and keeping them static in perpetuity after that.
    - HOWEVER, given that they consume 108mb of the International Edition, is there an argument for complete removal?
      - YES, we can inactivate them for 6-12 months then REMOVE these records COMPLETELY (not AttributeValue files)
      - WE SHOULD ALSO REMOVE THE ENTIRE STATEDRELATIONSHIP FILES WHICH HAVE BEEN INACTIVATED FOR 5 years or so now
        
        YES AGREED - LET’S MOVE IT INTO A STATIC PACAKGE ON MLDS AND KEEP IT SEPARATE.
        
        WE SHOULD PROBABLY GIVE THE USERS 6 MONTHS NOTICE FOR COMPLETE REMOVAL
  - Member Forum Briefing Note published giving notice of upcoming changes:
    - Concept Non Current Indicators - Notice of Deprecation
  - CURRENT PLAN WOULD THEN BE TO:
    - 2025 - write up comms for the following channels, and publish to provide notice of upcoming changes:
      - Release Notes, particularly in the “Early Visibility” section.
        
        Should we also publish the comms in the Release Notes themselves???
      - Release Management distribution channels
        
        Blog
        
        Email
    - Jan 2026 - Start actual deprecation in Jan 2026, with:
      - Inactivation of ALL CNC indicators
      - Remove creation of new CNC indicators, by wrapping current CNC indicator automation code in a check for a CodeSystem metadata flag.
      - This flag will be considered True by default (ie. do CNC processing), and so we only need to detect the presence of a “false” value, when CNC processing will be skipped.
        
        This is to allow for the disabling of CNC automations initially for International Edition (in Jan 2026), and then, post release, for each extension as they are upgraded to the Jan 2026 version of the International Edition.
        
        This will only prevent the creation of new CNC indicators. Bulk inactivations will also be required for each CodeSystem as it upgrade to our specified International Release.
    - JULY 2026 - Formal removal of CNC indicators
    - Before we move to the next stage in the deprecation process then, we want to encourage any final feedback, either from yourselves or from your end users???
- April 2025 - EVERYONE AGREED - WE NEED TO PUBLISH A FORMAL DEPRECATION PROCESS and then trial it ourselves using CNC Indicators!!