2025-10-21 - TRAG Meeting Agenda/Minutes

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.

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

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

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

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

• • Declaration of Interests

  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:

• • Terminology Release AG organization

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?

• 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

• Hopefully you all saw the new comms go out back in September, confirming the final Transition Plan:
  • https://www.snomed.org/news/blog%3A-snomed-international-concludes-community-feedback-period-on-proposed-description-character-limit-increase-and-finalizes-next-steps
  • https://forums.snomed.org/t/descriptiontype-length-limit-increase-proposal/461
• This confirms the planned migration date of July 2026 for the International Edition.
  •  
  • NOTE:  WE ALSO NEED TO TAKE THE OPPORTUNITY TO STANDARDISE THIS ACROSS ALL PRODUCTS (EXTENSIONS, SPANISH EDITION, DERIVATIVES + ALL OTHER SI PRODUCTS) TO AVOID A SIMILAR CONSULTATION in future!!  (as ALL our products would move to 4096)
    • ANY CONCERNS WITH ALL OTHER PRODUCTS TRANSITIONING AS WELL?
•  
  • NOTE: GUILLERMO would like us to move to this sooner for Spanish Edition
    • We will be doing this in line line with the International Edition updates, which will start in July 2026
    • AAT to therefore publish proposal comms to transition Spanish Edition in August 2026 
    • In the meantime, Guillermo will manage specific requirements with the DescriptionType config in the relevant local extensions.
•  .
• MAKE SURE THE FORUMS PAGE IS AVAILABLE TO ALL - Michael and others can't see it...
• .
• ALL AGREED
• .

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. /wiki/spaces/RMT/pages/131957934
      1. First Question is, in light of the new Module Storage Coordinator work that Peter introduced before, is the Package Composition data still useful?
      2. The next question is whether or not the distinction between "optional" and "mandatory" components is a useful one?
      3. .
3. In addition we have also received proposals to include the following New fields:

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

1. Removed fields:

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

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.

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

The Case For Removing Description Concept Non-Current Indicators

•  
• EVERYONE AGREED - WE NEED TO PUBLISH A FORMAL DEPRECATION PROCESS and then trial it ourselves using CNC Indicators!!
  • See above for Deprecation process review...

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

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

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

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.

• We therefore felt it appropriate to ask for REQUIREMENTS on the format, content and accessibility of the new Release Notes.
• Leong will present some options for you now...

RUN THROUGH OF PLAN, work done so far, and get feedback from 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? 

• MAIN QUESTION IS WHETHER OR NOT THIS MAKES ANY DIFFERENCE TO ANYONE??
  • As long as the effectiveTime is as expected, does it make any difference as to which day the actual publication happens, as long as it's BEFORE THE EFFECTIVETIME??
  • If it does make a difference to anyone, can we please discuss what Impact the publication date can have?
    • Does it help / hinder anyone to have specific publication dates, or does this have little impact?
•  
• DOES THIS WORK FOR EVERYONE?? CAN WE PROCEED AS PLANNED OR IS THERE ANY CRITICAL FEEDBACK????
•  
• FOR EXAMPLE, FOR EXTENSION MAINTAINERS - Would having the International Edition for 1st July published on 3rd July instead (if 1st July was a Saturday), have a large impact on timelines for upgrading extensions, etc??

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

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

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

Reuben Daniels (Unlicensed)

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!
  •  
• This will be therefore be rolled into the holistic discussions on Metadata in the new Metadata Working Group...
•  

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

  
  

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

