Renal PatientView specification for interfacing from renal unit EPRs

RPV specification for interfacing from renal unit EPRs

Extracted data is sent to the Renal PatientView server by (s)FTP as an encrypted file. The specification for EPR providers is presented as a series of required functions without making any assumptions about how data is stored or extracted in the EPR. See also the XML schema showing the tags and data items required; you can download the XML schema and a sample XML file (with correct filename etc) from the foot of the RPV page, see 'Info for suppliers'.

1 Register a patient. A simple method should be available for authorised renal unit staff to initiate data sends to RPV from their EPR. This must involve correct identification of the patient but should be quick and easy to operate, eg by setting a flag. Patients should not be registered for RPV by default.
Commentary: Local unit admins also have to register the patient on the RPV server in addition to setting the flag in the EPR

2. Suspend a patient. It should be possible to suspend the transmission of data from the EPR without deleting the patient from the RPV server. This could be a very simple function which is set and removed manually on a screen on the EPR (e.g. simply by removing the flag).

3. Remove a patient. This command suspends data transmission on a patient but also sends a ‘remove’ command to the RPV server which leads to deletion of the RPV registration and of all stored information on that patient. There should be an ability to (a) do this manually, and (b) automatically 90 days after the death of a patient is recorded on the EPR.
Commentary: request in writing is required for voluntary removal as their RPV record may include historical info and data from more than one unit which cannot be reassembled. A downloadable form explaining this is available. When a patient is removed from RPV, their GPs registration and access to their RPV record should also be removed. The same GP may still have access to the RPV records of other patients.
In the XML file, Status (in <flag> tags) can be New, Followup, Suspend, Remove, Lost or Died. For the last 4 these files otherwise include only: sequence, dateofreport, flag, surname, forename, dateofbirth, Sex, nhsno, hospitalnumber.

4. Automatic information extraction/send

(see schema for list of items): On FIRST (<flag>New</flag>) send, the last 10 items or values under each heading (e.g. serum creatinine values) should be sent, except for letters, which should not be sent retrospectively.

On SUBSEQUENT (<flag>Followup</flag>) sends, the last ten items (including letters dated after patient’s registration) should be sent. Static data (eg registration, diagnosis and GP details) need only be re-transmitted if they have changed if this can be determined.

Automatic sends should be configurable in frequency and timing.

To reduce data transfer and handling, only data from records changed since the last transmission, or (if identifiable) individual new or changed data items should be sent. [Note: in Proton, on each send, all static data and the most recent 10 time-related events are sent, as it is not possible to discern which data is changed, only that the record has been updated somehow]

Thus the First Send allows some historical data to be transferred on initial registration. Subsequent sends allow for amended information to be overwritten automatically for up to 10 items. Sends are usually configured to run automatically once daily during the night. [Note: originally this specification was for 10 days worth of items rather than 10 items. This is an alternative implementation if in place already].

5. Manual information extraction/send – authorised unit staff able to register patients should be able to (a) manually trigger a first or subsequent data transmission before the automatic send would normally occur. (b) In addition they should be able to configure the sending of information from any specified date or date range.

6. Transaction log – The EPR should be able to show a record of all changes to a patient’s RPV status and the time and date of data transmissions to RPV.

7. RPV data set. All possible items are shown in the XML schema, with the required tags. It should be possible to configure the system to include or exclude specific data items in individual units, and to alter this configuration quickly and simply. (Note that this configuration affects transmissions for all patients in a unit, not individual patients).
Some units may exclude transmission of Medicines, for instance, because they are not confident that their records are accurate. Apart from the example of drugs, our advice is that all values and items should be included if they are available.

8. Data conversion. Occasionally numeric data have to be converted to a new format before they are displayed on RPV, eg Hb is shown in g/L whereas this is stored in g/dL in some EPRs. Conversion should be done before transmission to RPV.

9. Addition of new data items. The RPV data set will be expanded. These additions will be published at least 4 months before implementation. Developers should make it easy to add new data items. New data items were added March 2009. These are shown in the XML schema.

9a. Configuration of additional data items. (March 2009). An interface should be provided for local unit RPV admins to configure the sending of additional time-related tests. Typically these will be data items that are recorded less commonly, and less universally that the items in the standard dataset. They are also likely to be items that may be recorded in many different formats and units. Examples could include microbiology results, viral DNA titres, etc. It may be possible to use the same mechanism to send items that are not in time-related fields. [Note: the XML for this new element is not yet defined]

10. Encryption and ftp transfer. Data must be encrypted before transfer to the RPV server. PGP encryption (or its unix equivalent GPG) is used. The RPV public key is available from (xxxx). Data should be sent by sFTP to [IP number]. [Note: some unmodified early adopter centres are still sending encrypted files by FTP]
Software developers can write their own routines for these tasks or they can re-use existing software (further information available).
11. Permissions. It is the responsibility of renal units to seek permission from their Caldicott Guardian to send these data to RPV. including opening a data port to enable FTP. Documentation and justification to support this is available from neil.turner@ed.ac.uk.

12. Guidance. A guide for local RPV admins to the RPV server end is available online. Those configuring the interface of local EPR systems to RPV should provide written information at a similar level to explain how to undertake the aspects of the tasks described above in the local EPR system, and how to carry out any simple troubleshooting that may be required. Note that it is not expected that such staff members will be IT professionals.

Please leave comments at the foot of this page! Someone at renal@ed.ac.uk will automatically be notified that the comment has been sent. Or you could comment on the RPV blog