Hi Matt Cordell Dion McMurtrie Michael Lawley Alejandro Lopez Osornio Mounir Bouzanih Patrick McLaughlin Mikael Nyström Stuart Abbott Gábor Nagy Reuben Daniels 

There are several options for managing the Language code -

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

• Please provide feedback asap before the next TRAG meeting in October, so that we can try to unblock development.  thanks!
• Decision made to use the "@[language]" (eg. "@en") in the "annotationValue" field
• ***** BUT THEN THE MAG JUST MADE A NEW (unanimous) DECISION - TO REMOVE ALL LANGUAGE CODES FROM THIS IMPLEMENTATION (as they're extraneous at present, and no valid use case is apparent at present)
• Any other major concerns with the decision made to remove the language code completely?
  • YES - Mikael has strong objections so we took a vote and adding a new Column (which would be empty (NOT null) when not required) won 8 votes to 5
• Changes upcoming  (within next few months):
  • Dialect added to Language column
  • Changes to refsetDescriptor
  • Upcoming content in future INT Releases

All

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

MAIN POINTS:

• The International Derivative releases have always been dependent on Jan/July, in order to align with the fact that most end users still only take the Jan/July releases, and not the other monthly releases.
• The new RT2 integration with snowstorm branches greatly improves the quality, because it allows the authors to run full validation against the new derivative content BEFORE promoting, thereby allowing identification + fixing of most issues before they hit the Release cycle. (eg)
  • MAIN/Refsets/GPFP,   MAIN/Refsets/ICNP,  etc
• However, in order to actually RELEASE these derivative products, we’ll need to Promote the Refset content up to MAIN/ (as the metadata content is in the International Edition, and we can’t currently export content from multiple snowstorm branches into SRS for the same release, just from one branch)

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

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

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

OPTIONS:

1. BEST option appears to be to allow the Derivative refsets to be dependent on the month prior to that in which they're Published (eg) March/September for most derivatives.
2. However, is it possible that if we were to make a different decision on the item above, then this issue in the RT2 release process could also be mitigated by moving the metadata into the Derivative packages themselves?  If we did this, could we potentially then retain the Derivative content in the Refsets' child branches and release from there?

   (eg) 

   • For GPFP we would maintain the content via the RT2 FE which would read/write to MAIN/Refsets/GPFP
   • Given that we would then also include the Module + other metadata in the same branch (instead of in MAIN),
   • ...Could we then version say into MAIN/Refsets/GPFP/2023-04-30, and Release straight out of that branch??
3. The final option is moving to Monthly releases for Derivative products as well - however:
   1. This is problematic from a capacity/practical point of view, and
   2. This would require significant discussions with all of our collaborating entities to sign off on new agreements (for those who have tangible inputs into the process), including monthly deadlines, etc - This could not be achieved quickly so would need to be discussed with 2024 in mind at the earliest. 
      1. The alternative to this would be to move just SOME of the derivatives (the straightforward refsets for example which don't require much/any external collaboration) to monthly schedules, and keep the others on annual/6 monthly schedules.
      2. However, this would be a significant operational issue, as the processes are already complex enough without introducing further complexity in terms of different derivatives runing on completely different processes.

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

• Option 1
  • No-one is in agreement with this option!
  • This would cause real problems for NRC's (let alone end users) who would struggle to keep up with downloading and consuming multiple monthly releases.  In addition, they wouldn't be able to then publish multiple releases of their own to the end users, containing the usual Jan/July changes + then extra releases for each month that is a dependency for the Derivative releases.
  • Finally, many of the entities doing Translations are struggling enough to keep up with the pace, without adding additional stress and complexity.  This option would therefore completely prevent them from consuming any of the Derivative products.
  • This Option is a non-starter.
•  
• Option 2 
  • The Pro's are far greater here - as all of the users who can't keep up can continue to download just the Jan/July INT Edition releases, and then consume whichever Derivatives they need.
  • Andrew Atkinson  to put forward this proposal, which would be to:
    • a) MOVE all of the Derivative content in Snowstorm from the INT Edition branch into their own Codesystems (checked with Rory and Terance and should not be a problem)
    • b) CHANGE RT2 to use the new individual codesystem branches for reading + writing each Derivative content to and from RT2 (checked with Brian and Rick and should not be a problem)
    • c) 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)
    • d) 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)
    • e) THEN EACH CYCLE WE WOULD:
      • i)  Upgrade each Derivative Codesystem to the relevant Jan/July INT content
      • ii) FREEZE the content in each of those "in flight" codesystems, to prevent any more re-basing until the Release cycle is complete
      • iii) VERSION in each relevant Derivative Codesystem
      • iv) RELEASE from each relevant Derivative Codesystem
  •  

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

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