1. • 1. 1. The SI Standards for Derivative packaging formats (and therefore the precedents set for all existing Releases such as MedDRA, GMDN, etc), are that we create packages that are inherently dependent on the relevant International Edition package (as per the MDRS). 

           These Derivatives are solely single refsets/maps, and so don’t mean anything to the end users without the supporting terms and other components from the International content. 

           This is why we have always created the metadata components (refset/module concepts, descriptions, relationships, etc) in the International content, and then made the Derivatives dependent on the relevant International Edition.

           Recently however, during the creation of the new EDQM maps, the question was raised as to whether or not we should change to include the metadata concepts in Derivative packages themselves, rather than in the International Edition.  This would not make them stand-alone (like the IPS sub-ontology for example), as they would still be dependent on the International Edition.

           However, as a Derivative with its own module there may be benefits of the package containing its own metadata concepts?

           The main benefit so far identified has been to avoid the situation experienced in the EDQM Alpha release:

           • the metadata for the EDQM product was published in the December 2022 International Edition,
           • and so the EDQM map content was upgraded in line with the December 2022 International content.   
           • the maps themselves however were not updated, and were still based on July 2022,
           • but the release itself was dependent on the December 2022 International Edition.  
           • this created a slight contradiction in terms of the map release which appeared to be based on December 2022, but actually the metadata itself was the only thing baselined on this release.  The content was only brought up to date with the July 2022 release.
           • Having said all this, the flip side is that if we just push the collaborators to request the metadata to be added to the International Edition at an earlier time, then this situation can also be avoided!

           HOWEVER, is it possible that the issue below 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??

           
           

           Changing the way we do things currently would take some work, and so would require a strong business case in order to 

           a) Change our standards

           b) Incur the cost of making the technical + release changes

           Thoughts on the original decision to package them in this way?

           • Everyone comfortable that this was the right decision at the time, but not anymore.

           Thoughts on the benefits/risks of refining this standard?

           • Consensus is that moving the Metadata components into the Derivative packages brings benefits to both the maintainers (SI + NRC's) + also to the end users, as it's easier than having to pull the metadata down from the dependent International Edition.
           • It doesn't have a huge impact however, as the end users still need to download and consume the relevant International Edition when using the derivatives.
           • The big benefit however, comes from combining this change with the new way of managing refsets in RT2 (see below for full details).  The inclusion of this metadata in the Derivative branches in Snowstorm (instead of in the INT branch)allows us to move the Derivatives into their own codesystems, and thereby allow us to retain the different dependencies of the Derivative products on older version of the INT Edition than it would do otherwise in the new world of RT2
             • (as things currently stand the Derivatives would have to be rebased against the LATEST INT Edition content whenever we need to promote them up to MAIN to publish them.  This would force us to bring the Derivatives up to date with the very latest INT Edition content just before publishing the Production Derivative releases, which would be April/October.  All users have confirmed this would be a huge problem for them as they're not yet ready to take multiple monthly releases of the INT Edition, and so desperately want us to retain the dependencies on the Jan/July INT Releases) 
             • Therefore we can continue to Publish the Derivatives in April/October (which is the earliest possible date for most of them because of the delays in collaborating with the external entities), based on the Jan/July INT Edition releases, exactly as the users want.
           •  
           • If we agree on moving the module concepts to the Derivative package(s), do we also need to remove them from the International Edition, in order to avoid duplicates when users implement them in conjunction with the International content?
           •  
           • EVERYONE IN AGREEMENT - 
           •  
           • SO ON RELEASE OF EACH NEW DERIVATIVE IN 2024 we need to:
             • • a) DEMOTE the various Derivative metadata components down from the INT Edition in the July 2023 Release
               •      (this would simply involve inactivating them all in the International Edition)
               • b) PROMOTE  them in the various Derivative packages in the Sept/October 2023 Derivative releases.
               •      (this would simply involve activating them in the relevant Derivative packages)
           •  
           • UPON FURTHER CONSIDERATION, WE REALISED THAT INACTIVATING THE INTERNATIONAL CONTENT IS UNNECESSARY, AND POTENTIALLY CONFUSING FOR END USERS.  This also removes the challenges involved with the timing of the demotions, which was going to be problematic either way - either creating active content in Derivatives first, or inactivating in INT first (which causes problems in the Browser)
           • THEREFORE THE NEW PLAN IS TO, ON RELEASE OF EACH NEW DERIVATIVE IN 2024:
             • a) LEAVE the various Derivative metadata components Active in the International Edition
             • b) ADD  the Active Derivative metadata components into the various Derivative packages in the 2024 Derivative releases
             • c) This results in covering off all use cases:
               • i) Users who just want to use the Derivative packages STANDALONE, have the relevant necessary Metadata in the Derivative packages
               • ii) Users who just want to query the International Edition can still see the Derivative metadata
               • iii) Users who want to continue combining the International + Derivative content before use, the Derivative Metadata records should naturally take precedence over the International records, due to the change of module + later effectiveTimes.
           •  EVERYONE happy with the new plan - only possible risk is that one set of the metadata (in either INT or the Derivative package) could potentially be updated without updating the other set and keeping them aligned.  This was agreed to be a very small risk however, as there is no reason to ever update this metadata without inactivating and recreating descriptions, etc
           •  
             • Andrew Atkinson TO IMPLEMENT ASAP AT THE SAME TIME AS MIGRATION TO RT2
               • TRANSITION BEGUN - PLEASE CAN EVERYONE REVIEW THE FIRST FEW PACKAGES CONTAINING THE NEW METADATA, IN ORDER TO ENSURE THAT IT'S IMPLEMENTED AS EXPECTED?
                 • GMDN - January 2024
                 • NCPT - January 2024
                 • MEDDRA - April 2024 (to be published at end of April)
                 • HPO - May 2024 (to be published at end of May)
                 • EDQM - May 2024 (to be published at end of May)
                 • ICNP - May 2024 (to be published at end of May)
                 • GP/FP - May 2024 (to be published at end of May)
                 •  
               • ****** WAS NOT POSSIBLE TO IMPLEMENT FOR THESE PRODUCTS AS THEY'RE STILL IN THE OLD FREESET FORMAT:
                 • IHE freeset - Jan 2024
                 • ERA Freeset - Jan 2024
                 •  
                 • SPANISH EDITION - Already contains 
                 •  
               • ANY FEEDBACK ALREADY FROM ANYONE ON IMPLEMENTATION OF THESE DERIVATIVES?????
               •  
               •  
           • DEMO EXACT CHANGES MADE IN GMDN IN MARCH:
             • Records taken from International Edition:
               • Concept
               • Description (x2) 
               • OwlExpression
             • Records NOT taken from Internaitonal Edition:
               • Inferred Relationship
               • Simple Map (as this is just CTV3 - no need to take that???)
             • ****** SHOW EVERYONE ACTUAL RECORDS IN FILES, ENSURE THEY'RE HAPPY WITH THEM (inc. Inferred output in GMDN after classifying - should we actually take the INT Inferred record into the GMDN package?) *******
           • +++++++ NCPT IN APRIL:
             • Records NOT TAKEN from International Edition AS THIS IS A FIRST TIME RELEASE, AND THEREFORE THESE ARE ALL BRAND NEW COMPONENTS:
               • Concept
               • Description (x2) 
               • OwlExpression
               • Inferred Relationship
               • Language Refset
           • +++++++ MEDDRA IN APRIL:
             • Records taken from International Edition:
               • Concept
               • Description (x2) 
               • OwlExpression
             • Records NOT taken from Internaitonal Edition:
               • Inferred Relationship
               •  
           •  
           • QUESTIONS:
             • Any issues with the new approach??  (eg)  VERIFY THAT THE FOLLOWING IS ACCEPTABLE AND NO ISSUES EXPERIENCED?:
               • 1. Reference of moduleID concept to itself (eg) MedDRA module concept (similar to how the Model Component Concept module is defined in the INT Edition) is part of it's own module:
                 • id    effectiveTime    active    moduleId    definitionStatusId
                   816211006    20240101    1    816211006    900000000000074008
                   
               • 2. Change of effectiveTime to 20240101 (or later) for inclusion in the Derivative package (standard operating procedure for Extensions (which these Derivatives are now effectively treated as), as although content is the same, module is changing)
               • 3. RETENTION of UUID's for components such as OWL records
   • Michael Lawley has objections - AAT to meet with him offline and work out if we need to change our approach...
     • After discussion, no objections were outstanding, so we're proceeding as planned...
     •  
   • NOW THAT WE HAVE IMPLEMENTED THIS, ANY FEEEDBACK?

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.

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.

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?

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?

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/

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 

