...
| Page Properties | ||||
|---|---|---|---|---|
| ||||
|
IN THE MATTER OF PATIENT KNOWS BEST AND IN THE MATTER OF A PROPOSED MODEL
FOR PROCESSING PERSONAL DATA
ADVICE
By instructions dated 25 th May 2020, I am asked to advise Patient Knows Best (“PKB”), the developer and operator of a technology platform for health information. In this Advice I address the questions raised in those instructions, and also the additional points raised in a subsequent email from my instructing solicitors dated 9th June 2020.
This advice is about whether PKB’s preferred future model of operating is lawful, in particular as regards data protection law. It involves discussion of the General Data Protection Regulation 2016 (“GDPR”) and the Data Protection Act 2018 (“DPA 2018”). I have been provided with enclosures, some of which consist of material produced by Kaleidoscope, a data protection consultancy that has been advising PKB. These enclosures contain a considerable amount of detail about how the PKB platform operates. Below, I set out a summary of the relevant factual background, based primarily on the account set out in my instructions.
I am happy to assist with any further advice arising out of the matters discussed below, if asked.
Background and context
4. PKB is the developer and operator of a technology platform, designed to bring together patient data both from patients themselves and from health and social care providers (“Providers”) into a single easily accessible record. The PKB platform allows patients to login so as to view appointment letters, test results, multi-disciplinary care plans, and other health information. Patients can choose which aspects of their record (if any) they wish to share with other individuals, such as healthcare professionals, carers, and family members.
5. Patients can only sign up to PKB if they have been sent a specific invitation to do so by a Provider; they cannot simply choose to do so of their own volition. The invitation includes a link to the PKB registration and sign up process.
6. My instructions distinguish between the role of PKB in relation to two sets of information, referred to as the “Patient Record” and the “Patient Account”. The distinction between these two sets of information, and the different role played by PKB in relation to each of them, is central to the issues discussed in this advice.
7. The Patient Record consists of patient personal data entered by Providers. Hitherto, this data has been processed on the understanding that the data controllers are the Providers, and that PKB acts as a data processor for the Providers; one of the issues raised in my instructions is whether this understanding is correct.
8. I have seen (at Enclosure C to my instructions) a copy of a sample data processing agreement between PKB and a Provider. I am told that Providers are contractually obliged by their agreements with PKB to encourage patients to activate their own PKB accounts.
9. The Patient Record can be accessed by clinicians in connection with the care and treatment of individual patients, and also enables the sharing of personal data between Providers where there is a lawful basis to share data. If PKB is indeed a processor of the Patient Record, then PKB’s processing can be justified by reference to whatever lawful bases of processing are available to the Provider; hence, if the Provider’s processing of personal data satisfies one of the conditions in GDPR Article 6 and (in relation to special category personal data) Article 9, then PKB’s processing of that personal data (as data processor for the Provider) will be lawful on the same basis.
10. I understand that Providers in Wales have concluded that the only lawful basis available to the Providers themselves under the GDPR in respect of the Patient Record is consent: i.e.
the Providers can only rely on the bases of processing set out in GDPR Article 6(1)(a) and 9(2)(a). The key documentation in relation to this issue is at enclosure E(i) and E(ii) to my instructions. The purported justification for the position taken appears to be that: the PKB platform is for information only; hence it does not satisfy the definition of a health record in DPA 2018 section 205; and this prevents Providers from relying on Article 9(2)(h), because the processing in relation to the Patient Record does not relate to a patient’s care and treatment.
11. The Patient Account consists of information entered by the patient on to the PKB platform once the patient has activated their account (assuming that they choose to do so). In relation to this information, PKB’s understanding is that PKB acts as data controller, since it determines the purpose and manner of processing. PKB will only allow third party access to information in the Patient Account with the consent of the patient.
12. In cases where the patient does not activate their PKB account, the PKB Platform will contain a Patient Record for that patient, but not a Patient Account. On the assumption that PKB processes the Patient Record as a data processor, then the only role played by PKB in this scenario will be as data processor for one or more Providers. If however the patient does choose to activate their PKB account, then PKB will play a dual role: PKB will be a data processor in relation to the Patient Record, and a data controller in relation to the Patient Account.
13. My instructions refer to a number of issues that arise as a result of the above dual role of PKB.
(i) Where PKB acts as a data controller, PKB is responsible for a range of compliance obligations in relation to the GDPR, the DPA 2018, and the common law duty of care. This includes the need for PKB to identify a lawful basis of processing (under GDPR Article 6 and Article 9) in relation to the processing of personal data by PKB.
(ii) My instructing solicitors’ present view is that the only available bases of processing are consent: i.e. PKB must rely on GDPR Article 6(1)(a) and Article 9(2)(a) (the latter of which requires explicit consent).
(iii) If the processing by PKB is based on consent, then this gives rise to a range of rights for the data subjects (i.e. the patients) under GDPR Articles 16-21. I note that the processing of personal data on the PKB platform does not involve any automated decision-making, or profiling, so as to give rise to rights under Article 22.
(iv) Particular concern arises in respect of requests for erasure of personal data under Article 17(1)(b) where the patient withdraws the consent on which the processing of their personal data is based. In general, my instructions suggest that most patient requests for erasure would have to be granted, while recognising that in some circumstances there might be scope under Article 17(3) for resisting the request.
14. A further complication arises where a Provider has, with the consent of the patient, accessed part of the Patient Account in connection with the provision of healthcare and treatment to the patient. The information in this part of the Patient Account is then potentially held in a dual capacity by PKB: as controller, through provision of the Patient Account to the patient; and as processor, on behalf of the Provider, in respect of the record of what information was accessed by the Provider in connection with the patient’s treatment. I understand that Provider IT systems do not synchronise with the PKB platform so as to allow the Provider to extract the information from the PKB platform; hence the only record as to what information contained in the Patient Record has been accessed by the Provider would be held on the PKB platform, not on the Provider’s own system.
15. My instructions indicate that PKB’s role in this situation is unclear, and that the Patient Records and Patient Account effectively become blurred. This gives rise to two areas of concern (although these are outside the direct scope of my instructions): (i) have all necessary transparency obligations been fulfilled at each stage by PKB and the Provider, in their dealings with the patient; and (ii) relatedly, can the patient genuinely have an opportunity to request erasure of their personal data in these circumstances, and how clearly has the application of their right to erasure been explained to them.
16. Further, as far as PKB’s relationship with Providers is concerned, it is necessary to distinguish between: the relationship between PKB and the Provider while there is a subsisting contract between PKB and the Provider; and their relationship after that contract has come to an end, when PKB may still be retaining data so that the Provider can have access to that data as a record of its dealings with the patent.
17. My instructions refer to various practical issues related to the above:
(i) During the contract, it may be necessary to determine which data has been added or accessed by Provider and/or patient, and to understand the implications this has from a data protection perspective;
(ii) After the end of the contract, it may be necessary to determine which data has been viewed by the Provider and is therefore liable for retention by PKB, and which data has never been viewed such that it should be destroyed;
(iii) After the end of the contract, it may be necessary to deal with data which has been viewed by the patient but not the Provider: arguably, this should be retained under the control of the patient and is subject to exercise of the patient’s rights including erasure;
(iv) After the end of the contract, it may be necessary to deal with data that has been viewed by either party but where the patient has added further data; and
(v) After the end of the contract, it may be necessary to deal with data that is patient controlled, but where the patient is deceased: the issue is, how would PKB know that the patient had died, and when would PKB delete the data?
18. Against this background, it has been suggested that an analysis under which PKB acts as a joint controller (rather than as a processor of the Patient Record or as sole controller of the Patient Account): (i) is the correct legal analysis of the basis on which PKB processes data; and (ii) would assist in resolving some of the issues identified above.
19. The suggestion is that PKB is, in fact, acting: (i) as a joint controller rather than a processor in respect of the Patient Record, from the point at which the patient activates their account; and/or (ii) as a joint controller in respect of the Patient Account. My instructions recognise (rightly) that determining the extent to which a party fulfils a particular data protection role is one of substance rather than merely applying a label. To this end, Kaleidoscope have provided some initial analysis (at slide 10 of Enclosure B to my instructions, which is a PowerPoint presentation prepared by Kaleidoscope) as to the facts which could support the analysis that PKB is a joint controller in relation to the Patient Record.
20. In very brief terms, the suggestion is that PKB is a joint controller because of the following:
(i) through its contractual obligation on Providers actively to encourage patient activation of the patient account, PKB are jointly determining the purpose of processing; and
(ii) the utilisation of the PKB platform means that PKB jointly determines the means of processing.
21. The key identified advantage to the joint controller model is the potential benefit of particular lawful bases being extended to PKB, which PKB would not otherwise be able to rely upon if acting as an individual controller. This is set out in slides 11 – 15 of Enclosure B. In summary this material envisages that:
(i) The provider can rely upon Article 6(1)(e) as its lawful basis;
(ii) This basis could be extended to PKB, as it is performing a statutory function derived from the NHS Constitution;
(iii) PKB can rely upon Article 9(2)(g), in conjunction with DPA 2018, Schedule 1;
(iv) The PKB platform is conducive to providers satisfying the duty to share information set out in Health and Social Care (Quality and Safety) Act 2015.
22. Against the above background, I am asked to advise on the following six questions, and 6
on any other issues that I consider relevant to the legality or viability of the proposed framework.
General issues
● Question 1 – Do I agree that the only lawful basis available to PKB in respect of the Patient Account is consent? If not, which specific alternative bases could be relied upon? This question is predicated on the basis of PKB acting as an individual controller in respect of the Patient Account, and not in the context of a potential joint controllership.
● Question 2 – To the extent that this is not effectively addressed elsewhere, do I agree with the suggestion from Welsh providers that the only lawful basis available to them (the providers) in respect of the Patient Record is consent?
Joint controller issues
● Question 3 – Is PKB acting as a joint controller in conjunction with providers in the context of the Patient Record?
● Question 4 – If so, what lawful bases are available to the provider and PKB respectively? In particular, does the joint controllership facilitate PKB’s reliance on any lawful bases other than consent, and if so which?
● Question 5 – What are the joint controller considerations and implications in respect of the Patient Account, in circumstances where the provider accesses the Account in connection with the care and treatment of the patient? I am asked to address this question by reference to the lawful bases available to the respective parties, including the requirements for ongoing retention of the data.
Lawfulness
● Question 6 – Do I have any further key compliance concerns in respect of any aspects of the PKB platform?
23. I address these six questions below, in turn.
General Issues
24. Question 1 is predicated on the basis of PKB acting as an individual controller in respect of the Patient Account, and not in the context of a potential joint controllership. I am asked whether I agree that the only lawful basis available to PKB is consent: if not, which lawful bases could be relied upon?
25. As indicated above, the information in the Patient Account is added to the PKB platform by the patient, and not by a Provider. In answering question 1, I shall focus on information that has been placed into the Patient Account but has not been accessed by a Provider. The reason for this is that, in the context of question 1, I am specifically asked not to focus on a joint controllership approach; and the question of joint controllership only arises in relation to the Patient Account as regards information that has been accessed by Providers.
26. Focusing therefore on information that is contained in the Patient Account and that has not been accessed by a Provider, is it correct that PKB is the sole data controller of that information? In my view the answer is yes.
27. PKB is processing such information: holding that information on the PKB platform is, in itself, a form of processing, and any use or disclosure of the information also amounts to processing. PKB must be processing either as a processor or a controller. If PKB were a processor, then this could only be on the basis either that: (i) a Provider was the controller; or (ii) the patient themselves was the controller. As to (i), there can be no question of any of the Providers being a controller: in relation to information in the Patient Account that they have not seen, Providers cannot give any instructions to PKB about how such information is to be held or used, and indeed Providers are not able to access that information themselves unless the patient agrees to allow access. As to (ii), in theory there could perhaps be a processor/controller relationship in which PKB was processor and the individual patient was controller. Although there probably could not be a controller/processor relationship in respect of the patient’s own personal data, some of the personal data in the Patient Record may be about third parties (e.g. clinicians who are treating the patient, or carers, or friends or family members).
But I do not discuss this possibility any further: at present, the Patient Record is not set up on the basis of PKB being processor and the patient being controller; and I do not consider that it would be feasible for it to be set up in this way, since requiring the patient to undertake the responsibilities of a controller would deter patients from setting up a Patient Record and would hence be inconsistent with the current and proposed future operation of the PKB platform.
28. To the extent that PKB processes patient personal data in the Patient Record, as sole data controller, what lawful bases of processing are available to PKB? It will be necessary for PKB to satisfy one of the processing conditions in GDPR Article 6. In addition, PKB will need to satisfy a processing condition in Article 9, since the data that it is processing will be “special category” personal data. Self-evidently, much (if not all) of that data will fall within Article 9, as being data concerning health. Some of that data may also fall within other categories listed in Article 9, e.g. it may be genetic data, or data concerning a patient’s sex life or sexual orientation.
29. I discuss below the various potential bases of processing under Article 6.
● Article 6(1)(a) (consent of the data subject) is in principle available to PKB. Any consent will need to satisfy the requirements of Article 6(11) and Article 7: these include that the consent must be freely given, specific, informed and unambiguous, and that the data controller must be able to demonstrate that consent has been given. This last requirement should not cause difficulties for PKB, since a Patient Account will not be set up unless the patient takes specific steps to approach PKB and activate a Patient Account (in response to an invitation from a Provider): hence PKB can ensure that a record of patient consent is created at the point of activation. As to the requirement that consent must be freely given, I indicated above the PKB requires Providers (when setting up a Patient Record) to encourage patients to set up a Patient Account. If PKB is to rely on consent as a processing condition, then it is essential that any communication from the Provider to the patient must make clear that it is up to the patient whether or not they set up a Patient Account, and that the failure to do so will not adversely affect the care that the Provider offers to the patient.
● Article 6(1)(b) (processing necessary for the performance of a contract, or for pre-contractual steps) does not seem to me to apply: as I understand it, there is not a contractual relationship between the patient and PKB.
● Article 6(1)(c) (processing necessary for compliance with a legal obligation to which the controller is subject) does not apply either: there is no legal obligation that requires PKB to set up or operate a Patient Account for any person.
● Article 6(1)(d) (processing necessary to protect the vital interests of the data subject or another natural person) would not apply. This ground of processing is narrow: see GDPR recital 46. I agree with the view expressed in the recent Commentary on the GDPR, edited by Kuner and others (OUP 2020: “Kuner”), that processing data on grounds of vital interests requires that a situation of concrete and imminent danger exists for the data subject or a third (natural) person: see Kuner, page 333, section 1.2.4.
● Article 6(1)(e) (processing for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller) would not apply: since PKB is a private sector body, with no statutory or other legal duties in relation to the provision of healthcare, I do not see any basis on which it can rely on this condition when acting as sole data controller.
● Article 6(1)(f) (legitimate interests): PKB can in principle rely on this, as it is not a public authority. See the final sentence of Article 6.1; see also DPA 2018 section 7, defining what constitutes a “public authority” in the UK for GDPR purposes. The legitimate interests in question seem to me to be those of both PKB itself (in providing services to the patient and to Providers) and of Providers (in providing healthcare to the patient). Given that the patient has a choice as to whether to set up a Patient Account, and also as to what information they will include in the Patient Account, there is a strong argument that these legitimate interests would not be overridden by the interests, rights or freedoms of the patient.
30. On the basis of the discussion so far, it seems that PKB could potentially rely on either GDPR Article 6(1)(a) or 6(1)(f). However, the difficulty in relation to Article 6(1)(f) is this: if PKB will in any event be compelled to rely on consent under Article 9 (in the
absence of any other available processing condition), then reliance on Article 6(1)(f) (rather than on Article 6(1)(a)) appears illogical. Indeed, to rely on consent in the context of Article 9 but not in the context of Article 6 may very well confuse patients, in such a way as to give rise to a serious risk of unfair processing (contrary to Article 5(1)(a)). My view therefore is that relying on Article 6(1)(f) is not a feasible option, unless there is some basis for processing other than consent that PKB could rely on under Article 9. I turn, therefore, to the Article 9 processing conditions.
31. Article 9(2)(a) is satisfied where the data subject has given explicit consent. The points made above, in relation to, Article 6(1)(a) would apply here also. Unlike Article 6(1)(a), there is a requirement under Article 9(2)(a) that consent should be explicit: though it is questionable how much different this makes, given that consent under Article 6(1)(a) must be both unambiguous (see Article 4(11)) and demonstrable (see Article 7(1)). In any event, PKB can readily ensure that any consent, given when the Patient Account is set up, is provided in explicit terms.
32. It seems to me that the only other potential processing condition available to PKB under Article 9 is the health-related condition in Article 9(2)(h).
● As to Article 9(2)(g) (substantial public interest), this gives rise to similar issues as were discussed above in relation to Article 6(1)(e).
● As to Article 9(2)(i) (public health), the purpose of processing the Patient Record is the provision of care to the individual patient, rather than safeguarding the public in general against threats to public health.
33. The focus therefore is on whether PKB can rely on Article 9(2)(h). This is satisfied where:
processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services on the basis of Union or Member State law or pursuant to contract with a health professional and subject to the conditions and safeguards referred to in paragraph 3.
Article 9(3) provides as follows.
Personal data referred to in paragraph 1 may be processed for the purposes referred to in point (h) of paragraph 2 when those data are processed by or under the responsibility of a professional subject to the obligation of professional secrecy under Union or Member State law or rules established by national competent bodies or by another person also subject to an obligation of secrecy under Union or Member State law or rules established by national competent bodies.
34. As far as the application of Article 9(2)(h) in the UK is concerned, there are two issues arising from DPA 2018. First, the effect of DPA 2018 section 10 is that Article 9(2)(h) can be relied on provided that the condition in paragraph 2 of Schedule 1, Part 1 to DPA 2018 is satisfied. This reads as follows:
(1) This condition is met if the processing is necessary for health or social care purposes.
(2) In this paragraph “health or social care purposes” means the purposes of— (a) preventive or occupational medicine,
(b) the assessment of the working capacity of an employee,
(c) medical diagnosis,
(d) the provision of health care or treatment,
(e) the provision of social care, or
(f) the management of health care systems or services or social care systems or services.
(3) See also the conditions and safeguards in Article 9(3) of the GDPR (obligations of secrecy) and section 11(1).
The second point arising from DPA 2018 is that section 11(1) makes further provision for the application of GDPR Article 9(3). It reads as follows:
For the purposes of Article 9(2)(h) of the GDPR (processing for health or social care purposes etc), the circumstances in which the processing of personal data is carried out subject to the conditions and safeguards referred to in Article 9(3) of the GDPR (obligation of secrecy) include circumstances in which it is carried out—
(a) by or under the responsibility of a health professional or a social work professional, or
(b) by another person who in the circumstances owes a duty of confidentiality under an enactment or rule of law.
35. My instructions raise the issue of whether PKB is precluded from relying on Article 9(2)(h), because it cannot satisfy Article 9(3): i.e. processing by PKB is not carried out by persons (such as doctors) who are subject to an obligation of professional secrecy. In my view, this does not in itself preclude PKB from relying on Article 9(2)(h). PKB, as I understand it, will not come within section 11(1)(a) of DPA 2018; but it seems to me that it could potentially come within section 11(1)(b), and therefore satisfy Article 9(3) on that basis. It would be sufficient, in my view, if the processing of personal data by PKB was carried out by persons who owed a contractual or other legal duty of confidentiality. A contractual duty of confidentiality could be imposed on those individuals by PKB (e.g. in their contracts of employment). Moreover, given the way in which breach of confidence has developed in the light of the Human Rights Act 1998 and Article 8 of the European Convention on Human Rights, it is strongly arguable that the individuals carrying out the relevant processing would owe a duty of confidence to patients, even if no express duties of confidentiality were imposed on those individuals in any contract with PKB: see for instance Vidal-Hall v Google, Inc. [2015] EWCA Civ 311 and Campbell v MGN [2004] 2 AC 457.
36. The next question is whether the processing of personal data by PKB in the context of the Patient Record satisfies Article 9(2)(h): this question needs to be considered by reference to DPA 2018 Schedule 1, Part 1, paragraph 2. The question here, in my view, is whether the processing of the Patient Record by PKB is necessary for the provision of health care or treatment, or social care or treatment (see limbs (d) and (e) of paragraph 2(2): this seems to me a better fit than any of other limbs of that provision). “Necessary” here does not mean strictly or absolutely necessary. The issue is not whether the provision of healthcare is impossible without the processing in question. Instead, the issue is whether
the processing meets a pressing social need and is proportionate to that need, which is an inquiry comparable to that which would arise when considering interference with a qualified right under the European Convention on Human Rights: compare the decision of the Supreme Court in South Lanarkshire Council v Scottish Information Commissioner [2013] UKSC 55.
37. In my view there is a strong argument that the processing by PKB of the personal data in the Patient Record is necessary (in the sense explained above) for the provision of health and/or social care or treatment. The processing enables the patient to make information available (via the PKB platform) to Providers involved in the patient’s care. The processing also enables the patient to share information with others, such as relatives or carers. Those others may not in themselves be involved in delivering health or social care to the patient, but sharing of information with them may nevertheless assist in the delivery of care: for instance, if a carer is made aware (via the Patient Record) of the prescription medication that a patient is taking, then they can assist in ensuring that the patient does in fact take that medication. Finally, the Patient Record may well assist the patient themselves in accessing health or social care; e.g. it may help them record the time and place of medical appointments. In all of these respects, it seems to me that there is a strong argument that PKB’s processing of the Patient Record falls within the ambit of GDPR Article 9(2)(h).
38. I turn next to question 2 in my instructions. This relates to the processing of data in the Patient Record by Providers, rather than by PKB. As explained above, hitherto the understanding of PKB and Providers has been that the Providers are the data controllers in relation to the Patient Record, with PKB being their data processor. This means that PKB’s own processing can be based on any lawful conditions that the Providers themselves are able to rely upon. It is therefore important to PKB to be clear as to which conditions it can rely upon. In this context, I am asked whether I agree with the suggestion from Welsh Providers that the only lawful basis available to them (the providers) in respect of the Patient Record is consent?
39. The short answer is that I do not agree with that suggestion. It seems to me that Providers may well also be able to rely on the processing conditions in: Article 6(1)(e); Article 6(1)(f); Article 9(2)(g); and Article 9(2)(h).
40. Article 6(1)(e) was briefly discussed above, in relation to PKB. The application of this provision in the UK requires consideration of DPA 2018 section 8, which reads as follows:
In Article 6(1) of the GDPR (lawfulness of processing), the reference in point (e) to processing of personal data that is necessary for the performance of a task carried out in the public interest or in the exercise of the controller’s official authority includes processing of personal data that is necessary for—
(a) the administration of justice,
(b) the exercise of a function of either House of Parliament,
(c) the exercise of a function conferred on a person by an enactment or rule of law,
(d) the exercise of a function of the Crown, a Minister of the Crown or a government department, or
(e) an activity that supports or promotes democratic engagement.
41. I do not know whether all Providers will be providing health care or social care in the exercise of a statutory function, but I would expect that this would be the case for many of them. Where this is so, and where the information is processed for the purposes of carrying out those statutory functions, then it seems to me that in principle Article 6(1)(e) would be available to the Providers in question as a processing condition. I understand that some Providers will not themselves be NHS providers of care, but will be commissioned to provide care via the NHS Contract; in relation to these Providers, in my view they would be able to rely on Article 6(1)(e) (on the basis that the processing of personal data by these Providers would be necessary for the exercise of the statutory functions of the commissioning body).
42. My instructions refer specifically to the duty to share information under section 251B of the Health and Social Care Act 2012 (inserted by the Health and Social Care (Safety and Quality) Act 2015). I note, however, that section 251B(5) provides that the section does not permit anything to be done which (but for the section) would be inconsistent with the GDPR or DPA 2018: so I doubt whether section 251B can itself be relied upon as a basis for processing, unless the processing would be lawful even in the absence of section 251B
43. For those Providers that are not public authorities or public bodies within the meaning of DPA 2018 section 7 – which, broadly speaking, means for those Providers that are not public authorities for the purposes of the Freedom of Information Act 2000 (“FOIA”) – the processing condition in Article 6(1)(f) (based on legitimate interests) would also be available. The provision of health care and/or social care would undoubtedly constitute a legitimate interest of the Providers: the question whether Article 6(1)(f) was available would then turn on whether there was sufficient protection of the interests of patients (in particular in relation to ensuring that personal data about patients was only shared between Providers when there was a lawful basis for that sharing to take place).
44. Turning to Article 9, the condition in Article 9(2)(g) is satisfied where:
processing is necessary for reasons of substantial public interest, on the basis of Union or Member State law which shall be proportionate to the aim pursued, respect the essence of the right to data protection and provide for suitable and specific measures to safeguard the fundamental rights and the interests of the data subject.
In order to rely on this processing condition in the UK, one of the conditions in DPA 2018 Schedule 2, Part 2 would need to be met: see DPA 2018 section 10. Of those conditions, the one that is most likely to be relevant in current circumstances is in Schedule 2, Part 2, paragraph 6:
(1)This condition is met if the processing—
(a) is necessary for a purpose listed in sub-paragraph (2), and
(b) is necessary for reasons of substantial public interest.
(2)Those purposes are—
(a) the exercise of a function conferred on a person by an enactment or rule of law;
(b) the exercise of a function of the Crown, a Minister of the Crown or a government department.
Note that this condition will only be met if the additional requirements of Schedule 2, Part 2, paragraph 5 (including the existence of an appropriate policy document) are also satisfied.
45. It seems to me that a Provider that could satisfy Article 6(1)(e) would also be likely to be able to satisfy Schedule 2, Part 2, paragraph 6 (and hence could rely on GDPR Article 9(2)(g)) provided that: the processing could satisfy the substantial public interest test; and the other requirements of paragraph 5 were met. As indicated above, some Providers will not themselves be NHS providers of care, but will be commissioned to provide care via the NHS Contract; in relation to these Providers, in my view they would be able to rely on Article 6(1)(e) (on the basis that the processing of personal data by these Providers would be necessary for the exercise of the statutory functions of the commissioning body). They would likewise be able, on a similar basis, to satisfy Schedule 2, Part 2, paragraph 6; and hence they could in my view rely on GDPR Article 9(2)(g).
46. Finally, I turn to Article 9(2)(h). This was discussed above, in the context of PKB’s processing of data in the Patient Account. As indicated above, Article 9(2)(h) needs to be considered in conjunction with DPA 2018 Schedule 1, Part 1, paragraph 2 At first sight, the Providers’ processing of data in the Patient Record seems likely to meet the requirements of Article 9(2)(h), for similar reasons to those that were discussed above in relation to PKB. I understand however that the Welsh Providers’ concern is that these requirements cannot be met, because the Patient Record is not a “health record” within the meaning of DPA 2018 section 205.
47. A “health record” is defined as a record that:
consists of data concerning health, and has been made by or on behalf of a health professional in connection with the diagnosis, care or treatment of the individual to whom the data relates.
I am not clear why the Providers take the view that the Patient Record does not constitute a “health record” in this sense. The information in the Patient Record – to the extent that it relates to health care rather than social care - will be used by Providers in connection with the provision of social care, including by sharing it with other Providers. But even if the Patient Record is not a “health record”, I do not think that this would preclude reliance on Article 9(2)(h) by Providers. The definition of a “health record” in DPA 2018 applies in relation to various health-related exceptions from data subject rights: see DPA 2018
Schedule 3, Part 2. There is no direct link between the application of that definition, and the operation of the processing condition in Article 9(2)(h).
48. Before moving on from questions 1 and 2, I should however make one further point that relates to both questions. The discussion above is focused on the processing conditions that would apply to the processing of personal data about patients. It may well be that the Patient Account and/or the Patient Record would include personal data about other identifiable individuals: for instance, clinicians or carers who are involved in providing health or social care to the patient, or family members and friends of the patient. Separate consideration would need to be given to the processing conditions that would apply to personal data about these individuals. I do not discuss this issue further here, in the absence of information about the nature of any personal data that is processed in relation to such third parties.
Joint controller issues
49. I turn now to a group of issues about the possibility of there being a joint controller relationship between PKB and Providers. As discussed above, there are two contexts in which there may be a relationship of joint controllership: in relation to the Patient Record; and in relation to information in the Patient Account that is accessed by Providers.
50. Question 3 asks whether PKB is acting as a joint controller in conjunction with Providers in the context of the Patient Record.
51. PKB and a Provider will be joint controllers, if they jointly determine the purposes and means of processing of personal data: see GDPR Article 4(7) and Article 26. As explained above, the understanding on which the PKB platform has been operated hitherto is that PKB is a processor of the Patient Record, and that the Providers are the data controllers of the Patient Record. No doubt the reason that this view has been taken is that it is the Providers who determine such matters as: what information should be uploaded to the Patient Record in relation to any specific patient; when, and by whom, that
information should be consulted for the purposes of patient care (or for any other purposes, e.g. dealing with patient complaints, or litigation); and whether and to what extent that information should be shared with others who are involved in the provision of health or social care to the same patient.
52. My instructions refer to two features of PKB’s role in support of the argument that PKB is a joint controller with the Providers, rather than a processor: (i) through its contractual obligation on Providers actively to encourage patient activation of the Patient Account, PKB are jointly determining the purpose of processing; and (ii) the utilisation of the PKB platform means that PKB jointly determines the means of processing. These points have been put forward by Kaleidoscope (see in particular at enclosure B to my instructions) in support of an analysis that PKB and Providers are joint controllers.
53. I doubt whether very much weight should be placed on the second point. It is true that the PKB platform is operated by PKB, and that its design and technical specifications have been determined by PKB not by the Providers. However, this would very often be the case where a processor provides a platform on which personal data can be held by a controller. If factors such as this were sufficient to establish a joint controller relationship, then any person or body offering data services at a relatively high level of technological sophistication would be likely to be a joint controller, not a processor. This does not seem to me a realistic analysis.
54. The first point seems to me to be a stronger argument. PKB is seeking to encourage (or indeed contractually to require) Providers to inform patients that their personal data is held in a Patient Record on the PKB platform, and to encourage patients to create a Patient Account. If such a Patient Account is created then one of its effects, as I understand it, is that the patient: (i) can access the information in the Patient Record; and (ii) can authorise sharing with others of the information that is contained in the Patient Record. In these respects, PKB is helping to determine the purposes for which the information in the Patient Record is held: i.e. PKB is seeking to bring it about that the information is accessible to patients, not just to Providers.
55. There are two further points that could be made in support of this analysis, and that are not set out in the material prepared by Kaleidoscope (enclosure B to my instructions).
● To the extent that patients can decide whether to share information in the Patient Record with others, it will be PKB, not the Providers, that is responsible for determining what steps patients need to take in order to convey their wish that information should be shared in this way. It will be PKB that will determine whether any particular patient has effectively communicated or recorded a wish for information to be shared, and if so what is the scope of that wish.
● PKB is the sole data controller in relation to information in the Patient Account that has not yet been viewed by Providers. It will be PKB that determines the steps that a patient needs to take in order to convey their agreement for Patient Account information to be made accessible to Providers, so that the latter can consider it in conjunction with Patient Record information. PKB plays a gatekeeper role, determining whether any particular patient has given the consent that would be required in order for a Provider to be able to view particular information in the Patient Account alongside the Patient Record, rather than being confined to viewing the Patient Record only.
56. Overall, it seems to me that there is a strong argument in support of the proposition that PKB and Providers are already joint controllers in respect of the Patient Record. However, careful consideration needs to be given as to how this analysis would work in practice. One question is, who would be the joint controllers in relation to any particular information? Clearly, PKB will not be a joint controller with all Providers in relation to all of the information held on the PKB platform: there will be some cases where there is no possible basis for a Provider to have any access to information relating to a particular patient, and there is no basis for saying that the Provider would be a joint controller with PKB in respect of that patient. It seems to me that there are two main possibilities as to how the relationship might operate in practice:
● For each patient, PKB would be a joint controller of the data in the Patient Record, together with all Providers who had contributed data to that Patient Record.
● Alternatively, in relation to each Provider, PKB and the Provider would be joint controllers for any information uploaded to the Patient Record by that Provider.
Which of these was the correct analysis would depend on the extent to which Providers who upload information about the same patient could lawfully access information about that patient.
57. A further consideration is this: how would the joint controller model operate, where information was shared between Providers? Assume the following situation, involving PKB, Providers A and B, and patient X. PKB and Provider A are joint controllers of information in the Patient Record about patient X. PKB and Provider B are joint controllers of other information. Provider A then shares part of patient X’s Patient Record with Provider B. It seems to me that the relevant part of patient X’s Patient Record will now need to be added to the information of which PKB and Provider B are joint controllers. This will enable Provider B to have continuing access to that information, both for the ongoing treatment of patient X and as a record of the information that Provider B has seen in relation to patient X (this may be necessary for audit purposes, or in connection with managing patient complaints, or dealing with litigation).
58. The joint controller model would require PKB to enter into agreement with each Provider, complying with GPDR Article 26, and setting out their respective responsibilities for complying with the GDPR (in particular as regards complying with the rights of data subjects under the GDPR). These agreements would replace the existing controller/processor agreements between PKB and Providers (entered into under GDPR Article 28). What this means in practical terms, is that there would be difficulties if the Providers (or some of them) did not agree that the joint controller analysis was correct, and therefore would not enter into Article 26 agreements with PKB. My instructing solicitors’ email of 9th June 2020 points out that there will be multiple parties involved in the joint controller arrangements, and that these will be a mixture of NHS and non-NHS bodies sharing data between themselves. In my view this does not prevent the joint controller model from operating; but there will need to be careful consideration (as discussed at paragraphs 56 and 57 above) as to which bodies are joint controllers in relation to which particular items of information.
59. I turn next to Question 4. On the assumption that PKB and Providers are acting as joint controllers, what lawful bases are available to the provider and PKB respectively? In particular, does the joint controllership facilitate PKB’s reliance on any lawful bases other
than consent, and if so, which bases?
60. As discussed above (in relation to question 2) I consider that: those Providers that were providing health care or social care in the exercise of a statutory function would probably be able to rely on GDPR Article 6(1)(e) and 9(2)(g); and Providers generally would probably be able to rely on Article 9(2)(h). Those Providers that were not FOIA public authorities would also potentially be able to rely on the legitimate interests condition (Article 6(1)(f)), though in this regard they would be no better placed than PKB itself. The practical issue is whether a joint controller relationship, as discussed above, would assist PKB in being able to rely on the following as providing a basis for PKB’s own processing of the Patient Record (as joint controller): Article 9(2)(h); and/or Article 6(1)(e) and 9(2)(g).
61. As far as Article 9(2)(h) is concerned, I have explained above – in relation to the Patient Account – why I consider that this processing condition is in principle open to PKB. Any argument that PKB could rely on this condition would however be strengthened if PKB were processing that data as joint controller with a body that itself provided health care or social care. This is for two reasons: (i) the joint controller arrangement would strengthen the argument that the purpose of the processing did, indeed, fall within Article 9(2)(h) (and DPA 2018 Schedule 1, Part 1, paragraph 2); and (ii) any difficulties in satisfying GDPR Article 9(3) could be overcome, if the processing were under the direction of a healthcare professional working for the Provider.
62. In relation to Article 6(1)(e) and Article 9(2)(g), the question is whether PKB could rely on these processing conditions in the context of a joint controller relationship, even though PKB as a private sector body does not itself have any statutory duties as regards health or social care. This question is not free from doubt. However, I think the better view is that where: (i) PKB enters into a joint controller relationship with a Provider; (ii) the Provider is able to rely on Article 6(1)(e) and/or Article 9(2)(g), on account of its statutory functions relating to health care or social care; and (iii) the processing in respect of which the Provider relies on those conditions is covered by the joint controller relationship, then PKB can rely on those processing conditions also. To put the point another way, PKB’s processing (as joint controller) does not discharge statutory functions of PKB (as it has no such functions), but it enables PKB to assist the Providers in discharging their own statutory functions, and this is sufficient for PKB to rely on Article
6(1)(e) and Article 9(2)(g).
63. Finally I turn to Question 5. This asks what are the joint controller considerations and implications in respect of the Patient Account, in circumstances where the provider accesses the Account in connection with the care and treatment of the patient. I am asked to address this question by reference to the lawful bases available to the respective parties, including the requirements for ongoing retention of the data.
64. It seems to me that information in the Patient Account may be processed at three stages.
● Stage 1: the information is held in the Patient Account, and is not accessed by a Provider.
● Stage 2: the information is accessed by a Provider in connection with the provision of health care or social care to the patient.
● Stage 3: the Provider that accessed the information is no longer providing health care or social care to the patient; but the Provider wishes to retain access to a record of the information in question (and a record of the fact that the Provider consulted it), for audit purposes, and in order to be able to respond to patient complaints or to deal with any litigation arising from the care of the patient.
65. I think it is important to work out, at each stage: who is the data controller; what is the lawful basis of processing that can be relied upon; and what rights are available to the patient in relation to erasure of the data or preventing it from being processed. It is also essential that any fair processing information provided to the patient – whether by PKB, or Providers, or both – should reflect the correct answers to these questions, at each stage.
66. At stage 1, the data controller in relation to patient personal data in the Patient Account will be PKB (as sole data controller). As discussed above, the basis for processing could be patient consent: or alternatively, it might be possible to rely on legitimate interests (Article 6(1)(f)) combined with processing for health care and/or social care (Article 9(2)(h)).
67. What about at stage 2? It seems to me that once a Provider has accessed information in the Patient Account, they will need to have continuing access to that information, both for care purposes, and for related purposes involving such matters as audit, complaints handling, and litigation. Moreover, the Provider will need to have access to a record of the fact that they have seen particular information in the Patient Account: i.e. a record of what information they saw, and when. It seems to me that what needs to happen at stage 2 is that the information from the Patient Record that was shared with the Provider, together with a record of what information the Provider saw and when, needs to be treated as being both part of the Patient Account, and part of the Patient Record. To the extent that the information is part of the Patient Record, it will be held by the Provider and PKB as joint controllers, in reliance on whatever basis of processing is applicable to the Patient Record (as to which, see the discussion above).
68. This clearly involves a change in status for information in the Patient Account, once that information is shared with a Provider: at that point, both the controllership and the basis of processing will change. In my view this is entirely permissible, provided that the fair processing information made available to the patient explains, for each stage, who the data controller is and what is the lawful basis of processing.
69. Finally, at stage 3, there are a number of possible approaches. Probably the most straightforward is for PKB and the Provider to continue to be joint data controllers; I doubt whether Article 9(2)(h) would still be available as a basis for processing, but I would anticipate that the Provider (and hence also PKB) could rely on Article 6(1)(e) and 9(2)(h), on the basis that in order to perform its statutory functions regarding health care and/or social care the Provider would need continuing access to this information for the purposes of such matters as audit, complaint handling, and litigation.
70. At each stage, the potential application of the patient’s rights under GDPR Articles 17-21 would need to be considered. If processing was based on consent, and there was no other available lawful basis of processing, then the patient could withdraw consent and insist on the erasure of the data in question (under Article 17(1)(b)). The request for erasure would have to be granted, except in the limited circumstances set out in Article 17(3). If the processing was based on Article 6(1)(e) or 6(1)(f) then the data subject could object to the processing, but the processing could continue if the controller demonstrated that there
were compelling legitimate grounds for the processing which override the interests, rights and freedoms of the data subject or that the processing was for the establishment, exercise or defence of legal claims. If continued access to the information was required for such matters as audit, complaint handling or dealing with litigation, then I would expect that continued processing would be justified: this would be so, in my view, even if there was no complaint or litigation currently under way and no specific reason to anticipate either of these eventualities.
71. It would of course be important to ensure that any fair processing information available to the data subject did not give a misleading impression as to the scope of the data subject’s rights (in particular, as regards the scope for and effect of any withdrawal of consent).
Lawfulness/general concerns
72. By question 6, I am asked whether I have any further key compliance concerns in respect of any aspects of the PKB platform. Generally, I am asked to address any issues that I consider relevant to the legality or viability of the proposed framework. These issues can be considered together.
73. One matter that I have not specifically been asked to address, is the provision of fair processing information to data subjects under GDPR Article 13 and/or 14. In relation to the Patient Account, it seems to me that PKB will be sole controller at the point when the account is set up by the patient, and also in relation to any information subsequently added by the patient; a joint controller relationship will not arise in relation to any of the information in the Patient Account, until that information has been viewed by a Provider. Consequently, it will be the responsibility of PKB (as controller) to provide fair processing information to the patient, before the Patient Account is set up; and the provision of this information will be governed by GDPR Article 13, since the personal data in the Patient Account is provided directly by the patient to PKB.
74. What about personal data that is jointly controlled by PKB and one or more Providers? In this regard, patients will need to be provided with: fair processing information compliant with GDPR Article 13, in relation to the data controller to whom the patient directly provides information; and fair processing information compliant with Article 14, in
relation to the data controller to whom the patient does not directly provide information. The position here is complex, because some information will be provided by patients directly to PKB (via the Patient Account), and other information will be provided by patients directly to Providers (and then placed on the PKB platform as part of the Patient Record). Any joint controllership agreement between PKB and Providers (entered into under GDPR Article 26) will need to allocate responsibility for the provision of fair processing information to patients, and will need to ensure that patients receive information that satisfies both Article 13 and 14 (where applicable) in respect of both PKB and Providers.
75. The above discussion focuses on the position of patients as data subjects; but (as discussed above) it may well be that the Patient Record and the Patient Account will both contain personal data about third parties as data subjects (e.g. family members of the patient, carers, and treating clinicians). I do not know what steps are currently taken to provide fair processing information to any such third parties in respect of information that is held on the PKB platform as part of the Patient Record or the Patient Account. This may be an issue that PKB needs to address, including when negotiating any joint controllership agreements with Providers pursuant to GDPR Article 26.
76. A further point (raised in my instructing solicitors’ email of 9th June 2020) is whether, where PKB is acting as sole data controller, the current PLB Patient Account activation process meets the standards of GDPR Article 9(2)(a) (and of the GDOR more generally) in relation to consent. If not, how does this affect existing consents and processing? Should there be a re-consenting process?
77. Under the current process, when activating an account patients see the following text:
By accepting the User Agreement and Privacy Policy I am providing consent to Patients Know Best to create a PKB Account as detailed in the User Agreement and Privacy Policy.
Immediately above that text is a box to tick, which states:
I have read and accept the User Agreement and Privacy Policy.
There is a click-through link to both the User Agreement and the Privacy Policy from this 26
text.
78. In my view the GDPR requirements for consent (and, in relation to GDPR Article 9(2)(a), explicit consent) would be satisfied here. It is important, however, that Providers (when encouraging individuals to activate their Patient Account) should not suggest that a failure to do so would adversely affect the level or standard of healthcare offered to a patient. Any such suggestion could undermine the free nature of the patient’s consent, prejudicing the ability to rely on consent in relation to that particular patient.
79. Otherwise, if there any further matters of concern that my instructing solicitors, or PKB, would like me to consider then I am happy to do so.
Next steps
80. As indicated above, I would be happy to assist with any further advice arising out of the matters discussed, if asked.
TIMOTHY PITT-PAYNE QC
11KBW
15th June 2020
Lay Summary (of the above legal opinion) from DAC Beachcroft LLP
Strictly Confidential and subject to legal professional privilege
PATIENT KNOWS BEST (“PKB”)
SUMMARY NOTE ON ASPECTS OF THE LAWFULNESS OF THE PKB PLATFORM
Background
1.1 We have been instructed by Patient Knows Best (“PKB”) to advise, and seek Counsel’s
opinion on, the data protection and privacy considerations relating to PKB’s approach.
Counsel’s opinion was obtained by Tim Pitt-Payne QC, and provided by way of a detailed
advice note. We have now been asked to prepare a summary advice note taking
counsel’s opinion into account. It is not intended to be a comprehensive precis of every
point considered in counsel’s advice, but instead as a high level statement of the key
findings.
1.2 In broad terms, this summary focusses on the lawfulness of processing patient data by
reference to the available conditions for processing under the General Data Protection
Regulation (“the GDPR”), as well as some consideration of the broad data protection
framework relating to PKB’s platform more generally. It should be noted that:
1.2.1 We provide our advice by reference to the shorthand descriptions ‘Patient
Record’, to cover the information uploaded to the PKB platform by providers,
and ‘Patient Account’, to cover the information uploaded to the PKB platform
by patients (following activation); and
1.2.2 We have approached this advice note by reference to patient data specifically,
which will be special category data thus requiring a condition for processing
under both Articles 6 and 9 of the GDPR.
1.3 With that broad introduction in mind this advice note addresses, in particular, whether:
1.3.1 providers have to rely upon consent as their condition for processing vis-à-vis
the Patient Record;
1.3.2 the current model of controller and processor in respect of the Patient Record
reflects the legal position; and
1.3.3 PKB, as sole controller of the Patient Account, can rely upon any conditions
for processing other than consent which, in turn, would potentially legitimise
ongoing retention of data for medico-legal purposes.
1.4 This note does not purport to consider every single aspect of data protection compliance
pertaining to PKB’s Patient Record and Patient Account, nor does it consider issues
relating to the common law duty of confidentiality. We can, of course, deal with any
further queries if and when they arise.
1.5 We now set out our summary advice, followed by the more detailed analysis which
supports those conclusions.
2. Summary
2.1 We set out our more detailed analysis below, but way of brief summary in relation to the
key issues within the scope of this note:
2.1.1 Providers do not have to rely on consent as their condition for processing under the GDPR in respect of the Patient Record. In fact, we would argue strongly against them doing so given the inherent difficulties in obtaining valid consent in the context of providing healthcare. Reliance on alternative conditions for processing would mean that the vast majority of requests for erasure of data held within the Patient Record would not have to be actioned by the provider and/or PKB;
2.1.2 The Patient Record actually gives rise to a joint controller relationship between providers and PKB, not one of controller and processor respectively. There
are number of corollary obligations under the GDPR which arise as a result,
and which both providers and PKB will need to address prior to the
commencement of the processing activity;
2.1.3 There are also alternative conditions for processing available to PKB other than consent, in connection with the Patient Account (for which they are
controller). Those alternatives would ensure that PKB is able to continue to
retain data within the Patient Account, notwithstanding any attempt by a
patient to exercise their right to erasure, where necessary to do so from a
medico-legal perspective. This will need to be fully and clearly outlined to
patients when they sign up to PKB.
2.2 We now consider each of those issues in more detail.
3. Patient Record: Providers
3.1 The first key issue we focus on relates to the lawful bases available to providers in respect of data comprised within the Patient Record, particularly whether the only viable condition for processing under the GDPR is consent. Our use of the term ‘providers’ entails both public bodies, such as NHS or Foundation Trusts, and private bodies commissioned under a NHS contract. Please note that our consideration as to PKB’s reliance on consent, in respect of the Patient Account specifically, is considered separately below.
3.2 The reliance on consent as the condition for processing under the GDPR gives rise to a number of difficulties, not least ensuring that it complies with both Article 4(11) of the GDPR, which requires it to be “freely given, specific, informed and unambiguous”, and the requirements of Article 9(2)(a) for consent to process special category data to be “explicit”. It also gives rise to data subject rights which are likely to cause significant practical problems, not least the right of erasure under Article 17 which arises in a number of specific circumstances including, under Article 17(1)(c) where:
...
“the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing.”
3.3 For reference, Articles 6(1)(a) and Article 9(2)(a) relate to consent for processing personal data and special category data respectively. On the face of it, therefore, providers relying on consent would face the very real possibility of having to delete information it had uploaded to the Patient Record, in the event that a patient seeks to exercise their Article 17 rights. It could, potentially, refuse such a request in the event an alternative condition for processing is found, but this would seem to give rise to further complicating factors, not least:
3.3.1 If such an alternative condition can be identified, then would this not have been available, and therefore relied upon, in the first place; and
3.3.2 Potentially unfair processing, by purporting to give patients the attendant rights pertaining to a consent-based approach, only to later refuse to give effect to those rights and therefore, arguably, would not be valid consent.
3.4 For all of those reasons, providers should avoid relying on consent from a GDPR perspective and, on our analysis, it is legitimate for them to do so as there are other, more appropriate, conditions for processing available. In short, they are:
3.4.1 Article 6(1)(e), which extends to processing necessary for performance of a task carried out in the public interest or pursuant to official authority. We are
satisfied that providers use of the Patient Record is sufficiently tethered to their
responsibilities for delivering healthcare to make reliance on this condition
entirely appropriate; and
3.4.2 Article 9(2)(h), the broad basis available for processing which is necessary for the provision of health or social care. The broad functionality of the PKB
Record, to include making patient information available to providers, relatives
and/or carers to support the delivery of care, as well as assisting the patient to
access health or social care, means that Article 9(2)(h) can be relied upon.
3.5 Previously, some doubts were raised as to whether the Patient Record constitutes a ‘health record’ as defined in the Data Protection Act 2018 (“DPA 2018”) and, in turn, whether this precludes reliance upon conditions for processing other than consent. In blunt terms, whether the definition is satisfied is irrelevant in this specific context. Reliance upon either Article 6(1)(e) and/or Article 9(2)(h) is not conditional upon the relevant processing taking place specifically within a ‘health record’.
3.6 Nonetheless, we are satisfied that the definition is indeed fulfilled in the context of the Patient Record. A health record is defined by section 205 of the DPA 2018 as a record which:
“consists of data concerning health, and has been made by or on behalf of a health professional in connection with the diagnosis, care or treatment of the individual to whom the data relates.”
3.7 Given that the Patient Record is specifically contributed to, and accessed by, healthcare professionals we fail to see the basis on which it is not a health record. For the avoidance of doubt, however, the relevance of the definition being fulfilled is that it gives rise to specific exemptions from data subject rights (which are beyond the scope of this note), only.
3.8 Accordingly, providers have alternative, and more appropriate, conditions for processing available to them other than consent. Those alternatives are more appropriate in the context of providing patients with healthcare, given the inherent imbalance of power between an individual patient and a provider of healthcare services. This would mean, in turn, that requests from patients to delete data comprised in the Patient Record should be refused (unless the data in question has been retained beyond what is necessary by reference to the retention periods set out, in particular, in the Information Governance Alliance Records Management Code of Practice1).
4. Patient Record: Joint Controllership
https://digital.nhs.uk/data-and-information/looking-after-information/data-security-and-information-governance/c odes-of-practice-for-handling-information-in-health-and-care/records-management-code-of-practice-for-health-an d-social-care-2016
4.1 previous review of the potential data protection designation and relationship between the providers and PKB identified , in respect of the Patient Record, one of controller (provider) and processor (PKB). In our view, however, the more compelling analysis is that the relationship is actually one of joint controllers.
4.2 The particular role fulfilled by a party from data protection perspective is a question of fact, based on what they are actually doing with the relevant data, and not merely ascribing a particular label. As per Articles 4(7) and 26 of the GDPR, PKB will be a joint controller under the Patient Record if, in conjunction with providers, it jointly determines the purpose and means of processing the data contained therein. That ‘determination’ does not have to be identical on the part of each controller, as joint controllers can each determine distinct aspects of processing. In our view, that accurately describes what is happening in respect of the Patient Record. There are three main justifications for this assessment, which in brief terms are that PKB:
4.2.1 contractually obliges providers to encourage patients to create a Patient Account, in turn enabling access to information held in the Patient Record and control over the manner in which that information can be shared;
4.2.2 determines the steps which patients need to take in order to convey their instructions on the sharing of information, including the scope of those instructions; and
4.2.3 acts as an independent controller in respect of the Patient Account, and therefore determining whether permission has been given to allow access to the same, which is akin to a gatekeeper role in maintaining the appropriate crossover or delineation between the Patient Record and Patient Account, as reflective of a particular patient’s expressed permissions.
4.3 PKB and the providers, as Joint Controllers are obliged to comply with Article 26 of the GDPR which requires joint controllers to:
“in a transparent manner determine their respective responsibilities for compliance with the obligations under this Regulation, in particular as regards the exercising of the rights of the data subject and their respective duties to provide the information referred to in Articles 13 and 14, by means of an arrangement between them unless, and in so far as, the respective responsibilities of the controllers are determined by Union or Member State law to which the controllers are subject. The arrangement may designate a contact point for data subjects.”
4.4 The arrangement described “shall duly reflect the respective roles and relationships of the joint controllers vis-à-vis the data subjects” and the “essence of the arrangement shall be made available to the data subject.”
4.5 Careful consideration will have to be given to ensuring that joint controller arrangements take appropriate account of the practical difficulties caused by the multi-party nature of the sharing relationships under the PKB platform. Providers and PKB will also need to cooperate in order to accurately and clearly communicate this relationship to patients.
4.6 This joint controller approach in respect of the Patient Record is predicated on the provider relying on Articles 6(1)(e) and either 9(2)(g) or 9(2)(h) of the GDPR and PKB, in turn, relying upon those same conditions for processing. PKB does not, of course, hold statutory functions, but the Patient Record enables PKB to assist providers in discharging their statutory functions. This further means that the rights to erasure in Article 17 would not, apart from very limited and specific circumstances, arise in respect of the data held in the Patient Record.
4.7 The final point to emphasise is that the further steps we have briefly outlined in the preceding paragraphs are required because there is a joint controller relationship, and not in order to create such a relationship. That is a very important distinction.
5. Patient Account: PKB
5.1 We now move onto consider the ‘Patient Account’. Our focus here is on the conditions for processing available to PKB, as the controller for the Patient Account. PKB adopting a consent-based approach would give rise to complications where patients elect to exercise their right to erasure under Article 17 of the GDPR. This would give rise to, potential concerns that providers (including GPs) who have accessed the Patient Account in connection with the provision of healthcare to a particular patient, and wanting to ensure an audit trail remains available in the event of medico-legal challenge.
5.2 The short answer is that there are alternative conditions for processing available to PKB under the GDPR, other than consent.
5.3 Those available conditions for processing are:
5.3.1 Article 6(1)(f), which extends to processing necessary for legitimate interests pursued by PKB, which would be the provision of the PKB Account services to
patients. Those interests must not be overridden by the interests, rights or
freedoms of the patient, which we are satisfied would not be the case given
that activation of the Patient Account is entirely voluntarily, as well as the
decision to include particular information within it; and
5.3.2 Article 9(2)(h), the broad basis available for processing which is necessary for the provision of health or social care. The broad functionality of the PKB
Account, to include making patient information available to providers, relatives
and/or carers to support the delivery of care, as well as assisting the patient to
access health or social care, means that Article 9(2)(h) can be relied upon. It
is sufficient, in this context, for the processing to be undertaken by those
subject to a contractual duty of confidence, and not necessarily a health
professional.
DAC BEACHCROFT LLP
30 JUNE 2020