2026-10-19- 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...

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

Welcome and thank you!

Welcome to new members!

• Alastair Kenworthy

• Laura Gutierrez

  • Laura left the Spanish NRC to take up a new professional opportunity, and unfortunately the Spanish Ministry of Health requires the representative in the TRAG to be a member of the NRC - she has therefore had to step down from the TRAG.

Please introduce yourselves!

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

2. Secondly, we need to walk through the original Terms Of Reference for the TRAG to ensure that they're still relevant, & 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 

• 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

• .

IMPROVEMENTS TO OUR TRAG WAYS OF WORKING

ALL

We have received feedback from some of our more infrequent attendees, regarding both the complexity of the discussions that we have, plus the the way in which we disseminate the decisions that we make.

We would therefore like to discuss the following, and compile a proposal of how we can improve the accessibility of the TRAG meetings for those who are not Chairs or regular attendees:

• A one-page onboarding guide for new or occasional TRAG participants, covering the group’s purpose, ways of working, key participants, and the main topics currently under discussion. We can post this on the TRAG site.

• Some way of categorising agenda items and outcomes, making it easier for NRC release teams to identify what requires their attention and what actions, if any, are expected of them?

  • This could be tricky, as we can’t predict all types (and levels) of user who might want to attend/read the TRAG minutes.

  • However, we could at least try to add some basic metadata that might help users sort the agenda items and conclusions (eg)

    • Product Impact analysis (which products/systems might be changed as a result of each discussion point)

    • User Impact analysis (which countries/users might be impacted by proposed changes - or at least INT/MS/Derivative?)

    • Anything else?

• We’re not suggesting that the technical level should change; they recognise it is appropriate for the audience. However, they felt that some relatively small improvements could make participation much easier:

• Perhaps we retain only the Header + the Decision history in the agenda, and move all Discussions history out into the FORUMS discussions??

  • OR WE COULD ADD SEVERAL KEY INFO POINTS TO THIS SUMMARY PAGE (eg):

    • Title

    • Specific SME’s involved

    • Current Status

    • Next Step(s)

    • Link to Full Discussions history

    • Prioritisation (time pressure, justification for the prioritisation)

    • Separated into Meeting dates agenda’s

      • Setup online call about a month in advance so we can decide and agree on all prioritisations and targets for the next in person meeting

    • Decisions made and rationale +++++ plan for communicating the decision out to the community

    • NOTE:

      • Either on this page, then this page is broken into sections

      • OR on separate page if this makes it more readable

  •  

  • IN ORDER to ENSURE TO

• ONCE WE’VE AGREED THE GENERAL APPROACH - AAT TO MOCK UP AND SHOW THE TRAG…

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? 

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 alternative dates:

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

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

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

3. October 2026 International Edition 3 days before. the planned release on 1st October

   1. did anyone notice that it was published on Monday 28th September instead??

• Did it impact anyone in any way?

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

  • Prefer BEFOREHAND if different, rather than after - NO-ONE HAS A HARD DEPENDENCY IF IT’S A DAY OR TWO LATER, BUT EVERYONE PREFERS IT TO BE EARLY (if it’s gonna be late, tell everyone in advance)

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

    • New decision log

    • Anywhere else??

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

Transition plan for the DescriptionType length limits

ALL - OCTOBER 2026

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?

October 2026

• Final confirmation of the changes made in July 2026:

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

  • Any more comms required?

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

Further improvements to the Release File Naming Conventions

We have now refined the planned changes to the Release File Specification, to incorporate all of the feedback received from yourselves and from the Member Forum.

In addition to this, we have pushed the implementation date back to July 2027, in order to provide adequate notice for all of the end users who need to prepare for the transition.

WALK THROUGH OF THE ORIGINAL PROPOSAL TO THE MF:

https://docs.google.com/document/d/1-H0Mi-3bM6FBTlJPrbwldOX_qosl1bXU0u8mHU-4X5M/edit?tab=t.0

One of the main changes was to include the “Scope” tag in the File Naming conventions as well as the Package Naming conventions.

• This was in response to feedback that the files contained within the package 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 should therefore mitigate the risk that users will have duplicate Concept/Description/Relationship files, and waste time ascertaining which is which.

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

• The plan is to therefore add the optional “Scope” flag (“Edition/Extension/Derivative”), to the File Naming conventions as well - specifically to the “ContentType” element of the File Name.

  • For example:

    • <file Name="der2_cciRefsetExtension_RefsetDescriptorFull_KR1000267_20260615.txt"/>

    • <file Name="der2_ssRefsetExtension_ModuleDependencyFull_KR1000267_20260615.txt"/>

    • <file Name="der2_ciRefsetExtension_DescriptionTypeFull_KR1000267_20260615.txt"/>

    • <file Name="der2_scsRefsetExtension_ComponentAnnotationStringValueFull_KR1000267_20260615.txt"/>

    • <file Name="der2_sscsRefsetExtension_MemberAnnotationStringValueFull_KR1000267_20260615.txt"/>

• This would appear to be the correct element in which to locate the “Scope” tag, as this element “…describes the content and purpose of the file.”

  • HOWEVER, we could in theory also house it in the “ContentSubType” element, which “provides additional information to describe the content and purpose of the file”. BUT this results in this third element looking extremely long in most cases, and so could be very confusing both for human readability and for machine reading (eg)

    • <file Name="xder2_cciRefset_RefsetDescriptorExtensionFull_KR1000267_20260615.txt"/>

    • <file Name="xder2_ssRefset_ModuleDependencyExtensionFull_KR1000267_20260615.txt"/>

    • <file Name="xder2_ciRefset_DescriptionTypeExtensionFull_KR1000267_20260615.txt"/>

    • <file Name="xder2_scsRefset_ComponentAnnotationStringValueExtensionFull_KR1000267_20260615.txt"/>

    • <file Name="xder2_sscsRefset_MemberAnnotationStringValueExtensionFull_KR1000267_20260615.txt"/>