• All of the above examples appear to fall nicely within the new "METADATA" definition for Annotations...
• Except, perhaps, for the last case??
• Thoughts??

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

• What validation, if any do we need?
  • MUST BE UTF8 compliant (and we need to lock down what we mean by this as means different things to different people - see Peter)
  • Existing refset validation for COMPONENT ID's (or UUID's) - (doesn't have to be Active, just EXISTING component)
  • non -empty Annotation validation
  • Andrew Atkinson to write up in tickets and request Dev work ASAP
• Anyone already have assertions they'd like to donate?

 John Snyder (Unlicensed)

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:
  • 
• Drilling down into the second level directory, we see that the base folder is duplicated:
  • 

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

• 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:
•  
•  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!!
  • .

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)

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.

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

   
   

This should help prove what barriers to adoption some of our implementors might face 

Andrew Atkinson  to Discuss with Alejandro and Kai to see if they can help - as this might be a good implementation team task?

Due to it coming to the end of its useful life, SNOMED International would like to propose planning for the deprecation of the CTV3 Identifier simple map (that currently resides in the RF2 International Edition package) as of the January 2020 International Edition. 

Some Member countries have already identified the reduction of the effectiveness of the product, and have already put plans in place to withdraw support for the CTV3 Identifiers from 2020 onwards. 

The TRAG therefore need to discuss whether or not there are any apparent problems with the proposed deprecation, and if so how they can be mitigated. 

We must also discuss the most effective method to pro-actively communicate out announcements to the community to warn them of the upcoming changes, in order to ensure that everyone who may still be using the Identifiers has plenty of notice in order to be able to make the necessary arrangements well in advance. 

Finally, we will need to decide on the best method for extricating it from the package, in order to ensure the smoothest transition for all parties, whilst remaining in line with the RF2 standards and best practices. 

• AAT CHECKED THE PREVIOUS IMPLEMENTATIONS OF DEPRECATION OF BOTH ICD-9-CM and RT Identifiers, AND AS THOUGHT BOTH WERE IN THE CORE MODULE, AND REMAINED IN THE CORE MODULE IN THE STATIC PACKAGES - SO ANY ISSUES WITH DOING THIS AGAIN?
• So the plan would be to follow the same deprecation process as we did with ICD-9-CM (ie)
  • move all of the content to a Static Package in July 2020, and inactivate all of the content
  • publish the reasons for inactivation in the historical associations
  • Release Notes similar to ICD-9 = SNOMED CT ICD-9-CM Resource Package - IHTSDO Release notes
  • CREATE A STATIC PACKAGE FOR CTV3 BASED ON THE JULY 2019 MAP FILES AND PUBLISH ON MLDS (and link through from Confluence link as well). ALSO LIFT THE CTV3 SPECIFIC DOCS FROM THE Jan 2020 RELEASE NOTES TO INCLUDE IN THE PACKAGE.
  1. Date of the files should be before the July 2020 edition (so say 1st June), in order to prevent inference of dependency on the July 2020 International edition
     1. So we set the effectiveTime of the Static package to be inbetween the relevant international edition releases (eg) 1st June
     2. This is to ensure that it's clear that the dependency of the Static package will always be the previous International Edition (here Jan 2020), and not continually updated to future releases
     3. It cannot therefore have an effectiveTime of July 2020 (as we would normally expect because we're removing the records from the July 2020 Int Edition) as this would suggest a dependency on the July 2020 content which doesn't exist
     4. It also can't have an effectiveTime of Jan 2020 as we need to distinguish between the the final published content which was Active in Jan 2020, and the new static package content where everything is Inactive.
  2. Inside the files should be all International edition file structures, all empty except for:
  1. Delta ComplexMap file needs to be cleared down (headers only), as no change in the content since the Jan 2020 files, so no Delta
  2. Full and Snapshot ComplexMap files exactly as they were in Jan 2020 release (including the effectiveTimes)
  3. ModuleDependency file needs to be blank, as CTV3 was in the core module (not in its own like ICD-10 is), and therefore the dependency of the core (and therefore the CTV3 content) module on the Jan 2020 edition is already called out in the Jan 2020 ModuelDependency file, and therefore persists for the static package too.
  4. Date of all of the files inside the package should be the new date (1st June)
  5. But all effectiveTimes remain as they were in Jan 2020
  6. Leave refsetDescriptor records as they are in the International edition
  7. RELEASE Notes Should describe all of the thinking we went through when creating this package, why the moduleDependency file remains blank, and why we’ve wiped the Delta, etc (see above)
• AND ALSO COMMS SAME AS WE DID WITH THE RT IDENTIFIER REFSET DEPRECATION:

  • RT Identifier Refset deprecation:

    We need additional comms around the July 2017 release, in addition to the usual Release Notes wording, in order to confirm what is happening and the rationale behind it.

    To re-iterate what was discussed on the previous call, Legal counsel confirmed that from a legal perspective, he doesn’t consider that it’s either necessary (or even advisable) for us to send CAP any further communications on this matter.  Legal counsel is confident that the informal discussions that we’ve already had with them (in order to remind them about what they need to do), are sufficient to cover our legal obligations, given that the licence is theirs and not SNOMED International's.  Therefore we no longer need to send a formal letter to CAP.

• Has anyone identified any issues with the proposed deprecation?

  • If so what?

• Is everyone still in favour of the refined process to use to deprecate??
  

• If all good then Andrew Atkinson to begin formal deprecation process

Maria Braithwaite

In our last TRAG meetings several people confirmed that many people within the community were asking for more information on our transition to Frequent Delivery - therefore it was requested that we create a presentation on how the migration went, benefits realised, lessons learned, etc

• Maria and Andrew to Present findings on our transition to Frequent Delivery:

• Processes transitioned
  • This is the benefits of the transition so far
            - [ ] 1.  These are the issues we faced
                - [ ] a)  This is how we resolved them
            - [ ] 2.  This is how we see the future going - improvements + benefits
