/
Proposed Tasks

Proposed Tasks

Owned by Tim Whitlock (Deactivated)
Last updated: Aug 18, 2020Version comment

CSV Upload - Phase 1

Patient Knows Best says:-

Mass creation of patient records by CSV upload . The CSV should include all available demographics and email addresses. CSV upload process has the additional benefits of:

  1. The CSV upload reporting of creation outcomes is valuable: https://manual.patientsknowbest.com/coordinator/records-mass. This can be used to determine which patients are already on PKB but part of another organisation.
  2. The CSV upload can trigger an invite to an existing record when an email is included. This is not currently possible via HL7.

This will then be followed by supplementary information to enrich the patient record via HL7 messages including.
- Demographics (ADT^A31).

- Verified NHS filtered.

- ZRX medication segments included where available.

- DG1 diagnosis segments included where available.

- Email address included in PID segment where available.

- Test Results (ORU^R01).

- LOINC codes should be included in OBX-3.1/OBX-3.3 where available. PKB has an existing set of LOINC mappings where there is likely beneficial overlap.

- Documents (MDM^T02)

- Appointments (SIU^S12)

This would then be followed by:

PKB should be sent all the data that is currently on RPV. This will mean that the upload of data to the patient records may be broken into two pieces of work:

  1. A one off upload of existing historical data to PKB to ensure that PKB records are equivalent to the current RPV records. This should be done prior to the patient invite or in parallel to the invite so that the records are present when the patient registers on PKB.
  2. An ongoing feed of new / updated data to the PKB records.

PV/RDA Feed to PKB - Phase 1

Two options/methods for this task:

  • Copy incoming RDA file or converted PV file RDA  to a new channel and transform it to HL7 then send to PKB
  • Customise the PV-extract to produce an HL7 file and send to PKB

The former will require mapping of the result names for incoming RDA files because the UKRDC feeds use the Audit dataset naming by default and only PV naming if the value is not part of the audit dataset.

The latter would "just" change the output format of the pv-extract code to create and HL7 file. This process would replicate the current PV-Outbound channel but use a different PV-Extract and also connect to the PKB api instead of the current PV one.  

pv-extract-hl7 to be developed to work in the same way as the current pv-extract that produces a pv-xml file for the current Patientview server.

PKB to UKRDC -  Phase 1 late/Phase 2

This will involve downloading the record data for PV and RaDaR patients whose data is going directly to PKB. It is likely there will need to be a mapping between the way results are held/presented on PKB and the conventions required by the UKRDC. There is also a question of scope of the data in that there may well be more data from different sources than just the required renal data.

This again would probably be a channel triggered every x hours to download data on PV patients we know are receiving data directly (how will we flag these?) It is likely that we would need a custom process to convert the HL7 file to RDA and do any mapping required for result names/coding etc. This would then just feed in to the standard RDA path. It is unclear at the moment if data received will indicate a source and so we would need to create multiple feeds for multiple sources.

If access is denied to the data by PKB it would mean the consent box had been un-ticked and we would need to flag the patient as no longer a PV member. As it stands at the moment we would need to include all RaDaR members without a specific PV membership. Not sure if we can distinguish RaDaR only membership using consents?

Create PV Membership - Phase 1 - late

On a regular basis we will need to request a list of members of "PV" from PKB it seems this would amount to all people in the Renal Association space. If we don't have a PV membership for them we would need to add a membership possibly by requesting the required basic demographics. Full details are unclear at the moment. A question mark remains over distinguishing RaDaR only memberships and those with PV membership. This process would effectively create a PV membership if the record is present.


NHSBT Transplant Status - Phase 1

Mirth would need to create the list of NHS numbers currently produced by PV and send this to NHSBT via the sftp server. It would then need a channel to pull down the response file, process it and create updated messages for PKB on the transplant status for the patients. It would make sense to store this info in the ukrdc and have a separate process that queries for updated entries and only send that information to PKB.

We currently don't know where this transplant status data would be held/displayed so it is unclear what HL7 message will be required to send this information through. It is likely this information will be asked to be synced to RaDaR.   


RaDaR Syncing

Depending on how the data is stored ie the result labels used the RaDaR syncing code will need updating to accommodate this. ie if snomed codes are used in the feed from PKB then we would need to map this in the syncing.


Future development

Expanding this to support gathering data via PKB for Audit