• Release versioning changes have now been implemented in both the International Edition and all derivative packages (including the "Z" suffix)
• Any issues experienced?
• Any suggestions for improvement?
• If not, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.

• Perl script now separated from the International Edition - any issues experienced?
• Any suggestions for improvement?
• If not, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.
  
  

• Release Notes now separated from the International Edition - any issues experienced?
• Any suggestions for improvement?
• If not, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.
  
  

• Any new requirement for this feature?
• If not, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.

• We are now ensuring that both dependencies are called out in ALL cases (as even though the dependency is inferred the TIG still requires us to state it)
• If no further issues/concerns, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.

• This change was successfully implemented in the July 2017 International Edition.
• Did anyone have any issues with the volume involved?
• If not, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.
  
  

• This was resolved in the September 2017 US Edition
• Any suggestions for improvement? YES - See Negative Delta file approach discussions below...
• If not, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.

• Andrew Atkinson sent out early warning comms, and implemented it in the Jan 2018 release.
• This was also implemented in the various derivative products based on the January 2018 International Edition.
• Any issues experienced?
• Any suggestions for improvement?
• If not, Andrew Atkinson to close down after checking again in October 2018, as it will then have been confirmed over 2 release cycles.

• This change was successfully implemented in the July 2017 International Edition.
• Has anyone had any issues with the refsets?
• Has anyone had any feedback from their community on the refsets and their real world application?
• Has anyone had any feedback from their community on how the communication went? Any feedback to be fed into the IHTSDO Release Management Communication Plan review
• If not Andrew Atkinson to close down as will now be confirmed over 2 release cycles.

• April 2018 - This change was successfully implemented in the July 2017 International Edition.
• Did anyone have any issues with the removal itself?
• Did anyone have any issues themselves, or feedback from their community on how the communication went this time? We went further than normal to ensure that everyone had visibility of the changes, and understood all of the issues and rationale behind the decisions made - so any feedback would be great to see if we can improve even further next time? Any feedback to be fed into the IHTSDO Release Management Communication Plan review
• If not, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.
  
  

•  Everyone is happy with this change, so we will keep this topic open for another 2 conferences to keep an eye on any unintended impact (as the first Spanish Edition containing the new namespace will not be published until the 31st October 2017), so people should continue to provide feedback.
• If all okay, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.
  

•  No-one is concerned about this, so if everyone's happy Andrew Atkinson will close this down and run internal clean up at some point in future

• Laterality refset now published in the International Edition - any issues experienced using it?
• Any suggestions for improvement? NO
• If not, Andrew Atkinson to close down as will now be confirmed over 2 release cycles.
• If required, Andrew Atkinson TO ADD TO DOCUMENTATION TO a) ENSURE THAT PEOPLE KNOW TO ENGAGE ON THE REFSET WHEN THEY RE ADDING LATERALIZABLE CONTENT b) TO IMPROVE VISIBILITY OF USE CASES - not required, everyone happy with documentation and visibility of refset
• ALSO Andrew Atkinson TO SPEAK TO YONG ABOUT WHETHER OR NOT THE BLANKET APPLICATION OF LATERALIZABLE TO ALL CHILDREN OF LATERALIZABLE CONCEPTS IS ALWAYS ACCURATE.. - not required, everyone happy with documentation and visibility of refset

•  Andrew Atkinson added the fact that the Delta should be populated into the Packaging conventions document (section 4.5)
• As the TRAG are in agreement with the final solution, we sent out comms accordingly.
• We then implemented the changes for the first new release - the Starter Set Translation Refset package.
• TRAG to review and confirm if this works for everyone?
• Andrew Atkinson has engaged with E-learning dept to ensure Training courses are updated accordingly, along with potentially the definition in the TIG.

Suzy Roy

Andrew to talk to the Linda about what she needs...

Suzy to provide more feedback to the MF on regualr udates to the Release AG

• Andrew Atkinson to create a new page for Linda, with "TRAG Decisions" listed. This will be kept in line with all future TRAG meetings, and will therefore provide one location for people to search when looking for final decisions made by the TRAG.

Suzy Roy

• No-one else initially interested in joining the working group, and so Suzy Roy will continue to keep the TRAG informed of progress...
  
  
  

Suzy Roy

Dion McMurtrie