• Lessons learned
• Questions?

• We could setup a blog post with Kelly (similar to Jim's on collaborative authoring - https://www.snomed.org/news-and-events/articles/embracing-collaborative-authoring) that would be based on this presentation...
  • Would this be helpful to people? 
• FEEDBACK ON PRESENTATION:
  • Would be useful to add Example monthly cycle for Authoring team in terms of Dates for cut off's, delivery, etc
  • Would be great to clarify how often the authors have to "unpromote" concepts from MAIN because of conflicts, etc?
  • Mapping - no impact moving to keeping up with monthly cycles - useful to specify this so people aren't guessing?

1. USER DOCUMENTATION
   • Several end users have contacted Guillermo to request more information on the transition to more frequent delivery (and/or more frequent updates to the dependent content of both extensions and derivatives).
     1. It would be great if we could provide people with a white paper or presentation (both from a Content and Technical perspective) on 
        1. How the transition went
        2. Benefits realised
        3. Lessons learned
        4. Risks
        5. etc
   • This should be targeted at both the Supplier level + the end users level for max effect
   • Does the presentation myself and Maria gave cover this?  Or could we add an area on the website??
   •  
2. RELEASE NOTES
   • Can translators please have more detailed release notes - automated to the extent of having EACH component change listed out?
   • We need to be able to automate the generation and publishing of the Release Notes -
     1. this work is still underway, but will take quite awhile for the Dev team to complete....
   • NEW REQUIREMENTS FOR SONJA:
     1. Option for detailed release notes as well as the standard level for all Releases (as per Guillermo's requirement above) - either in the RNMS (preferable) or in the Delta Generation Tool?
     2. It would be great to also link each Component change to the relevant high level change note in the official Release Notes as well (eg)
     3. Release Notes March 2023:
        1. Drugs Changes:
           1. Component 1 changed
        2. Anatomy changes:
           1. Component 1 added
           2. Component 2 removed
           3. Component 3 changed
        3. Quality Initiative:
           1. Component 1 changed
           2. Component 2 inactivated
     4. INFRA-8739 RAISED
        1. RNMS-65 created to track development
     5.  
     6. Explicit annotations in the Release Notes to that each component change in the Delta period is linked to a specific Template
     7. INFRA-8740 RAISED 
        1. RNMS-100 created to track development
3. DELTA GENERATION TOOL
   • Has anyone trialled the Delta File Generation Tool as yet?  Any feedback?
   • YES GABOR HAS TRIED IT AND FED BACK ISSUES TO PETER - PETER IS STILL WORKING ON IMPROVEMENTS SUCH AS THE Snowstorm issue whereby if there are multiple different states for the same component withint the Delta period, snowstorm loses the history of all those changes and just spits out a (random) one line state!  So if a concept has started active, been inactivated and then reactivated in the Delta timeframe, snowstorm might decide to spit out active or inactive as the latest state!  It will also lose those 3 changes and only export one change!
   • UPDATE ON THIS WORK:

     • "...the problem here is more with the Terminology Servers not being able to deal with deltas that contain more than one state for the same component than it with with the DGT itself.   

     • However we added a flag to the tool (see https://github.com/IHTSDO/delta-generator-tool/releases/tag/1.2.0 ) so that you can generate output that will contain multiple effective times, but only the most recent effective time for each component.   This is a workaround that means your TS does not end up with the correct Full file representation.

     • So really the only additional work would in theory be in Snowstorm so that it can treat deltas as successive updates to the Full file and generate release branches as it needs to.  However so far this has not been raised as a requirement by the community, and so is not planned work...

   • DO WE NEED FURTHER ENHANCEMENTS, OR NO APPETITE FOR THIS?? 
     • a)  Delta's to be generated from any point in time to any other point in time
     • b)  Metadata to be included somehow (to be discussed further in the Metadata Working Group) to record critical information, such as which Dates the Delta is from + to, which Modules are incorporated, etc
     • c)  Compound Delta's (including ALL changes since the relevant date, including ALL changes in the dependent release package(s), rather than just the latest state - so these are "Full file to Full file" Delta's, as we are used to) are favoured so far, however we should continue to assess any potential use cases for Atomic Delta's (effectively "Snapshot file to Snapshot file" Delta's) as we go along, in case it becomes apparent that there is a valid Business Case to ensure that the new Delta generation tool can provide either or both of these Delta file types...
     • d)  It needs to support the future requirements for Service Based delivery, once we transition over
     •  