• WHICH DOES EVERYONE BELIEVE TO BE MOST USEFUL??

  • The former - ContentType

• .

• WE HAVE NOW REFINED THE PROPOSAL BASED ON VARIOUS FEEDBACK FROM THE COMMUNITY:

  • REVISED VERSION:

• Feedback please?

  • OBVIOUSLY WE WOULD LIKE YOU TO ADVISE ON EACH OF THE CHANGES, BUT IN PARTICULAR FOCUS ON NEW CHANGES:

    • Improved Examples:

      • We intentionally restricted the changes in each example to that specific change, as we believed that applying all of the changes to the examples in every section would make it extremely unclear as to what the specific change was in each section. 

        • So, the examples in section 1 only show the changes in section 1

        • The examples in section 9, only show the changes in section 9 - not those in the previous 8 sections.

      • However, we appreciate that this can be confusing in the context of the overarching Briefing Note, and so we’ve now also included a section giving examples of the new naming conventions including ALL changes, at the end of the document (Appendix A).

      • Does this provide enough clarity for people to understand what changes to expect?

      • Or does it introduce potential confusion?

      • Should we perhaps just have the Appendix at the end instead of individual examples?

    • Refinement of the explanations of the background and rationale of changes, especially in sections 6, 8 and 9

    • Improved numbering - sections should now be self-contained and/or correctly referenced through from others

• NEXT STEPS = Send Revised BN back through the MF for final approval

  • Retain individual examples as well +

  • BUT add the note at the top of the doc stating to look at the appendix for examples of ALL changes, to each inidivual example section so it’s clear

  • We need to push out EXAMPLES OF FULL PACKAGE CHANGES to community well in advnace

  • Fix Gabor’s typo highlighted in red

"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:

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

Reference set metadata

* MAG crossover

Reuben Daniels

Replacement of the Refset Descriptor file with a machine readable Release Package metadata file

See David's proposal here: Reference set metadata (plus sub page here: Potential New Approach to Refset Descriptors)

Everyone confirmed no issues with the proposal in principle, in April 2018

However, do we consider this to just be relevant to refsets in the International Edition release package?

Or to all derivative products as well?

Both refsets and maps?

Also, are we talking about only human readable descriptive information, or also machine readable metadata such as

ranges of permitted values

mutability, etc?

michael lawley to kindly provide an update on his work with David to help design and implement the solution - this will now be in the second TRAG meeting of the April 2019 conference, after they have met together....

Michael + David + Harold agreed to create a straw man to put up in the next meeting and take this further...

michael lawley - where are the discussion on this currently?

 Michael confirmed (20210420) that this straw man was never created, and so we should use the published .json file as the straw man for future discussions... 

Can we link this in to the .JSON file above? (Computer readable metadata) - yes, done!

 

IN FACT, are there any requirements for machine-readable or human-readable metadata that can't be addressed with extensions to the new .JSON file in the release packages?

No, not that people can foresee!

 

 

Reuben would like to re-instate this topic in order to propose some new refset metadata - either as :

1. a new DescriptionType or

2. a new use case for Annotations....

Reuben will introduce the use case and ask for feedback on which of the above solutions would be most appropriate...

This has therefore been rolled into the holistic discussions on Metadata in the Metadata Working Group:

Dion + Reuben volunteered to write an initial proposal

Guillermo and others will then feed their ideas & user requirements into the proposal

Once the TRAG is happy with the proposal, we can then socialise it internally within SI

Once that's signed off, we can then socialise it within the community...

PROPOSAL IS NOW AVAILABLE FOR OUR REVIEW, BUT DION WILL INTRODUCE IT NOW FOR US TO TALK THROUGH:

https://forums.snomed.org/t/reference-set-metadata-revived/1668

This covers two of the Working Group’s four categories:

1. Component gaps (such as a map’s foreign code system URI and correlation) and

2. Refset metadata.

Package-level metadata stays in release_package_information.json, where it belongs.

Michael Lawley proposed to use the new “mini test SNOMED package” (being discussed in the Languages groups) to test and trial this new framework before we push it live

Dion also wants to refine the RVF assertions to ensure that they’re fit for purpose for the new artefacts

Dion (Peter Williams agrees) that the TRAG are the best gateway for new/changed properties to come into the terminology, so we would own the property catalogue. However I think we should involve the content team too - NEED. TO ASK MARIA!!

We should align some of the properties with FHIR properties to allow easy integration - but NO-ONE feels the need to align the exact naming conventions of the properties with FHIR - as long as they’re eseentially the same as the FHIR properties, then the naming does not have to match.

We need to prioritise Additional Relationships internally toe nsure our internal systems are aligned before we proceed - Peter Williams thinks we can use this as a justification for pushing the prioritisation of them in order to support the metadata use case….

.

NEXT STEPS:

Everyone review the document and especially the “Open questions” page, and provide comments asap

We need to all AGREE the framework first

We all need to formalise and AGREE the owner(s) of the property catalogue

We then need to AGREE the initial property set

Proposal to update the RF2 specification to allow 3 letter language codes

Proposal to update the RF2 specification to allow 3 letter language codes, eg for the Karakalpak language

The RF2 spec currently limits the language code field to two letters because that is what the old "ISO-639-1" spec dictates.

"Specifies the language of the description text using the two character ISO-639-1 code. Note that this specifies a language level only, not a dialect or country code."

• RF2 Description Spec

In November 2023 ISO published a new version of this standard:

• ISO 639-1 (two-letter codes that we use in RF2) and ISO 639-2 (three-letter codes) became obsolete.

  • These standards now have "withdrawn" status

• Since November 2023 the new version "ISO 639:2023" includes both two- and three-letter codes. It is backward-compatible with ISO 639-1, all previously used two-letter codes are still valid.

• https://www.iso.org/standard/74575.html

We must maintain a stable standard, but for nearly everyone involved this would be an unnoticeable, zero impact change. The fact that ISO 639:2023 is backward-compatible and will have no impact on all existing editions is a significant advantage.

Consultation will likely be required, but mostly because there will be a spec change required. Existing INT and extensions will not actually transmit more than 2 characters (not using a different language). No need to change implementation unless Karakalpak (or other languages that use 3 letter language codes) are expected to be used.

Database Loader: https://github.com/IHTSDO/snomed-database-loader/blob/master/MySQL/environment-mysql.sql

RVF: https://github.com/IHTSDO/release-validation-framework/blob/a5e24b452a45abd2bce8144ae70af430223d6c54/src/main/resources/sql/create-tables-mysql.sql#L46

Allowed Characters in SNOMED CT Descriptions

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?

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

ACTIONS (April 2026):

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

DEPRECATION PLANS

ALL - OCTOBER 2026

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

ALL - OCTOBER 2026

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

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

• PLAN IS TO REMOVE THE CNC INDICATORS COMPLETELY FROM THE INTERNATIONAL EDITION AS SOON AS POSSIBLE

  • HOWEVER AS THIS WILL USE THE NEW NEGATIVE DELTA FILE PROCESS (See Historical Change Framework) THIS WILL HAVE TO WAIT UNTIL THIS PROCESS IS COMPLETE AND APPROVED

• Any issues?

• Any more comms required?

ALL - OCTOBER 2026

ICD-0 Deprecation??

FORMAL Deprecation of the IPST product

ALL

Confirmation of final deprecation, decision on whether or not to create BN’s, etc

ALL /

Peter Williams

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

The Case For Removing Description Concept Non-Current Indicators

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

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 - SEE NEW VERSION:

  • Discuss further feedback received:

    • Examples are still confusing - Whilst the Appendix shows the full examples with ALL changes applied, each imndividual section contains a “Partial” example that only shows the change for that section. This could be confusing for some?

    • Perhaps we should remove the individual examples completely?

    • Or maybe we should use other layering methods such as italics, strikethrough etc? (though this could be tricky for elements that have been removed!)

• Or if already approved by MF, final Transition Plan brought to TRAG for confirmation

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

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

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

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

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

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

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

ALL

Any other Release File Spec changes that the TRAG would like to put on the table?  NOT FOR NOW

ACTIONS (April 2026):

ONCE ALL CHANGES AGREED, WE ALSO NEED TO DISCUSS AND AGREE WHERE RELATED CHANGES ARE REQUIRED

(eg)

• update the various documents accordingly 

  • https://docs.snomed.org/snomed-ct-specifications/snomed-ct-release-file-specification/reference-set-release-file-specification/5.1.3-naming-conventions-for-reference-sets

  • https://docs.snomed.org/snomed-ct-specifications/snomed-ct-release-file-specification/release-types-packages-and-files/3.3-naming-conventions-for-release-packages-and-files/3.3.2-release-file-naming-convention

  • Anne Randorff Højen

• Any training courses or other materials require updating??

  • Kath Priest

Invalid vs inactive referenced components

ALL

TRAG feedback + update RVF validation rules

The RVF currently validates all refset members by checking that the referenced components are active (historical association refsets are excluded).

In the Managed Service, we frequently encounter one of the following scenarios, especially with simple refsets:

1. Refset and terminology authoring have different cadences (e.g. clinical refsets reviewed 6-monthly vs. terminology updated every month)

2. Content owners delay updating refsets because newly inactivated concepts break data entry or messaging

AU raised a similar proposal previously (VAL-444). We would like to revise the validation rule:

• Add a rule that checks whether a referenced component exists in any of the following files: Concept, Description, TextDefinition, Relationship (per Release File Spec), and

• Keep the “active” check for the OWL Expression refset as an error, and

• Downgrade the current “active” component check for all other refset types from error to warning

New Documentation locations

ALL

Walk through of new location(s) now that we’ve split everything off from Confluence:

• SNOMED DOCUMENTS (eg)

  • https://docs.snomed.org/snomed-ct-specifications/snomed-ct-release-file-specification

• SNOMED SPACES (eg)

  • New TRAG Site: Terminology Release Advisory Group

  • New Release Management site: SNOMED International Release Management

• SNOMED FORUMS (eg)

  • New Release Comms distribution site: https://forums.snomed.org/c/company-news/release/44

    • (Please make sure you’ve signed up to receive updates from this site)

  • TRAG Discussions: https://forums.snomed.org/c/groups/trag/27

• .

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

• Feedback on usability of new websites?

• Feedback on usability of actual docs?

International Monthly Release schedule

OCTOBER 2026

termMed

Guillermo has kindly offered to then walk through a retrospective of their use (over the 6 months from April 2026 to October 2026) of the Daily Builds, so that other extension owners/maintainers can benefit from lessons learned, and decide whether or not this solution will be helpful for them as well. This will include:

• How they used the Daily Builds

• What they used them for

• Lessons learned

• Recommendations for other extension owners/maintainers

International Monthly Release schedule

Extension Owners & Maintainers, including (but not limited to) Guillermo + Spanish Edition users

SNOMED International have made several improvements to the efficiency of the International Edition release schedule, resulting in an ability to move our authoring cut off & versioning dates back to later in the month.  The cut off used to be in the first week of each month, resulting in a provisional Production release being created by the middle of the month, and the actual Production release being published on the 1st of the next month.

This means that instead of having a confirmed, validated package available to provide to extension maintainers (such as termMed for the Spanish Edition) with early visibility half way through each month, it's now almost the end of the month before we have this available (usually after the 26th of the month).

In order to mitigate this, we have agree to provide access to termMed to the un-versioned Daily Build packages, allowing them early visibility of the proposed (but not finalised) components, which in most cases is enough to improve the speed of translations etc for products such as the Spanish Edition.

However, the move towards shorter transition times for the International Edition release might also have impacts for other extension owners/maintainers, and therefore we wanted to discuss this with the group.

1. Can we please ask for any feedback from those who believe it might impact them?

2. We may then need to discuss alternative solutions that would provide users (in particular in relation to regular translation) with earlier visibility….

   1. The first (and simplest) option is to move the International Edition cut off’s back to the middle of the month, thus providing everyone with versioned content at least a couple of weeks in advance of each monthly release.

   2. Any other options?

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:

NEW Deprecation Policy

ALL

Full review in meeting of both:

• Overarching plan for the new Deprecation Policy

  • Do people like the idea of having the overarching policy + the specific Deprecation Plans?  Or better to have a massive Policy that has all of the diffferent possible options in it?

  • Is it good that we've written it from the SI process perspective (and then NRC's and other users can re-purpose it if they'd like to re-use it)?  Or would you prefer that we write it generically to allow anyone in the community to use it?

• Deprecation Plan Template

• Suggestions for which Examples will be most useful for people

  • 1.  Transparency in allowing users to see what's being Validly removed from history due to mistakes

  • 2.  Obsolete content that wasn't a mistake, is just no longer relevant and we want to tidy up history (especially where we're talking about thousands of records (like CNC indicators)

  • 3.  Legal issues (such as licensing issues) - where you CAN'T retain hisotry ANYWHERE (even in a static folder) and so history has to be completely deleted and never seen again

  • 4.  UNSAFE data (ie) clinical risks, technical issues that cause dangerous content issues (duplicate ID's, etc) - that should again not be kept in a separate package that's available to users, in order to prevent them being loaded accidentally!

• Any questions and/or suggestions for changes?

  • Should we be creating new repo's in MLDS to cover the various different use cases for deprecation?  As otherwise we risk Overloading the "Resources" section??

    • (eg)

      • a repo for "removed content due to obsolescence" +

      • a repo for "removed content due to errors" + 

      • a repo for "removed content due to legal issues" + 

      • a repo for "removed content due to Clinical Safety issues"

    • NO, JUST ONE "DEPRECATED" FOLDER for all (with Deprecation reasons held in each Product)

  • Are the Examples in the Appendix helpful, or just confusing?

  • For NEGATIVE DELTA's, for example - do we think this would be more appropriate

    • a) In the Policy, as part of one of the Examples?

    • b) In the Policy, as it's own entity?  (perhaps we need to define "Deprecation Methods"?  (but then we run the risk of going to the nth degree in the high level Policy again!)

    • c) Outside of the Policy, somewhere else??

    • JUST PART OF EACH INDIVIDUAL DEPRECATION PLAN - as there are infintie number of POSSIBLE Deprecation Methods!

      • INCLUDE EXAMPLES OF POTENTIAL METHODS TO USE (including their pro's and cons when implementing)

  • Is SMT approval sufficient for these Operational proposals?

    • OR should we have to get this ratified by all Members, and GA as well?

  • We need to discuss the policy with the Content and Implementation teams to ensure that it's 

    • a) Aligned with their policy(s) on inactivation of both individual and bulk amounts of components AND demotion

    • b) their policy on Demotions (which currently involves our content team inactivating as usual - "Demotion" is then only triggered when an extension takes the inactive International Content, and activates it in their own Extension).

    • c) the overarching Deprecation Policy should either incorporate, or link through to, any other policy(s) within the organisation (eg) Content Demotion policy

    • d) includes the deprecation policy for all possible components within the organisation,

    • e) BUT Not overlapping, or duplicating other organisational policies

• .

• AAT and Suzy to complete Deprecation Policy - THEN once we've had this reviewed internally, next steps will be:

  • Feedback in TRAG, followed by refinements

    • Happening in the April 2026 Meetings….

  • Sign off by SMT

    • Will happen post-April 2026 meetings…

  • Review and approval from the MF

    • Will happen after SMT sign off obtained…

  • Publication of the Policy

    • Before the October conference

  • THEN IMPLEMENT POLICY FOR ALL OF THE BELOW DEPRECATION TARGETS, FOLLOWING THE NEW DEPRECATION PROCESS:

    • Target is to bring the plans to the TRAG in the October 2026 conference for review and feedback…

Once we have updated the policy and shared the Full Draft version, can the TRAG then please review and come to the meeting with feedback and ideas for improvement:

Potential changes to the International RefsetDescriptor records

Peter Williams

Need to bring this to a conclusion and set action points to address it, first in the International Edition, and then afterwards in any necessary Extensions/Editions...

PWI agreed to investigate and Report on progress on MSSP-3226... definitely need to change the refsetDescriptors in the International Edition at some point though...

ALL

EVERYONE AGREED - WE NEED TO PUBLISH A FORMAL DEPRECATION PROCESS and then trial it ourselves using Stated Relationships

ALL

EVERYONE AGREED - WE NEED TO PUBLISH A FORMAL DEPRECATION PROCESS and then trial it ourselves using ICD-0

Archiving policy for MLDS

ALL

We need to agree on an Archiving policy for MLDS, now that we have archiving functionality in the system (rather than just delete)

I would like to preferably move to an N-2 policy, however would that would for everyone wrt International Edition releases? (eg)

Would you be happy just to have say the following releases available in the MAIN folder:

•  

  • April 2025

  • May 2025

  • June 2025

Or, do you consider the previous Jan/July releases to also be "current" (as opposed to "archived")?  So it would then look like this in the main folder:

•  

  • July 2024

  • January 2025

  • April 2025

  • May 2025

  • June 2025

