Page tree


IssueResolution actions

Good news, no technical issues to resolve going forward, Maria was extremely happy with the process.


IssueResolution actions

The Content issues experiences in this release cycle required some new validation to be added, in order to prevent the same issues from reoccurring going forward.

Please see the following page for details of all of the new validation that is required to be created before the next Release cycle:

RVF new assertion planning

Future Improvements

Area for improvementActions

Walk through known issues with the content team, to ensure they will all be resolved in time for the Jan 2018 release…

AAT to discuss with Lesley

ICD-0 map can actually be maintained in the mapping tool now, (and has been able to do so for a year) , so we now need to move to that as termServer isn’t maintaining it properly

AAT to setup a call to discuss with Lesley + Donna + Yong + WCI...


  1. 10 inactivated records came through in the termserver simplemap export:

                                          See ticket

  1. Donna thought these were related to ICD-10 codes (instead of ICD-0 like it supposed to be the scope for simplemap, as ICD-10 is supposed to only be extendedmap), but Yong thought they were Anatomy codes, inactivated automatically by the system because the related concepts had been inactivated. Yong then confirmed these were outside of the scope of ICD-0 mapping.
  2. We may have a small disconnect here, as I’m asking Donna to account for the content of simplemap and extendedmap files, yet she doesn’t have visibility of all of the input for these files!
AAT to discuss with Lesley + Donna - include in ICD-0 conversation

Some Namespace concepts are now being created with the requesting company/body in as a preferred term (eg) 1000198   but this is not being consistently applied (eg) 1000201 - so can we either do it consistently or not at all...

AAT to discuss with Lesley - Yohani actually does this, so AAT to speak to Yo instead... company is available, so should be no issue to include:
We received reports in from one of the community to tell us that they couldn’t access some of the pages that the team linked into the Release Notes. Lesley agreed to just open up content pages

Authors are concerned with the fact that we can’t merge alpha/beta fixes back to main until end of July - this has always been the case but never a problem before due to small volumes of change in the alpha/beta period in the past.  Going forward this will likely increase, so we need to find a way to merge changes back into main after each release stable phase (alpha/beta/member) without any risk to MAIN

Rory confirmed that we can’t promote to main every alpha/beta/member release because you can’t promote without re-basing - so the only option is to fix this restriction might be to have 2x fix branches, then each time you want to do a fix, you test it on the first (release fix) branch until you’re happy with it, then once testing signed off you replicate the change(s) in the second (merge fix) branch, which we will then promote to main in order to keep the authors in sync.  this will allow the merge branch to get re_based with the latest content (for the next editing cycle), whilst keeping the release branch clean with only the current release’s content in it…

AAT to agree the update to the release process with Lesley/Maria in order to ensure she understands that she will need to make each fix twice in the next release...

Lesley to talk to Maria/Monica first to get perspective on how much impact the delays had in the July 2017 release (Toni, Penni and Maria) - then we can all talk together about whether or not tp update the process...


Both Hazel and Genevieve managed to have an adverse impact on our mapping process - so we need to refine the process to ensure that we can check both “New”/“Editing”/“Finished" statuses and “QA” work (Need to ask WCI to update the tool here??  Or just have a manual process whereby Donna asks them on the weekly calls to confirm they have nothing outstanding in QA status after content cut off for each release)

Lesley confirmed Content Release Managers should also have this as a check box on their list - both to communicate to the externals not to touch anythign during Release periods, and also to look into changing externals access rights in the Mapping Tool to Read-only durin htese periods...

NEED TO DECIDE THE PRIORITY OF THE FIXES FOR THE MRCM INFERRED + STATED HISTORICAL ISSUES - for example, there was one concept (717703006) which Jim said should be fixed asap

AAT to discuss with Lesley + Jim - Lesley to plan this out

BATCH IMPORT APPEARS TO BE POTENTIALLY RISKY - quite a few issues we came across in the July 2017 seemed to be rooted in batch content added - so would be good to review and refine the validation around Bulk imports - for example ISRS-221 (concepts marked in white in the spreadsheet attached) - all bulk imported by Toni (or so Monica thinks)

Not much we can do about this technically - need to discuss with Lesley to ensure everyone takes the utmost care when implementing Batch Imports - and also tries their best to finalise content before importing, rather than importing and then changing FSN's, etc.

Batches are all different processes, so Lesley needs me to send her all of the batches in question in order to fix them. I sent her ISRS-221, and she said this was an issue with the dirty content from termMed - Lesley will discuss with Rory how to get these reviewed BEFORE they get put into a task...

Some documentation gaps that still need closing - matt cordell to send details so we can close them in time for jan 2018

AAT to speak to Maria when Matt sends the list
ISRS-221 - we need to agree what the relationship between inactivation indicator & historical association should be, and raise tickets to have the SCA and RVF enhanced to matchAAT to discuss with Michael/Hunter

Re-basing issues! rfbintjula yet again got re-based against our express request 

RDA confirmed that this ticket has already been raised to be able to lock the Release branches - it will definitely get done before the Jan 2018 Release cycle starts in November 2017.

New potential clinical safety issue (see email from Monica at 14:30 on 13/7/2017 - any way to prevent this from happening again going forward?

Not really, but the main learning point here is that we need to ensure that we have reached a full (and unanimous) decision on whether or not these issues are actually Clinical Risks, before we raise the red flag with the Release/Technical teams and start off the whole recall process.  If this had been discussed fully with all Content authors, we may have not needed to perform the recall after all.  Therefore, we need an internal process first which goes through and confirms with their own stakeholders before raising the red flag.

Need to work through all issues found in pre-alpha, alpha and beta testing, both internally +++++ externally, and ensure that we retrospectively update the rvf to cover all these scenarios

AAT to discuss with Hunter as part of the next cycle of Release improvements.
  1. We need to start working on moving the technical back end changes to be able to be fixed by the authors instead. This is causing us a lot of problems in the Alpha/Beta period, where backend fixes are clashing with front end fixes (eg) - where back end fixes (PLUS in this case also changes to the were made for Yong’s SEP Refsets) and so an AssociationReference Delta created for the Release and placed int he Externally Maintained Refset folder, then continue to overwrite changes to the Historical Associations that Monica was trying to fix as part of the Beta feedback period.

    1. This is only likely to get worse going forward, so the more we can move to the authors fixing everything in the SCA (and therefore delivering everything through the termServer Delta exports) the better
    2. This is also a problem for a load of fix types that can’t be fixed by the authors because of the Versioning issue - so all Born Inactive content has to have back end fixes because they’ve already been versioned - this also gets very messy!
    3. Also this is a problem for new changes to the International Release which can’t get include in the International Edition - like Yong’s SEP refsets!  Next time might be slightly easier because we may have HM changes to merge these Delta’s available (if not descoped), but still MUCH better to incorporate all authored content in the termServer or refset/Mapping tools…
    4. Also a problem for the simpleMap files, as the CTV3 map comes out of the termServer, but the ICD-0 map comes from the mapping tool, so we need to manually merge the 2 into one simpleMap file. This means that if any impact o CTV3 from alpha/beta changes, we need to manually export the CTV3 changes from the termServer again, and re-merge the files!  So would be so much better to either host ICD-0 in the termServer, or both CTV3 and ICD-0 in the mapping tool!
  1. Michael hoping to allow them to start doing a lot of these fixes themselves - for example allowing the release lead to delete born inactive content during the release cycle - AAT to raise infra ticket
  2. Hunter work should also improve this situation

We need to fix the conflicts that can happen when runnig multiple jenkins jobs, or possibly even jenkins jobs vs validation runs!  

  1. so if for example i’m running a full international build, but someone kicks of an sca validation run, will that clash? 
  2. could this explain the 409 conflicts i sometimes get when trying to run the international builds, which then magically disappear and fix themselves before we find the root cause?
  3. peter had a look but was not sure that the code for returning a sensible error when an export is already underway was done however, this ticket is still at "assigned" to b2i:
  4. either way we need to be able to run multiple concurrent builds!!!
  1. Hunter work to improve this situation - after hunter complete their work, we should update the status management of the release process as per Michael’s idea, to allow multiple contiguous builds

Need to discuss whether or not we should be going back to the uktc and telling them we will no longer consider any rf1 defects as part of the current release cycle - only as part of ongoing editing cycles for future releases?  (only issue here is that i no longer have a friendly contact in the uktc, or even someone who will talk to us or answer any of our emails!  so could be an issue getting the message across, as might sound harsh via email…)

  1. Rory confirmed any RF1 issues that have their roots in RF2 still need to be fixed, but anything RF1 specific we will no longer fix - but no need to make noise about it now, just wait until the next set of RF1 only defects come through

Traceability database logging - is there any way to break down the logs for concepts which have huge logs? example was isrs-230, where we couldn’t track the root cause of the issue because the log for just one of the 3 concepts in question was over 11mb!!  the logging needs to cut off at 1mb otherwise it’ll break the indexes, so at the moment it just completely fails to log for any large complex changes!  if we could break it down into smaller chunks then this’d be great, as given the likelihood of content authoring continuing to be complex going forward (with all the remodelling work coming down the pipeline), we otherwise run the risk of having holes in our audit trail, making it more time-consuming to track issues down.

  1. AAT to raise infra ticket to say even if a log is too large then truncate it before the limit to prevent crashing.

How realistic would it be to cut off the content slightly earlier than normal next release cycle?  As we saw from the craziness in this release, the volume and complexity of the authoring changes meant we were working long hours right up until the very last day of the release!  this is fine from my perspective, but it will impact the content release lead if this continues, plus it’s a huge risk to the release, as human error is far more likely to creep in if we’re working that late.

AAT to discuss this with the content team for the July 2018 release, as the next Jan 2018 release cycle is already confirmed.
  • No labels