4. VALIDATION advances:

   • OWL testing - anyone worked on this as yet?

   • Template validation - thoughts?

   • Implementation testing feasible? (see Implementation Load Test topic below)

   • Need to identify Modelling areas that need improving - for example where concepts have 2x parents, this is usually an indication of areas that need re-modelling
   • Need automation of the QA system itself - so some quick way to validate RVF + DROOLS Assertions, both old + especially new!
   • Whitelisting - API required?
   • Specific extensions to the automation Validation scope (eg)
     • New idea for an RVF assertion regarding the ordering of OWL records (based on first concept) with disjoints:
   •  
5. Critical Incident Policy update
   • We need to refine the Critical Incident Policy:
     • Need to ensure categorisation is solid (as otherwise requests may be made for minor issues to be fixed immediately as "Critical Incidents" just because it impacts one institution (but not Internationally))
     • Currently Content Team critical incident policy states:
       • If it's a Clinical Risk then it has to be fixed
       • OR if it's not a Clinical Risk but impacts certain number of members etc then still Critical, etc
   • April 2023
   • What other criteria do we need to use?
   • How strict should we be with the criteria?
     • We need to balance the risk of NOT fixing an issue vs the risk of impact to a stable Release candidate from the fix...
   • As discussed yesterday, we should keep the policy flexible on the solution that will need to be implemented in order to resolve any critical incidents:
     • The best solution is simply to mark the Release in question as "Invalid" and advise all users to download the next stable Release
       • However, can we reliably contact all users who've consumed a Release, given all the possible end users who've downloaded it via NRC's as well as direct from MLDS?
     • We should only use Negative Delta files and other potentially confusing and destructive techniques if there is no other option (eg) Critical Legal Incidents.
   • Any useful lessons learned from anyone else's Critical Incident Policies?

Potential Improvements:

1. USER DOCUMENTATION
2. RELEASE NOTES
3. DELTA GENERATION TOOL

4. VALIDATION advances:

5. Critical Incident Policy update

Dion McMurtrie

Dion McMurtrie

CSIRO have been working on improvements to the RVF, and would like to report on and discuss some of the results with us...

• Dion to Present current status + plan...
• Comments and feedback welcomed...
  • Plenty of feedback and so further discussions required as we move through the project...
• The main feedback for the past few months has been the RVF failures for the new MDRS assertions, which appear at first glance to be false positives.  However, they have been proven to be valid failures, as long as you consider that the MDRS format itself is (and has always been) inherently flawed.
• The closure of this topic is therefore dependent on the outcome of the discussions on the Proposal for a complimentary file to the MDRS - the "ECRS" ("Edition Composition Reference Set")
  • If this concludes that we need to change the MDRS, then this RVF topic can be closed down.
  • If, however, we decide to retain the MDRS format, then we need to revisit these RVF assertions...
• We need to use the new planned changes to .JSON metadata file:  /wiki/spaces/RMT/pages/131957934 in order to fix the RVF assertions and remove the false positives...
  • FRI-169 - Getting issue details... STATUS
•  
• QUESTION FOR DION/MICHAEL - CAN WE JUST REFINE THE .JSON FILE (as per the proposals here:  /wiki/spaces/RMT/pages/131957934)  IN ORDER TO ALLOW THE MDRS ASSERTIONS TO WORK PROPERLY FOR NOW????
• YES, but the question is how best to do this?
  • We need to work together to create examples of how we might extend the JSON file to include more useful data, both for the a) users b) syndication + c) to allow the MDRS assertions to work as expected for SI Products.
  • Examples to be added here, and assessed by the TRAG at a later date:
    • /wiki/spaces/RMT/pages/131957934
• NEED TO ADD EXAMPLES OF EACH USE CASE + SAMPLE MANIFESTS - This will not only help with MDRS assertions, but also Syndication info...

This topic was closed down by the TRAG a few years ago due to the lack of requirements vs the complexity of finding a robust solution.

However, new requirements and a potential solution from Ed Cheetham have now been submitted for our review and discussion - please see here for details: Refset containing the semantic tags?

We will discuss in detail in the next TRAG meeting in April, however please feel free to contribute to the online discussion in the above link in the meantime.

• Slide deck here for advanced review:
  • SemanticTags20220326.pptx
• Feedback from the group:
  • Excellent identification of issues that need addressing
    • The first target should be to discuss the application of the Validation that Ed has kindly brought to us, both in the AP + Release validation stages.
    • The second sim is to bring the discussions on the potential Formalisation of the Semantic tags to the relevant AG's for furhter consideration
      • EAG
      • MAG
      • CMAG
      •  
      • Discussion in the chat to be found here:  meeting_saved_chat.txt
      •  
• Yong has kindly agreed to add this to the agenda for the next MAG meeting, to be discussed further.....
• UPDATES FROM THE MAG???

Jim Campbell 

Dion McMurtrie

Question here is whether or not RefsetDescriptor records themselves should remain active for retired reference sets?

TRAG to decide on correct policy and feedback to Matt...

