ACTION:Yongsheng Gao to deliver this, as this now comes from the Refset tool ... AAT to receive from Yong w/c 13/05/2019
YONG confirmed he would complete the refset by cop on ............., so once Maria reviewed as well AAT should receive the completed version by ........... at the latest.
YONG Delivered as requested on
ACTION:Yongsheng Gao to deliver them, AAT to receive from Yong w/c 13/05/2019
YONG confirmed he would complete the refset by cop on ............., so once Maria reviewed as well AAT should receive the completed version by ............. at the latest.
YONG Delivered as requested on
Content Validation Activities:
Concepts that have changed its high level hierarchy ancestor since last release
Concepts with FSNs with changed semantic tags
Active concepts with changed FSNs (check for shifts in meaning)
Concepts *in*-activated since the last release
Concepts *re*-activated since the last release
Concepts that changed from fully defined to primitive
Concepts that changed from primitive to fully defined
New FSNs: Check for adherence to naming conventions, no acronyms, etc.
Spell checking for new descriptions and/or manual inspection
Review all new and changed text definitions
Additions/removals of members of VMP refset (Inactive concepts still in the VMP refsets are removed during release extraction)
Additions/removals of members of VTM refset (Inactive concepts still in the VTM refsets are removed during release extraction)
Verify that there have been no changes to the Non-human refset in the Workbench.
Additions/removals of members of ICD-O simple map refset (Inactive concept still in the ICDO map are removed during release extraction)
Active concepts having active historical associations and reasons for inactivation
MBR has been analysing the Daily Build RVF results for the past few weeks, and working with Peter to clear down the failures. We just, therefore, need to confirm that the RVF report is now:
a) In the Preliminary Handover meeting it is being cleaned on a daily basis, with the intention of having it cleared down completely by the handover on 8th May as planned - complete
b) Clean in the Final Handover meeting (before we version the content) to confirm next week...
ACTION: Maria Braithwaiteto share the Content report results with the content team - she will confirm whether or not any fixes are required before the Alpha release - Maria confirmed all clean now and no further issues requiring action
Final issue found by UK (
Getting issue details...STATUS
) was confirmed by content team as planned for fix in July 2019 (and agreed to be carried over by Elaine and Jeremy), so team to just confirm this was resolved in the July 2019 editing branch. MBR new concept added 782715005 |Infection caused by Bordetella (disorder)| no other changes required.
will be carried over to Jan 2020 - she will manually add the notes into the Release Notes to confirm - no need to add ISRS tickets. MBR added a section to release notes.
MARIA confirmed she's included all of the information for this in the July 2019 Release Notes.
Content Team Support availability - Confirm which members of the content team will remain on stand-by until clean database milestone is achieved after release build file QA and post-release assertions are validated.
Maria, Donna and Yong will all be around to support wherever needed.
ACTION:Monica Harryand Paul Amos to review and approve once complete - Monica completed, + Maria confirmed Paul has also signed them off
Discussion of existing Known Issues from the previous Release
ISRS-365- Long term "part of" fixes - current status - May 2019 update has dependency on the implementation of DL enhancements. ACTION: Yong to close ticket....DONE
ISRS-366 - Long term case significance fixes - May 2019 review work completed, requires implementation into editing environment, meeting planned to discuss 8 May 2019. To be carried over to Jan 2020
ISRS-409- Specific case significance issue - I have asked JCA for an update, no immediate action, requires wider consultation. To be carried over to Jan 2020
ISRS-414- Non breaking spaces - fixed please see INFRA-3329 - ACTION: fixed, just need to validate in this release cycle
ISRS-459 - resolved by Maria in
Getting issue details...STATUS
non breaking spaces fixed please see line above INFRA-3329ACTION: fixed, just need to validate in this release cycle
ISRS-464 - Veterinary inactivation issues - not an error, a new concept was added for July 2019 but the original inactivation is correct. Feedback provided to UKTC via Freshdesk ticket. ACTION: fixed, just need to validate in this release cycle
ISRS-487 - MRCM domain issues - ACTION:fixed, just need to validate in this release cycle
ISRS-489- MRCM updates - part two of the changes we implemented in Jan 2019 - Maria completed the warning, ACTION: Linda to finalise....DONE - AAT provided LInda with UUID to standardise early so David could continue with HRCM prep...
ISRS-491 - MRCM constraint issues - ACTION: fixed, just need to validate in this release cycle, fixed this duplicates number 7 above.
Brief run through of the known issues already identified by the content team during the QA batch process, to ensure that technical team are aware of them, and can either resolve them in time for the release, or confirm as known issues.
Getting issue details...STATUS- these should be false positives, and RVF fix has been deployed so we just need to verify that this has cleared down the report... ACTION: fixed, just need to validate in this release cycle
Mapping: Clean after initial meeting - how are we looking for meeting the planned delivery timelines - DONNA confirmed all on track
Versioning and Change Freeze
KAI TO RUN ONE FINAL MANUAL OWL DAILY BUILD BEFORE WE VERSION JUST TO DOUBLE CHECK NO UNEXPECTED CONTENT ISSUES.... HE WILL RUN EITHER THIS AFTERNOON OR TOMORROW MORNING (FRIDAY 10th) - COMPLETED with reasonably clean results.
AAT to then get a clean Alpha package built before we can sign off content for versioning...finally got a clean build on
AAT to request Rory/Michael to action after all above confirmed.....Versioning and branching completed and authoring tool re-opened on as planned.
Validation up and running immediately due to no more reliance on the AMI!! - Maria and team to let us know immediately if any issues found in the validation as might be a few initial niggles...
????????Versioning completed and initial successful builds run - will confirm properly once final validation run after mapping files delivered....
ACTION: Maria Braithwaitewill run the spell check and RVF one final time after the cut off is complete - completed 7 May 2019
MBR can also now use this for the stats in the Release Notes, as once content cut off is complete, this Daily Build report will show the static version for the July 2018 International Edition.
ACTION: Maria BraithwaiteThe only thing we need to be careful of here is large updates during Alpha/Beta release cycle - so MBR to run this again after Beta release is complete and update Release Notes if required - done??
OWL Daily Build has not yet been automated and run, and so Maria has not had sight of the results of this before the handover.
ACTION: We therefore need to run some additional checks to ensure that there are no unexpected issues - KAI TO RUN ONE FINAL MANUAL OWL DAILY BUILD BEFORE WE VERSION JUST TO DOUBLE CHECK NO UNEXPECTED CONTENT ISSUES.... HE WILL RUN EITHER THIS AFTERNOON OR TOMORROW MORNING (FRIDAY 10th) - COMPLETED and the few minor issues found have now been fixed - in test now with aim to get them into Production before the Alpha release...
ACTION: PLUS Andrew to run the preliminary version of the OWL Delta that Kai has produced through the early validation builds and ensure no failures in the RVF or DROOLS... DONE
The next risk is that we don't have the full OWL functionality in place in the termServer as yet - this is coming soon, but not quite in time for the July 2019 release. This is resulting in us having to follow several workarounds for creating the OWL files as we promised for this release package. These workarounds are manageable, but quite manual, and so naturally introduce some additional inherent risks that wouldn't be there if we had the full end to end OWL solution in place already. We will mitigate this with as much validation as is possible in the time, but we should still acknowledge this as a potential risk to the quality of the end deliverables.
The other risk is that we still don't have a final decision as yet on the format of the OWL content in the RF2 files -
Snapshot file - Whether or not to use flat July 2019 effectiveTimes against every record in the OWLExpression files (except those already published in July 2018 + Jan 2019), or whether to try to align the effectiveTimes with the previous Snapshot state from each related Stated Relationship record.
This would make sense, as there would be continuity from a Stated Relationship record that hasn't been updated since, say, 20100131 - as the OWL record replacing it would start from that last known update time and therefore have an effectiveTime of 20100131 instead of 20190731.
However, it contravenes RF2 paradigm somewhat, as
The fact that the OWL record didn't technically exist (or was published) prior to 20190731 means that having an effectiveTime years before this breaks the RF2 format by "inventing" history (something that the people who requested this Full OWL file in the MAG have previously vehemently opposed!).
Technically it contradicts the statuses in the Full file of the Stated Relationships file, which will still be in the package, and will still state that the Stated Rel records were active until July 2019.
Full file - Some people would like the Full file to have a full history all the way back to 2002, showing the OWL statuses in line with each related Stated Rel change for the entire history of SNOMED CT.
This however, will take a long time to validate, so at this stage given that no work has been done on this yet, would potentially be a risk to the delivery of the July 2019 Release.
Delta file - The Delta file has been requested to include ONLY those OWL records that have had changes made to them since the last Jan 2019 release.
However, this again contravenes RF2 paradigm as:
The Delta file must contain all NEW records as well as updated records, and as all of the OWL records in question are new (despite many of them not having had their related Stated Rel changed for years) this would result in an invalid Delta from the Jan 2019 release
The Delta file should also be representative of the changes to the Snapshot, so technically if we're making the effectiveTimes artificially align with the previous states of the related Stated Rel records, the Delta should also contain multiple previous effectiveTimes. This is again in contravention with the RF2 format of including only the latest changes in the Delta files. So in this case only changes made in the July 2019 cycle should be in the Delta, which is technically the case here, but the older effectiveTimes may cause problems for some users' systems.
If, on the other hand, we align the Snapshot effectiveTimes with the historical states, yet have the Delta containing all new July 2019 effectiveTimes, we will then have a misaligned Delta/Snapshot...
Really, we should either:
Retain the Stated Relationship files (inactivated) and add in the OWL files with the July 2019 effectiveTimes, and full Delta files - as per the 2x Demonstration releases that we've published out and had signed off by the community, or
REPLACE the Stated Relationship files completely (remove them from the Int Release package) and add in the OWL files with the artificially aligned effectiveTimes, in order to retain the full history.
ACTION: A decision must be taken quickly, that takes into account the needs of both the vocal people in the community, but also those Members and Affiliates who aren't present at conferences etc but who may have read all the plans/warnings about the upcoming OWL changes and have made system changes ready to consume them (possibly even via Delta's)
ACTION: WHATEVER IS DECIDED HERE MUST BE COMMUNICATED OUT TO THE COMMUNITY ASAP, TO GET AGREEMENT FROM EVERYONE BEFORE WE PROCEED WITH THE ALPHA RELEASE NEXT WEEK...
DECISION TAKEN: to continue with the blanket July 2019 effectiveTimes in all OWL files (as per the 2x Demonstration releases that we've published out and had signed off by the community), and to retain the Stated Relationship files (inactivated). Decision make in the meeting with Rory, Yong, Kai and Maria at 14:00 on 10/05/2019
Other than that, no known risks! Everyone comfortable so far...
No new risks raised in the Final Handover meeting - everyone signed off ready to proceed as planned...