• We need to discuss and agree an approach that allows us to both express the correct moduledependencies + the new module composition (to express which modules comprise the Edition package, for URI purposes).
  
• Michael Lawley has already started to write up a proposal for this, so he will share this and we can review remotely

Dion McMurtrie

Harold Solbrig

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

• Everyone is happy with the Terminology folder as the correct location
  
• Andrew Atkinson to propose to the Project team that we add the "Stated" back in, and to change the prefix to SCT instead of DER

  sct2_sRefset_statedOWLOntologySnapshot_INT_20180228.txt

  sct2_sRefset_statedOWLAxiomSnapshot_INT_20180228.txt

• We should be able to now remove this OWL script from the International Edition release package entirely now, due to it no longer being relevant in the new world of OWL Axiom files.

  Andrew Atkinson TO COMMUNICATE THIS OUT AND REMOVE IT AS OF THE RELEASE IN WHICH WE'RE GOING TO FIRST INCLUDE THE NEW OWL Toolkit (July 2018??)

  
  

• The TRAG would like to see a link to the new SNOMED OWL Toolkit included in the International Release package:

  https://github.com/IHTSDO/snomed-owl-toolkit

  
  

• 
  

• Andrew Atkinson to add the link into the Release Notes
  
  

Given the updates to the OWL approach (with the imminent addition of the OWL Axiom and OWL Ontology refsets), this discussion should become obsolete, as the old PERL script becomes redundant, and the new SNOMED OWL Toolkit is already open-sourced:

https://github.com/IHTSDO/snomed-owl-toolkit

TRAG to consider the implications of the new scripts being compiled by the Modelling AG

Last time we all agreed to 1) Wait for the document to be completed by the MAG which defines exactly what SNOMED CT should look like in OWL 2) Ensure that both the old PERL and the new Python scripts work completely and document all caveats 3) Ensure when we open source them both, we clearly call out what kind of SNOMED packages each does/doesn't work with (eg) International + extensions, but not derivatives?

Harold Solbrig to provide an update on when the MAG the document to be available.

•  Discussion can now be closed down

Harold Solbrig

• The MAG are proposing that they are perhaps going to put these non-defining relationships into a new Relationships file completely, in order to allow them to be viewed, but to also ensure that it's clear that they are distinct from normal, defining relationships (the MAG discussions are still ongoing on this)........
  
• Question is whether or not this will happen before they become inherently redundant as a result of the Anatomy remodelling.
• ORSI CONFIRMED THAT A LOT OF END USERS ARE USING THESE ADDITIONAL RELATIONSHIPS IN THEIR IMPLEMENTATIONS, AND THEREFORE IT WOULD BE PAINFUL FOR THEM TO CHANGE THEIR EXISTING SYSTEMS IN ORDER TO USE A NEW, SEPARATE RELATIONSHIP FILE.
• WE NEED TO KEEP AN EYE ON THIS MAG TOPIC AND RESPOND ACCORDINGLY - Harold Solbrig to update on progress in next TRAG meeting....
  
  

• Everyone is on board with this change, and can foresee no problems whatsoever.
• Andrew Atkinson to communicate out
• Andrew Atkinson to then implement in the relevant International Edition

Suzy Roy

• Andrew Atkinson to check with technical services as to whether or not the refset function in the borwser allows searching and/or sorting?
• Andrew Atkinson to check also if the ECL expression functionality works in the refset section of the brwoser, as it does in the normal content?
• Andrew Atkinson to add the announcement of the browser update to each Production Refset release announcement (to confirm it will be updated in the browser as well)
• Andrew Atkinson to ASK RORY FOR A WAY AROUD THE FACT THAT THE RESETS LIKE GP/FP ARE REMOVED IN THE RF2 TO JSON REPRESENTATION WHEN THE NEW INTERNATIONAL EDITIONS ARE LOADED.

• Everyone confirmed no issues with the proposal
• Michael Lawley to kindly work with David to help design and implement the solution

• Andrew Atkinson to document and communicate out the proposed categories, and plan when to implement depending on feedback received.
  1. Segregate into technical and clinical issues
  2. Prioritise only Legal issues, critical patient safety issues, and major technical issues.
  3. Continue to communicate through the JIRA tickets, so there's a good audit trail
  4. Provide access to the JIRA tickets not just through Release notes at the end of the Release cycle, but also mid-cycle so people can see what we're discussing/agreeing...