Note:  The current Archiving functionality only allows the SI Release Team to move packages back and forth from the main to the archived repos.  This would mean if you wanted an older package you'd have to raise a ticket for us to put the package back in the main repo.

Whilst this may sound onerous at first, it's actually useful for more than just efficiency purposes - it also forces uses to consider whether or not they actually need an older (potentially clinically unsafe) package, or if they should actually be using a more recent one.

From an MS perspective, we also need to start applying an Archive policy, for several reasons:

1. Because otherwise the volume of packages will start to cause performance issues (as it did a few years ago), and

2. Because we are already archiving the International Edition edition (currently on a 12 month cycle), and so the dependent International releases are often not available for the older MS packages anyway!

3. The risk to your end users is VERY HIGH if they’re using ancient, out of date releases…

So can we agree a policy something like this?

• For monthly releases = n-12

• For six monthly releases = n-4

• For annual releases = n-2

Module Storage Coordinator

Peter Williams

RUN THROUGH OF PLAN, work done so far, and get feedback from all....

Differences between the format of Extensions and the SI Spec

Matt/Dion to

present

Australia have identified multiple differences between their Extension (which was valid from a Spec perspective), but different to other Managed Service extensions - would be great to discuss them through and decide:

a) Should the spec be tightened?

b) Should the Validation (RVF, etc) be tightened to ENSURE alignment of extensions with the spec?

Product Portfolio

LEONG

OCTOBER 2026

Review of demo...

Transition to a newer format for Release Notes

LEONG

OCTOBER 2026

We're now in the process of moving away from proprietary tools (which cost the organisation and therefore the community money) and towards more generic tools.  We'd therefore like to move the Release Notes from Confluence Cloud and onto something like Github.

We'd like to therefore ask for a list of Requirements for the new format

• Thinking of using Markdown - any issues with that?

• Who needs access?

• Whose end users have requirements?

• Feedback on usability of previous Notes?

(eventual walk through of new process(es) to create Release Notes, both for Managed Service customers and others??)

We have not yet formally migrated over to a new Release Notes system, but are in the process of user testing.

Potential move towards Editions

ALL

MAIN POINTS:

• Over the past couple of years we've noticed a trend towards requests for Edition packages containing multiple combined modules, rather than individual extensions/derivatives that are dependent upon other packages.

• In addition, some of our Managed Service work (in particular wrt the Common French + Common German content) is driving us in this direction as a natural part of the products' evolution.

• We'd therefore like to open the discussion on whether or not we should start moving towards producing more Editions, with an eventual aim of publishing most of our products in Edition format.

  • Would this make things easier for yourselves as consumers?

  • Would it make things easier/more difficult for smaller users such as affiliates and licensees?

  • What are the benefits / drawbacks of such a move?

• Spain is another example:

  • The Articles of Association appear to specify nothing, but one of our country contracts state that SNOMED International need to "Provide at least twice-yearly updated versions to the international release of SNOMED CT, including the English and Spanish editions" -

  • However it does NOT specify format or structure.... So perhaps this allows us to change the Spanish Edition to a true Edition??

FEEDBACK SO FAR

• National Extensions should move to Editions in order to remove blockers for end users:

  • Knowing which International Edition to download in conjunction with the Extension

  • Knowing how to combine Extension + INT packages to make something useable

  • ESPECIALLY as this all needs to be done consistently across all countries and users, in order to make the final results useable and compatible for interoperability purposes.

  • Edition packages also remove the ambiguity around modules that have been included in a package that aren't part of the MDRS - composition versus dependency.

• International Derivatives should remain as dependent Extensions

  • Surely the same benefits for end users apply as with the National Extensions? (ie)

    • Knowing which International Edition to download in conjunction with the Extension

    • Knowing how to combine Extension + INT packages to make something useable

  • HOWEVER:

  • As they are mostly Refsets, having an enormous Edition (500mb+)  for one tiny refset (10kb!!!) seems redundant and a massive overkill

  • Many users want multiple derivatives, and so combining Editions then becomes extra-complicated! 

  • Derivatives (maps and reference sets, even language translations) don't typically incur the same level of risk as Extensions (wrt module dependencies etc) as they don't modify components declared in upstream modules.

  • ANOTHER OPTION:

  • Would be for SI to create a "Super-Edition" containing INT content + ALL derivatives, but we moved away from this several years ago for many reasons:

    • Most Users don't want all derivatives, just one or two

    • All derivatives are on different maintenance schedules, so no matter when we published this we'd be out of date with several of them.

    • If something goes wrong with just one derivative, it holds up the release of ALL derivatives.

•  

  •  release.... 

Skipping unnecessary Releases

All

EVERYONE AGREED - WE NEED TO PUBLISH A FORMAL POLICY ON RELEASE SCHEDULES (inc. "NON-RELEASES") and then folllow it ourselves

Redesign of the Map Reference Set formats

All

We have now successfully migrated MedDRA over to the new Map formats:

We now, therefore, need to start work on standardising this new format across our Product portfolio:

QUESTIONS:

• How much notice should we be providing for changing the International Edition map files?

• Comms scope?

• Any impact to existing systems? 

  • (eg) 

    • Mapping tools (WCI)

    • SnaptoSnomed

    • Simplex?

    • Browser

Common Language process improvements

All + RDA

Rory has experienced an issue during the maintenance and management of Common Language content - for example Common French and Common German.  This issue occurs when, for example, the Switzerland Extension publishes every 6 months, but the Common German content is updated every month.  This results in cases where:

• The Switzerland Extension is published in June

• The Common German content is updated to introduce new concepts in August

• The Common German concept(s) are then inactivated in say October

• The Switzerland Extension is then published in December 

This means that these concepts are then "born inactive" in the December Switzerland extension release.  This can potentially cause some issues within snowstorm, but has no known impact on end users trying to implement the Switzerland Extension.

