2025-04-07 - TRAG Meeting Agenda/Minutes

Welcome!

All

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

INTRODUCTIONS...

I'D LIKE TO PLEASE WELCOME LEONG HUI WONG, WHO IS NOW A MEMBER OF THE SNOMED INTERNATIONAL RELEASE TEAM, AND SO WILL BE JOINING US AT ALL FUTURE TRAG MEETINGS!!

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

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

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

Conclusion of previous Discussions topics

RF2 Refset file naming convention

All

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

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

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

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

   Therefore we have (**** CONFIRM ALREADY IMPLEMENTED BY THE TIME THE NEXT TRAG MEETING HAS OCCURRED ****) trialled a refined naming convention for ne of the MS extensions:

   • FROM:

     • der2_Refset_AjccHaematologicMalignancyPathologicalMCategorySimpleRefsetSnapshot_NZ1000210_20231001.txt

   • TO:

     • der2_Refset_253731000210103SimpleRefsetSnapshot_NZ1000210_20231001.txt

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

   Therefore:

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

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

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

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

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

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

   Thoughts?

   Long term....

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

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

   .

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

   DUE TO THE SHEER VOLUME OF REFSETS IN THE NZ EXTENSION, WE'VE TRIALLED THE TRANSITION IN THE OCTOBER 2024 NZ RELEASE :

   ....

   Any feedback????

   ....

   IF NOT, LET'S JUST PUSH FORWARD AND MAKE THE CHANGES ACROSS ALL PRODUCTS, IN ORDER TO ENSURE CONSISTENCY AND INTEROPERABILITY!!

Annotations - Additional Relationship file

ALL

Annotations - Language Code 

ALL

Hi @Matt Cordell @Dion McMurtrie @michael lawley @Alejandro Lopez Osornio @Mounir Bouzanih (Unlicensed) @Patrick McLaughlin @Mikael Nyström (Unlicensed) @Stuart Abbott (Unlicensed) @Gábor Nagy (Unlicensed) @Reuben Daniels 

There are several options for managing the Language code -

• see the options here:  Annotations review 

• Plus also see the "Representation of annotation data type" section of the MAG proposal: SNOMED CT Annotations (this is because the other option was to include "@language" in the "annotationValue" field, which would be a problematic idea for implementations as the entire field would have to be parsed each time in order to extract the language code) 

Annotations - Release Dates

ALL

The release date depends on two factors:

1. Firstly, the authoring platform being ready for annotations (which will be November 2023)

2. Secondly, content authored for annotations. Language tags only involve about 8 concepts under 900000000000506000 |Language type reference set (foundation metadata concept)|. The attribution could be done by technical batch changes.

Because of the change to release date (to the 1st of the month), it is therefore unlikely to be possible to prepare everything in time for the December 2023 release. We are therefore currently aiming for the January 2024 releases - as this will also provide the largest audience for these major new changes (as opposed to Feb/March which most users still do no consume).

Refset  processes in the post-RT2 world

All

Options to be discussed (see local Notes "RT2 New Process")

MAIN POINTS:

• The International Derivative releases have always been dependent on Jan/July, in order to align with the fact that most end users still only take the Jan/July releases, and not the other monthly releases.

• The new RT2 integration with snowstorm branches greatly improves the quality, because it allows the authors to run full validation against the new derivative content BEFORE promoting, thereby allowing identification + fixing of most issues before they hit the Release cycle. (eg)

  • MAIN/Refsets/GPFP,   MAIN/Refsets/ICNP,  etc

• However, in order to actually RELEASE these derivative products, we’ll need to Promote the Refset content up to MAIN/ (as the metadata content is in the International Edition, and we can’t currently export content from multiple snowstorm branches into SRS for the same release, just from one branch)

• Before you’re allowed to promote in the AP, you HAVE TO re-base and validation FIRST

  • The re-base process will pull the content through from the LATEST International content in MAIN, which may include monthly content from later releases than the recent JAN/JULY release that we originally wanted to base the Derivative release upon!

• This makes it inherently less flexible in terms of preventing re-basing against later monthly International releases, and therefore extremely difficult to retain dependency on JAN/JULY releases.

OPTIONS:

1. BEST option appears to be to allow the Derivative refsets to be dependent on the month prior to that in which they're Published (eg) March/September for most derivatives.

2. However, is it possible that if we were to make a different decision on the item above, then this issue in the RT2 release process could also be mitigated by moving the metadata into the Derivative packages themselves?  If we did this, could we potentially then retain the Derivative content in the Refsets' child branches and release from there?

   (eg) 

   • For GPFP we would maintain the content via the RT2 FE which would read/write to MAIN/Refsets/GPFP

   • Given that we would then also include the Module + other metadata in the same branch (instead of in MAIN),

   • ...Could we then version say into MAIN/Refsets/GPFP/2023-04-30, and Release straight out of that branch??

3. The final option is moving to Monthly releases for Derivative products as well - however:

   1. This is problematic from a capacity/practical point of view, and

   2. This would require significant discussions with all of our collaborating entities to sign off on new agreements (for those who have tangible inputs into the process), including monthly deadlines, etc - This could not be achieved quickly so would need to be discussed with 2024 in mind at the earliest. 

      1. The alternative to this would be to move just SOME of the derivatives (the straightforward refsets for example which don't require much/any external collaboration) to monthly schedules, and keep the others on annual/6 monthly schedules.

      2. However, this would be a significant operational issue, as the processes are already complex enough without introducing further complexity in terms of different derivatives runing on completely different processes.

We should discuss options and agree the best way forward for retaining quality within the Release process vs impact to the users.

Active Discussions for April 2025

Welcome and thank you!

Welcome to new members!

Welcome to Leong!

Potential changes to the International RefsetDescriptor records

All /

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

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

ALL

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

The Case For Removing Description Concept Non-Current Indicators

Edition vs Extension Packaging Naming conventions

All

As a result of the gradual move towards more Editions, we now have a requirement from various Members to publish BOTH Edition and Extension packages.

In order to support this, we need to differentiate between those 2x types of packages in the Package Naming Conventions.

The Release Package Naming conventions already allow for this, so the question is which option people would prefer (eg)

Skipping unnecessary Releases

All

We've recently had a couple of releases where no changes were required that cycle.

This is becoming more frequent with the advent of more Frequent Delivery, but is also occurring where products are so small that they have a tiny chance of having inactive content each cycle.

This has happened recently with some Extensions, where the decision falls with the Product Owners and therefore the NRC's make a call as to whether or not they want to publish a Release with zero changes.  This is dependent on their users use cases, and therefore has a clear business case either way.

However, it has also occurred with some of the smaller Derivative products such as ERA - in this case we are the product owners, but from an International perspective have less visibility of the impact to end users.

Therefore, we make the decisions based on priorities, and whether we believe the members would like us to spend our time publishing releases that have Zero changes.  This decision is usually made in favour of not publishing another release where no changes would be made to the previously published content.

However, we also wanted to double check with you to ensure that this is as you'd like it to be, and that you wouldn't prefer the certainty of having a new ERA release, or GP/FP release, etc - even though it has no changes, to ensure that you know that you're using the latest product?

Perhaps this would also be different depending on whether or not it's a 

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

Transition to a newer format for Release Notes

LEONG

HUI

WONG

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

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:

Stated Relationship deprecation

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

Release Publication days

All

We're considering 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 would impact you, and if so how? 

October 2025...

Proposal to deprecate the ICD-0 Maps

ALL

This is not yet formalised, but is incoming: