2018-12-10 Meeting notes

Tim Whitlock (Deactivated)

• UKRR Extract specification is continuing to be added to. George Swinnerton has been adding extra details in preparation for the Renalware visit on 12 Dec 2018. The kings feed still needs correction before a PV extract can be successfully created. George Swinnerton will double check the issues with the current feed before the meeting and also make a list of any other issues we are currently aware of with the feed.
• NHSBT file was matched to wrong column due to the continued use of RR_Number for two columns one which is the matched this time column and one which is the previously matched column. George Swinnerton is awaiting a re-matched file from Chloe to include all the newly matched patients that were missed due to using the previously matched column. He has also asked what name she would like for the columns so they can be appropriately renamed.
• Simplified extract is still awaiting feed back. In addition we need confirmation they are happy with the use of audit data for patients with no PV record since it is 12 months or so in arrears etc.
• rapolas (Unlicensed) will be progressing the initial extract code whilst he is working from home over Christmas.
• George Swinnerton has arranaged a face to face meeting with the renalware developer for 12 Dec 2018  It is likely further meetings will be required and probably with Kings users.
• Shaun Mannings (Deactivated) has been using the merging interface to merge RaDaR records and correct RaDaR as appropriate to ensure PV data is being fed through. The merging interface is still not complete in that it is difficult to ascertain which records should be shown based from the workitems, which workitem should be used as the "master" item and should all related be cleared when the master is and what should happen and be done when a match is not valid. Tim Whitlock (Deactivated) has contacted Nick for his input he has responded
  

  First of all I need to raise a warning – duplicate patient records management will always be a specialist task. I’m not sure you will ever pass it to a generic user. There used to be (probably still is) a large team of specialists in Southport dedicating to managing duplicate and confusions cases for the NHS Number and PDS.

  Ok – now I’ve got that off my chest, on to some specifics about the matching / work item process.

  FAC001 adds Fred Smith [01/01/1980] with NHS Number 1
  FAC002 adds Fred Smith [02/02/1980] with NHS Number 1
  • Because of the NHS Number match, JTRACE tries to link the master record for NHS Number 1.
  o It completes the link because there is an explicit information from FAC002 that this is the correct NHS Number
  o If raises a WorkItem (Type 4) because the verification fails
  • Next step it tries to find a related UKRDC number and it thinks it has found one because of the NHS Number link. However,
  o It does not link to the UKRDC Id because this is only an implicit link – based on the NHS Number. A new UKRDC Id is created
  o It raises a WorkItem (Type 3) because the inferred link is not verified

  FAC002 updates Fred Smith to be 01/03/1980 – will NHS Number 1
  • The Master records for both NHS Number and UKRDC will be updated.
  • All records linked to those Master Records will be reverified and work items raised
  o Type 6 if the Master is of type UKRDC Id (the primary id in this system)
  o Type 7 if the Master is of any other type
  • Because FAC002/Fred Smith was linked to the NHS Number then a Type 7 should perhaps be raised at this point BUT there is already a WI for this [Person || Master] combination so none is created.
  o NOTE – this is deliberate to stop repeated raising of WI records. Also there is no status check, so an existing but closed WI would also stop a new one being raised. This is meant to allow an issue to be cleared by an operator and not come back. I don’t think the logic has been fully thought through though, so I’m just pointing out the intent for now.

  Now to solutions. Again this is complex so I think we need to set up a call – and we will need to break this down, because we won’t be able to eat the whole elephant in one.

  Tim Whitlock (Deactivated) will arrange a call to further discuss this.
• George Swinnerton has had a look at the RaDaR dash board requirements and originally suggested creating separate databases for each cohort. He has since looked at creating a single table but has found the exporter runs into memory issues. His current attempts at fixing this have not resolved the issue and he thinks the fixes rapolas (Unlicensed) previously used for export memory issues will be needed.
• Validation has had no progress made on any issues. George Swinnerton will check where Shaun got with checking the QBL counts and see what code corrections are required.