The Case For Removing Description Concept Non-Current Indicators

• The key points of the proposal that are salient to our group are:
  • TODAY                                   = Discuss whether or not there are any known users still using the CNC indicators?
  •                                                  = Discuss whether there are any valid use cases still in existence to retain them? (whether in use or not)
  •                                                  = Are there any dissenting arguments against the assertion that CNC indicators are completely
  •                                                    obsolete, and that it's more efficient and reliable to determine the relevant Concept's state from the
  •                                                    Concept record, rather than from the AttributeValue record?
  •                                                 = Are there any dissenting arguments against the assertion that CNC indicators cause additional work
  •                                                    for all creators of SNOMED CT content, in terms of maintenance, packaging and validation?
  •                                                 = Are there any dissenting arguments against the assertion that the removal of CNC indicators 
  •                                                    will serve to simplify the understanding of SNOMED CT, + help to lower barriers to adoption?
  •                                                  = Discuss any impacts to the terminology, or to any users, when removing the CNC indicators?
  •                                                    (beyond our internal impact, which is restricted solely to removing/simplifying existing code)
  •                                                  = Discuss who, if anyone, we should specifically target for feedback on the proposal?
  •                                                 = Agreement in principle of the deprecation of CNC indicators by the TRAG.
  •  
  • PROPOSED TIMELINE (updated)
    • May 2024                               = Publication of an official Notice of Deprecation, and request for feedback -
      • • • • • • • • • WHAT WOULD WE LIKE TO INCLUDE IN THIS TO ENSURE FULL VISIBILITY???
    •                                                     a)  Inclusion of this proposal in the "Early Visibility" notes????
    •                                                     b)  notes in the RF2 Specification?????
    • Just mark the specification as "this content is being deprecated" but keep the spec around for some time for those lagging...
    •                                                     c) the exact plan
    •                                                     d) proposed timelines
    •                                                     e) consultation period 
    •                                                     f) feedback channels, etc. 
    •                                                     g) Specifics for this deprecation - (eg) whether or not the final plan included complete removal of the 108mb of data after say 12-18 months after inactivation?
    •                                                    At this stage, no changes will be made to any products or systems.

    •                                                    Changes should be considered to Editorial Guidance and Educational Changes?

    • July 2024 INT Edition         = Inactivation of all existing CNC indicators,    
    •                                                          + Removal of all code creating new CNC indicators
    •                                                          + Removal of all code relating to the display and validation of CNC indicators
    • January 2025                       =  Removal of all code relating to the display and validation of CNC indicators, except in the most general structural tests for refset members eg that a referenced component id exists.
    •                                                     + Inactivation of the 900000000000495008 |Concept non-current (foundation metadata concept)| concept. 
    • Future                                     = We’re not at any point suggesting surgical extraction of the historical CNC indicators (using negative delta's or any other such mechanism!)  Just inactivation and keeping them static in perpetuity after that.
    • HOWEVER, given that they consume 108mb of the International Edition, is there an argument for complete removal?
      • YES, we can inactivate them for 6-12 months then REMOVE these records COMPLETELY (not AttributeValue files)
      • WE SHOULD ALSO REMOVE THE ENTIRE STATEDRELATIONSHIP FILES WHICH HAVE BEEN INACTIVATED FOR 5 years or so now
        •  
        • YES AGREED - LET'S MOVE IT INTO A STATIC PACAKGE ON MLDS AND KEEP IT SEPARATE.
        • WE SHOULD PROBABLY GIVE THE USERS 6 MONTHS NOTICE FOR COMPLETE REMOVAL
        •  
    • Andrew Atkinson  TO WRITE UP SOME COMMS AND SEND OUT ONCE TRAG HAVE FORMALISED PROPOSAL....
    •  
    • WE SHOULD ALSO DESIGN AND AGREE A TEMPLATE FOR FUTURE DEPRECATIONS - previously it's just been ad-hoc - but would be useful to always include the information that you consider critical for full visibility (eg)
      • SEE NEW DEPRECATION TEMPLATE.... 
        • Rationale (at least a summary paragraph) - or a link to the original Discussion which details the reasons behond it
          • But we need to consider document archiving in this respect as well, in order to keep current docuemntation clean.
        • Best early visibility notificaiton channels:
          • Member Forum Briefing Note - INITIAL statement to say "we have decided to deprecate this..."
          • Once MF confirmed okay - send confirmation out to:
            • Release Management email channels
            • Release Notes (early visibility for several months first)
          • Proposed timelines
          • Feedback channels (google form etc) for them to provide critical feedback if necessary
          • Feedback period needs to be formally cut off - say 2-3 months before implementation time, to allow us to take any action if required.
          • Documentation - Release, RF2, Ed guides, education etc
            • RF2 Spec can retain info on the components being deprecated, and state why they were removed
            • Can also provide a timeline for when they were inactivated + then subsequenetly removed
            • Can also provide a link to the new locatin where the Static data is being held forever
          • Potential Impacts to users:
            • (eg) If the Release Package suddenly becomes much smaller or larger - then tell people why so that they aren't suprrised and consider it to be an error
            • (eg) Changes to structure or format of the Release package - this could break hard coded upload routines
              • WE agreed NOT to leave empty files (with just headers) in the package as this is messy and also incurs an education overhead to explain to people why the files are there but empty!
          • Historical audit trail of changes 
            • Something that says "in 2018 we inactivated all Stated Rel's and created OWL files', in 2024 we intriduced new annotations files, etc 
            • (eg) like the Early visibility page but a historical trail of what DID happen and when
            • There may already be something like this in Appendix A of the Release File Spec which we could extend and use...
      •                                           
• .
• Any other Feedback?
•  

• • Have we now given enough notice to REMOVE THE ENTIRE STATEDRELATIONSHIP FILES??????
    •  
    • YES AGREED - LET'S MOVE IT INTO A STATIC PACAKGE ON MLDS AND KEEP IT SEPARATE.
    • WE SHOULD PROBABLY GIVE THE USERS 6 MONTHS NOTICE FOR COMPLETE REMOVAL
    •  

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

• 5.2.3.1 Simple Map from SNOMED CT Reference Set
• 5.2.3.2 Simple Map to SNOMED CT Reference Set 

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

• • International Edition:
    • File naming conventions for Simple + Complex maps may need to change (eg)
      • SIMPLE MAPS:
        • der2_sRefset_SimpleMapSnapshot_INT_20240701.txt
          • NOW WOULD NEED TO BECOME 2x FILES:
            • der2_sRefset_SimpleMapToSNOMEDSnapshot_INT_20240701.txt +
            • der2_sRefset_SNOMEDtoSimpleMapSnapshot_INT_20240701.txt
        • Map content would then need to be split into the relevant files (eg)
          
          • Content in module 446608001 |SNOMED CT to ICD-O simple map reference set| would be held in:
            •  der2_sRefset_SNOMEDtoSimpleMapSnapshot_INT_20240701.txt
          • Content in module 900000000000497000  |CTV3 to SNOMED CT simple map reference set| would be held in:
            • der2_sRefset_SimpleMapToSNOMEDSnapshot_INT_20240701.txt
        • Would the refsetID's also need to change??
          • (eg) with MedDRA we had to create a new refsetID for MedDRA to SNOMED (1193497006) as the old refsetID (816209002) was not compatible with the new format
          • IF SO, the refsetDescriptor records will also need to be changed in order to describe the new format.
      • EXTENDED MAPS:
        • DO WE NEED TO CHANGE THE RELEASE FILE SPEC IN A SIMILAR WAY THAT WE DID TO THE SIMPLE MAPS (in order to add in the directionality to the format - see above)??
        • OR DO WE SEE A DIMINISHING RETURN ON EXTENDED MAPS LIKE ICD-10 THAT RENDERS THIS REDUNDANT?
        • .
        • Internally, SNOMED International can't see many (if any) strong use cases for reverse directionality Extended Maps, as our intention is usually to map from SNOMED to external classifications when it comes to Complex maps.
          • However if you can foresee use cases then please let us know now!
          • Even if the use case is a local one (because you would like to develop your own complex/extended maps in the other direction), we can still update the overall spec in order to allow support for your local use cases in the global SNOMED standard...
  • .
  • Derivatives:
    • ORPHANET - Need to align this and plan transition for next year 
    • GMDN - already aligned? (is the refset under the correct new refsetID?)
    • EDQM - already aligned? (is the refset under the correct new refsetID?)
    • .
    • FUTURE:
      • HPO Map....

QUESTIONS:

• How much notice should we be providing?
• Comms scope?
• Any impact to existing systems? 
  • (eg) 
    • Mapping tools (WCI)
    • SnaptoSnomed
    • Simplex?
    • Browser

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.

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)

• Back in October 2023, the MAG agreed that increasing the DescriptionType spec to allow longer terms in Descriptions would be a good idea - see item 4 here: 2023-10-24/25 Full MAG Atlanta Hybrid Meeting 

  • Subsequently, they posted a blog in the MAG advertising a community consultation to solicit feedback on our proposal to increase the description length limits of FSNs and Synonyms from 255 characters to 4096:  https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=232391626

    This blog links to the proposal here:  https://confluence.ihtsdotools.org/display/mag/SNOMED+International+Proposal+to+Increase+Description+Length+Limit and a Google Form for feedback: https://docs.google.com/forms/d/1cBxZnJDV5cy_5hkWaCc02xXhFaz8-2c6JI6yppQ8QUE/edit

  •  
• FYI - In the meantime, NZ require a new limit for a handful of terms, and so we extended their DescriptionType in the April 2024 NZ release, in order to allow for slightly longer terms locally until the International spec has been updated.
•  
• Because the spec already allows us to increase the length of the field,  the concern is predominantly for impact to end implementers.

• 
  

• It’s mostly, therefore, a question of warning implementers that the status quo is going to change
  • We have therefore started a full community consultation in 2024, in order to garner feedback from anyone who may be impacted by the changes.
  • We will also ask if anyone has any issues with the length that we change it to, as we can foresee terms breaching 512 characters (with vaccine product with 10 ingredients for example) - so 1024 would be the next obvious target.  However, at that point it's not clear why we don’t just jump to 4096, given that we already have that configured for textDefinitions… otherwise we could end up having to extend it again within the next few years.
  • The potential problems are for end implementations who have local hard coding, or worse technical restrictions on imports, etc - but it feels like that’s going to be the same problem at 1024 as at 4096?
  • Therefore it would appear that the best plan would be to increase it from 255 to 4096?
