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:

https://snomed.zoom.us/j/83229530169?pwd=DhTDQLiXoMkwvKbBgiS9c4TpOsfUFQ.1
Password: 228226

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!
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		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...
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: Terminology Release AG organization 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	"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. 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. 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. 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. 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. 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: Negative Delta file processing 2019-10-28 & 30 Face to Face Meeting, Kuala Lumpur ....... 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… https://conf.spaces.snomed.org/wiki/spaces/TRAG/pages/133988918/Negative+Delta+file+approach
14	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: A list of allowable and non-allowable characters to add to the editorial guide. 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? 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?
15	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: https://www.snomed.org/news/blog%3A-snomed-international-concludes-community-feedback-period-on-proposed-description-character-limit-increase-and-finalizes-next-steps https://forums.snomed.org/t/descriptiontype-length-limit-increase-proposal/461 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: https://forums.snomed.org/t/transition-plan-for-description-type-length-limits/1149 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??
16	DEPRECATION PLANS	ALL - OCTOBER 2026
17		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??
18		ALL - OCTOBER 2026	Walk through plan to Deprecate CNC Indicators (started Jan 2026, concludes Jan 2027) Any issues? Any more comms required?
19		ALL - OCTOBER 2026	ICD-0 Deprecation??
20
21	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…. https://forums.snomed.org/t/spanish-edition-product-naming-convention/1238
22
23	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 SEND OUT A BRIEFING NOTE and Release COMMS FOR ?????JULY 2026?????? WITH CAVEAT THAT "IF ANYONE HAS CRITICAL OBJECTIONS TO THIS PLEASE RAISE NOW" https://docs.google.com/document/d/1-H0Mi-3bM6FBTlJPrbwldOX_qosl1bXU0u8mHU-4X5M/edit?tab=t.0 QUESTION: ARE WE HAPPY THAT THIS ISN’T TOO MUCH CHANGE FOR ONE RELEASE, GIVEN THE DescriptionType CHANGES THAT ARE ALREADY GOING THROUGH??? WE COULD PUSH THESE THROUGH IN THE JUNE 2026 RELEASE INSTEAD??? ASK NRC's TO PUT OUT A BRIEF REQUEST (linking in our comms) TO THEIR USERS TO ASK IF THERE ARE ANY STRONG OBJECTIONS May 2026 THEN IF NO OBJECTIONS WE’LL SEND OUT CONFIRMATION THAT WE WILL TRANSITION IN ???JULY??? 2026 ???JULY??? 2026 INTERNATIONAL Release: TRANSITION TO NEW FORMAT IN JULY 2026 International Edition TRANSITION ALL SUBSEQUENT PRODUCTS TO NEW FORMAT AS THEY BECOME DEPENDENT ON >=JULY 2026 INT Edition October 2026 Final proposal to be brought to TRAG for confirmation? Or if already approved by MF, final Transition Plan brought to TRAG for confirmation
24	Edition vs Extension Packaging Naming conventions	All	TRAG already discussed and provisionally agreed in previous TRAG meeting, so just need to confirm that the Briefing Note for the MF accurately represents the TRAG’s Proposal...
25	Proposal to remove the "ManagedService" tag from the package naming convention	All	TRAG NEED TO DECIDE ON THE BEST OPTION (see linked Discussion) + include in the MF Proposal... (ie) Whether or not to propose changing the Product element to include the namespace, and removing the (then redundant) fourth Element????
26	Removal of Format element "RF2" from release package naming conventions	All	TRAG NEED TO DECIDE ON THE BEST OPTION (see linked Discussion) + include in the MF Proposal... (ie) Whether or not to remove the “Format” element entirely (as it’s redundant in the absence of RF1), OR could we foresee a need for other formats going forward? Perhaps instead we just need to leave it as an “Optional” element and just stop using it for now??? OR we could remove it entirely ( to prevent confusion) and add it back in if we need it in the future??
27	Filenaming Conventions for Association and Simple reference set files	All	TRAG decide + include in the MF Proposal...
28	Refinement of the Dialect code element	ALL	Some would say the use of the Dialect code is redundant and others say outright confusing, as they don’t specify dependencies such as the contents of the language refset file. In addition, these can cause problems within systems where the inconsistency between packages that use the dialect code and those that don’t, can cause problems with reconciliation, etc. The file naming convention is potentially ambiguous and despite users trying to align themselves to the common practice from the managed service as the most numerous set of release files it has proven challenging. https://projects.jira.snomed.org/browse/MSSP-3408 We could therefore either tighten up the file naming convention, or the managed service de-facto standard could be documented to make it easier to align to? It therefore makes sense to standardise and keep as many countries' naming conventions in line with each other as possible, in order to foster interoperability.

2026-10-19- TRAG Meeting Agenda/Minutes

Attendees

Apologies

Objectives

Discussion items

Conclusion of previous Discussions topics

Active Discussions for April 2025

@Peter Williams