2025-10-21 - 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...

Conclusion of previous Discussions topics

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 package Module decisions

ALL

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

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

Active Discussions for April 2025

Welcome and thank you!

Welcome to new members!

UPDATING TRAG DATA

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

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

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

Secondly, we need to walk through the original Terms Of Reference for the TRAG, and ensure that they're still relevant, and update if required:

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?

New Documentation location

ALL

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

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

• Feedback on usability of new websites?

• Feedback on usability of actual docs?

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?

AGREED

DescriptionType length limit increase proposal

ALL

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:

1. Removed fields:

RELEASE FILE SPEC CHANGES:

TRAG to create a proposal for the MF (including a target timeframe for making the changes, including a period of time to allow Member Forum Representatives opportunity to engage and seek feedback from users) in the October 2025 meeting, with the intention of driving the following timeline once MF signed off:

All

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

All

TRAG decide + include in the MF Proposal...

All

TRAG decide + include in the MF Proposal...

All

TRAG decide + include in the MF Proposal...

ALL

TRAG decide + include in the MF Proposal...

ALL

TRAG CONFIRM if the new wording is adequate???

YES, just specify that it's now OPTIONAL to include Delta files in the packages

We can also add in wording to state that you can OPTIONALLY add in the From/To effectievTimes to the Delta file naming convention - BUT the default is that it's always a Delta to the PreviouslyPublishedPackage.

ALL

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

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

  • Sign off by SMT

  • Review and approval from the MF

  • Publication of the Policy

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

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:

ALL /

Peter Williams

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

The Case For Removing Description Concept Non-Current Indicators

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

Product Portfolio

LEONG

Review of demo...

Transition to a newer format for Release Notes

LEONG

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.

Module Storage Coordinator

Peter Williams

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