• Can anyone foresee any implementation issues? (other than providing a reasonable lead time to allow implementers to potentially change hard coded limits, etc?)
  • At the moment the only implementation issues we're seeing are that several countries are finding terms that contravene the 255 spec (both in the INT Edition + the MS terms) and so only positive reinforcement for increasing the limits (eg) https://ihtsdo.freshdesk.com/helpdesk/tickets/49593
  • But could we foresee, perhaps, any issues with implementers who might have
    • a) hardcoded the 255 limit and could take a long time to get it changed (especially given how long the limit has remained the same), or
    • b) still be running systems that can't actually cope with >255 characters even if the implementers want to increase the limit?
  • The reason we ask this is that if terms are concatenated (especially Drugs, etc) by out-dated systems, then this could cause Clinical Risks, which we want to avoid at all costs.
  • So perhaps we need a lengthy Community Consultation period (say 6-9 months) to socialise the change before we implement?
    • This would be okay for the current known offenders, as:
      • a)  The International terms have successfully been reduced down to comply with the 255 limit for now
      • b)  The MS customer who had longer terms specialised their DescriptionType format to 4096 in their own extension - the only issue here of course is global interoperability, but this is a lower risk for now than contravening our own specs.
•  
• WE ALSO NEEED TO INCLUDE THE SPANISH EDITION + ALL OTHER SI PRODUCTS IN THIS CONSULTATION!!  (as ALL our products would move to 4096)
  • ANY CONCERNS WITH THIS PRODUCT TRANSITIONING AS WELL?
•  
• SNOMED International Content team was asked to confirm how many FSN's (especially in the Drug content) in the International edition are pushing up and above the existing 255 limit - 

  • The project lead advised that the current content is usually truncated with a comma if it exceeds the 255 limit.   

  • A report for content that may use a comma to reduce the character count was run and it looks like a very small number (approx. 17) - however there is no accurate way of identifying the exact numbers as this truncation is historical and the issue that arose with https://ihtsdo.freshdesk.com/a/tickets/49593 only occurred because the descriptions were being modified for a different reason.

  • The DROOLS warning (which had been switched off for awhile on the international platform in response to a request from a member country) will be reinstated for 255 characters in the international release until the increase in character numbers is agreed https://jira.ihtsdotools.org/browse/MAINT-2532