• 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??
• ALSO we need to discuss Dion's point from the joint AG where he talked about nailing down the rules for derivative modules... - EVERYONE AGREED - Dion McMurtrie to discuss/agree in the October 2018 meetings
• 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.
• Andrew Atkinson to then 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.
• Andrew Atkinson to then ensure all relevant sections incorporated in the TIG (or at least linked through)
• Once complete, the document should be published and opened up to anyone to view.
• 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
• 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

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!

• 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.
• 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
• 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
• What about cross module dependencies? Michael Lawley's idea on having a separate Module purely for managing module dependencies
• IN THE FINAL PROPOSAL, WE NEED TO CREATE A NESTED MDRS TO MANAGE THE INTER-MODULE DEPENDENCIES (as per Michael's comments)
• NEED TO PROVIDE GOOD EXAMPLES AND WHITE PAPERS OF THE USE CASES FOR MODULARISATION IN ORDER TO ENGAGE OTHERS...
• 
  
• 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.
• 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.
• THEREFORE THE FEEDBACK FOR RORY AND THE STRATEGY TEAM IS THAT MODULARISATION SHOULD NOT BE IMPLEMENTED UNLESS A VALID USE CASE CAN BE IDENTIFIED.

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.
  

Most NRC's (Australia, USA, Sweden, etc) were agreed that there was no longer any need for this Member Release period, as they only ever use the Member Release for preliminary internal validation, etc. However, Guillermo Reynoso expressed concerns that the removal of this phase would present a barrier to their support of members such as Netherlands, Uruguay, etc - and also with their translation of the Spanish edition.

The UK also need to confirm whether or not this would present them with a problem, given their release cycle timelines...

TRAG to discuss whether or not there are any new pro's/con's to removing the Member Release period?

Could we, for example, use the new Alpha release stage to remove the Member Release period (in order to gain an extra month of authoring)? This has resulted in us now having 5 testing phases to each International Edition:

1. On-going testing during the authoring cycle, both through front end validation, plus weekly issue resolution using the advanced notice provided by the Daily Build.
2. pre-Alpha testing
3. Alpha testing
4. Beta testing
5. Member Release period

We now have a well refined process, which has resulted in our having removed the issues from the Member Release period. This is because we are now catching most issues in the Alpha stage, instead of in the Beta stage, and therefore the Beta is now as it should be - as close to Production level as possible.

If we have a clean Member release period for say, 2 more release cycles, can we consider the Member Release period obsolete?

In order to make this plan work, we would need to all agree the following:

• We would need full, consistent cooperation of members in terms of allocating sufficient resource to implement thorough Alpha and Beta testing.
• We would need to ensure enough time between Alpha and Beta phases to ensure full feedback allowed.
• We would need to triage any Beta issues effectively to ensure that the release remains stable for all but critical issues found in the Beta period.

•  No-one had any problem with removing the Member Release period - even Chris Morris confirmed that the UKTC only take the release from the Production status onwards (31st Jan / 31st July), and therefore removing the Member Release period would have no impact for them
• Andrew Atkinson to discuss with Guillermo Reynoso, who is the only outstanding opponent to this proposal, and see if we can work out how to ensure that they can still meet their translation commitments...
• Depending on outcome of strategy discussions with Rory we may decide it's better to just leave this one to expire naturally as part of the introduction of Continuous Delivery (as that will inherently remove the Member release period)?
• These strategic discussions have now confirmed the need to move to Continuous Delivery, and therefore this issue should be able to be closed down in lieu of the necessary removal of the Member release period inherent with this new approach.

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

This should all be documented and disseminated to get confirmation of approval from everyone.

• Andrew Atkinson to create a survey to provide to everyone so that they can send out to all users and get feedback on the proposed changes (especially multiple effective Times in Delta files, and removal of Delta files - just a service now)
  
• Andrew Atkinson to feed all of this into the continued internal discussions on whether or not moving to Continuous Delivery is feasible, and if so plan what the timelines would look like:

• Move to Monthly Releases before we go to full continuous delivery - yes, everyone agreed
• How do we best automate all of the validation?
  - Best thing is to make the RVF the central source of truth for all International validation.
  -Therefore NRC's like Australia will promote all International related content to the core RVF, and only retain and run validation that is local to themselves.
  -This would mean that whenever they identify a new issue, they can simply promote the new test up to us and we can run it and replicate the issue for ourselves, and therefore fix it quickly.
  -It will also share the burden of maintaining the validation rules.
• Question: can we do any automation for Modelling issues? ECL? New validation using the editorial rules in the new templates as a basis for automating modelling QA? ECL the best bet - plus MRCM doing well so far - can we extend this? (Australia so far only implemented modelling validation by writing manual rules for known issues)
• What's the impact of multiple effectiveTimes in Delta files? Should be negligible, Australia and US already implemented with no effect to users (despite initial complaints!)
• Creation of a bespoke Delta using a new tool - Delta at the International level is very simple, but at the Extension level is much more complex due to all of the dependencies, etc. This could also become more involved when we modularise...
  -Australia intended to build this as well, but it never happended because no one ever requested it in the end!
  -The other issue was the traditional issue of never knowing (in a machine readbale way within the Delta file itself) what the Delta file is a Delta from (ie) is it a delta from the Jan 2014 release, or the July 2016 release, etc.
  -So there as a lot of discussion over whether or not they should create roll up Delta's, or provide the service - but in the end they found that only a few people were actually using Delta's, and those were the people who knoew what they were doing already, and so nothing was ever required!
  -So we need to decide whether or not this is useful...
  -We also need to be wary of the fact that there are two different things to be relative to - so you can have a Delta to a release, or a Delta to a date in time, and they can be very different things.
  -Suzy has always released a delta with multiple effectiveTimes in it (due to the Edition) and no-one has any issues of this ever.
  -If we remove the Delta files completely everyone would definitely need to provide a Service to download bespoke Delta's (both International and local Extension level) - AT THE SAME TIME WE SHOULD FIX THE ISSUE OF LACK OF METADATA PROVIDED FOR WHAT THE BASELINE OF THE DELTA IS
  -For local extensions this service does get a lot more complex than for International, as they need a range of Delta dates PER MODULE, as they have a lot more going on than just the International Edition - so the service would need to be a) clever enough to correctly get the relevant depednencies from all sources, plus b) Validate that the resulting Delta is correct and valid - provide a checksum of some kind (needs to be identified).
  -SNOMED INTERNATIONAL TO CREATE A SMALL, TARGETED SURVEY TO QUESTION WHETHER OR NOT THERE WOULD BE ANY IMPACT TO ANYONE TO PROVIDING A DELTA SERVICE INSTEAD OF DELTA FILES... Everyone will happily disseminate this to their users and get responses asap...
  -SUZY ISN'T ALLOWED TO ASK HERSELF, SO WE SHOULD CREATE AN ONLINE VERSION THEN SHE CAN ISSUE A NOTE TO ALL HER AFFILIATES SAYING THAT SNOMED INTERNATIONAL HAVE REQUESTED THEM TO FILL OUT OUR SURVEY (as otherwise if it comes from the NLM thy have a lot of loopholes to jump through!)
• Release Notes automation - simple, just attach notes metadata to each change in MAIN then export on Release
• Question: Is it worth starting off with a trial using just Content Requests monthly, and then bring everything else in line once happy? NO! Everyone feels strongly like there would be no benefit to this whatsoever, as the majority of urgent cases in CRS are to do with getting an ID to use in refsets etc before the next 6 monthly release, and as this has already been mitigated due to the new tooling providing those ID's early, there's no benefit in moving to CRS early. Small risk in moving to monthly at all, so better off just moving everything at once to prevent a) confusion for users b) confusion in message about continuous delivery, and c) overhead for SNOMED managing 2 different delivery schedules during the pilot
• Question: What are the next steps that we need to consider to help move this forward? Central RVF service, communication with community (survey etc)
• Question: Is everyone happy with the new plan to remove the Delta files from the RF2 packages completely, and just provide the Delta service to create Delta's on the fly? YES
• Question: How can we get a survey out to as many implementers as possible in order to ask a lot of these questions and get the
• Question: How do we manage translations? (including the Spanish release) - How do we cope with the likelihood that one month could have only 50 changes, and the next month 50,000 (Drugs project, etc)? - no impact, as should allow for incremental translations - just need to not set expectations with your users that you stay one month behind the International Edition! Just need to decouple the translation release schedule from the International Edition schedule. ARTURO woudl prefer the Spanish edition to also move the MOnhtly (or even more frequent) releases, but he fully understands the natural latency required for trandlated Editions, and so understands even if we went to monthly we can't keep up with the monthly content changes
• Question: How do we manage extensions? Again need to decouple them - MDRS will naturally get a lot bigger - also the versioning process internally currently takes a long tiem and a lot of effort for each upgrade to the new Intenational Edition...
• Question: How do we manage derivatives? Just keep them decoupled from the International Edition release schedule, and do not set false expectations by promising to keep them closely up to date with monthly International Releases!
• Question: How do we manage maps? So again there is a natural latency here where we can't keep up to date with monthly releases. WE ALSO NEED TO DEFINE WHAT AN ACCEPTABLE UNIT OF RELEASE IS FOR EACH TYPE F CONTENT CHANGE (so what our concept of "DONE" is for each type of change) - FOR EXAMPLE SOME CONCEPTS SHOULD NOT BE RELEASED UNTILT HE RELEVANT ICD-10 MAP COULD BE CREATED AND PUBLISHED AT THE SMAE TIEM. OTHERS COULD BE RELEASED NO PROBLEM AND WAIT FOR 6 MONTHS FOR THE RELATED MAPS...
• WE ALSO NEED TO CAREFULLY DEFINE AND COMMUNICATE OUT WHAT THE SCOPE AND GOALS OF MOVING TO CONTINUOUS DELIVERY ARE - TO ENSURE THA WE MANAGE EVERYONE'S EXPECTATIONS. FOR EXAMPLE, WHAT IT DOESN'T MEAN IS THAT EVERYONE WILL GET THEIR CHANGE INTO SNOMED WITHIN 4 WEEKS, JUST BECAUSE WE'RE RELEASING MONTHLY!!!
• Question: What questions would we like to ask the vendors and affiliates to a) Ensure we cover off all problems/potential issues, but b) do NOT put us in a position where they think that we might not go ahead with the plans despite their answers.... just wording the survey to ensure that they know we're going ahead, but just want to ensure there's no negative impact to them that might tweak our plans, and c) How much time do they need to adapt to the change for multiple effectiveTimes in the same Delta, and d) How do we promote the benefits? (responsiveness to changes with more frequent releases, improvement to quality with more frequent fixes, etc)

