Development Notes
PV to PKB Channel
The current proposal for this is to take the PV->RDA output that would normally be sent to the repository and remap his to. HL7 suitable for PKB. For files sent via the RDA we would just map the RDA file potentially with extra data.
RDA files supplied as UKRDC feeds will use a different coding scheme to PV files /wiki/spaces/UKRRD/pages/1730216146 This suggests that instead of feeding off of the incoming RDA file we should be extracting data from the UKRDC and then formatting it as HL7 in order to ensure we create consistent result names. Perhaps a modified PV-Extract to return an HL7 file instead of a PV-XML. Â
Much like with PV-XML PKB does have some field size limitations - string length restrictions - that need to be observed. These are documented on the PKB - HL7v2 pages where known.
Planned Process
Replicate the current process used to generate PV feeds from the UKRDC.
We have a channel PV identify Changes which feeds a list of identifiers to a channel PV Outbound this calls a routine pv-extract which creates the PV XML file for the current PV website.
We will create a new channel PV Outbound PKB which will call a process pv-extract-hl7 which will create a suitable HL7 message for pkb. The channel in mirth will handle the sending of this file in a similar way to the current channel does to the current PV website. All messages are submitted under the same sending facility (Renal Association) so the data loses its sending unit association.Â
Questions
How will PKB handle Medications which are a point in time?
Will we need to send historic data? if so how will this be done? Will we need to extract the data from the UKRDC and convert to HL7?
Should we use a modified PV-extract to handle mapping to the PV result names. Should we use a different/standard naming scheme?
Do we need a merged data view for the UKRDC to more readily compare data on PKB and that held in UKRDC? Currently results are shown by sending unit.
Check "PV" Membership and update membership on UKRDC
The PKB system will provide a single "PV" TEAM which will need to be queried using an HL7 A19 call to get a list of NHS numbers present. This can be used to update memberships. There is some ambiguity as to whether this would be a combined cohort of RaDaR/PV/and ultimately Audit patients differentiated by consent. It may be that the returned list will need to validated as PV conesnt before updating.
RaDaR members can be added to this Team either via a csv upload or using HL7 queries. PKB assumes NHS numbers are validated so before adding new RaDaR members some validation of the entered NHS number is required. PKB can be queried for a given NHS number to see if there is a record and if there is the demographics are returned which could be used for validation? Also it could be that the radar entry must be traced validated before registering on PKB?
Planned Process
Currently the only way this could be done is query PKB for a list of NHS numbers in the Renal Association Team this would not have any renal unit association etc but the assumption would be if in the group then they have a PV membership and so create a ukrdc membership if one doesn't exist. Relying on the receipt of a PV Feed is know to be an unreliable way of doing this but is currently the only alternative. How Consent boxes impact this is currently unknown.
Questions
How will the different groups be identified?
Will they each have individual consent?
Can this be queried for the group?
PKB to UKRDC
This section is to list questions relating to development of the PKB to UKRDC. This would receive data from PKB and transform it into RDA data.
Assuming we now have a PKB membership information either as PV/RadaR/Audit or anew on PKB membership this channel would query the API and pull back the individual records for each person. It would need to handle refused consent and we would would need to consider how the National Opt out would fit into this. The returned file would then need to be converted into an RDA file to save to the database.Â
We know some fields are held as snomed codes on PKB these will require mapping when sending through to RaDaR. The current list are mainly Measurements on PKB (Observations on UKRDC).
Questions
How are multiple data data sources sent through?
How will the data be stored in the UKRDC will there be multiple record sets to reflect the different sources?
What coding scheme will be used for PKB data? Will it need mapping to Audit/PV codes or use the supplied codes. if using the supplied codes these will need mapping for the RaDaR extract.
Will there need to be a mapping table between incoming source identifiers and UKRDC identifiers? Does PKB use ODS codes for sites? How should the GP data be mapped?
Are Medication units normalised?
How will permitted lists be maintained? PV, Audit, RaDaR etc. These would need to reflect patients that can be requested from PKB.
NHSBT Wait listing
Pull list from PV membership and send to nhsbt in a similar way as we currently transfer a file from PV. The returned file then needs to be transformed from the supplied format in to a series of HL7 updates where with the transplant status in. These then need to be sent through to PKB. It is currently suggested that Transplant status should go in the careplan.
Testing
Needs some PV users to compare access to their data via PKB and patientview to see what needs tweaking/isn't working before go live.
National Opt out does it need to be applied...if so how?