• This confirms that there is no urgency for this change from an International perspective, and Extensions can continue to specialise the config in their own DescriptionType refset where required.
• We can therefore discuss and analyse this change properly, and apply a suitably lengthy Consultation Period for the Community, given the high potential for impact to end users.
• .

• In summary the feedback so far has been:

  
  

  • We have received feedback from 15 entities (both NRC’s + organisations)
  • The vast majority are fully supportive of the proposed changes, and have in fact already signed off the changes
  • This is despite the fact that more than half are expecting to have to make changes to systems/processes in order to accommodate the new limits
  • There are some reservations, which users have asked to be considered before implementing the changes - including (but not limited to):
  • Need to be able to support the change in Postgres, Oracle and Snowflake DBMSs, plus SQL, Java and common programming languages
  • Due to potential impact to existing systems, they hope that SNOMED will keep system limitations in mind and avoid lengthy FSNs to the extent feasible.
  • Potential issue with human-selection of codes if FSN’s increase significantly in length
  • Potential impact to existing API’s, in particular import and upload end points
  • Potential to overload user interfaces
  • *However, many of these issues can be addressed by the fact that SNOMED International have stated that despite the increase in the maximum length, there is currently no intention to significantly increase the length of descriptions
  • Most users are comfortable implementing the changes within the next 12 months, with 3 stating that they will require more than 12 months to make the necessary internal preparatory changes
  • However, the feedback becomes slightly less positive when going down below the NRC level - the UK for example have received 34 responses from their end users, 13 of which will require more than 12 months to make the necessary internal preparatory changes.  

  There are still several months to go until the feedback deadline, so the picture formed so far may change, but this is where we stand at this point in time.

  The key point that is coming through so far on the feedback is that the important caveat that we stated in the announcement will resolve most concerns raised:

  It is important to note that there is absolutely no intention to increase the length of a multitude of the International Descriptions.  The proposal is simply to increase the maximum size to 4096, in order to allow a small number of necessarily longer terms to be consumed.  However, the vast majority of Descriptions will remain at their current length, well below 255 characters.

• ANY OTHER FEEDBACK, PLEASE PROVIDE IT VIA THE FEEDBACK FORM BEFORE THE UPDATED DEADLINE OF 31st DECEMBER 2024:  https://docs.google.com/forms/d/1cBxZnJDV5cy_5hkWaCc02xXhFaz8-2c6JI6yppQ8QUE/viewform?edit_requested=true
• SHOULD WE ALSO CONSIDER A MORE CAUTIOUS APPROACH?  Moving to a limit of say 1024 first, and then building up?
• OR SHOULD WE move straight to 4096, but then provide a list of all actual terms above 255 in the International Edition so that consumers know exactly what to expect?
• OR IS IT REASONABLE to expect users to be able to cope with moving to a MAXIMUM of 4096, in the knowledge that most terms will no go anywhere near that length?

•  Guillermo initially confirmed that many Spanish Users are requesting more frequent delivery of the Spanish content.
  • Some ideas they have for addressing this are:
    • 1.  Allow Spanish users to build + publish their extensions based on the UNOFFICIAL preview release that we currently share with termMed - BUT this is a risk, and not great for interoperability
    • 2.  Allow Spanish users to version the content "locally" at ANY TIME, in order to baseline for their extensin - again not great for interoperability
    • 3. Move Spanish Edition to a monthly release 
      • BUT this is a significant overhead for termMed + SI, and so we asked for use cases to support this requirement...
• Perhaps best would be a move to a Frequent Delivery of a Spanish Drugs extension, as this is the predominant use case Guillermo's users have for needing more frequent delivery of Spanish contnet - and therefore trying to move the entire Spanish Edition (with it's rigid requirements for FULL translation of the INT Edition, etc) would be a large and potentially unnecessary overhead.
• To be discussed in October 2024 meeeting...
  • No objections (Oct 24) - Guillermo to look into trialling this...

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.

Reuben Daniels 

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

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

• Everyone confirmed no issues with the proposal in principle, in April 2018
• However, do we consider this to just be relevant to refsets in the International Edition release package?
  • Or to all derivative products as well?
  • Both refsets and maps?
• Also, are we talking about only human readable descriptive information, or also machine readable metadata such as
  • ranges of permitted values
  • mutability, etc?
    
• Michael Lawley to kindly provide an update on his work with David to help design and implement the solution - this will now be in the second TRAG meeting of the April 2019 conference, after they have met together....
• Michael + David + Harold agreed to create a straw man to put up in the next meeting and take this further...
  
  • Michael Lawley - where are the discussion on this currently?
  •  Michael confirmed (20210420) that this straw man was never created, and so we should use the published .json file as the straw man for future discussions... 
• Can we link this in to the .JSON file above? (Computer readable metadata) - yes, done!
•  
• IN FACT, are there any requirements for machine-readable or human-readable metadata that can't be addressed with extensions to the new .JSON file in the release packages?
  • No, not that people can foresee!
  •  
• 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...

• • 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
       • • • • (eg) ORPHANET OWL record changed from:
       • • • • • id    effectiveTime    active    moduleId    refsetId    referencedComponentId    owlExpression
               • 05c5bdfd-1c04-4e8f-9ad1-30922dc10114    20190731    1    900000000000012004    733073007    784009001    SubClassOf(:784009001 :900000000000445007)
             • ...to 
               • id    effectiveTime    active    moduleId    refsetId    referencedComponentId    owlExpression
               • 05c5bdfd-1c04-4e8f-9ad1-30922dc10114    20240701    1    784009001    733073007    784009001    SubClassOf(:784009001 :900000000000445007)
                 
               • .
             • (eg) GMDN OWL records change from:
             • id    effectiveTime    active    moduleId    refsetId    referencedComponentId    owlExpression
             • 2eeb5ab7-378f-4221-b7a7-d251811609dd    20190731    1    900000000000012004    733073007    466707005    SubClassOf(:466707005 :900000000000443000)
             • ...to
             • id    effectiveTime    active    moduleId    refsetId    referencedComponentId    owlExpression
             • 2eeb5ab7-378f-4221-b7a7-d251811609dd    20240701    1    466707005    733073007    466707005    SubClassOf(:466707005 :900000000000443000)
             •  

    WE WILL BE CONTINUING TO ROLL THIS OUT TO ALL OTHER DERIVATIVE PACKAGES FOR THE REST OF THE YEAR, SO PLEASE SPEAK UP NOW IF YOU HAVE ANY ISSUES WITH ANY OF THE CHANGES ABOVE??

  • Michael Lawley has objections - AAT to meet with him offline and work out if we need to change our approach...

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/

• Multiple different use cases:
  • • 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!
    •  
