/
2026-04-14 - TRAG Meeting Agenda/Minutes

2026-04-14 - TRAG Meeting Agenda/Minutes

Date

  • 21st October 2025  -  09:00 - 12:30 (CEST - LOCAL TIME) (07:00 - 10:30 UTC)

Room: Gorilla 1



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

 

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 release date

Spanish

Edition

users

Now that we have proven that we can refine the timelines required to build, test and validate the Spanish Edition release packages, we now need to start the discussion regarding the Release Dates.

Recently we changed them to bring them forward to 31st March/30th September, in order to reduce the time between the dependent International Edition + the Publication of the Spanish Edition package.

Now that this has been trialled and confirmed, we should discuss what dates would be most helpful to the Spanish Edition users.

The end users can most likely benefit from moving our release closer to theirs (rather than moving them earlier and continuing using the "July" and "January" releases). For example, Argentina publishes November 30, Spain December 1st, Uruguay December 15th.  So we are considering moving the Spanish release to 1) October 30th, or mid-November 2024, or to a fixed date late in the month (e.g., November 25 to 27).  (see email trail with Guillermo 27/02/2024 18:45)

This would be with a view to socialising the plan for several months (assuming that we can agree on the best approach), and giving the end users time to adjust to the new schedule.  This would therefore likely be targeted for actual transition in 2025. 

  • WE NOW HAVE  A NEW REQUIREMENT AS THE SPANISH COMMUNITY AREN'T ABLE TO CHANGE THEIR RELEASE DATES TO BRING THEM FORWARD, in order to take advantage of the additional time gained by us releasing the Spanish Edition a month earlier!!  (they Release Nov/May)

    So instead of continuing the refine the process down in order to release the Spanish Edition even earlier each year, should we instead:
    Revert the Spanish Edition releases back to April/October
    Just cut off the translations much later in the cycle, in order to allow us to use a much later monthly INT Edition as the baseline? (eg) Sept/March?
    This would allow many more translations to get into each Spanish Edition release, but still allow the users to retain their own Release dates?
    HOWEVER - IS THIS JUST A COUPLE OF CUSTOMERS, OR ALL OF THEM?????
    NEED TO UNDERSTAND THE FULL USE CASES INVOLVED HERE, SO NEED TO HEAR FROM:
    Guillermo
    Spanish Extension NRC?
    WHAT ARE OUR THOUGHTS?  ANY IMPACT ON ANYONE, OR SHOULD WE SOCIALISE WITH SPANISH COMMUNITY?

TRAG TO confirm a proposal to Change to:

May 10th + November 10th (based on INT Edition April 1st + October 1st) 
The first release on the new cycle would be targeted for 10th May 2025
 NOTE:  We'd like to be certain that this will be the last change to this release cycle for the foreseeable future, in order to prevent furhter disruption and confusion for the end users.  Are there ANY other predicted changes in requirements within the next few years?
FOR EXAMPLE, POTENTIAL MOVE TO MORE FREQUENT RELEASES (see previous topic) ??????
APPROVED BY ALL
AA to socialise the proposal to transition to the new release dates from 2025 onwards.
 
.
On 01/11/2024 we started the consultation on this migration, by publishing the proposal to start the new schedule from the May 2025 Spanish Edition release:

Dear all

An opportunity has been identified to further improve the Release schedule for the SNOMED CT Spanish Edition package.  Currently the Spanish Edition Release is published on 31st March + 30th September each year, which were the new dates designed to reduce the time between the dependent International Edition + the Publication of the Spanish Edition package.  Now that this has been trialled and confirmed to be of benefit, we have further analysed the dates to identify what would be most helpful to the Spanish Edition users.

The conclusion was that users can most likely benefit from moving our release closer to theirs, rather than moving them earlier and continuing using the "January" and "July" International releases as the dependent versions.  This is because the majority of users of the Spanish Edition are not able to change their release dates to bring them forward, in order to take advantage of the additional time gained by us releasing the Spanish Edition a month earlier.

Therefore, instead of continuing the refine the process down to release the Spanish Edition earlier each year, we will instead cut off the translations much later in the cycle, in order to allow us to use a later International Edition as the baseline (September or even October, for example).  This will allow many more translations to get into each Spanish Edition release, but still allow the users to retain their own Release dates.

The proposed new dates for the Spanish Edition release each year are therefore:

We will transition to this new release schedule as planned, unless we receive any critical objections in the meantime.  If you have any concerns or questions on these proposed changes, please let us know on release@snomed.org, or by responding to this message directly.

.

We received the following feedback:

.
We are therefore proposing to go ahead with the migration in May 2025.
HOWEVER, we will also try to publish early visibility to help users out - for example we could publish the 2025 schedule and confirm something like the following:
The Spanish Edition 10th May 2025 release will be dependent upon the 1st April 2025 International Edition
The Spanish Edition 10th November 2025 release will be dependent upon the 1st October 2025 International EditionWILL THIS HELP??  OR DO WE NEED SOMETHING ELSE??
 
DOES THIS WORK FOR EVERYONE?? CAN WE PROCEED AS PLANNED OR IS THERE ANY CRITICAL FEEDBACK????
.
EVERYONE AGREED - proceed!

 

4

Edition package Module decisions

ALL

So now that we're moving closer to using the Edition Packaging tool, we want to start discussions on requirements.

Starting with where we'd like to go with modules in general - for example Implementation questions:

What module would you us in FHIR when it's an Edition package we're talking about? (and therefore contains multiple modules)
Is it just the Extension module (and the International modules are assumed)?
Or can it handle multiple modules? 
How about complex Extension packages that contain multiple modules? (core, drugs, etc)
Would/Should it be the owning organisation that ultimately decides which module(s) to use?
If so, how/where do you actually define that?

 

5







 

6

Active Discussions for April 2025



 

7

Welcome and thank you!



Welcome to new members!



 

8







 

9

UPDATING TRAG DATA



  1. First thing is that we need to update the Conflicts of Interest page here:

  2. Second question is whether or not you'd like this information to remain hidden, or whether we can open it up to community view? (in line with our efforts at complete transparency)

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

 

10





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!

 

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 

 

12

 

 

 

 

13

https://forums.snomed.org/t/standardised-set-of-allowed-characters-in-snomed-ct-descriptions/818

 

 

 

14

DEPRECATION PLANS

 

 

 

15

 

ALL

DEPRECATION POLICY

  • Walk through

  • Any issues?

  • Any feedback?

  • What comms required?

 

16

 

ALL

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

  • Any issues?

  • Any more comms required?

 

17

 

ALL

Walkthrough plan to transition to new DescriptionType format:

  • Next steps

  • Any issues?

  • Any more comms required?

 

18

 

ALL

ICD-0 Deprecation??

 

 

19

New Documentation location

ALL

Walk through of new location(s) now that we're splitting everything off from Confluence

  • Any issues with access for anyone, or for anyone's end users?

  • Feedback on usability of new websites?

  • Feedback on usability of actual docs?

 

20

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

 

21

DescriptionType length limit increase proposal

ALL

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)
ANY CONCERNS WITH ALL OTHER PRODUCTS TRANSITIONING AS WELL?
NOTE: GUILLERMO would like us to move to this sooner for Spanish Edition
We will 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 AVAILABLE TO ALL - Michael and others can't see it...
.
ALL AGREED
.

 

22

Update to the .JSON file metadata - addition of "Package Composition" data

ALL

Now we've used this file for several months, we have some suggestions for improvements:

  1. *NOTE* - we have had various discussions (including in Saturday's Terminology Management meeting) regarding the scope of this:

    1. We are intending to use some other methods to store CONTENT-SPECIFIC metadata

    2. So the .JSON file in the releases will be very specifically targeted at PACKAGE metadata. 

      1. This will be things that are specific to each Package published for a Product, rather than high level Product/Content metadata that applies across all releases of a Product.

        1. We may, therefore, remove some of the existing fields, where we consider them to be Content-specific - WE'LL COME TO THAT BELOW....

      2. HOWEVER, it would also include things that might easily change between releases - so even though it would usually be considered to be static, it may change between releases, and therefore needs to be explicitly stated

        1. (eg) the moduleID(s) of the module(s) included in the package, would normally remain relatively static, but can sometimes changes with module(s) added/removed, and therefore should be explicitly stated in each release metadata.

  2. We first have the proposal to add in Package Composition data:

    1. Update to the .JSON file metadata - addition of "Package Composition" data

      1. First Question is, in light of the new Module Storage Coordinator work that Peter introduced before, is the Package Composition data still useful?

      2. The next question is whether or not the distinction between "optional" and "mandatory" components is a useful one?

      3. .

  3. In addition we have also received proposals to include the following New fields:

  •  

    Previous Published compositionModuleID's - 
    Need Module|VersionDate PAIRS to show what the previousPublishedPackage was COMPOSED of (programmatically NOT the Zip file name) (eg)
    57091000202101|2025-07-01
    57101000202106|2025-01-01
    51000202101|2025-07-01
    CURRENT package filename as well
    compositionModuleID's - confirm what the CURRENT composition of the CURRENT package is (may need version dates as everything SHOULD be on same effectiveTime, but MIGHT NOT BE going forward!)
    NOTE:  ONLY if this is DIFFERENT from the new proposal for the "Package Composition" data proposal.....
    YES, AGREED WITH THE PACKAGECOMPSOTION PROPOSAL EXCEPT REMOVE FSN...
    URI that identifies the package being published
    PackageType (ie) Edition or Extension or Derivative (might now be redundant with the "Edition" naming convention changes above?)
     
    XXXDefault Namespace - CONTENT-SPECIFIC??
     Defaut Language Refset 
    Yes, we need a structured, ORDERED list of Language refsets, with a DEFAULT refset tagged would be useful
    XXXDefault module to start authoring - CONTENT-SPECIFIC??
    OPTIONAL:
    Country code
    Custom tag
    ALL INFORMATION FROM THE README FILE (which is neither human nor computer readable)
    XXXXMANIFEST INFO
    Licencing info
    Could be MULTIPLE licences, because of potentially containing multiple products in the Edition Packages
    May need a Copyright stattement PER module so can be different! 
    JSON SCHEMA for this JSON file
    (to allow computer readable version of how to read the JSON file)
    MD5 Hash???
    Either of entire package or of each specific files in package
    .
    ANY OTHERS????
    .

  1. Removed fields:

IN PARALLEL, WE HAVE ALSO BEEN DISCUSSING WITH THE COMMUNITY ADDING IN NEW CONTENT METADATA INTO THE CONTENT ITSELF (eg) Map Source URI's now be added into the content as additional relationships, in order to help implementers/vendors who don't always have access to the actual packages (and therefore the JSON files) - Kai can confirm which are being added (18/10/25).
THEREFORE, we want to now distinguish between:
a)  Content Metadata (for example at the PRODUCT level, such as related to maps/refsets) - which should be held in the CONTENT
(eg)
Language Refset Aliases (to be held as an Additional Relationship)
Map Source/Target URI's (to be held as an Additional Relationship)
CodeSystem version URI
b)  Package Metadata (which is at the RELEASE level, such as Release date/Dependency Versions, etc) - which should continue to be held in the JSON files in each Package  
We therefore do NOT want to duplicate information across these two formats...
SO DO WE HAVE ANY WE'D NOW LIKE TO REMOVE FROM THE JSON FILES???
.
.
 
NEXT STEPS
AAT to write a straw man proposal to update the JSON file format, including all fields discussed above
AAT to then share with the TRAG so that they can review before the next meeting, and provide feedback
AIM to then ratify change proposal in the next TRAG meeitng (April 2026) 
AAT to then either a) take change proposal to MF, or (if not required) b) Implement change proposal...
AAT to then refine the new FILE SPEC FOR THIS FILE TYPE:
*MICHAEL WOULD PREFER THAT WE CHANGE THE FORMAT OF THIS PAGE TO JSON FORMAT (instead of a table of fields) SO THAT IT CLEARLY REPRESENTS THE FILE FORMAT
 

 

23

RELEASE FILE SPEC CHANGES:



TRAG to create a 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 October 2025 meeting, with the intention of driving the following timeline once MF signed off:

  •  

    • October 2025

      • SEND OUT A BRIEFING NOTE and Release COMMS FOR JANUARY 2026 WITH CAVEAT THAT

        • "IF ANYONE HAS CRITICAL OBJECTIONS TO THIS PLEASE RAISE NOW" 

      • ASK NRC's TO PUT OUT A BRIEF REQUEST (linking in our comms) TO THEIR USERS TO ASK IF THERE ARE ANY STRONG OBJECTIONS

    • November 2025

      • THEN IF NO OBJECTIONS WE’LL SEND OUT CONFIRMATION THAT WE WILL TRANSITION IN JANUARY 2026

    • January 2026 INTERNATIONAL Release:

      • TRANSITION TO NEW FORMAT IN January 2026 International Edition

      • TRANSIITON ALL SUBSEQUENT PRODUCTS TO NEW FORMAT AS THEY BECOME DEPENDENT ON >=January 2026 INT Edition

  • .

  • ALL AGREED!!

  • .

  • NEXT STEPS

    AAT to CREATE MF PROPOSAL COMBINING ALL OF THE BELOW IMPROVEMENTS, and present to the MF

  • .

 

24

Edition vs Extension Packaging Naming conventions

All

TRAG already discussed and provisionally agreed in previous TRAG meeting, so just need to confirm + include in the MF Proposal...

 

25

Proposal to remove the "ManagedService" tag from the package naming convention

All

TRAG decide + include in the MF Proposal...

 

26

Removal of Format element "RF2" from release package naming conventions

All

TRAG decide + include in the MF Proposal...

 

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

TRAG decide + include in the MF Proposal...

 

29

Delta file types in the Release File Spec

ALL

Copyright © 2026, SNOMED International