So the question for the TRAG is whether or not:

1. We need to find a better way to maintain/upgrade the Common Language content?  or

2. We don't care about the born inactive content, and just continue on with the current state?

MD5 Hash update

All

As we all know, our current MD5 uses the standard 128 bit encryption, giving a 32 digit hash.

However there are newer and more effective methods out there which we could in theory upgrade to, for example sha256Hash (which has been tested and proven already elsewhere in the community)

Proposal to remove the Release Notes PDF file from Releases

All

Start discussions on the utility of the Release Notes PDF file that we currently publish as one of the deliverables with each of our Release packages.

Exception listing features

All

We should walk through how we would expect our end to end Exception listing functionality to work, from all points of view (ie)

• International Edition visibility for everyone

• Managed Service process and visibility (also across extensions, not just within each one)

• Derivative products

• How we want to see the end result of Known Issues?  

  • Just discoverable in Release Notes when you need to find them?

  • Or pushed out in pro-active comms?

  • Or just searchable in Confluence somewhere if and when needed?

• Permanent vs Temporary Exception listing:

  • Temporary Exception listing (that gets reset every Release cycle, whether that's monthly, 6 monthly or Annually) is great because it keeps good visibility of issues, and nothing gets hidden. 

    • However, the maintenance overheads here are extremely high, as for issues that can't be resolved quickly, this can mean repeatedly exception listing potentially thousands of records every single cycle

  • Permanent Exception listing is fantastic for reducing maintenance overheads.

    • However, we have recently found several problems that are obfuscated as a direct result of this, and so cause much larger, more serious problems after several months/years of hiding them (eg) Re: Potential changes to the International RefsetDescriptor records

    • This can be caused by changing circumstances, ed. guidance and/or technical systems - any of which can mean that whilst it was the right call to permanently exception list issues in the first instance, it is no longer the case due to these changes being implemented afterwards.  There is no way for us to then subsequently identify those exceptions that should be brought back off the permanent list... (at least not in an automated way)

  • Mixed approach - this is what we currently implement, but then whilst we get the benefits of both, we also get the risks & issues of both as well!

• Any other concerns?

Validation feedback

All

Now that we've been running Frequent Delivery for some time, both in International and some MS products, we would like to ask for feedback on any and all Validation gaps that need plugging.

1. So anything major that anyone has found in any Production release packages?

2. Anything minor that anyone is repeatedly finding in any Production release packages?

New style Release Notes review

All

EITHER:

• Heads up that the new style will be coming down soon, or

• DEMO of the new style (from 1st October Parallel run) so that you can provide initial feedback to us for use in future improvements

  • https://authoring.ihtsdotools.org/release-notes-management/

Frequent Delivery for Managed Service

Whilst the overall MS move to Frequent Delivery won't be made available to MS customers until after the International Edition transition, we also don't want to diverge the code bases. 

Therefore, we need to consider and include configuration items within the code to allows the MS Projects to move through the new Frequent Delivery workflow WITHOUT moving to Frequent delivery (for example, we could just enable the basic mandatory automated SAC and nothing else?)

Annotations - Documentation for Refset File types

ALL

The Primary Use Cases for Annotations have been provided as follows:

•  

  • Attribution                             -  (eg)  AJCC vs. UICC tumor staging concepts

  • Editor notes                          -  (eg)  Reference to section of editorial guide when "nonconformance" is used as an inactivation reason

  • Authoritative reference        -  (eg)  Point to sources of truth such as UpToDate or Clinical key pages

  • Regulatory data for drugs   -  (eg)   approved uses, off-label uses 

The new Annotations Refsets do not conform to any of the existing Refset types/patterns:

• 5.2.1.1+Simple+Reference+Set

• .

• (the StringValue refsets do not even conform to earlier versions of the Annotations refset here  5.2.1.6 DEPRECATED: Annotation Reference Set)

We likely therefore need to agree on a new type/format - this will be discussed first in the MAG in the morning and then in the TRAG in the afternoon, with the aim to agree new refset types in these meetings so that they can be used from the December 2023 International Edition Release onwards, and also to create the necessary documentation for the new Refset types in Confluence (as we did for the last new Refset type - the OWL Expression refsets:  

• 5.2.1.9+OWL+Expression+Reference+Set)

New types / formats agreed?

Do we need to DEPRECATE the earlier versions of the Annotations refset here  5.2.1.6 DEPRECATED: Annotation Reference Set ?

 900000000000516008 | Annotation type reference set| 

YES - EVERYONE AGREED!

 

Refset Type formats:

. 

Additional fields for the Member Annotation Refset (created to support annotations on members of any refsets):

refsetId                               - Identifies the reference set to which this reference set member belongs. In this case, a subtype descendant of |Member annotation type reference set|.

referencedComponentId - A referred the referencedComponentId in the referencedMember entry in a refset.

referencedMemberId       - A reference to the UUID of a member in a reference set. The entity to which the annotation is being applied.

Annotation                          - Any descendant of 900000000000459000 |Attribute type (foundation metadata concept)| in the metadata hierarchy.

.

Additional fields for the Component Annotation Refset (created to allow annotations to be assigned to any SNOMED CT component):

refsetId                               - Identifies the reference set to which this reference set member belongs. In this case, a subtype descendant of |Member annotation type reference set|.

referencedComponentId - A referred the referencedComponentId in the referencedMember entry in a refset.

Annotation                          - Any descendant of 900000000000459000 |Attribute type (foundation metadata concept)| in the metadata hierarchy.

.

Documentation complete?

NO - Andrew Atkinson to complete proposed Specs and send out internally for review, before sending to TRAG for final review

Annotations - Validation

All

SNOMED Release Package causing file path length issues in Windows environments.

 John Snyder

WHEN US NRC IS IN ATTENDANCE:

• The base file name is 63 characters:  SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z.zip

• When the zip package is decompressed on a windows based computer using 7zip, the base folder name is the same length as the zip package file name:

  • Open

    

• Drilling down into the second level directory, we see that the base folder is duplicated:

  • Open

    

• The user must click through the duplicate folder before actually getting to the Full and Snapshot folders:

•  

  •  

    Open

    

• The duplicated folder is easily viewable when looking at the file path.

•  

  • C:\Users\snyderjw\Desktop\SNOMED\

  • ...SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z\...

  • ...SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z

• To access files in the release package, the SNOMED path and file name can reach up to 218 characters.

•  

  • ..\SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z\...

  • ...SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z\

  • ...Snapshot\Refset\meta\

  • ...der2_cissccRefset_MRCMAttributeDomainSnapshot_US1000124_20230301.txt

• The maximum file path length allowed in Microsoft windows is 260 characters. This leaves distributed file systems only 42 characters, which can easily be exceeded by simply placing the zip package in the following directory

•  

  • “C:\Users\username\Documents\SNOMED\Downloads\USEdition\March2023\”

• When attempting to copy / paste or work with the files, cause the windows operating system to display an error message to the user as follows:

•  

  •  

    Open

    

•  This error causes the user to move and unzip the package in a shorter directory path to work with the files, which is not always feasible. While the duplicated folder structure issue has always existed, it has been accentuated by the recent change in the zip package and upper level folder renaming which increased the length.

Solution Request:

While some windows server and client systems have been configured to allow file lengths greater than 260 characters, not all systems or local computers have been so configured.

The US NRC is requesting that the duplicate folder structure be removed from the zip package during the zip package generation process to minimize file path length issue in windows environments. 

ACTIONS

•  

  If I download the US Edition from March 2023, I don't get the duplicate base folder structure - albeit using a Mac!

  PROVEN THIS IS A WINDOWS-ONLY ISSUE...

  Has anyone else experienced this issue on Windows or anywhere else?

   YES!  

  HOWEVER Mikael confirmed this is NO LONGER an issue with the native winzip program in the latest version of Windows!  So upgrading Windows resolves this issue.

  Stuart confirmed that it worked for him too, and also if we change the format we would have to make EVERY package different for every user in the world - not feasible!

  Gabor had checked and it is a configuration item that you can change in the Windows Registry, even on older versions

  THEREFORE ONLY ACTION IS FOR SNOMED International to add some guidance for Windows users - perhaps to the Readme files?

  ALSO AAT to check Release Packaging Conventions doc, as Gabor said that our MS PAckages contravene OUR OWN CONVENTIONS for the 4th Element (eg) "_US1000124_", etc ????????

  NOTE:  Everyone agreed that the TRAG should occasionally review ALL of these RELEASE DOCS and confirm that they're still up to date, as things change quite frequeently so we should have a formal ACTION in place to review and update where needed at least once per year!!

  .

IPS Terminology Product

All

Quick run through of the changes that we're proposing to make in the final Production release in Q4 2022, as compared to the BETA release

(ie) discussion of the feedback that we accepted and have implemented in the Production release:

1.  INCLUSION OF THE “EML” (new Drugs refset) IN THE FEEDER FOR THIS PRODUCT FROM 2022 ONWARDS

2. IPS Terminology URI:

• The terminology code system & code system version used to refer to the IPS Terminology are shown below:

  • Code system

    • coding.system = "http://snomed.info/sct"

  • Code system version

    • coding.version = "http://snomed.info/ips/999991001000101"

    • coding.version = "http://snomed.info/ips/999991001000101/version/<publicationDate>"

    • e.g. "http://snomed.info/ips/999991001000101/version/20220430"

         *** PLEASE SEE SECTION E here for final solution:

•  

  • Using a Terminology Server 

ACTIONS:

Association Relationship file naming conventions

All

Once the above decision on the implementation of the Association Relationship records has been made, we then need to consider the naming and packaging conventions for any new files that are required (IF THE DECISION TAKEN WAS TO INTRODUCE NEW FILES)

The proposal would be to follow previous conventions, and therefore be something like this:

• sct2_AssociationRelationship_Snapshot_INT_[date].txt

• sct2_AssociationRelationshipConcreteValues_Snapshot_INT_[date].txt

Association Relationship file

All

In the MAG the requirement for the new Association Relationships (previously called "Additional Relationships") has been identified.

Although they will take the same form as the Inferred Relationships, and therefore be stored in the same format as the Inferred Rel's in the RF2 package, there was still a discussion on whether or not they should be held in the Inferred Rel's file or a completely separate file.

The arguments for retaining them in the Inferred File are:

•  

  • The format is the same, and therefore it could be confusing to users for them to be in a separate file

  • Slightly smaller overhead to maintain and upload

The arguments for putting them into a separate file (with the same format as the Inferred file) are:

•  

  • The precedent for implementing new types of content is to hold them in a separate file, in order to:

    • ...allow for backward compatibility (to allow users to continue to use the Inferred file standalone)

    • ...make it clear for users that this is a new type of content (even though it happens to be in the same format) 

    • ...prevent confusion for users who might not see them as different from the existing Inferred Relationships

  • The source of these Association Relationships (which are almost stated relationships) are different from the Inferred Relationships (which come from the classifier), and there is a potential for confusing systems by adding in a new source to the same file.

  • The maintenance of the ID's could therefore potentially be impacted by having them in the same file.

The arguments for the latter, therefore, appear to be more compelling, and this is the MAG's recommendation.

However, if anyone has any strong opinions either way then please raise them now?

Computer readable metadata

* MAG crossover

Suzy Roy

1. Suzy introduced the topic for discussion...

   
   
   

   Suzy would like to raise the question of creating computer readable metadata, and raise questions such as whether or not to include known namespace & modules? 
   Or just the current metadata for the files in a machine readable format? 
   
   

   
   
   

   CAN WE PLEASE REQUEST THAT PEOPLE SHOUT NOW IF THEY HAVE ANY FURTHER REQUIREMENTS FOR THE METADATA PROJECT??

   WE NEED TO FORMALISE THE SCOPE IF WE'RE GOING TO BE ABLE TO ADD THIS INTO THE WORKPLAN FOR 2024 - PLEASE SUBMIT REQUIREMENTS TO ME BY 30th September OTHERWISE THEY MAY NOT MAKE IT INTO THE SCOPE OF THE FIRST PHASE OF THIS PROJECT...

   Suzy Roy to provide an update on progress:

   All agreed that whilst this is a large topic, we should start somewhere, and get at least some of the quick wins in (then request the change to content via the CMAG):

   1. Check where the progress with the namespace metadata has got to - can we progress this?

   2. Code systems (and versions) of the map baselines

   3. Common strings such as boiler plate licence text etc

   4. Description of use cases for the various refsets (using the text definition of the Refset concetps themselves) - either json or markdown representation of multiple pieces of info within the same field.

   Michael Lawley to provide an update from the related MAG topic...

   TRAG agreed that this should be incorporated into the discussions with the continuous delivery, in order that we can plan the changes here in line with the transition to more frequent releases. To be continued over the next few months...

   michael lawley to kindly provide an update on his work with David to help design and implement the solution - this will now be in the second TRAG meeting of the April 2019 conference, after they have met together....

    

   DID THIS EVER GO ANYWHERE michael lawley?

    

   Ideas:

   Some human readable metadata could potentially live as descriptions (which can then be translated)? David to discuss further...

   David will mock up something in Json...

   Michael + David + Harold agreed to create a straw man to put up in the next meeting and take this further...

   This should now be combined with the Reference set metadata topic, to address all updated metadata use cases - Human readable, Machine readable, etc

   We need to setup a JOINT Working group to deal with this!

   Dion kindly volunteered for this group

   We've added a new machine-readable file to the International Edition this cycle, which can be refined for future usage:

   Standard July 2020 International Edition metadata file:

   release_package_information_INT_edition.json

   NON-Standard July 2020 International Edition Rollup Delta metadata file:

   release_package_information.json

    

   Suzy Roy kindly volunteered to run a Project Group later in 2021 to refine and improve this data as needed going forward:

   Volunteers confirmed in October 2021 TRAG meeting:

   Dion, Mikael + Alejandro

   + Andrew + Peter from tech team

   + need 2 volunteers from MAG (as SMT decided we need wide range of views)

   Suzy to setup meetings once we have MAG volunteers confirmed...

   This will be rolled into the holistic discussions on Metadata in the new Metadata Working Group... Working Group: Refined Metadata 

    

   Plus new requirements from other discussions:

   HOWEVER, WE'RE STILL MISSING THE IDENTIFICATION OF THE ACTUAL MAP PRODUCT ITSELF, AND THE VERSION OF THAT ENTITY

   (eg) "ICNP version Jan 2019" should exist as metadata somewhere within the ICNP map product package...

   + possibly even the direct URI?

   SUGGESTION IS TO USE THE JSON FILE FOR THIS - Andrew Atkinson  to take this forward in the Metadata working group...

    

    ANOTHER DISCUSSION POINT FOR THE JSON FILE:

   Are the "DeltaToDate" and "DeltaFromDate" fields in the JSON file now misleading in the new world of Frequent Delivery where we have no Delta files in the INT package itself?!

   "deltaFromDate" : "20210930",
   "deltaToDate" : "20211031",
   
   

    

   FINAL DECISIONS:

   Agreed that these fields should ONLY be available in packages with Delta files

   Monthly International Releases going forward, should instead just have:

   EffectiveTime

   PreviousPublishedPackage (that the current release is based upon)

   Any retracted releases + their replacements

    

    

    Examples of extending this metadata:

   .json format 5 ?? (Please see Michael Lawley's comments on 16/04/2021 here:  Re: Working Group: Refined Metadata)

   Namespace data

   Individual external Refset data

   ranges of permitted values

   mutability, etc?

   Package Name? (Please see Michael Lawley's comments on  20/04/2021 here:  Re: Working Group: Refined Metadata:  Yes, regarding the "Name" entry, it would be ideal if it could be used to populate the "Product Name" field in a list of available packages (and other required and relevant fields for MLDS).  Then the zip contents would be sufficient to automatically populate MLDS (or an ATOM-based Syndication feed))

   WE'RE STILL MISSING THE IDENTIFICATION OF THE ACTUAL MAP PRODUCT ITSELF, AND THE VERSION OF THAT ENTITY

   (eg) "ICNP version Jan 2019" should exist as metadata somewhere within the ICNP map product package...

   + possibly even the direct URI?

   SUGGESTION IS TO USE THE JSON FILE FOR THIS - group to provide examples of how this would look to the TRAG for review...

    

   ANYTHING TO SUPPORT FREQUENT DELIVERY USEFULLY???? 

   Also create 2 new pages -

   one to capture the requirements for all different use cases

   Use cases and requirements for refined Metadata

   one to discuss and agree on the proposed solutions....

   Proposed Solutions for the requirements

    

   ALL AGREED NO OTHER REQUIREMENTS CURRENTLY, BEYOND THOSE NOW COVERED OFF BY EITHER:

   1.  Extension of JSON file metadata, or

   2. Annotations, or

   3. Additional Relationships file

   4. .

   5. THEREFORE WE'LL HOLD THIS TOPIC OPEN ANOTHER MEETING OR TWO, AND CLOSE DOWN IF NO NEW REQUIREMENTS COME IN

   6. JUST TO CHECK WE STILL NEED THIS TOPIC GIVEN ANNOTATIONS IMPLEMENTATION??