• Method for 1 + 2:
  • Inactivate it all first for a certain period...
  • Remove it completely on agreed date
  • Put all removed data into its own separate package, in a "static package" in MLDS 
    • This allows users who absolutely CANNOT live without the deleted content to reload it into their extensiovs
    • We would need a spearate place in MLDS ??per product?? and also split between each use case above?? (so a repo for "removed content due to obsolescence" + a repo for "removed content 
  • Do we also then need to change status to something other than 0 or 1?
    • Or perhaps even move it to a new "trash" module or something?
    • OR do we retain each row in its exact state from the last Published state, as this gives users the opportunity to know exacty what needs to be deleted from their own extensions, etc (as the Triple index still exists as it would in Prod)
  • the Problem with this approach is whether or not the risk of someone then misinterpreting this "removed" package (and uploading it into their systems instead of using it to remove data!) is too high to keep the records in the same status?
  • OR perhaps we retain the info of which records to delete in the Annotations refset?  So we could add an Annotations record for each deleted record, which would contain the Triple (ComponentID + ModuleID + effectiveTime) so that users could know exactly which records need to be deleted...
  • ALSO NEED TO CONSIDER HOW TO PROVIDE THE USERS WITH A STANDARDISED METHOD 
  • Release Notes would also need link to MLDS static pacakge
  • Naming convention for the Static Pacakge needs to be OBVIOSU + content in the JSON and Readme files made clear to mitigate the risk

All

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

• • Attribution                             -  (eg)  AJCC vs. UICC tumor staging concepts
  • Editor notes                          -  (eg)  Reference to section of editorial guide when "nonconformance" is used as an inactivation reason
  • Authoritative reference        -  (eg)  Point to sources of truth such as UpToDate or Clinical key pages
  • Regulatory data for drugs   -  (eg)   approved uses, off-label uses 

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

• https://confluence.ihtsdotools.org/display/DOCRELFMT/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:  

• https://confluence.ihtsdotools.org/display/DOCRELFMT/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?

Patrick McLaughlin John Snyder 

WHEN US NRC IS IN ATTENDANCE:

• The base file name is 63 characters:  SnomedCT_ManagedServiceUS_PRODUCTION_US1000124_20230301T120000Z.zip
• When the zip package is decompressed on a windows based computer using 7zip, the base folder name is the same length as the zip package file name:
  • 
• 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!!
  • .

All

Question:  Do we need to update the release file specification to reflect the new practice of not including the delta release file type in the International Edition release package?

• As we know, the delta format is still "valid", but it is no longer provided as part of the International release package.
• Also we now provide a tool to generate delta files.
• We've updated the Delta file specifications (3.2 Release Types) to specifically mention the removal of Delta files from the International Edition:

  • Please note : 

    • Delta files have been removed from the SNOMED International release package, but a Delta Generation Tool is available for those who need it. The Delta Generation Tool allows users to create their own Delta between two fixed release dates - you can find it here: https://github.com/IHTSDO/delta-generator-tool/releases.
  • BUT this doesn't include ALL Extensions + Derivative products - does it need to??
  • It also states at the top that :
    • "A  SNOMED CT International Release includes three distinct  release types."
    • THIS IS NO LONGER TRUE - DOES IT NEED REFINING to say "...may include up to..."?
• ALSO the RELEASE PACKAGE CONTENTS page is definitely out of date:
  • 3.4 Release Package Contents
  • UNLESS we consider this to still be useful info for historical packages that still contain DELTA files? (or other extensions outside of SI control that still include them??)
•  
• If we need to do this, let's walk through it in the Release File Spec docs...
  • SNOMED CT Release File Specifications
• Andrew Atkinson to implement changes in the Documentation??????

ALL

Now we've used this file for several months, do we have any suggestions for improvements?

1. Andrew Atkinson to put together proposal to include following New fields:

• • URI that identifies the package being published
  • PackageType (ie) Edition or Extension or Derivative
  • List of modules used
  • Default Namespace 
  • Default module to start authoring
  • Country tag
  • Custom tag
  • ALL INFORMATION FROM THE README FILE (which is neither human nor computer readable)
    • MANIFEST INFO
    • Licencing info
  • JSON SCHEMA for this JSON file
    • (to allow computer readable version of how to read the JSON file)
  • .
  • ANY OTHERS????
  • .
  • JUST TO CHECK WE STILL NEED THIS GIVEN ANNOTATIONS IMPLEMENTATION??
  •  
  • TRAG TO REVIEW THIS PROPOSAL IN OCTOBER 2024 + IF RATIFIED WE'LL IMPLEMENT SHORTLY AFTER

1. Removed fields:

• • ANY TO REMOVE???
  • .
  • .
  •  

Suzy Roy

Patrick McLaughlin

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 - Getting issue details... STATUS 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 - Getting issue details... STATUS RAISED 
        1. MAINT-1958 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:  Update to the .JSON file metadata - addition of "Package Composition" data 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:  Update to the .JSON file metadata - addition of "Package Composition" data)  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:
    • Update to the .JSON file metadata - addition of "Package Composition" data
• NEED TO ADD EXAMPLES OF EACH USE CASE + SAMPLE MANIFESTS - This will not only help with MDRS assertions, but also Syndication info...

Ed Cheetham

Yongsheng Gao 

Peter G. Williams 

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

James R. Campbell 

Dion McMurtrie

Michael Lawley

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: SNOMED CT Release Configuration and Packaging Conventions
• 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 to raise a ticket to update the fhir specs accordingly
• Reuben Daniels to talk to Linda to get URI specs updated accordingly.
• URI Specs to be updated and aligned accordingly - Reuben Daniels 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, Suzy Roy, Corey Smith, Harold Solbrig, Mikael Nyström, 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.
• https://confluence.ihtsdotools.org/display/RMT/
• SNOMED+CT+Release+Management+Communication+plan
• 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 Solbrig

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 Harold Solbrig) 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, Suzy Roy, Corey Smith, Harold Solbrig, Mikael Nyström, Chris Morris
  We therefore all need to come up with potential scenarios where going forward we may need to implement a similar solution to the Negative Delta, and send them to AAT. Once I've documented them all, we can then discuss again and agree on the correct approach in each place, then AAT will document all of these as standard, proportionate responses to each situation, and we will use these as guidelines in future. If we have issues come up that fall outside of these situations, we'll then come back to the group to discuss each one subjectively, and then add them back into the list of agreed solutions.

1. Preference now is to retain EVERYTHING in the Full file, regardless of errors - this is because the Full File should show the state at that point in time, even if it was an error! This is because there is not an error in the Full file, the Full file is accurately representing the error in the content/data at that time.
2. The problem here is that the tools are unable to cope with historical errors - so we perhaps need to update the tools to allow for these errors.
3. So we need the tools to be able to whitelist the errors, and honestly document the KNOWN ISSUES (preferably in a machine readable manner), so that everyone knows what the historical errors were.
4. The manner of this documentation is up for debate - perhaps we add it to a new refset? Then we could use something very similar in format to the Negative delta, but instead of it actually changing history retrospectively, we simply document them as known issues, and allowing people to deal with the information in their own extensions and systems in whatever way they feel is appropriate.
5. Only situation we can think of where we couldn't apply the above gentle response, would be copyright infringement - whereby if we discovered (several releases after the fact) that we had released content that was in direct infringement of copyright, then we would potentially have to revoke all releases since the issues occurred. However, this would raise a very interesting situation where patient safety might be compromised - as if we remove all historical content that contravened the copyright, then we run the risk of patient data being impacted, thus potentially adversely affecting decision support. This is simple to resolve when the problem is in the latest release (simply recall the release), but if found in a 5 year old release for example, it could be very problematic to recall 5 years' worth of content and change it!

• October 2018 - Guillermo proposed a separate possibility, which is to introduce a new Status (eg) -1 whereby if you find this status in the latest snpashot you would just ignore it - this doesn't however address the use case where there is a legal contravention and you need to physically remove the content from the package - the use case where you would have something that contravenes RF2 paradigm, you can't use the RF2 format to correct something that is RF2 invalid! So this is unlikely to work...
  • Nobody is on board with this idea, as it's too fragile and introduces unnecessary complexity such as we had with RF1...
• 
  
• April 2019
• If we're still all in agreement with this, then steps 1-5 above should all be documented and disseminated to get confirmation of approval from everyone??
• Did everyone read through everything? Has anyone got any further scenarios that we can include in the documentation?
  
• 
  
• The EAG raised this issue again on 08/04/2109 - Peter to try to make it to the next TRAG to explain the use case that was raised today and elaborate on the new proposal...
• The TRAG discussed this issue at length, and came to the conclusion that we cannot address ALL potential use cases with a standard, generic, solution (certainly not any of those offered above).
  • Instead the solution in each case should be agreed on given each specific use case that comes up each time
  • So INSTEAD we should update the Critical Incident Policy to very clearly define the process to be followed each time we need to remove something from the Published release(s):
    • Which group of people should make the decision on the solution
    • Perhaps we also provide examples of how each use case might be resolved:
      
      • For Legal/IP contraventions, we should either remove content from history entirely, or redact it (leave the records in place, but remove all content from fields except for UUID, effectiveTime, moduleID, etc - thus allowing traceability of the history of the components, without including the offending content itself)
      • For Clinical risk issues, we can remove it from the Snapshot, but leave the Full file intact to leave a historical audit trail whilst ensuring that the dangerous content shouldn't get used again (as most people use the snapshot) - see Full file steps 1-5 above, etc
    • How to communicate it out to the users, etc
• OCTOBER 2019 - DISCUSSION RE-OPENED AS PART OF THE MAG:
  • Negative Delta file processing
    
  • 2019-10-28 & 30 Face to Face Meeting, Kuala Lumpur
    
  • .......
• ONCE FEEDBACK OBTAINED FROM MAG:
• Andrew Atkinson to update the Critical Incident Policy with
  • the various use cases that we've identified so far
  • the governing bodies who should be the deciding entities
  • the process for making the decision in each case
  • including the critical entities that need to be collaborated with in each case (all NRC's, plus 3rd party suppliers (termMed etc) who represent some of them), to ensure the final solution does not break outlying extensions or anything
  • the process for communicating out those decisions to ALL relevant users
  •  
• 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?