• The consensus so far is that we should keep the RefsetDescriptor records themselves active, which has been the precedent for all cases in RF2 history so far, with the exception of the Non-human refset which was physically removed from the International Edition package.
• The UKTC and others have previously requested these RefsetDescriptor records to be inactivated ( ISRS-112 - Getting issue details... STATUS , etc) - for consistency purposes, but the corollary of this is that the refset structure itself (which the refsetDescriptor describes) remains valid and active, despite the refset itself having been inactivated.
• TRAG TO DISCUSS AND AGREE BEST SOLUTION...
  • Then propose an addition to the TIG to provide clear guidance on this for all users...
  • AGREED:
    • Happy to leave the RefsetDescriptor Active for all normal circumstances
    • If we're removing the Refset entirely from the Extension/Edition, we should 
      • a) if it's just for space or something, then leave refsetDescriptor record in place
      • b) if it's for CRITICAL INCIDENTS ONLY (and even then only certain subsets of this - most likely only legal issues), we'll remove RefsetDescriptor completely
    •  
    • Matt Cordell  to write up and send to all of us for review.... confirmed on 20/04/2021 that Matt will write this up and present to the TRAG in future meetings
      • we will then incorporate the new conventions into the TIG and other documentation in order to ensure consistent approaches for all users going forward...
      • Matt has written this up now for review:
      • https://docs.google.com/document/d/1c4HcqhRs0OC_uDG_R8ZTPc44HzVjKBK3lrmB1iCSPoU/edit?usp=sharing
      • Matt to present and discuss...
      •  
    • FINAL DECISIONS:
      • Matt Presented - no contentious points, so Matt is ready to take this proposal further...
      • UPDATES FROM MATT???

RVF has now been open sourced to allow people to contribute towards it more easily, so that Implementation issues can be reverse engineered into the assertions. All of the NRC validation systems should remain separate, in order to ensure as great a coverage across the board as possible.

However, it makes sense to ensure the critical tests are included in all systems, in order to ensure that if, say, one NRC doesn't have the capacity to run Alpha/Beta testing for a certain release, we don't miss critical checks out. We are working on this in the Working Group, and also in the RVF Improvement program, where we are including the DROOLS rules, etc. These are also being incorporated into the front end input validation for the SCA.

TRAG to therefore discuss taking the Implementation Load test forward, including the potential to incorporate key rules from NRC validation systems into the RVF. So we should discuss the tests that are specific to the Implementation of vendor and affiliate systems, in order that we can facilitate the best baseline for the RVF when agreeing the generic testing functionality in the Working Group.

• Matt Cordell will promote some useful new ADHA specific rules to the RVF so we can improve the scope... report back in October 2019
• Chris Morris to do the same - get the RVF up and running and then promote any missing rules that they run locally.... report back in October 2019
•  
• THIS NEEDS TO BE CONSIDERED AS PART OF THE OVERARCHING Shared Validation Service PROJECT GROUP
• Anything we can add to the Shared Validation Service going forward?
•  

TRAG to review and provide final feedback.

Reuben to provide feedback on progress of the URI specs + FHIR specs updates...

• Document updated by Andrew Atkinson in line with the recommendations from the last meeting, and then migrated to a Confluence page here: /wiki/spaces/RMT/pages/131957197
• To be reviewed in detail by everyone, and all feedback to be discussed in the meetings. AS OF OCTOBER 2017 MOST PEOPLE STILL NEEDED TIME TO REVIEW THE DOC - Andrew Atkinson INFORMED EVERYONE THAT THIS DOCUMENT WILL BE ENFORCED AS OF THE JAN 2018 RELEASE AND THEREFORE WE NEED REVIEWS COMPLETED ASAP... so now need to check if reviews still outstanding, or if all complete and signed off??
• AAT to add in to the Release Versioning spec that the time stamp is UTC
• AAT to add the trailing "Z" into the Release packaging conventions to bring us in line with ISO8601
• AAT to add new discussion point in order to completely review the actual file naming conventions. An example, would be to add into the Delta/Full/Snapshot element the dependent release that the Delta is from (eg) "_Delta-20170131_" etc. AAT to discuss with Linda/David. Or we hold a zero byte file in the Delta folder containing this info as this is less intrusive to existing users. Then publish the proposal, and everyone would then take this to their relevant stakeholders for feedback before the next meeting in October. If this is ratified, we would then update the TIG accordingly.
• AAT to add in a statement to the section 4 (Release package configuration) to state that multiple Delta's are not advised within the same package.
• AAT to add in appendix with human readable version of the folder structure. Done - see section 7
• IN ADDITION, we should discuss both the File Naming convention recommendations in the Requirements section (at the top of the page), PLUS Dion's suggestions further below (with the diagram included).
• Dion McMurtrie to discuss syndication options for MLDS in October 2018 - see hwat they've done (using Atom) and discuss with Rory as to what we can do. Suzy would be interested is this as well from an MS persepctive. UK also interested. This shouldn't hold up the publishing of the document. Discussions to continue in parallel with the creation of this document...
• Reuben Daniels (Unlicensed) to raise a ticket to update the fhir specs accordingly
• Reuben Daniels (Unlicensed) to talk to Linda to get URI specs updated accordingly.
• URI Specs to be updated and aligned accordingly - Reuben Daniels (Unlicensed) to assist
• EVERYONE TO REVIEW TONIGHT AND SIGN OFF TOMRORROW
• ONLY outstanding point from earlier discussing was Dion's point from the joint AG where he talked about nailing down the rules for derivative modules... -
• Dion McMurtrie to discuss/agree in the October 2018 meetings - REPORT FROM DION??
  
