2020-04-06 - TRAG Meeting Agenda/Minutes

Date

6th April 2020 - 10:00 - 12:00 GMT (09:00 - 11:00 UTC)

Room: NONE - Conference Call ONLY!

(https://snomed.zoom.us/j/289236148?pwd=NEdQZUhKZjgrTUxabGhCMzhpMWtWZz09 Password: 422062)

6th April 2020 - 13:30 - 17:30 - CANCELLED

LONDON - CANCELLED

7th April 2020 - 09:00 - 12:30 - CANCELLED

LONDON - CANCELLED

Dial in details:

https://snomed.zoom.us/j/289236148?pwd=NEdQZUhKZjgrTUxabGhCMzhpMWtWZz09

Password: 422062

Attendees

@Andrew Atkinson, Chair
@Former user (Deleted), member
@Dion McMurtrie, guest/observer
@Mikael Nyström (Unlicensed), member
@Patrick McLaughlin, member
@Alejandro Lopez Osornio, member
@Stuart Abbott (Unlicensed), member
@Former user (Deleted)member
@Orsolya Bali (Unlicensed), member
@Matt Cordell, member
@Suzy Roy, staff/observer
@Chris Morris, staff/observerst
@Reuben Daniels, observer

Apologies

@Matt Cordell, member
@Stuart Abbott (Unlicensed), member
@Former user (Deleted), member
@Orsolya Bali (Unlicensed), member
@Patrick McLaughlin, member

Meeting Recording

Objectives

Briefly discuss each item
Agree on the plan to analyse and resolve each issue, and document the Action points
All those with Action points assigned to them to agree to complete them before the next face to face conference meeting

Discussion items

	Subject	Owner	Notes	Action

	Subject	Owner	Notes	Action
1	Welcome!	All	Thanks to our members for all of their help. Welcome to our observers! INTRODUCTIONS...
2	Conclusion of previous Discussions topics
3	URGENT: Proposed format of the July 2019 Optional Release package	All	We wanted to give you a quick heads up on the proposed format of the July 2019 optional release package. Whilst we haven’t received any adverse feedback from any users, we did find a couple of minor issues (during our internal testing) with the UUID’s due to the divergence of the Production and Optional packages. For example, as the Jan 2019 optional release wasn’t ever officially published, a few of the ID’s in the MRCM and inferred files have been used for different records in the July 2019 Optional release than in the Jan 2019 Optional release. Given these potential inconsistencies, we’re proposing to publish just the OWLAxiom files themselves in the July 2019 Optional release. This will ensure that the information provided is accurate, and given that there are no known use cases for anyone to use anything except for the Axiom files in this Optional package, it will serve to remove any possible confusion.	Please can everyone confirm whether or not you're happy with the final published format, and if not please provide details about why this would have an adverse effect on you or any other known users of this package? Interested to know if anyone's intending to use it other than those I already know about? Need feedback in April 2020 to see if we need to discuss further or Provide any other data in an additional release? IF NOT close down in April 2020 NO further feedback, so closing this topic down as planned
4
5	Active discussions for April 2020
6	Potential for an additional interim International Edition release in June 2020	All	In order to continue supporting the efforts to combat COVID-19, there is the potential for an additional interim International Edition release in June 2020	No-one had any valid use cases to propose to support this suggestion, as the standard July 2020 release will already be well underway and so there is such a small likelihood that anyone would have the capability of taking another interim release so close the July date, that it would almost certainly not get used by anyone. Therefore we will proceed for now on the basis that the July 2020 release will be the next International Edition published, until someone finds a use case for another interim release.
7	URGENT: Additional Delta file planned for Corona Virus descriptions	All	APRIL 2020 - How did the Release go for the end users? Did anyone use it yet or just re-publish?	Everyone now in agreement with the 5th option, as follows: 5. We publish the formal July 2020 International Edition as if the March 2020 Interim release is an official release, with a Delta relative to March 2020, containing all of the new Corona content with an effectiveTime of 20200309. This is transparent as it doesn't pretend the March 2020 never happened, but assumes that the majority of July 2020 users DID consume the March 2020 Interim release. The consensus is that people should try to use option 2c wherever possible, but that we should provide the rollup package as well just in case this is easier for some users. If we track the downloads for this rollup delta package, we should then get a really good idea of: roughly how many people would be likely to use a new "Delta" tool (currently planned for Continuous Delivery), because they aren't using the Snapshots and aren't able to simply load multiple delta's consecutively. then speak to these people and try to gently encourage them to move to using the Snapshots for future updates, in order to make strong foundations for the future migration to Continuous Delivery. @Andrew Atkinson to post the proposal on the July 2020 Early visibility page in order to provide a heads up of this plan to the community, with a chance for people to feedback before the July 2020 Release cycle begins. Done here: July 2020 Early Visibility Release Notice - Planned changes to upcoming SNOMED International Release packages PLUS also published on Release Blog: ADVANCED NOTICE: Plan for the July 2020 International Edition release, in relation to the March 2020 Interim release
8	Multiple effectiveTimes in Delta files - are they required?	All	APRIL 2020 - This needs to be answered for interim releases like we've just had, but more importantly also for the future migration to Continuous Delivery	Everyone in agreement that multiple effective times will be necessary in Delta files for future continuous releases. We also unequivocally need to include ALL historical records in a true Delta file. HOWEVER, the entire use case for Delta files is becoming less and less certain. This is because fewer and fewer users are utilising Delta's to actually upload content, but instead simply to quickly and cleanly ascertain the latest changes between the previous and current releases. This latter use case could perhaps be much better served by offering a Diff Tool, rather than the originally intended Delta tool: This Diff tool would allow the user to enter the two releases they want to see the differences between, and then just show the Diff between 2x snapshots We could also parameterise whether or not they want to see ALL changes between each dates or just the LATEST change... (so whether it would be like a true delta, or just a snapshot diff with the latest change) (eg) Multiple effectiveTimes in Delta files - are they required? We could also potentially include information for WHAT components were changed to and why (ie) historical associations - (eg) this component was inactivated for this reason, and was REPLACED BY this other component...
9	Refset Descriptor Inactivation	@Matt Cordell	TRAG to decide on correct policy and feedback to Matt...	Matt wasn't available for this call, so we'll discuss this in the next TRAG meeting....
10	MRCM format update	All	APRIL 2020 - everyone to discuss and agree	Everyone agreed that there are no predictable issues with this proposal, and so we can proceed as planned. Unless further feedback received, we can close this item down in the next TRAG meeting...
11	URGENT: CONCRETE DOMAINS Consultation + Concrete Domains * MAG crossover	All	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 Williams, therefore, has taken 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 current most popular approach suggested is to create a 2nd Inferred file ("sct2_RelationshipConcreteValues_Delta_INT_[date].txt") 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. At the same time, existing drugs strengths and counts expressed using concepts (which represent those same numeric values) will be inactivated. SNOMED International will inactivate the existing strength / concentration attributes which use concepts-as-numbers and replace them with new ones (using the same FSNs) and switch the target/value to the corresponding concrete numeric. This enhancement will increase the analytical power of SNOMED CT through the use of numeric queries and assist with interoperability by removing the need for extension maintainers to all - separately - add concepts representing numbers in order to publish their own drug dictionaries.	October 2018 - @Former user (Deleted)to give an update on the MAG's plans? No further updates yet, check back in April 2019.... Consultation: SNOMED International are now running a consultation around the introduction of Concrete Domains to SNOMED CT.I you are interested in this area, and/or wish to express an opinion on this proposed change, please read the following information and complete the feedback form if desired:http://www.snomed.org/news-and-events/articles/addition-concrete-domains-consultation Update from Peter Williams after subsequent MAG discussions - NEW MAG Proposal: Concrete Domains - Community of Practice Consultation ANYONE HAVE ANY FEEDBACK?? The MAG have only received formal feedback (via the online form - I know some of you commented direct on the page!) from ONE person so far, so can we please make a point of providing some feedback on this ASAP - even if it's just to say that you're in complete agreement? Thanks! We should also be issuing advice to downstream users of the drug model to avoid using the current concepts as numbers as they will soon be disappearing - can we please have confirmation of who knows that they have users impacted by this, and that they'll provide the advice immediately? Can anyone foresee any impact (negative or positive) on the Release(s)? NO Does the introduction of a second inferred file present any risk of confusion, etc? NO Are there any perceived restrictions around the use of concrete domains in inferred format? NO Should the new inferred file take exactly the same format as the current file? Current proposal removes the DestinationID field completely and replaces it with the new "Value" field But in theory, we could just hold the Values in the existing DestinationID field, if there's a strong business case for people to need the same format as the existing Inferred file? (hard coding of field names in import systems, etc) NO, THE NEW FORMAT IS ACCEPTABLE Will the inactivation of the existing concepts containing drugs strengths/counts cause anyone problems? NO, BUT MORE COMMS NEEDED TO WANR PEOPLE THEY'LL BE INACTIVATED Are they any users, for example, for currently use these concepts, who are unable to switch to the new approach? YES plenty, so we just need to continue to ensure this is an OPTIONAL file (to consume, it must be mandatory to include in the Release package) April 2020 - Any further feedback? (especially from any further updates from MAG plans) YES - the new question is whether or not we actually NEED to inactivate all previous concepts, or if (as we are only changing one attribute) we can leave them active and just update the attributes? Question sent to MAG Jim also kindly agreed to ask Editorial AG in meeting on 6th April...
12	Discussion of proposed format and packaging of new combined Freeset product + Proposed new Freeset format	All	TRAG to review and provide feedback and ideas for business case(s)...	Andrew Atkinson to present the current proposal, and gather feedback Feedback: Uncertainty on use cases - however this was mitigated by the specific messaging from SNOMED licensed users to non-licensed recipients... Content DICOM in particular no representative without sub-division, PLUS actually risky with unverified attributes... AAT to discuss further with Jane, etc Agreed that SI are confident that DICOM will provide some use Using the US PT instead of the FSN (whilst providing less exposure of the IP) prevents visibility of the hierarchy (due to lack of semantic tag) - however the reason for this is because the target users (who are NOT current SNOMED licensed users) will find more use from the PT in drop-downs, messaging, etc than the FSN... Now included both! Everyone happy with each subsequent release being a snapshot - so additions added but inactivations just removed - as long as we include something in the legal licence statement to state that use of all concepts that have ever been included is in perpetuity (even after they've been inactivated) New requirements have suggested that we need to now include a full historical audit trail, even in the Freeset formatted file! This means we've included an Active flag column to allow this to be added in future releases... We don't need to do this for a few months, so we need feedback now on whether or not we think this is a good idea? Any potential drawbacks? None idenitifed in Oct 2019 - but no-one has used it yet! Check again in April 2020 - no NONE - go ahead! This is a dependency for signing off the final version of the Release packaging conventions and File Naming Conventions item (next) In addition, Members would also like a Proposal to create an additional Simple refset (full RF2) of the entire GPS freeset in order to enable active/inactive querying etc by licenced users... Potential to automate the creation of this using ECL queries if we ensure all freesets are included in the refset tool.. Would people still see a valid business case for including an RF2 refset file in the GPS package as well? OCTOBER 2019 - NOT IN THE ROOM - BUT RORY HAS BEEN ASKED FOR IT BY SEVERAL PEOPLE, SO WE NEED TO DO IT This will be in line with the September 2020 GPS release. Any potential drawbacks with doing this? NO If so, should it be part of the existing GPS release package, or a separate file released at the same time? Separate, released at same time - this is because the use case is different for each file type - Users who don't have SNOMED CT will use freeset format file to scope which concepts they can receive successfully Users who already have SNOMED CT will use the RF2 file format to scope which concepts they can send successfully to those who aren't regular SNOMED users... APRIL 2020 - Any other feedback from actually using the GPS freeset file???? no - everyone would just like the RF2 file version in Sept 2020 as planned... Need to update the Release packaging conventions and File Naming Conventions with the final decisions on the freeset format, ONCE the next GPS release has been published and we've had time to receive any useful feedback on it all...
13	Release packaging conventions and File Naming Conventions	All	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 2020 - DO WE NEED TO MAKE ANY REFINEMENTS IN ORDER TO PREPARE FOR CONTINUOUS DELIVERY? Did ADHA need any formatting changes when moving to monthly? 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 would require implementing the new proposal for the Delta file naming conventions - these will in future contain the effectiveTime of BOTH the current Delta, and also the release that the Delta is taken from - for example, if a Delta is from Jan 2020 to March 2020: We can therefore use the July 2020 Rollup package as an opportunity to trial our new proposal Once all happy, the document will be published and opened up to anyone to view.
14	Continual Improvement to the Frequent Delivery process	All	APRIL 2020 - Gather Practical requirements for the various deliverables that we need to implement in order to successfully make the move to Continuous Delivery...	Requirements: Increase the scope of RVF validation to include: All current authoring manual validation Generic Validation Service assertions (from all community validators)
15	Continual Improvement to the Frequent Delivery process	All	We need to continue discussions on this on-going item, in light of the strategic meeting before the conference. In addition we now have new members with additional experience, and we have also now lived with the more stable International Edition release process for the past couple of years. Last time we discussed this everyone thought it a good idea in principle, but were concerned that we are not yet in a position to deliver the same level of quality on a daily basis than as on a monthly basis (due to the current gap in our manual/automated testing). Therefore we were going to discuss this once we had further progressed our automated testing - however as the new working group for the RVF service will testify this is a slow process, and therefore it may not be possible to wait for this to be completed in its entirety. We have identified several additional potential issues with moving to Continuous Delivery, which we should consider before proposing a solution: Perceived quality issues: There would be no time for Alpha or Beta Releases - so all Members would have to be comfortable with issues in Production for until the next interim release All issues that normally get tidied up as part of the normal Content Authoring cycle will become public - they will get fixed quickly but in the meantime there may be an impact to the reputation of the quality of SNOMED CT. Roll up Releases: The 6 monthly delta releases would need to be relative to the prior 6 month release, and therefore named as such somehow (ie) we would need to somehow make it explicit as to which previous release the delta is a differential to. Other possibility is that each month is the same interim release, and then every 6 months we also release the Delta's relative to the priori 6 monthly release, in addition to the usual monthly release. In this case we would need to reserve the 31st Jan + 31st July effectiveTime's /package naming for the 6 monthly roll up releases, so that the users who want to remain on 6 monthly schedule would remain unaffected. The other option is to have no roll up releases at all, thus releasing a stand-alone package every day/week/month, depending on the agreed frequency. The issue with this approach though is that anyone using the Delta files (rather than Snapshot) for uploads would need to keep up with the continuous schedule. UPDATE FROM THE EVOLUTION WORKSHOP: Pros Allows people to choose whether or not the users take one release every 6 months, or frequent monthly releases... Derivative maps wouldn't be a huge issue as just release them whenever we had a chance, dependent on whichever edition One of the plus points are that when we're still at 6 monthly releases, if the vendors miss a release its a big deal, whereas if they miss monthly releases then they have a smaller impact Cons One drawback is for the non english speaking members, who need to keep up with translations - shouldn't really have an impact if they keep up with each smaller release. Could be painful for translations when a monthly release happens to contain a drop of a huge project like Drugs or something... What about interoperability issues, with some people taking each monthly release, and others still waiting for every 6 months? ADHA believe this hasn't caused a huge problem for them, just an addition to the existing problem even with 6 monthly releases... Also need to implement the metadata for identifying which dependent release each Delta is relative to... Refsets aren't too much work to keep up to date - however Mapping is a different ball game - this can take some time Maps that are still inherent in the int Edition (ICD-0 ICD-11 etc) are potentially problematic, and the workflow would need to be carefully worked out... If your projects happen to drop in-between the normal 6 monthly releases, then someone who might have taken Jan and July still, might miss out on the important big releases that happen in April and November! Also quality might be an issue - need to have the automated testing completely airtight before we move to continuous delivery! Thereafter you would run all major validation at input stage and ensure authors only ever promote to MAIN when everything perfectly clean. Then we run Daily builds with automated release validation every night, and provides a RAG status on release issues every morning. Then by the end of the month, we publish the last Green Daily build!	@Andrew Atkinson to continue to feed all of this into the continued internal discussions on whether or not moving to more frequent Delivery is feasible, and if so plan what the timelines would look like. @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): https://docs.google.com/forms/d/17Rhxc3TrMgPq1lnhAm2G6LkGsaN05_-TMKr69WRVdc4/edit TRAG to add/update any of the questions.... 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) @Andrew Atkinson to refine survey to ensure that it's accessible to those with more limited SNOMED knowledge/experience, as these are the preferable target market for the survey, given that the more advanced users will (or have already) speak up for themselves: GDPR questions - verify with Terance whether or not we just need to provide a link to our data policy (https://www.iubenda.com/privacy-policy/46600952), or if we specifically need to ask the questions (of whether or not they're happy for us to store their data, etc) as questions in the survey? (check box) - If the latter, ask if we have standard legal wording I can use? Small intro - description + pros/cons Couple of fairly wide ranging questions as to whether or not they think they'll be impacted If so, then either fill in the details here (conditional question in google forms) OR please just get in contact with your NRC to discuss Avoid technical language for non native English speakers Suzy to include in her UMLS survey in January Not done yet as she's stuck with red tape in the NLM! @Andrew Atkinson refined the survey accordingly, and sent out to TRAG members for final review on 16/10/2018: https://docs.google.com/forms/d/17Rhxc3TrMgPq1lnhAm2G6LkGsaN05_-TMKr69WRVdc4/edit @Andrew Atkinson sent final survey to Terance and Kelly in particular, (from GDPR and comms perspective) to ensure in line with company strategy and verify whether or not they'd prefer this to be an SI survey or NRC surveys? Survey sent to the TRAG to disseminate to their users Survey also sent to Kelly for inclusion in the newsletter, and also on LinkedIn AGREED: 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. Share Validation Service to address this... 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 happened because no one 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 were 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 know 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 depedencies 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... None identified in survey here: https://docs.google.com/forms/d/17Rhxc3TrMgPq1lnhAm2G6LkGsaN05_-TMKr69WRVdc4/edit#responses Only 23% of respondents used the Delta's, and out of them none identified an issue as long as a Delta service was provided to allow them to continue consuming and publishing Delta's 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 that 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, + c) overhead for SNOMED managing 2 different delivery schedules during 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 would prefer the Spanish edition to also move the Monthly (or even more frequent) releases, but he fully understands the natural latency required for translated 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 time + a lot of effort for each upgrade to new International 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 UNTIL THE RELEVANT ICD-10 MAP COULD BE CREATED AND PUBLISHED AT THE SMAE TIME. 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 THAT 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 DAILY!!! TRAG members to send out the survey... Awaiting all results... ANYTHING BACK YET from anyone? ANY RESPONSES OF ANY USE FROM PEOPLE???? THE RESPONSES WE GOT WERE QUITE INTERESTING IN SOME RESPECTS (lack of understanding of the proposal, evidence of use of Delta's still, etc): WORTH HAVING A LOOK WITH THE TRAG https://docs.google.com/forms/d/17Rhxc3TrMgPq1lnhAm2G6LkGsaN05_-TMKr69WRVdc4/edit#responses New questions: NEW PROPOSAL IS TO MOVE STRAIGHT TO DAILY CONTINUOUS DELIVERY! WHAT DO PEOPLE THINK ABOUT THIS??? ALL OTHER POINTS NOT YET DISCUSSED IN THIS LIST: