This assumes that the UKRDC will receive identifiable information for all patients about whom we wish to exchange data with PKB. The implications of this will be discussed elsewhere in UKRDC documentation.
Current Situation
UKRDC Inputs from Units
“PV XML”
This is the historic feed which is still supplied by the majority of sites. Although we refer to it as “PV XML” because that was the original use it is now incorrect to associate it just with PatientView as its use has widened to include our RADAR system, as well as being a source of data to several research projects (SIMPLIFIED, PHOSPHATE, etc.). The renal unit will have satisfied themselves that the patient having consented to one or more of these projects gives them permission to enable the feed but there is nothing in the file itself to documents which project(s) gave rise to that.
“RDA XML”
This is the new feed which is presently supplied by a small number of sites but is expected to be used by the majority over the next year or so. An important difference here is that while the feed can be still enabled for an individual patient due to project participation the majority of feeds we receive will be because the patient meets the criteria for collection under s251.
While with the “PV XML” the majority of patients having the feed enabled would be for the purposes of PatientView, with the “RDA XML” one that ratio is very much reversed.
Input Processing
Both feeds are loaded into our UKRDC system. Any “RDA XML” files are accepted but with the “PV XML” ones we require that they have an open Program Membership for one or more of the projects that could use the feed. If no such memberships exist the file is rejected and the unit informed.
Memberships
As mentioned above we have a concept in the UKRDC of a Program Membership which is a dated period between which we assume the patient to be part of the corresponding project. Although for information reasons we may break these down into the individual Units/Groups a patient is a member of on a system for IG purposes we assume that membership of the system/project in any way allows for data to be collected from any Unit.
PV
PV sends the UKRDC a message (in “RDA XML” format) when a patient is added to a group (this includes account creation) or removed from a group (which includes deletion), or where the demographics of the patient have been changed.
RADAR
RADAR sends the UKRDC a message (in “RDA XML” format) when a patient is initially added and once a week as part of a general synchronisation.
Others
Other projects work in different ways but the essential behaviour is the same in that a patient has a Program Membership record opened when they join a project and closed when they leave.
PKB
If a patient has an open PV membership and does not have an open PKB membership one is created for them.
We do not close the PKB membership if they subsequently close their PV account (or their Unit does so on their behalf) as we cannot assume the two events are connected.
We do however close PKB memberships if a patient has a Date of Death added to their record.
Until recently we would also create a PKB Membership if a patient had data in “PV XML” format regardless of whether they had a membership. The assumption here was that a site sending us data in that format was likely to signify they wished to be on PKB but with the new RADAR consent forms we are no longer happy about making that assumption.
Most significantly we currently have no way of knowing when Renal patients are added (or indeed removed) from PKB.
UKRDC Outputs to PKB
We require that a patient has an open PKB Membership in order to send data to PKB.
PKB Inputs to the UKRDC
This is not yet available.
PKB “Memberships”
Initial Send
The initial demographic send was done using everyone who was on PV when we started sending data, excluding those for whom we had a Tracing DOD. This was done using the “Renal Association” credentials. Note - this may be referred to as the “Research” data pathway.
One record is sent per patient (by UKRDCID) using their latest demographics.
This also created a PKB Membership record for them in the UKRDC.
Unit Send
When each Unit comes onboard we do a send for all patients, excluding those for whom we have a Tracing DOD. This is done using the “Partner” credentials, referred to as the “Partner” data pathway.
Multiple records are send depending on how much data they have. Some types of data may be duplicated if we hold data from multiple sources (“Migrated from PatientView”, “PatientView XML”, “RDA XML”).
New Patient
If a patient meets the criteria for having a PKB Membership and does not already have one then data is sent to the “Research” data pathway, as with the initial send and a PKB membership created in the UKRDC.
Dead Patient
If a patient has an open PKB membership in the UKRDC and a Tracing DOD then an update is sent to the “Research” data pathway. Their PKB membership in the UKRDC is then closed.
Needs
This is the bit most UKRR people need to review.
Sending Data to PKB
In order to send data to PKB we need a unit to have enabled the data send (at least for now, this becomes more the default as we move to “RDA” feeds).
We then need to know that the patient has consented to PKB. The minimum we require for this would be that they had an account at all, but it would be reasonable to assume that they would be a member of one or more renal units.
Alternatively they could just be a member of a single Organisation that we own. The complication with this as-is is that we only have a single we only have a single “Renal Association” Organisation. If that’s used in any way to control the flow of data from the UKRDC to PKB, what about if they wish to opt-out from the reverse happening and their data being included in the UKRDC for the purposes of the UKRR audit? My (GS)'s suggestion would be that for this went for this approach a second organisation would need to be created that represented the UKRDC as a data source, whereas the one we have now would be for the UKRR as an organisation that they allow to see their data.
I (GS) have a question about how an account is deemed to be dormant on PKB (and whether we, from a UKRR perspective need to take account of that). My general question is that as part of the PKB migration we have created a lot of PKB accounts. Again thinking back to the “RDA XML” data being sent by default should we have a mechanism to stop sending data if a) The patient expressly wants their PKB account shut or b) merely stops using it for a period of time - say a year or more?.
Current Proposal
The current proposal is to use A19 messages to query whether a patient is on PKB. A positive response would result in a PKB membership being created in the UKRDC and the flow of data starting.
The logic should be -
Patient Type | Expected Response |
|---|---|
Patient at Renal Unit | Yes |
Patient not at Renal Unit | No |
Pulling Data from PKB
One possible assumption here is that we only pull from those who are with the “Renal Association” Organisation. The problem we have though is that for Imperial or others who do not use PV (or more correctly send data via the UKRDC) those patients will not have been added.
We cannot do anything though that requires us sending data to PKB without us first knowing the patient is on PKB. I.e. we cannot do a Research Channel Send” of all RADAR patients to PKB to create those “Renal Association” entries because some of the patients we create won’t be on PKB.
As before we also need to allow for patients to break this relationship by opting out without breaking the flow of data into PKB.
Proposal
Patient Type | Expected Response |
|---|---|
Patient member of Renal Association | Data Available |
Patient not member of Renal Association | Data is not Available |