• Everyone is now happy with the current version, therefore Andrew Atkinson to publish - we can then start refining it as we use it.
• Andrew Atkinson to therefore agree all of the relevant changes that will be required as a result of this document internally in SNOMED International, and publish the document accordingly.
• FIRST POINT WAS THEREFORE TO have it reviewed internally by all relevant stakeholders...
  • This has been completed and signed off
• Do we consider anything in here needs to be incorporated into the TIG?
  • or perhaps just linked through?
  • or not relevant and just separate? YES - NOT RELEVANT!!
  • the litmus test should be whether or not implementers still use the TIG, or whether people now use separate documentation instead?
    • ??????????
• We also need to make a decision on the final Freeset distribution format(s), as I want to ensure we only have a MAXIMUM of 2 distribution formats - RF2 + the agreed new Freeset format (whatever that may be)
  • YES everyone is happy with this!
  • Add this into the Release Packaging Conventions and publish
• APRIL 2021 - DO WE NEED TO MAKE ANY REFINEMENTS IN ORDER TO PREPARE FOR CONTINUOUS DELIVERY? Did ADHA need any formatting changes when moving to monthly?
  • No, nothing beyond the new .json file and refinements to that 
  • We really need to tackle the Delta from and to release version in the Delta file naming, and possibly package file naming. At the moment it is impossible to know what a Delta is relative to making it hard to safely process it. Perhaps beyond the scope of this document, but quite important
    
    • THIS IS NOW ADDRESSED IN THE NEW Metadata file:
      • 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
      • January 2021 International Edition metadata file:
        • release_package_information.json
      • March 2021 Belgium Extension metadata file:
        • release_package_information.json
      • DOES IT NOW COVER EVERYTHING NEEDED???
        • No!  We'll continue to discuss and agree ideas for new fields in this file as we progress towards Frequent Delivery....
        • This will therefore be rolled into the holistic discussions on Metadata in the new Metadata Working Group...
  • 
    
• THIS NEEDS TO BE CONTINUALLY REFINED OVER THE NEXT YEAR WHEN WORKING TOWARDS MORE FREQUENT DELIVERY:
  • Once all happy, the document will be published and opened up to anyone to view.
    
  •  
• Everyone was invited to either join the Working Group, or contribute ideas towards it - we will therefore continue to report back on how this is going...
•  

This document was reviewed in detail and all feedback was discussed and agreed upon - new version (v0.3) is available for review, attached to the IHTSDO Release Management Communication Plan review page.

AAT has added in details to state that we'll prefix the comms with "Change" or "Release" in order to distinguish between the type of communications. See version 0.4 now - IHTSDO Release Management Communication plan v0.4.docx

Once we've collated the feedback from the revised comms processes that we've implemented over the past year (in the items above), we'll incorporate that into the final version and discuss with the SNOMED International Executive Lead for Communications (Kelly Kuru), to ensure that it is aligned with the new overall Communication strategy. Once complete, the Release Management comms plan will be transferred to Confluence and opened up for everyone to view.

We have publicised the Release Management confluence portal to both NRC's and the end users to get people to sign up as and when they require the information. Do we know of anyone still not getting the information they need?

We also agreed last time that the community needs more visibility of significant, unusual changes (such as bulk plural change, or case significance change). These changes should be communicated out not just when they're assigned to a release, but actually well in advance (ie) as soon as the content team start authoring it, regardless of which future release it will actually make it in. I have therefore created a new Confluence page here: January 2020 Early Visibility Release Notices - Planned changes to upcoming SNOMED International Release packages

I've left the previous items up (from the July 2017 International Edition) because there are no examples yet from the Jan 2018 editing cycle - so please take a look and provide feedback on whether or not this is useful, and how it can be improved.

• ACTION POINT FOR EVERYONE BEFORE OCTOBER 2018: (Dion McMurtrie, Matt Cordell, Orsolya Bali (Unlicensed), Suzy Roy, Former user (Deleted), Former user (Deleted), Mikael Nyström (Unlicensed), Chris Morris)
  The final version of the communication plan needs to be reviewed by everyone and any comments included before we agree the document internally and incorporate it into our communication strategy
• Suzy Roy will discuss the end use cases of her users with them and come back to use with feedback on the practical uses of SNOMED CT and any improvements that we can make, etc 
• We may now also need to add a new section in here wrt the comms for the TRAG, so that this is standardised and agreed with the community? Or is it outside of the scope for the Release Communication Plan? This was felt to be out of scope, and should this be restricted only to communication related to actual releases of products.
  
• Everyone is now happy with the current version, therefore Andrew Atkinson to publish - we can then start refining it as we use it.
• Andrew Atkinson to therefore agree all of the relevant changes that will be required as a result of this document internally in SNOMED International, and publish the document accordingly.
• AAT MIGRATED THE DOCUMENT FROM WORD TO CONFLUENCE, AND THEN SENT IT TO THE EPS Team for first review.....
• The feedback has been incorporated and the document refined accordingly.
• IHTSDO Release Management Communication Plan review
• Andrew Atkinson has now sent to the relevant members of the SMT for final sign off....
  • This has now been signed off and is ready for publication
• Do we consider anything in here needs to be incorporated into the TIG?
  • or perhaps just linked through?
  • or not relevant and just separate?
    
  • the litmus test should be whether or not implementers still use the TIG, or whether people now use separate documentation instead?
    
•  
• THIS NEEDS TO BE CONTINUALLY REFINED OVER THE NEXT YEAR WHEN WORKING TOWARDS FREQUENT DELIVERY:
  • Do we need more Communications over the first few months to ensure that everyone knows what's going on? 
  • Or do we actually need LESS now that we have regular, monthly releases?
  • Once all happy, the document will be published and opened up to anyone to view
    
  •  

Harold would like to introduce this topic for discussion...

• Language refset conflicts are not yet resolved - Linda has been discussing this in terms of how to merge Language refsets or dictate whether or not one should override the other in cases of multiple language refsets - in the UK they combine them all into one but this is not ideal either. In translation situations they use the EN-US preferred term as the default where there is no translated term in the local language. Perhaps we need to do a survey on the members and who's using what how.
• Suzy Roy (or Former user (Deleted)) to get Olivier's initial analysis and come back to us on what worked and what didn't, and we can take it from there.
• Suzy would like to ask Matt Cordell if he can share his ppt from his CMAG extensions comparison project.
  
• Matt Cordell will distribute this to everyone for review before the April 2019 meeting.....
• Harold to continue analysis and report back with the results of reviewing the specific examples that Olivier identified in the next meeting....
• 
  
• Can you please present the revisited presentation Matt Cordell ?
•  

Dion McMurtrie completed the Alpha release - did anyone have chance to review it? (I haven't had any requests for access to the remainder of the package)

The subject of Modularisation needs to be discussed between the various AG's who are considering the topic, before we can proceed with the Release-specific sections.

We need to discuss any red flags expected for the major areas of the strategy:

1. Modularisation
2. Members who want to abstain from monthly releases, and therefore need to use delta's with mulitple effective times contained within.
3. Also need to consider if we continue to hold the date against the root concept - works perhaps still for 12 monthly releases, but not necessarily for continuous delivery daily!
4. THIS NOW BECOMES CRITICAL TO THE STRATEGIC DIRECTION WE DISCUSSED IN TERMS OF MODULARISING OUR CONTENT, AND IMPROVING THE WAY THAT THE MDRS WORKS, IN ORDER TO ALLOW RANGES OF DEPENDENCIES. THIS WILL ALLOW THE "UNIT" OF RELEASE TO BE REFINED ACCORDING TO THE RELEVANT USE CASES.
5. Understand the Use cases thoroughly, and refine the proposal doc to provide people with more real information - Dion McMurtrie TO PROVIDE THESE USE CASES FOR Andrew Atkinson TO DOCUMENT
6. Does the POC allow for concepts to be contained within multiple modules? NO - BUT DION CAN'T THINK OF ANY CONCRETE EXAMPLES WHERE THIS WOULD BE NECESSARY
7. What about cross module dependencies? Michael Lawley's idea on having a separate Module purely for managing module dependencies
8. IN THE FINAL PROPOSAL, WE NEED TO CREATE A NESTED MDRS TO MANAGE THE INTER-MODULE DEPENDENCIES (as per Michael's comments)
9. NEED TO PROVIDE GOOD EXAMPLES AND WHITE PAPERS OF THE USE CASES FOR MODULARISATION IN ORDER TO ENGAGE OTHERS...
10. 
    
11. AFTER SIGNIFICANT DISCUSSION AND CONSIDERATION, THERE ARE NO VALID USE CASES LEFT FOR MODULARISATION. IT CAUSES A LOT OF WORK AND POTENTIAL CONFUSION, WITHOUT ANY TANGIBLE BENEFIT.
12. THE PERCEIVED BENEFIT OF HAVING A WAY TO REDUCE THE SIZE/SCOPE FO RELEASE PACKAGES IS BOTH a) invalid (due to everyone's experience of being unable to successfully do anything useful with any small part of SNOMED!), and b) easily answered by tooling that using the ECL to identify sub-sections of SNOMED to pull out for research purposes, etc.
13. THEREFORE AS OF APRIL 2018 THE FEEDBACK FOR RORY AND THE STRATEGY TEAM WAS THAT MODULARISATION SHOULD NOT BE IMPLEMENTED UNLESS A VALID USE CASE CAN BE IDENTIFIED.
14. HOWEVER, KNOWING THE HISTORY OF THIS ISSUE, THIS WASN'T NECESSARILY GOING TO BE THE FINAL WORD ON THE MATTER, SO IS EVERYONE STILL SURE THAT THERE ARE NO KNOWN USE CASES FOR MODULARISATION?? (eg) linking modules to use cases, as Keith was talking about with Suicide risk assessment in Saturday's meeting,etc??
15. This topic came up several times again during other discussions in the April 2019 meetings, and it was clear that people had not yet given up on the idea of Modularisation - we therefore need to discuss further in October 2019....
16. Agreed to see where the linked discussions in the MAG etc end up going, and then discussing the proposals rather than just in abstract....
17. UPDATES FROM THE MAG???

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:
  • /wiki/spaces/RMT/pages/131957217
    
  • 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
  •  
• UPDATES FROM THE MAG???

Jim Case +

Suzy Roy

This is a subject that would be helpful to include Jim in the discussions, as he has some definite opinions on how to improve the metadata in this area. 

Some suggestions would be to make more detailed information available for authors to describe their reasons for inactivation (especially in those areas where currently they are forced to use inactivation reason codes that aren't completely representative of the reasons in that instance).

Adding Jim Case - for further discussion later...

• TRAG to discuss with Jim in the next conference - in conjunction with linked discussions such as Computer readable metadata, Potential for adding a "withdrawn" reason for inactivated content, etc
•  
• Jim to comment on whether or not the EAG have agreed anything on this as yet?