Naming convention was updated in order to target the specific Laterality that we're discussing in this respect - now called the "Lateralizable body structure reference set".
TRAG to report on any issues experienced when using it?
Andrew Atkinson to discuss this with Peter G. Williams and Yongsheng Gao in order to correctly rename the existing concept for the Refset in the January 2017 International Edition.
Everyone was in agreement that removing the Perl script from the International Edition is a good idea, as long as we clearly communicate the change out, and ensure that the users are a) aware of where to get it now, and b) assured that it still has the same support from IHTSDO as it always has.
This change was communicated out, and has now been implemented in the January 2017 International Edition.
TRAG to report on any issues experienced as a result of the change?
Everyone is now happy with the segregation of the Release Notes from the International edition package (in fact ADHA have already effected this change)
This change was communicated out, and has now been implemented in the January 2017 International Edition.
TRAG to report on any issues experienced as a result of the change?
Andrew Atkinson will put together some communication on this and send it out ASAP, with the intention of decoupling them for the Jan 2017 release.
Everyone confirmed that this was a complicated and subjective discussion, and that the only true constants were the hierarchies themselves, and not the semantic tags which can range across them. Therefore creating this refset was not advised, as it could become misleading.
TRAG to confirm if they're happy to close this discussion down.
No-one has an interest in this at present, as everyone who is in a position to evaluate the Releases have already got processes in place for this. The clinical level of review that this type of Beta browser could engender should already have taken place long before we get to the Alpha/Beta stages, and so this shouldn't be encouraged at this point. In particular, this could be dangerous due to the unconfirmed content being too easily accessed and used in clinical systems if we make it available at this stage (whilst simultaneously stating that no-one should use it as such in the Readme file and Release Notes).
TRAG to confirm whether or not there are any new use cases for this, and if not if they're happy to close this discussion down.
Both dependencies now called out in all Release packages.
TRAG to report on any issues experienced as a result of the change?
Andrew Atkinson to ensure that both dependencies are called out in ALL cases (as even though the dependency is inferred the TIG still requires us to state it)
This is planned for implementation in the July 2017 International Edition.
TRAG to confirm if there are any new issues before we proceed?
Given that this is part of the natural content authoring cycle for July now, do we need specific advanced comms on this, or just put details in the Release Notes?
The issue is not with the change itself, more with the volume of changes (680k+) and so we should try to communicate it out as soon as possible - AAT to speak to the content team and put some comms together asap.
AAT to also discuss whether or not we can easily identify the distinct description changes for this cycle before the case significance changes went in, and publish this in the Release Notes.
Thanks to the UKTC for identifying and raising this issue - it has helped us to further refine our Validation service.
The question for the TRAG is: are there any other similar scenarios that we should attempt to pre-empt by adding validation to cover them, before they occur?
All agreed this is a very difficult issue to identify - can't use length, and no hard and fast rules. So perhaps the only rule we could apply is that all records in the TextDefinition file must be a Definition?
This is the number one priority for the TRAG this session - to come to an agreement on the cleanest method of removing the SNOMED RT Identifier refset.
AAT to raise with Jane - Harold raised the fact that the DICOM content still has a lot of antecedent content inherent in it - so we need to remind them to remove that (part of the fhir examples). Also see the DICOM partnerships page on the website as states no migration timeline... AAT emailed Jane on 3/5/2017
The best approach we could come up with is to a) remove it from the Release completely b) Create a Negative delta (to inactivate the content as of July 2017), which you'd include in the International edition (plus this could be used for machine readable URI automation etc) c) Create the standard static package separately.
AAT to discuss with Jane, Rory + the Legal team as to whether or not we need to remove it completely, or if we can just deprecate (inactivate) everything in the International edition. On one hand you can can say that we should legally remove it for IP purposes, but on the other hand if it's still available in the separate static package then what's the point in removing it form the International edition and breaking the RF2 standard. However, if we leave it in the International edition and just inactivate it, are we then going to get into trouble for going against all the plans that the GA made 7 years ago and have been continuously reminded about since then?? AAT held meeting on 28/04/2017, where all parties agreed that it needed to be removed completely - AAT therefore updated the discussion to inform everyone in the TRAG, and ask them for advice on the cleanest method of removal.
TRAG to review the proposal and come back with any objections or potential issues.
AAT to ensure that the TIG is updated with a permanent description of the refsets, plus a note in the Release Notes introducing it, with a link to the TIG.
AAT to add the fact that the Dlta should be populated into the Packaging conventions and send out comms. Training courses should be updated accordingly, along with potentially the definition in the TIG.
Final document to be reviewed in detail by everyone, and all feedback to be discussed in the meetings.
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.
Once complete, the document should be transferred to Confluence and opened up to anyone to view.
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
Reuben to raise a ticket to update the fhir specs accordingly
Reuben/AAT to talk to Linda to get URI specs updated accordingly.
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 discuss syndication options for MLDS with Dion - 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.
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.
AAT to ensure all relevaant sections incorporated in the TIG (or at least linked through)
Andrew Atkinson to work with the new SNOMED International Executive Lead for Communications (Kelly Kuru), and ensure that it is aligned with the new overall Communication strategy. Once complete, the Release Management comms plan should be transferred to Confluence and opened up to anyone to view.
AAT to publicise the Release Management confluence portal to the end users to get people to sign up as and when they require the information.
AAT to discuss with Jim, Lesley and Kelly 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.
AAT to also discuss this with Rory to see if we could include warnings in the tooling - bulk changes, authoring system unusal changes/large changes - define thresholds and triggers to ensure that the authors are warned/reminded to communicate this change out to the relevant stakeholders. Suggested triggers would be on volume (1000+), concept model changes, policy changes on the standard way of applying editing (eg) descriptions, and bulk retirements. WE CAN DO THIS BUT BETTER TO DO IT MANUALLY (as too much maintenance overhead otherwise) - JJTS HAVE A "WIP" PAGE THAT SHOWS UPCOMING SIGNIFICNAT CHANGES IN FUTURE RELEASES, WHICH THE CONTENT TEAM UPDATE WITH ANY KNOWN CHANGES.
AAT to put out a notice via the Release Management blog, to request NRC's to publicise the sign up of releevnat vendors/affiliates (who are confident is receving direct comms from us) to the Release Management site.
AAT to also ask Kelly to so the same
AAT to add in a section to state that we'll prefix the comms with "Change" or "Release" or something in order to distinguish between the type of communications.
TRAG to consider the implications of the new scripts being compiled by the Modelling AG
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 confirm the timelines for the document to be available.
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. Andrew Atkinson therefore agreed to put this discussion on hold until we have confirmed the timeline of the Continuous Delivery deployment, as if this will be implemented in 2017 then it will imminently negate the Member Release period, and therefore render this issue redundant.
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:
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.
pre-Alpha testing
Alpha testing
Beta testing
Member Release period
We now have a well refined process, which has resulted in our having removed the issues from the Member Release period - for the first time in several cycles, the Jan 2017 International Edition did not require any updates during 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 the same result for, say, 2 more release cycles, can we consider the Member Release period obsolete?
Most members are happy with this plan, as long as the Beta release would be consistent and stable.
Also we would need to ensure enough time between Alpha and Beta phases to ensure full feedback allowed.
Also 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.
RVF has now been open sourced to allow people to contribute towards it more easily.
TRAG to discuss taking the Implementation Load test forward, including the potential to incorporate key rules from NRC validation systems into the RVF. I don't want to make all validation systems completely generic across the board, as there is a lot of value in having different scope across the systems, creating a layered testing approach.
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.
So to allow the RVF to be contributable towards, is more useful going forwards, as then Implementation issues can be reverse engineered into the assertions.
Andrew Atkinson to also ensure that termMed's DROOLS rules are fully incorporated into the front end input validation for the SCA, etc.
If extensions promote content via RF2 delta, we just need to retain all ID's, and only change the ModuleID and effectiveTime, and therefore it is all managed by effectiveTime.
If IHTSDO reject content this is also managed
The only issue then comes if IHTSDO want to change the FSN, then we ned a way to manage the change of the meaning of the concept without creating 2 FSN's - as then we need a feedback loop to ensure that it's also corrected at source in the extension as well as in the International edition.
TRAG to continue the discussion and come to a conclusion that will work for all.
Has anyone though of any issues whatsoever with termMed creating a new namespace for the Spanish edition? If not, they are planning to implement this for the October 2017 Spanish Edition.
Andrew Atkinson to agree internally and then inform termMed.
TRAG to propose use cases for creating an actual service (with a user-friendly UI, etc) to enable people to load up their release packages and run them through the standard validation assertions
Currently we have the appetite to have one, but the start is to use the open sourced RVF as a basis to refine the rules.
Standardisation is the primary use case here - everyone agrees that there is a significant benefit to interoperability by ensuring that all RF2 packages are standard and conformant to the basic standards at least - and so this would be a strong business case for the service.
TRAG to work on defining the high level rules for the basis for a validation service.
Guillermo also has some time assigned to assisting with this in 2017, so we can setup a working group to kick this off.
Suzy, Dion, Guillermo, Chris, Rory as a starting group, to decide a) What the scope/targets should be b) What technology platform would be most appropriate c) What the high level rules should be (packaging format, content etc).
AAT to setup working group and take it forward
Liara also discussed validation with ADHA during the London conference, and as a result the assertions will be shared to improve validation on all sides.
We have identified several potential issues with moving to Continuous Delivery, which we should consider before proposing a solution:
Again we discussed this - everyone would like it in principle, but we are still not 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 need to make this dependent on first getting our automated testing up to speed - so the new working group for the RVF service will help to get us closer to being ready for the Continuous Delivery proposal.
Dion McMurtrie completed the Alpha release in May 2016 - 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.
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.
