Skip to content

Submission

Submission

Each child that has a completed a year of diabetes care is included in a submission.

A single submission covers an audit year which runs from 1st April to 31st March. Each submission is then broken into 4 quarters, though a single submission is a single instance of the Submission model.

The Submission model has a many to many relationship with Patient, with a patients field and a related field of submissions.

Opening a Submission

Users submit their data to the audit through one of two ways:

  1. csv upload
  2. 'questionnaire'

Vulnerabilty of two forms of data entry

A significant number of users submit data via Twinkle, a third party commercial platform which represents a patient management system embedded within many EHRs. Clinicians use Twinkle to enter clinical data for their patients which is stored in a structured way that allows an NPDA-compatible csv be autogenerated at the end of the audit year to be uploaded to the NPDA. Once uploaded, the data within the NPDA platform is validated and pulled into tables, and therefore viewable and potentially editable in the 'questionnaire'. If this happens though, there is a divergance in the data stored in Twinkle and that in the platform. To guard against this, therefore, on first upload of a csv, a flag is set in the permissions that prevents users from that Paediatric Diabetes Unit from editing the data in the questionnaire. This can be overridden if necessary by RCPCH Audit Team members. Conversely, those that input data directly into the questionnaire are then prevented from entering data later by csv upload. This guards against them inadvertently overwriting previously entered data.

csv upload

The csv upload option is favoured by users - ~85% use this option currently. A csv template is published on the NPDA website and this has the headings with the correct spelling and order to receive the data into the platform. Any deviation from this will be rejected.

The csv structure is clear and well documented and not for the scope of this documentation. The choices in the selects are reused in the data model. Each row in the csv represents a patient visit or activity. Because each patient has many visits/activities (10-20 typically) but a csv is a flattened table, this means that each row where the visit items are different but relate to the same patient, will have identical values for the patient items in all rows relating to that patient.

This has led to discussion over whether the Patient model should be 'denormalised', meaning that the database is trained to accept multiple records of the same patient, since over time a patient NHS number and date of birth will not change but their address and GP might. This would only be needed if records of historical addresses or GP surgeries were needed. For example, if the postcode changes, the IMD score will change, and if the patient has transferred from one centre to another, it is likely their IMD will change and any update to their address and IMD score will become associated with any previous submissions in the previous PDU.

Compromise One patient therefore can have more than record, but only one record that is associated with a given Paediatric Diabetes Unit. This is because in health care a patient should never have more than one GP, so when they move address, and change GP, their record will move. If, for example a patient moves their care from Leicester to Norwich because they have relocated, there would be two records for that patient, each with the same NHS number but different address (and IMD score) and GP ods code. The first record would be associated with Leicester PDU, the second with Norwich.

In terms of submissions, the child will have moved PDUs in the middle of an audit year, so at the time of transfer from Leicester, the audit would collect measures for Leicester PDU up until transfer date (and IMD would be calculated from their previous address), and after the transfer date measures would be collected for Norwich, including IMD. This means while calculating the measures, for that child the denominator for each needs to be pro rata based on the amount of time spent in either PDU. This makes this whole process quite complicated. See #276