Dataset version 5

(Also known as the CKD/AKI clinical dataset)

Thank you to everyone who provided feedback on the proposed version 5 of the UKRR dataset. Our responses to key queries can be found below.

The full list of feedback and responses can be viewed here.

The most significant aspect to the new dataset is the move to the UKRDC feed. It’s quite easy to understand how things like lab results can easily be fed directly to the UKRR, but it’s much harder to understand how we control things like timelines

Thank you. Full details are at https://renalregistry.atlassian.net/wiki/spaces/UD/overview.

In brief – for items such as medication, the entire list is sent in each file.

The UKRR will drop any existing list and replace it with the new submission.

For Observations and LabOrders it works like PatientView (with new data submitted between two dates sent in the submission file).

There was no RR7 available to review

This took longer to finalise than we expected, so we added it in mid-November and extended the consultation by two weeks.

Change RR23 codeset to lowercase letters to better match the UKRDC schema

This is changed in the final version.

Consider changing the code for micro grams to avoid the use of a non-standard (non-ASCII) character? ‘mcg’ perhaps?

We will change to ug in the codeset and XML schema.

Should we have 2 different items for creatinine-based eGFR? The current (QBLAB) for MDRD calculated, and a new one for CKD_EPI?

We will add specific new items consistent with SNOMED-CT, and retain the current one for historical values where we do not know the method or ethnicity correction.

I am concerned that you have adopted this - "The definition of ‘conservative kidney care’ in this code-set is about reaching symptomatic CKD5"

We have tried to contact the author by email to explore this concern.

At the UKRR, we believe that the 'future care intentions' items allow people to be identified as preferring supportive rather than dialysis care in the future and that the definition here is to give centres a chance to identify ESRD not treated with dialysis.

It does make sense. Whether or not eMed can support it is another matter. Not a bad thing but also part of a registry empire growing tactic.

We have had discussions with the main system suppliers and are advertising that we are keen to work with any who wish to develop a UKRDC feed.

We are pleased that we are getting an increasing number of enquiries from system suppliers to work with us.

As data submission is required by the commissioners, the renal registry can make up whatever rules they like and have to be followed – except NHSE do not commission CKD care which is the data they are now collecting.

Commissioning is changing to ICB(S) who will have a greater interest in the whole pathway.

Others within the UKKA, and respondents to the consultation, have welcomed the inclusion of CKD4/5 under the care of renal centres.

The key will be the “Alongside this” paragraph. If there is no easy tool to view data completeness (or accuracy) then rubbish in = rubbish out.

We are also well aware that if we wish centres to improve the quality of the data in the UKRR feed, they will need to identify where those errors are to allow them to amend the data in their renal centre system.

We are scoping tools to do this, starting with a tool to allow centres to see which and why files failed to load.

This has potential for significantly increasing workload of admins and consultants with lots more queries.

The UKRR are trying to provide a means to compare treatment between centres.

It is likely to be for others (esp. the commissioners guided by clinicians) to mandate/encourage data collection.

Any new validation will only be on recent items.

We have reduced the number of items and are no longer collecting derived items (which so often cause problems). Overall we do not intend to increase the number of queries.