2026-04-13- TRAG Meeting Agenda/Minutes

Welcome!

All

Thanks to our members for all of their help. Welcome to our observers!

INTRODUCTIONS...

We've got several topics that we've resolved and closed down

As always, we won't waste time going through them again in detail, but if you'd like to read through them they're listed below...  

I'll also run through them very quickly from a high level, and if you have any further questions/news on any of the discussions please let me know now and we can decide whether or not to re-open them...

Conclusion of previous Discussions topics

Spanish Edition frequency of delivery

Guillermo + Spanish Edition users

Proposal to move to QUARTERLY RELEASES from 10th November onwards, new schedule would therefore be:

• 10th February

• 10th May

• 10th August

• 10th November

In the interim, any early translations required in each relevant country, will be included in the local extensions.  They will then be re-aligned with the Spanish Edition once we move to quarterly releases.

Any concerns/foreseeable issues?

•  

  • Confirmation received from the US that this shouldn't impact them

  • Confirmation from Victor (10/09/25) that his Spanish speaking users are also happy with the proposed migration to quarterly releases, and can foresee no negative impacts.

AGREED

Naming Conventions for Refsets

All

1. Proposal was sent to TRAG Members at the start of May 2024 for urgent feedback as the intention was to trial these changes in the NZ (and possibly also EE + SE) Extensions in Q4 2024, and we would therefore need to provide plenty of notice to end users....:

   1.  

      1.  

         1. We have identified a requirement for Refset filenames to be a) more machine readable, and b) more maintainable c) more consistent (as we've already seen many filenames change over the years, due to mistakes in the descriptions, or valid changes to the purpose of the refsets)- especially for Extensions who have hundreds or more refsets.

            The human readable description in the file name is all very well, but:

            1. It's not actually readable in countries with non english languages, and

            2. It's often concatenated due to machine limits of filenames (especially in Windows)

            Therefore we have trialled a refined naming convention for ne of the MS extensions:

            • FROM:

              • der2_Refset_AjccHaematologicMalignancyPathologicalMCategorySimpleRefsetSnapshot_NZ1000210_20231001.txt

            • TO:

              • der2_Refset_253731000210103SimpleRefsetSnapshot_NZ1000210_20231001.txt

            This stays within the RF2 spec, which states that this description is "An optional short camel case summary of the usage of the file. The value of this sub-element may be determined on a case-by-case basis but, in conjunction with the ContentType element, should be adequate to identify the content and purpose of the file."

            Therefore:

            1. The spec states that this should be "adequate to identify the content and purpose of the file", and the RefsetID is adequate because you can easily plug it into the browser to find the descriptions, etc

            2. The spec states that the description itself is actually completely optional and therefore we could actually remove it completely! 

            It also proves useful in both directions, as if you want to:

            a) search for the refset in the package then searching by refsetID in the name is much faster, or

            b) allow systems to create/maintain the names of the files is also much faster by ID, as the descriptions are all manually curated

            c) if you want continuity in the refset file names, using the ID is far more consistent, as the descriptions can change (as we have already proven!).  Therefore using the ID's allows complete continuity, whereas using the descriptions can mean the refset filenames change from one Release to another!

   
   
   

   Full discussion required in October 2024 meetings:

   •  

     • Trialled in the October 2024 NZ Release, mostly due to the unmanageable volume of refsets in NZ Extension (now nearly 800)

     • Also trialled for KR Extension, as this made sense to start off right due to it being a brand new release (+++++ still only a BETA release)

       • ANY KNOWN ISSUES EXPERIENCED AS A RESULT OF THESE TRIALS??

     • .

     • Demonstrate to the group the NZ Extension package....

     • .

     • Discuss future plans to roll out to all other extensions

       • We'd like to start rolling out changes ASAP to all other MS customers, as of their next releases

       • We would advise other Extension managers to align themselves with the change as well, for interoperability purposes.

         • Comms required to roll this out??

     • No planned changes to INT Edition UNLESS we want to start considering also changing core refsets (eg)

       • der2_cRefset_AssociationSnapshot_INT_20241001.txt

       • der2_cRefset_AttributeValueSnapshot_INT_20241001.txt

       • der2_Refset_SimpleSnapshot_INT_20241001.txt

     • These don't incur the same overheads and/or issues with Length of naming convention, so no urgent need to change

       • HOWEVER, we could consider it as part of standardising the new changes?

       • If we do consider this, do we then also consider other core refsets outside of the Content folder (eg)
         
         

         • der2_cRefset_LanguageSnapshot-en_INT_20241001.txt

         • der2_iisssccRefset_ExtendedMapSnapshot_INT_20241001.txt

         • der2_sRefset_SimpleMapSnapshot_INT_20241001.txt

       • + how about all the Metadata refsets (eg)

         • der2_cissccRefset_MRCMAttributeDomainSnapshot_INT_20241001.txt

         • der2_cRefset_MRCMModuleScopeSnapshot_INT_20241001.txt

         • der2_scsRefset_ComponentAnnotationStringValueSnapshot_INT_20241001.txt

         • der2_ssccRefset_MRCMAttributeRangeSnapshot_INT_20241001.txt

         • der2_sscsRefset_MemberAnnotationStringValueSnapshot_INT_20241001.txt

         • der2_sssssssRefset_MRCMDomainSnapshot_INT_20241001.txt

       • THIS WOULD STANDARDISE THE CHANGES, BUT COULD IMPACT A LOT OF USERS WHO MAY HAVE HARD CODED IMPORT ROUTINES, etc?  (unlikely with external Refsets local to extensions)

     • FINALLY, WHAT ABOUT DERIVATIVE RELEASES??

       • ...do we consider moving the INT derivatives to the same approach??

       • ...do we even then potentially talk about other files (maps, lang refsets, etc) moving to the same convention, as otherwise they would then be slightly conflicting with the others in the same package? (though changing core filenames might be a leap too far for end users - perhaps we draw the line in the sand between core files and optional files?)

     • ALTERNATIVE OPTIONS TO MOVING STRAIGHT TO MANDATING THE USE OF ID'S IN FILENAMES

       • We could potentially move to a hybrid state, whereby we allow EITHER ID or name to be used in the fielnames.  
         
         

         • This would then continue to allow people to either host one or multiple refsets in the same file
           
           

         • This would also give users some time to transfer across
           
           

           • BUT it would potentially create inconsistency and confusion for end users...
             
             

       • We could migrate to using ONLY refsetID's in filenames (eg)
         
         

         • RefsetID would be used when only ONE refset is included in the file
           
           

         • RefsetID OF PARENT (eg.  "Simple Refset Type Concept")  would  be used where the file hosts multiple refsets
           
           

       • .

   
   
   

   FEEDBACK:

Derivative product Release package formats

All

1.  

   Michael Lawley has objections - AAT to meet with him offline and work out if we need to change our approach...

   After discussion, no objections were outstanding, so we're proceeding as planned...

    

   NOW THAT WE HAVE IMPLEMENTED THIS, ANY FEEEDBACK?

Active Discussions for April 2025

Welcome and thank you!

Welcome to new members!

IMPORTANT ANNOUNCEMENT

In order to comply with SNOMED International’s governance in relation to the electronic recording of telephone or video calls and generated artificial intelligence summaries in relation to SI business, AI enabled summaries will now be required as a course of SI business.

This means that AI enabled summaries will be activated for all Advisory Group meeting from this point onwards, including this TRAG meeting.

This is to enable SI to provide written event summaries after our Business Meetings to the GA, and the AI function is key to administering that.  

Please note: All summaries will be de-identified (anonymised) before including them in the post event reports.

By remaining in this session, you consent to these summaries being created and used to generate the reports.

UPDATING TRAG DATA

1. We need to keep the Conflicts of Interest page updated:

• Declaration of Interests

Please send declarations of interest to AAT and I'll update them...

ALL - OCTOBER 2026

Secondly, we need to walk through the original Terms Of Reference for the TRAG, and ensure that they're still relevant, and update if required:

• Terminology Release AG organization

REGULAR TOPIC

Suzy

We will be regularly providing updates on the current Collaboration pieces.

More importantly, we will also regularly be asking for feedback on all of our Collaborative products, in order to ascertain how we can improve our offerings going forward (eg)  Who's using the following, what for, and how can the products be improved?

• EDQM

• MedDRA

• IPS

• IPST

• etc 

"Negative Delta" file approach

All

This approach was successfully implemented in order to resolve the issues found in the September 2017 US Edition - is everyone comfortable with using this approach for all future similar situations? If so we can document it as the accepted practice in these circumstances...

1. Preference now is to retain EVERYTHING in the Full file, regardless of errors - this is because the Full File should show the state at that point in time, even if it was an error! This is because there is not an error in the Full file, the Full file is accurately representing the error in the content/data at that time.

2. The problem here is that the tools are unable to cope with historical errors - so we perhaps need to update the tools to allow for these errors.

3. So we need the tools to be able to whitelist the errors, and honestly document the KNOWN ISSUES (preferably in a machine readable manner), so that everyone knows what the historical errors were.

4. The manner of this documentation is up for debate - perhaps we add it to a new refset? Then we could use something very similar in format to the Negative delta, but instead of it actually changing history retrospectively, we simply document them as known issues, and allowing people to deal with the information in their own extensions and systems in whatever way they feel is appropriate.

5. Only situation we can think of where we couldn't apply the above gentle response, would be copyright infringement - whereby if we discovered (several releases after the fact) that we had released content that was in direct infringement of copyright, then we would potentially have to revoke all releases since the issues occurred. However, this would raise a very interesting situation where patient safety might be compromised - as if we remove all historical content that contravened the copyright, then we run the risk of patient data being impacted, thus potentially adversely affecting decision support. This is simple to resolve when the problem is in the latest release (simply recall the release), but if found in a 5 year old release for example, it could be very problematic to recall 5 years' worth of content and change it!

Allowed Characters in SNOMED CT Despcriptions

ALL

This topic is to discuss what action to take with both historical terms and future terms, wrt the inclusion of UTF-8 characters that aren’t necessarily helpful to end users.

Please see Dion’s analysis here: https://forums.snomed.org/t/standardised-set-of-allowed-characters-in-snomed-ct-descriptions/818

A file was originally received from the UK regarding unhelpful characters, such as soft hyphens, in some published descriptions. Consequently, a ticket has been logged with the tech team to enhance validation and reporting for these characters: https://projects.jira.snomed.org/browse/RP-975 This check was implemented in March 2026.

Peter has since generated a report of existing descriptions with "Acceptable character violations," which you can review here: https://docs.google.com/spreadsheets/d/1bsN36W9QijjPuLJ2B7p7wniqBpPKSuhirhBf0xg9szg/edit?usp=sharing

The TRAG then, needs to aim to identify:

1. A list of allowable and non-allowable characters to add to the editorial guide.

2. A list of allowable and non-allowable characters to add to validation and reporting.

This will enable us to decide which course of action to take:

• a) for the existing 168 odd terms that include these characters - should we:

  • i) inactivate them and replace them with more palatable terms, or

  • ii) leave them as they are and Exception list them in all future validation?

• b) for future terms that are yet to be created:

  • i) do we prevent all of the non-allowable characters from being created?

  • ii) warn the authors about them but allow them to override if required?

  • iii) continue to allow them to create terms containing these characters, because we are supposed to support all of UTF-8?

3. Whether TRAG prefers to inactivate and replace the descriptions in the report or move them to the exception list.

ACTIONS (April 2026):

@Peter Williams

• Create a GitHub repository for the allowable characters configuration and set tags corresponding to release effective times

• Add a column to the allowable characters configuration to specify which extensions each character set applies to

• Add Estonian Cyrillic characters to the allowable characters configuration

@Maria Braithwaite

• Coordinate with translation teams to ensure synchronized updates, with FR and Maria planning to share updates through an early visibility page.

Transition plan for the DescriptionType length limits

ALL

Walkthrough plan to transition to new DescriptionType length limit:

•  

• Next steps:

  • Update the International Edition to increase the max. Description length to 4096 in the July 2026 International Edition

  • Update each Managed Service release to increase the max. Description length to 4096 in each subsequent MS release that is dependent upon the July 2026 International Edition

  • NO INCREASE to ANY International Edition descriptions themselves in the July 2026 International Edition. Instead, they will be analysed accordingly and drip fed through where required in subsequent International Edition releases…

• Any issues?

• Any more comms required?

DEPRECATION PLANS

ALL

DEPRECATION POLICY -

• INTRO:

  • As SNOMED International evolve, a formal, transparent process for removing artifacts is required.

  • This draft policy establishes a high-level framework.

    • It defines deprecation as the removal of an artifact, such as a release package, mapping file, or service from maintenance and the SNOMED International Published Service Catalog.

    • It sets out overarching guidelines for governance, communications, and process to ensure end-to-end transparency for all stakeholders.

    • Under this policy, no deprecation should compromise clinical safety, and all changes must be auditable and well-documented.

    • Key Features of the Proposed Policy

      • ● Took a High-Level Approach: The details of specifically "how" an item is deprecated are purposely left out of the document. Instead, individual Deprecation Plans will determine the exact process based on the specific artifact, impacts, dependencies, and need for support.

      • ● Established the Governance Model: The proposed process requires SNOMED Senior Management Team (SMT) engagement at multiple stages. SMT approval is required to proceed with an evaluation, and subsequently, SMT must approve the formalized plan before implementation.

      • ● Most importantly, we want to ensure Member and Stakeholder Engagement: The policy emphasizes that Member feedback must be sought from the Member Forum, alongside appropriate consultation with Advisory Groups and the community of practice. This will help to conduct an Impact Analysis during the Deprecation Proposal step, as well as determining an approach for deprecation that will help to minimize or mitigate any negative impacts for users.

  • Next Steps

    • Feedback from the Advisory Groups consultation will be incorporated into the updated version which will then go to SNOMED International SMT and Members (Member Forum) for approval.

      In order to include feedback from those who are unable to attend the in-person April business meeting, the feedback period will be open until 30th April 2026.

• Walk through

• Any issues?

• Any feedback?

• What comms required?

  • BEYOND the planned comms to run this through the MF??

  • Should we send it out to the usual Release mailing list, or is this too much spam??

  • Should we send it out to members in addition to the MF??

  • Or perhaps via the website?

ALL - OCTOBER 2026

Walk through plan to Deprecate CNC Indicators (started Jan 2026, concludes Jan 2027)