Building a Renal Unit to UKRDC Feed

Introduction

First, if you haven’t already done so please e-mail rrsystems@renalregistry.nhs.uk to let us know what you’re doing and so that we can provide support.

When you come to develop the feed we suggest you start out simple at first, such as just completing the Patient element (identifiers and demographics) and sending us those for testing. We suggest the next step is to expand it to match what is typically sent in a “PV XML” feed, which your system may be already generating. To possibly assist with this we’ve a page describing how the items in the PV XML map to the RDA XML.

XML Notes

All XML should be validated against the version of the schema you’re developing against, especially before sending files for testing.

All date/datetime fields should be the localtime for the location where/when the activity occured. xs:dateTime fields should be sent in in ISO 8601 format with the timezone information. If any time component isn’t recorded in the source system please set it to 0.

ASCII or Unicode encodings are preferred. Any other encodings must be indicated in the XML header and consistently applied throughout the document - a common issue with PV XML feeds was that the document as a whole claimed to be ASCII but individual sections would be in CP-1252.

Coding Standards

In line with the NHS the UKRDC has adopted SNOMED as its preferred coding standard. We have however found that not all specialised renal concepts have been coded yet, and that getting them added takes more time than we had expected.

Where it is not possible to use SNOMED to code, or fully code a data item the backup is to use the UKRR Code Lists. In the case of Test Results / Observations this is the QBLXX item used in the V4 dataset for the value of that item. It is possible to use a mixture of Coding Standards for one element.

If any System is using SNOMED natively - i.e. where the user can potentially pick any code and not just the list supplied by the UKRR then we would like to discuss this with the system supplier. The hope for the future is that the site will record the most descriptive code possible and that grouping of the codes will only happen in the UKRDC.

Where a data item has a field to specify the Coding Standard (typically in a triple set of CodingStandard, Code, Description) you must only supply the Coding Standard when there is a value for the Code.

Patient Record Header

In the Patient Record header there are some attributes. The meaning is as follows -

SendingFacility - This should be the Main Renal Unit as submitted in PAT01 in the UKRR Quarterly Files. Systems which serve multiple Units MUST have the value of this reflect the Unit the patient is attending as this is used for the UKRR report, as well as other purposes such as restricting access to the data. If a patient moves Hospitals within the group the System should try to avoid re-sending activity which happened at the previous Hospital to avoid it being attributed to the new one.

SendingExtract - This should be “UKRDC” for the feeds from Renal System. This controls the logic we apply processing the data.

Standard Validation

Incoming Files are Validated against the UKRDC Schema. In addition we do the following checks which will cause a file to be rejected.

• All files must have an MRN type identifier. (“Local Hospital Number”).

• All files should have an NI type identifer. (NHS Number or UID).

• Any Post Codes must meet the Code Format.

• GP / GP Practice Codes must meet the Code Format.

• Any Dates should be possible - by this we mean they should not be before the patient was born, after they died, or years in the future.

• Where a Field has a CodingStandard the Code supplied must exist in our Code List.

What / When / How should Data Be Sent?

What - UKRDC Cohort Selection

When - Communicating Changes

How -

Files should be named -

ABC123_11111_0000000000.xml

Where

• ABC123 is the SendingFacility value

• 11111 is the batch number. The batch number should be incremented each time the extract is run.

• 0000000000 is the NHS Number or UID for the patient.

Each file should then be individually PGP encrypted using the PatientView public key.

The files should be sent to us via SFTP. We have SFTP servers on both the internet and HSCN depending on which is best for you. Please contact the UKRR ( rrsystems@renalregistry.nhs.uk ) for credentials.

PKB

At present the following items are currently sent to PKB, matching what was available in the “PV XML” feed.

• Patient

• Diagnoses / RenalDiagnoses

• Documents

• LabOrders / ResultItems

• Observations

There should be a way to record that a patient has joined PKB in the renal system. Whereas with the old “PV XML” feed this was typically done as a single checkbox we would suggest that the system record each program the patient participates in separately.

Documents should ONLY be sent for patients who are on PKB as we do not use them for any other purposes.

There are some tests which are displayed in PV which are not in the UKRR dataset. These are listed in a table at the bottom of the Result / Observation page. They should be sent using a Coding Standard of “PV”. If there are any other tests which your patients would like displayed in PKB please let us know.

RaDaR

Same as with PKB.

• Cause of Death

UKRR

We suggest that to approach this you look in the UKRR V5 dataset and for each item you intend to submit look at the “UKRDC / RDA Mapping” column in the worksheet. This will show you which element in the schema needs to be populated for that item.

For V5 this includes the following items in addition to what is required by PKB/RADAR:

• Assessments ( Care Plans )

• Dialysis Prescription

• Dialysis Session (Procedure)

• OptOut

• Transplant (Procedure)

• Treatment (Encounter)

Under our s251 approval the UKRR has permission to collect all information which is relevant to our Audit work. This means that whilst we only require sites to collect the information from the V5 dataset we would appreciate it if Sites/Systems would a) continue to send items from V4 if they are being recorded in the renal system anyway and b) would send Any Results, Diagnoses, Observations etc. being held in the Renal System even if they are not ones which we specifically ask for. If there are any gaps in our code lists please let us know.

UKRR Quarterly Extract

The UKRR will generate a quarterly file for each site from the UKRDC. This will be to the V4 specification and validated using the existing processes. Feedback will be given by the Data Managers and Units should provide information to the UKRR Data Manager then make any corrections which are required in the renal system,  so the updated data is sent to the UKRDC. We will then produce new versions of the quarterly file as required.

The intention is that once more UKRDC feeds are operational a schedule of when we will be generating the initial extract will be produced to allow sites to do any corrections they wish beforehand.

Submission Feedback

This should be agreed with the UKRR but the general process is -

Individual files should be sent to your contact at the UKRR as soon as possible to allow feedback to be given. If the files contain patient identifiable information then they should be encrypted using PGP, the same as if they’d been sent via SFTP.

Once the extract is mostly complete we will create a Staging SFTP Account. This will load automatically load files into our test instance in the same way as would happen in Live.

UKRR staff will provide feedback or you can look yourself via the UKRDC UI ( See here. ). Supplier staff who wish to have access should have each unit they support contact the UKRR by e-mail to approve them having access as the data will be patient identifiable.