/
2026-10-19- TRAG Meeting Agenda/Minutes

2026-10-19- TRAG Meeting Agenda/Minutes

Date

  • Oct 19, 2026 -  13:30 - 17:00 (CEST - LOCAL TIME) (12:30 - 16:00 UTC)

Room: ?????



Dial in details:

Attendees

  • @Andrew Atkinson, Chair

  • @Mikael Nyström (Unlicensed), member

  • @Graeme Elsby (Unlicensed) , member

  • @Dion McMurtrie , member

  • @Gábor Nagy (Unlicensed) , member

  • @Ale , member

  • @Maria Braithwaite , staff/observerst

  • @michael lawley, guest/observer

  • @Mounir Bouzanih (Unlicensed), member

Apologies

  • @Alejandro Lopez Osornio, staff/observers

  • @Matt Cordell , guest/observer

  • @Chris Morris, staff/observerst

  • @Patrick McLaughlin, member

  • @Reuben Daniels, member

  • t

Objectives

  • Briefly discuss each item

  • Agree on the plan to analyse and resolve each issue, and document the Action points

  • All those with Action points assigned to them to agree to complete them before the next face to face conference meeting

Discussion items



Subject

Owner

Notes & Actions

Subject

Owner

Notes & Actions

1

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...

2

Conclusion of previous Discussions topics

3

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

4

 

 

 

5

Active Discussions for April 2025



6

Welcome and thank you!



Welcome to new members!

  • Alastair Kenworthy

  • Laura Gutierrez

Please introduce yourselves!

7







8

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.

9

UPDATING TRAG DATA



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

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

10



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:

AAT to update ToR
ADD "Product development", and
remove all obsolete references (such as 14 people, etc) 
and send to TRAG for final review!
COMPLETED:
TRAG to review in 2026 :
ToR to ultimately be uploaded to the site
11

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 

 

ACTIONS (April 2026):

  • Collaboration Team (Suzy/Ian/Kelly) @Suzy Roy :

    • Collect feedback on LOINC Ontology via survey

    • Collect feedback on expanded Global Patient Set

    • Collect feedback on EDQM to SNOMED Dose Form map

    • Renew collaboration agreements with HL7 International and IHE International

    • Renew collaboration agreements with DICOM and ICH MEDRA

12

 

 

 

13

Further improvements to the Release File Naming Conventions

 

We are considering a further improvement to the planned changes to the Specification in January 2027:

  • This would be to add the optional “Edition/Extension” flag (which we started using from the July 2026 International Edition onwards - Edition vs Extension Packaging Naming conventions) to the File Naming conventions as well

  • This is because the files contained within the package follow a different naming convention to the package, in that they do not include any element identifying the terminological product and scope. As a result, when files are extracted from their packages, it is not possible to determine whether a file belongs to an Edition or an Extension without referring back to the original ZIP file.

  • Given the current trend towards publishing both Edition + Extension packages for certain products, this change would prevent the unwanted situation of having files that have identical filenames (due to the effectiveTime being the same) but different content, coming from different release packages.

  • This change would, therefore, potentially make file handling less manual and allow for more automation.

  • Thoughts???

14

Release Publication days

All

We have started introducing a rule to state that we won’t publish on weekends or public holidays, but instead the nearest working day to it (i.e. a Friday instead of a Saturday, or a Monday instead of a Sunday)

Please can you provide initial feedback on this proposal, regarding whether or not this has impacted you, and if so how? 

MAIN QUESTION IS WHETHER OR NOT THIS MAKES ANY DIFFERENCE TO ANYONE??
As long as the effectiveTime is as expected, does it make any difference as to which day the actual publication happens, as long as it's BEFORE THE EFFECTIVETIME??
If it does make a difference to anyone, can we please discuss what Impact the publication date can have?
Does it help / hinder anyone to have specific publication dates, or does this have little impact?
 
DOES THIS WORK FOR EVERYONE?? CAN WE PROCEED AS PLANNED OR IS THERE ANY CRITICAL FEEDBACK????
 
FOR EXAMPLE, FOR EXTENSION MAINTAINERS - Would having the International Edition for 1st July published on 3rd July instead (if 1st July was a Saturday), have a large impact on timelines for upgrading extensions, etc??

October 2025... TO FEED INTO THE OVERARCHING "RELEASE SCHEDULE POLICY" THAT WE NEED TO WRITE, TO INCLUDE BOTH THIS TOPIC AND THE "Skipping unnecessary Releases" TOPIC

NOTE: We published the following releases on alterantive dates:

  1. March 2026 International Edition a day after the planned release on 1st (which was a Sunday) -

  2. May 2026 Spanish Edition on Friday 8th May instead of Sunday May 10, 2026

  • did anyone notice that it was published on Monday 2nd instead??

  • Did it impact anyone in any way?

  • IF NOT, IS EVERYONE HAPPY WITH US MAKING THIS A PERMANENT RULE??

    • IF SO, DO WE NEED TO UPDATE ANY DOCUMENTATION ANYWHERE??

    • IF SO, DO WE NEED TO COMMUNICATE THIS OUT TO THE MF OR ANYWHERE ELSE???

15

"Negative Delta" file approach

ALL - OCTOBER 2026

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...

NO! Everyone is decidedly uncomfortable with this solution! In particular Keith Campbell, Michael Lawley and Guillermo are all vehemently opposed to changing history.
The consensus is that in the particular example of the US problem, we should have instead granted permission for the US to publish an update record in the International module, thus fixing the problem (though leaving the incorrect history in place). This would have been far preferable to changing history.
ACTION POINT FOR EVERYONE FOR OCTOBER 2018: (@Dion McMurtrie, @Matt Cordell, @Orsolya Bali (Unlicensed), @Suzy Roy, @Former user (Deleted), @Former user (Deleted), @Mikael Nyström (Unlicensed), @Chris Morris
We therefore all need to come up with potential scenarios where going forward we may need to implement a similar solution to the Negative Delta, and send them to AAT. Once I've documented them all, we can then discuss again and agree on the correct approach in each place, then AAT will document all of these as standard, proportionate responses to each situation, and we will use these as guidelines in future. If we have issues come up that fall outside of these situations, we'll then come back to the group to discuss each one subjectively, and then add them back into the list of agreed solutions.

  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!

October 2018 - Guillermo proposed a separate possibility, which is to introduce a new Status (eg) -1 whereby if you find this status in the latest snpashot you would just ignore it - this doesn't however address the use case where there is a legal contravention and you need to physically remove the content from the package - the use case where you would have something that contravenes RF2 paradigm, you can't use the RF2 format to correct something that is RF2 invalid! So this is unlikely to work...
Nobody is on board with this idea, as it's too fragile and introduces unnecessary complexity such as we had with RF1...


April 2019
If we're still all in agreement with this, then steps 1-5 above should all be documented and disseminated to get confirmation of approval from everyone??
Did everyone read through everything? Has anyone got any further scenarios that we can include in the documentation?



The EAG raised this issue again on 08/04/2109 - Peter to try to make it to the next TRAG to explain the use case that was raised today and elaborate on the new proposal...
The TRAG discussed this issue at length, and came to the conclusion that we cannot address ALL potential use cases with a standard, generic, solution (certainly not any of those offered above).
Instead the solution in each case should be agreed on given each specific use case that comes up each time
So INSTEAD we should update the Critical Incident Policy to very clearly define the process to be followed each time we need to remove something from the Published release(s):
Which group of people should make the decision on the solution
Perhaps we also provide examples of how each use case might be resolved:

For Legal/IP contraventions, we should either remove content from history entirely, or redact it (leave the records in place, but remove all content from fields except for UUID, effectiveTime, moduleID, etc - thus allowing traceability of the history of the components, without including the offending content itself)
For Clinical risk issues, we can remove it from the Snapshot, but leave the Full file intact to leave a historical audit trail whilst ensuring that the dangerous content shouldn't get used again (as most people use the snapshot) - see Full file steps 1-5 above, etc
How to communicate it out to the users, etc
OCTOBER 2019 - DISCUSSION RE-OPENED AS PART OF THE MAG:
.......
ONCE FEEDBACK OBTAINED FROM MAG:
@Andrew Atkinson to update the Critical Incident Policy with
the various use cases that we've identified so far
the governing bodies who should be the deciding entities
the process for making the decision in each case
including the critical entities that need to be collaborated with in each case (all NRC's, plus 3rd party suppliers (termMed etc) who represent some of them), to ensure the final solution does not break outlying extensions or anything
the process for communicating out those decisions to ALL relevant users
 
FRESH APPROACH IN OCTOBER 2026:
ACTIONS (April 2026):
Guillermo to create a straw man…
.
.
NOTE:
THIS MAY BE REQUIRED QUICK SOON IN ORDER TO REMOVE THE CNC INDICATORS COMPLETELY FROM THE INTERNATIONAL EDITION IN JANUARY 2027



16

Allowed Characters in SNOMED CT Despcriptions

ALL - OCTOBER 2026

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?

  1. 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.

 

October 2026

  • Final proposal to be brought to TRAG for confirmation?

17

Transition plan for the DescriptionType length limits

ALL - OCTOBER 2026

Walkthrough plan to transition to new DescriptionType length limit:

Hopefully you all saw the new comms go out back in September, confirming the final Transition Plan:
This confirms the planned migration date of July 2026 for the International Edition.
 NOTE:  WE ALSO NEED TO TAKE THE OPPORTUNITY TO STANDARDISE THIS ACROSS ALL PRODUCTS (EXTENSIONS, SPANISH EDITION, DERIVATIVES + ALL OTHER SI PRODUCTS) TO AVOID A SIMILAR CONSULTATION in future!!  (as ALL our products would move to 4096)
NOTE: we looked at options for moving to this sooner for Spanish Edition, but it wasn’t feasible.
We will therefore be doing this in line line with the International Edition updates, which will start in July 2026
AAT to therefore publish proposal comms to transition Spanish Edition in August 2026 
In the meantime, Guillermo will manage specific requirements with the DescriptionType config in the relevant local extensions.
 .
MAKE SURE THE FORUMS PAGE IS NOW AVAILABLE TO ALL - Michael and others couldn’t see it back in October 2025...
.
WE SENT A BRIEFING NOTE OUT EARLIER THIS MONTH REGARDING THE FINAL TRANSITION PLAN FOR THE DescriptionType Length Limit Changes:
1. We will proceed to make the CONFIG change (increasing the MAX limit to 4096 in July 2026)
2. BUT we will NOT be changing any of the actual International descriptions yet. These changes will follow in subsequent International Edition releases.
.
Currently we’ve made this post available (for information only) on the MF forum:
The Early Visibility page has also been updated accordingly.
HOWEVER, assuming that the MF have no objections with this, we’re thinking that there might be more people still needing notice?
SO SHOULD WE POST THIS PUBLICLY AS WELL TO ENSURE MAXIMUM VISIBILITY??
SHOULD WE ALSO POST SOMETHING IN THE INTERNATIONAL RELEASE NOTES??

 

  •  

  • 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?

October 2026

  • Final confirmation of the changes made in July 2026:

    • Any impact for anyone, or any end users as yet??

  • Notice (from Maria) of any International Edition descriptions which will need to be updated to longer than 255 character in an upcoming International Edition??

18

DEPRECATION PLANS

ALL - OCTOBER 2026

 

19

 

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?

October 2026

  • Final proposal to be brought to TRAG for confirmation?

  • Policy signed off??

20

 

ALL - OCTOBER 2026

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

21

 

ALL - OCTOBER 2026

ICD-0 Deprecation??

 

22

 

 

 

23

Spanish Edition Product Naming convention

GUILLERMO - OCTOBER 2026

Guillermo is proposing that we change the name of the Spanish Edition that it Published quarterly by SNOMED International.

Please see attached discussion for details….

 

 

24

 

 

 

25

RELEASE FILE SPEC CHANGES:

ALL - OCTOBER 2026

TRAG to review the proposal for the MF (including a target timeframe for making the changes, including a period of time to allow Member Forum Representatives opportunity to engage and seek feedback from users) in the April 2026 meeting, with the intention of driving the following timeline once MF signed off:

  • April 2026

Copyright © 2026, SNOMED International