2018-10-22 Meeting notes

Tim Whitlock (Deactivated)

• QBL Block Counts fix has been released along with a number of other minor fixes. So far no issues have been reported though Fran is still testing.
• RaDaR meeting continues to wait resolution of issues on UKRDC first
• George Swinnerton has not completed the list of data items that conflict with PV naming and is currently working on this.
• Encoding of pdf issues has been fixed however it was noted that a new issue appeared on live today where the code has now been deployed. TNG-491 which appears to be an issue with the pdf encoding. George Swinnerton suggested this was because the schema had changed but the updated pyxb library has not been pulled in. The survey files have not been processed on live and the final changes required to the database to support these have not been done.
• George Swinnerton hasn't produced the list of fields that don't have an obvious location in the RDA schema and may require a schema change to support or a coding decision.
• foghorn_leghorn (Unlicensed) has started looking at the survey error correction GUI.and expects it to take 3-5 days. The time consuming bit is the data fields mapping due to the number. When dealing with errors Roger will need to filter the errors by Template due to the gui only being suitable for 2018 surveys. This could also be done using survey completion date. In order to make the error processing easier a number of specific meta fields are required. These would be Survey Completion Date, NHS Number, Unit Code and pdf filename. We may also require extra demographics to ensure a correct match but currently that seems overkill. rapolas (Unlicensed) will adjust the meta data fields to include these fields.
• Reviewing the managing of code development and releasing. It was decided after discussion to that we would develop using branches on the master. A release would be made of a number of these "developments" being merged into master and then pushed to a staging branch. The versions on the Staging branches would represent release candidates with minor fixes being done on this branch during the testing. Once the release candidate is deemed stable for production it gets merged to the Production/live branch. This branch only has fully working versions on it that would be deployed to live. Staging would generally get its releases from the staging branch release candidates. Dev would have various development versions. foghorn_leghorn (Unlicensed) look at the implications of this decision and ensuring banboo can build the live and staging branch versions. It was decided this process would be applied to services initially after a discussion about how updates to libraries should be incorporated.
• George Swinnerton reported that Patientview had noticed that the renal diagnosis codes were not being sent to PV. TNG-490 has been created for this. It looks like it may have been an artifact from the fix TNG-379. Nick is looking at this.

 A number of ambiguities were identified in the specification such as

• whilst the rda field was listed the mapping to the database table was not
• The fields didn't define how the content should be worked out such as the reported quarter. The count starts in 1995 but doesn't say if it starts at 0/1 or another number etc.

Whilst due to the current teams knowledge of the database some of these questions could be answered/worked out these need to be properly documented for new programmers or contractors who may be working on the system. It also helps define the coding requirements.

Some disscussion was had around how we might process the data for a patient should we pull a record out for the patient and process it in memory or parts of the record. Whilst a number of the values represent data within the quarter of interest some would require searching back through the data to find the first "value" after an event/treatment etc. With the current historic processing of the data some events are submitted after then end of a quarter because they run across the cutoff date or because they are known facts such as date of death. A similar approach will be needed for some entries created by the extract.

The minimun blocks required for an extract are CNT IDN and a few other odd fields. It was proposed that we start with trying to get a minimal extract from data we currently have from Kings. We would then look to plug the gaps in the kings data and expand the blocks with the highest priority blocks. rapolas (Unlicensed) will start looking at the code. It is anticipated that the code will be used as part of a mirth channel/ukrdc api call which whilst not required at the moment does mean we need to ensure the code could be used in this way. Thus we need a "identify" patients function that returns a set a of pids for a given unit in a given quarter. This is then sent to the extract code that extracts each individual patients information and creates the RR file.