Dion McMurtrie

•  October 2018

• Plan is to ensure that the generic service is flexible enough to fail gracefully if certain extensions don't contain some of the expected files, etc.
• We should also provide a standard Manifest to show what files they should include wherever possible (even if blank)

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...
• Chris Morris to do the same - get the RVF up and running and then promote any missing rules that they run locally.

•  October 2018 - Harold Solbrig to give an update on the MAG's plans?
• This has already been implemented as of Feb 2018 - any concerns?

•  October 2018 - Harold Solbrig to give an update on the MAG's plans?

•  October 2018

The short term proposal of precoordinating the numbers and measures as concepts (and therefore not changing the RF2 format) was generally well accepted, though there were concerns raised regarding the longevity of this approach, and whether or not this addresses the original target of the project (which was to allow a standardised approach across all extensions, instead of perpetuating distinct coding for different users). The other concern raised was that any solution needs to be implemented rapidly, as otherwise the various members will be forced to start/continue implementing their own solutions.

Peter G. Williams, therefore, will take this forward in the Modelling AG and further implementation. The functionality has been rolled in to the wider discussion of enhancing SNOMED’s DL capabilities.    The Modelling AG is planning a targeted discussion on this in June 2017, and will then produce a document which would then be reviewed by the MAG at the October conference.This Proposal document will be shared when complete.

Last update from Peter was that the OWL Refset solution allows us to classify with concrete domains. The thing we’re still discussing, is how to represent that in the release. The currently most popular approach suggested is to create a 2nd inferred file which contains concrete values in the destination column, rather than SCTIDs. This allows them to be added without impact to the current approach i.e. ignore it if you don’t want to use them. The new file would only contain concrete values.

Harold to give an update on the MAG's plans?

•  October 2018 - Harold Solbrig to give an update on the MAG's plans?

•  October 2018