...
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
| Note |
|---|
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
...
Suggested Process
Patient Enrolment
The patient signs up to PKB
The patient contacts the Renal Unit and completes a consent form.
The patient is added to the Renal Organization
We are assuming that the Organizations will only ever contain patients from Renal Units (Main, Paediatric, Satellite etc.).
Although there isn’t a need at present to send additional data for patients who are only attending a hospital which sends data directly to PKB (for example Imperial) we think it worth considering if this process would work with these without us having access to non-Renal patients.
4. With the data feeds as-is most units will need to enable the “PV” feed in their Renal system.
Patient Moving Units
Basically as-above - the patient needs to contact the new unit and ask them to add them to the new Organization etc.
UKRDC Sending Data to PKB
The UKRDC will have credentials for each of the Renal Organizations
For each of the Organizations the UKRDC will make an A19 query for each of them asking for patients who have joined within the last X days.
The original idea was that each NHS number would be queried individually, triggered by a unit sending data for a patient for the first time. While this works with the “PV XML” feed where the feed being turned on correlates to the patient joining PKB we can’t make that assumption with an “RDA XML” feed and the alternative of continuous checking of each patient without an existing PKB Membership would be too resource intensive.
3. For all matched records a PKB Membership will be created in the UKRDC. This will enable the flow of data to PKB.
4. If there are gaps in this process, such as if a patient had joined PKB some time prior to being added to any of the Renal Organizations the backup would be for a PKB Membership to be created in the UKRDC via the Web UI - this could potentially be done by Units themselves.
5. With the process as-is we will a) Add patients to the appropriate Renal Teams and b) Add patients to the “Renal Association” Organization, both via A28 Messages.
UKRDC Pulling Data from PKB
This is a future requirement but at the moment we assume this will be done via membership of the “Renal Association” Organization.
Cease Data Send on Patient Withdrawal from PKB
If a patient withdraws from the PKB (i.e. asks for their account to be deleted) their PKB Membership needs to be manually deleted from the UKRDC. We assume that this will be be infrequent enough not to be a problem. This would be done via the UI either by the Unit directly or by UKRR staff.
The risk if this is not done prior to the account being deleted from the PKB system is that we will send another A28 message and effectively re-create the account.
Cease Data Send on Patient being Inactive
Because PKB’s default position is to retain patient data unless ordered otherwise we have a concern about continuing to send data when a patient has ceased to use PKB, or, in the case of those patients who were migrated from PV may never have used it.
We intend to have a process using the “Indicator” last-login report you’ve already provided where those patients who have not logged in for a period of a year after their UKRDC PKB Membership was created have that membership ended so no more data is sent.
We will need a way that the “Indicator” report can be run regularly as part of an automated process, ideally via SSH or an API call.
I am also not sure whether at present it is working on the “Renal Association” Organization alone whereas we probably need it to also include memberships of the Renal Unit Organizations incase they don’t perfectly overlap.
If the patient later changes their mind a new membership can be created via the UKRDC UI and a send of the data backlog triggered.