2024-10-21 - TRAG Meeting Agenda/Minutes

Welcome!

All

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

INTRODUCTIONS...

FIRST OF ALL I'D LIKE TO SAY A HUGE THANK YOU TO ALL OF OUR OUTGOING MEMBERS, FOR ALL OF THEIR HARD WORK AND COMMITMENT IN EXEXCUTING THE WORK OF THE TRAG.

NEXT PLEASE JOIN ME IN WELCOMING SEVERAL NEW MEMBERS TO THE RELEASE AG:

• Graeme Elsby

• Alejandro Rodriguez

• Reuben Daniels

• Dion McMurtrie (who has been a member previously, and is re-joining us)

I'll allow them to introduce themselves, rather than providing you with pointless generic 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...

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 October 2024

Welcome and thank you!

Welcome to new members!

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 arguments for putting them into a separate file (with the same format as the Inferred file) are:

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?

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

DescriptionType spec improvements

ALL

Naming Conventions for Refsets

All

Spanish Edition frequency of delivery

Spanish Edition users

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:

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)

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)

Derivative product Release package formats

All

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