Data Protection Impact Assessment (DPIA)Connected Care (LHCR) - Analytics

Index

A. The need for a DPIA – Article 35(1)

B. Conflicts of InterestDocuments

C. Timescales and “Deadlines”

D. Simultaneous new processing

E. Is personal data being processed?The Processing - Article 35(7)(a)

1. How does this directly benefit data subjects?

2. How does this directly benefit our organisation?

F. Consultation – Article 35(9)

G. Article 35(7)(b) – Necessity and Proportionality

1. Common Law

2. Caldicott Principles

3. The Data Protection Principles – Article 5

H. “No Surprises”

I. GMC Confidentiality Principles

J. The Human Rights Act 1998

K. Article 28 – Data Controllership and Data Processors

L. Data Subject Rights

M. Things to think about

1. Surrender of control

2. Do we have to do disclose?

3. Can we do this in a less intrusive way?

4. Is this lawful?

5. Is this ethical and fair?

6. Reputational risks & Trust in Doctors

7. Consequences of not processing

8. What about children?

9. How does this compare with other, similar projects?

N. Article 35(7)(c) – Risks to data subjects

O. Article 35(7)(d) - Measures to mitigate risks

P. Conclusion

Q. Sign Off

R. Appendix 1 – GP Dataset

S. Appendix 2 – Data Flows

T. Appendix 3 – Regulatory guidance

U. Appendix 4 – Responses from consultees

V. Appendix 5 – Article 28 of the GDPR

Article 35(1) - Need for a DPIA

Summarise why you identified the need for a DPIA.

This project has several criteria that warrant a DPIA:

· Processing special category data – health & social care data

· Large Scale of special category data - Article 35(3)(b)

· Children

· Vulnerable adults

· Linkage of individuals’ data across multiple datasets

· Processing that clearly limits data subject rights

· Processing that appears not to respect the data minimisation principle

· Processing that appears not to respect the purpose limitation principle

· Processing that appears not to respect the security principle

· Processing that appears unlawful (CLoC, HRA, Article 28)

“What is accountability?

There are two key elements. First, the accountability principle makes it clear that you are responsible for complying with the GDPR. Second, you must be able to demonstrate your compliance.” (ICO)

The controller is responsible for ensuring compliance with the data protection legislation, including the fundamental data protection principles established in the General Data Protection Regulation (the "GDPR") of lawfulness, fairness and transparency.Controllers are accountable for complying with these principles, including ensuring purpose limitation, establishing legal basis for processing of the data, limiting the amount of data collected and only for the necessary time period (data minimisation), and implementing "privacy by design".Controllers are also responsible for providing transparent information to individuals about their personal data as well as for the compliance of their processors.Controllers must also ensure that individuals can exercise their rights regarding their personal data, including the rights of access, rectification, erasure, restriction, data portability, objection and those related to automated decision-making.

It is policy for Oakley Health Group (OHG) to always undertake a DPIA for any new, or significant change in an existing, data sharing project involving the personal, confidential (and sensitive), information of our patients. We have in excess of 28,000 patients.

Back to Index

Conflicts of interest

Dr Neil Bhatia has no conflicts of interest in undertaking this DPIA, either in his role as IG lead/Caldicott Guardian or as the Data Protection Officer for OHG.

He is neither an employee of, nor receives payment from, any CCG, SCW CSU, Graphnet, Microsoft, System C, FHNHSFT, or any other related organisation.

Any decision to proceed with processing, and to refer this DPIA to the ICO under Art 36 if so required, as a result of the conclusions of this DPIA, will be a partnership decision (majority vote). As a GP partner, however, Dr Neil Bhatia is entitled to a personal vote on this matter.

Back to Index

Documents

List all documents provided and which this DPIA utilises

We have been provided with a “Core” information sharing agreement and two separate information sharing agreements relating to analytics.

The “Core” ISA meets the requirements of Article 26(1).

http://www.regisa.uk/documents/91exampleMasterAgreementAndSchedules.pdf

The all practices “Connected Care Analytics” ISA:http://www.regisa.uk/documents/SU180001ccAPpracticesv2.pdf

The “Yateley PCN” Analytics ISA:

http://www.regisa.uk/documents/SU200002ccPCNshv1.pdf

We have also been provided with an ISA for direct care records access (though the analysis of that is not the subject of this DPIA).

http://www.regisa.uk/documents/PC170011ccNEHFpracticesv2.pdf

We have not been provided with a clear, obvious, and standard data processor contract, nor any documentation labelled as such.

We have been provided with a link to a DPIA undertaken by the ICS for “analytics”:http://regisa.uk/documents/DPIA0002v2Publish.pdf

The DPIA is confusing and muddled, and repeatedly refers to the sharing, or viewing, of data for direct care purposes, not secondary uses.It is bizarrely labelled as an “Information Sharing Agreement”.

It often refers to the sharing of data for direct care as justification for the absence of actions that might be necessary for secondary uses (such as consultation with patients).

It is best ignored.

Back to Index

Timescales and “Deadlines”

Does additional, related or subsequent processing depend on deciding on this processing by a certain date?

No, there is no deadline.This is not COVID-19 related processing.

Back to Index

Simultaneous new processing

Is any other data sharing project being launched at the same time, that might lead to confusion for patients?Remember when SCR & care.data were launched simultaneously…?

Yes – there is a mandatory NHS Digital GPES extraction for COVID-19 research and planning, launched in end May/beginning of June.

This too is secondary uses of confidential information.

Oakley Health Group currently extracts and uploads confidential information to another LHCR, the Care and Health Information Exchange (CHIE, formerly the Hampshire Health Record).

CHIE does not process data for secondary uses; processing for that LHCR is limited to direct care purposes only (“Data within CHIE is only being processed to support the provision of direct care by the partners participating in the CHIE programme”).

Oakley Health Group does disclose confidential information:

· To third parties (including data processors)

· For secondary uses

within a number of projects:

· For Risk Stratification for Case FindingWe have a lawful – and demonstrable - data processor contractWe have specific s251 CAG authorisation to meet the CLoC (in the absence of explicit permission)

· For the National Cancer Diagnosis AuditThis is disclosure to a data controller (PHE)We rely on Regulation 2 of COPI 2002 to meet the CLoC (in the absence of explicit permission)

· For our local Vanguard/New Care Models evaluationWe have a lawful – and demonstrable - data processor contractWe rely on the explicit permission of the patient to meet the CLoC

· For the national NHS Digital GPES COVID-19 data extractionThis is disclosure to a data controller (NHS Digital)We rely on a legal obligation (s259 of HSCA 2012) to meet the CLoC (in the absence of explicit permission)

· For mandatory data uploads to NHS Digital(such as individual level GP data, the National Diabetes Audit, eMed3 data)This is disclosure to a data controller (NHS Digital)We rely on a legal obligation (s259 of HSCA 2012) to meet the CLoC (in the absence of explicit permission)

Back to Index

Is personal data being processed?

Or is this truly anonymous data out with the GDPR/DPA?Pseudonymised data = personal data

Yes, clearly identifiable, confidential information is being disclosed from the GP surgery, to a 3rd party (data processor), for secondary purposes.

Additionally, and should the practice also (ultimately) sign up to GP records sharing for direct care, the practice would be simultaneously disclosing clearly identifiable, confidential information for that purpose as well (in other words, two separate purposes).

When that clearly identifiable, confidential data is received by the data processor is it then copied to another data warehouse. As such personal data now exists in two separate databases.

That personal data is then anonymised and/or pseudonymised. If pseudonymised, then personal data about an individual exists in three separate forms.

Disclosure of pseudonymised data is disclosure of personal data.

Viewing of pseudonymised data is processing of personal data.

Back to Index

Article 35(7)(a) - The Processing

· The nature of the processing

How will you collect, use, store and delete data? What is the source of the data? Will you be sharing data with anyone? You might find it useful to refer to a flow diagram or another way of describing data flows. What types of processing identified as likely high risk are involved?

This DPIA concerns purely secondary uses processing of data (“analytics”). We have been asked to consider allowing extraction and uploading of confidential information for two purposes, direct care and analytics.

We can agree to upload for direct care but refuse secondary processing.We can agree to secondary processing but refuse direct care processing.We can agree to both direct care and secondary uses processing.We can agree to neither.

There is a single “GP dataset” extracted from GP records systems and uploaded to a data processor (Graphnet). Accordingly, the source of the GP data is the surgery’s electronic patient record.

The data extracted from the GP records system does not vary, whatever the purpose – direct care or secondary uses - of the data extraction. As the analytic ISAs state:

“There is no change to the manner in which data is extracted from GP clinical systems for use within Connected Care.”

Oakley Health Group – as well as all associated contributing data controllers – is a joint controller of the shared clinical record that is generated.But it remains the data controller for the GP records supplied to Graphnet.

The dataset definitions are listed in Appendix 1. Certain sensitive terms (excluded read codes) are not disclosed by default.

Once that clearly identifiable GP data arrives at the data processor, it is stored within the “operational CareCentric database” where it is linked to clearly identifiable “clinical data extracts from Acute, Community, Mental Health and Social Care systems”. That data is further combined with "supplementary non-clinical data covering topics such as capacity and bed state, as provided to Connected Care by the Acute, Community, Mental Health and Social Care organisations on a daily basis".

This operational CareCentric database thus consists of a huge amount of linked data about individuals, sourced from GP/Social Care/Acute Trusts/Mental Health/Community Services etc. Its primary purpose is for direct care, to enable a “shared care record” to be available to healthcare professionals when justified.

For secondary uses/analytics, a copy of that clearly identifiable data "is passed from the core CareCentric operational data repository to the CareCentric Azure-based data warehouse on a near real time basis". For that data repository, Microsoft is the sub-controller.

There is thus a second copy of the data repository, a "replication of the operational data within a separate warehouse".

Yet further linkage of data occurs within the data warehouse:

At this point, data analysis occurs, and:

· Clearly identifiable; and

· Pseudonymised; and

· Anonymised

data outputs are made accessible, via so-called “Data Marts” as described below.

There are two “streams” of secondary processing. One combines data from all GP practices, so called (and as the ISA is labelled):“Data Flow - SU180001 - Connected Care Analytics (practices)”

The other appears to limit the GP data analysed to that of Oakley Health Group, so called (and as the ISA is labelled):“Data flow SU200002 - PCN Analytics Yateley”

For “Data Flow - SU180001 - Connected Care Analytics (practices)”:

For “Data flow SU200002 - PCN Analytics Yateley”:

Accordingly, clearly identifiable data is subsequently processed by means of anonymisation and pseudonymisation.

But the data disclosed from GP practices is clearly identifiable, confidential information.

And the data copied from the data repository to the data warehouse is clearly identifiable, confidential information.

It should be noted that one of the purposes defined within “Data flow SU200002 - PCN Analytics Yateley” is “identifiable data for use by a patient’s GP to support referrals and the instigation of specific direct care activity”. It is not clear what this is, or indeed whether it is replicating “risk stratification for case finding”, for which the practices already have a s251/HRA/CAG authorised, NHS England commissioned service, and a separate data processor, for this.

It should also be noted that risk stratification for case finding remains a secondary use of confidential information, so mandating s251 authority for any such disclosure for GP records for this processing purpose(CAG 7-04 (a)/2013).

I have tried to demonstrate the data flows in a single diagram,Appendix 2.

It should also be noted that the “Data flow SU200002 - PCN Analytics Yateley” data flow applies only to our practice because our practice is a PCN. For other practices within the CCG, the data flow here would involve combining GP datasets from multiple practices within a PCN. There would then be access to psuedonymised (personal) data by persons outwith that individual’s usual surgery.

· Scope of Processing

What is the nature of the data, and does it include special category or criminal offence data? How much data will you be collecting and using? How often? How long will you keep it? How many individuals are affected? What geographical area does it cover? What will we learn about people that we already do not know, either by obtaining new information or by combining existing information?

The data is as described in Appendix 1 – confidential information derived from the GP records. It is special category, personal, data and is the very same dataset extracted and uploaded for direct care purposes.

The Connected Care data extraction process runs every 24 hrs.

See “storage limitation” under data protection principles for data retention.

The data extraction will apply to all patients of the practice except those with a relevant objection (see Right to Object).

The data sourced for the Connected Care data repository spans the Frimley STP/ICS footprint, including the GP practices of 3 CCGs, numerous trusts, social care, mental health providers, community services etc.

This processing is for secondary purposes – population health, screening, medicines monitoring, commissioning, research etc. etc.

· Context

What is the nature of your relationship with the individuals? How much control will they have? Would they expect you to use their data in this way? Do they include children or other vulnerable groups? Are there prior concerns over this type of processing or security flaws? Is it novel in any way? What is the current state of technology in this area? Are there any current issues of public concern that you should factor in?

This is use of confidential information for purposes out with direct care.

As such, patients would not expect their data to be disclosed to a third party for such purposes. That is not a reasonable expectation.

Yes, the data does come from vulnerable adults and children.

For control (or the abject lack thereof), see the Right to Object.

It is not novel technology.

There have been prior concerns about the secondary uses of such data, in relation to the authority granted under s251 for risk stratification for case finding (see “Common Law”). However, that particular CAG approval is not applicable here.

· Purposes

What do you want to achieve? What is the intended effect on individuals? What are the benefits of the processing for you, and more broadly? What will this processing allow us to do that we cannot do now?

The purposes listed are extremely wide-ranging.

For “Data Flow - SU180001 - Connected Care Analytics (practices)” :

For “Data flow SU200002 - PCN Analytics Yateley”:

It should be pointed out at the start that GP practices are perfectly capable of analysing their surgery records for almost all of those listed purposes, without the need to disclose any data to a data processor.

Our GP system, EMIS Web, is immensely powerful. We have in-built population health analysis tools.

We already have a well-established and well-used, lawful, fair, and CAG authorised risk stratification for case finding service commissioned for the practices of our CCG.

What the Connected Care strives to add is a “system wide” analysis of population health matters.

How does this directly benefit data subjects?

What is the intended outcome for individuals?

It has been suggested that the commissioning information available by system wide analysis might lead to more efficient services for patients.

The DPIA provided describes their view of benefits:

How does this directly benefit our organisation?

Does this give us a “competitive advantage”?

"If you just treat privacy as a function of regulatory compliance, you’ll do the bare minimum. Businesses need to think of privacy as a competitive advantage.”Anna Cavoukian, Global Privacy and Security by Design Centre

“Taking responsibility for what you do with personal data and demonstrating the steps you have taken to protect people’s rights not only results in better legal compliance, it also offers you a competitive edge.”ICO

It is unlikely that this processing will give our organisation a competitive edge.

We already receive referral data, prescribing data, admissions data etc from our local trusts.

But – as ever – the governance around assessing such processing, and if implemented, upholding fairness, transparency, and data subject rights, will further reinforce Oakley Health Group’s standing as a responsible data controller.

Back to Index

Article 35(9) - Consultation with data subjects

Consider how to consult with relevant stakeholders: describe when and how you will seek individuals’ views – or justify why it’s not appropriate to do so. Who else do you need to involve within your organisation? Do you need to ask your processors to assist? Do you plan to consult information security experts, or any other experts?

Was it undertaken? Do we need to? Do we need to get advice from experts?Is their written advice already out there about this?(NDG, GMC, MDU, BMA, UKCGC)

Connected Care/ICS

No consultation with patients has been undertaken about the proposed secondary uses.

There has been no patient and public involvement about the acceptability of processing confidential patient information without explicit permission.

Inexplicably, the justification within the DPIA is that:

“As the uses of the identifiable data covered by this sharing requirement are restricted to the provision of care, no explicit and direct consultation has been carried with the public in respect of this sharing requirement.”

despite that fact that the uses of identifiable data from GP systems, for this data sharing request, is for secondary uses.

We have not been provided with any consultation outcome between Connected Care and the HRA’s Confidentiality Advisory Group as to whether such processing requires, or might require, s251/CAG support to render it lawful. This is presumably because no such advice from CAG has ever been sought.

Oakley Health Group

No consultation (yet), with any of our patients, has been undertaken about the proposed secondary uses of this project.

But we have sought advice from the following experts:

· The National Data Guardian

· The General Medical Council

· The British Medical Association (Ethics Committee)

· The Medical Defence Union

· And, informally, from CAG

Existing guidance

See Appendix 3.

Back to Index

Article 35(7)(b) - Necessity and Proportionality

What is your lawful basis for processing? Does the processing actually achieve your purpose? Is there another way to achieve the same outcome? How will you prevent function creep? How will you ensure data quality and data minimisation? What information will you give individuals? How will you help to support their rights? What measures do you take to ensure processors comply?

Common Law (CLoC)

How is this met?

“If you use 'task in the public interest', it does not automatically mean that the requirements of the common law duty of confidentiality have been met. The requirements of both data protection legislation and the common law duty of confidentiality must be satisfied.”Health Research Authority

"GDPR requirements do not affect the common law duty of confidence (confidentiality)."Information Governance Alliance

When an individual entrusts a clinical care team with confidential information, the team must handle this information in line with “reasonable expectations”. In other words, confidential information should only normally be shared when there would be ‘no surprises’ for the individuals concerned.

In the UK there are legal avenues that allow the disclosure of confidential information for secondary purposes, including to support medical research, even when this is not in line with ‘reasonable expectations’ (i.e. without consent). In England and Wales, such disclosure can be approved by the HRA who are advised by the Confidentiality Advisory Group (so called ‘Section 251 approval’)

For all other secondary use disclosures (risk stratification for case finding, National Cancer Diagnosis Audit, Vanguard/New Care Models Evaluation), we meet the CLoC in one of 4 ways:

· The explicit permission (“consent”) of the individual

· A legal obligation

· Substantial public interest

· s251 HRA/CAG approval to set aside the requirement for consent

For Connected Care, we clearly cannot seek the explicit permission of all our 28,000+ patients, some of whom are children, and some of whom lack capacity.

We are under no legal obligation to disclose data for this purpose. It is not mandated by the HSCA 2012, nor COPI 2002 3(4). It is not COVID-19 related. We have no duty to disclose.

We cannot disclose the records of all our patients under substantial public interest. That is an exceptional justification and is never used for mass processing (legal obligation is, usually, instead).

The only way for such analytics to proceed would be for there to be s251 HRA/CAG authority in place.

But no such authority has been sought and provided to us.

There is a valid s251 HRA/CAG authority to disclose in force, nationally. This is CAG 7-04 (a)/2013, and it permits – solely – such disclosure for risk stratification for case finding. It is negotiated, and re-approval sought, on behalf of GP surgeries, by NHS England.

But CAG 7-04 (a)/2013 cannot be used as the CLoC legal basis for Connected Care analytics.

· CAG 7-04 (a)/2013 does not permit the disclosure of data “within” a LHCR.

· CAG 7-04 (a)/2013 permits a strictly defined GP dataset, not the dataset that is disclosed for direct care purposes within Connected Care.

· NEHFCCG’s contract for risk stratification for case finding is with SCW CSU, not Graphnet.

· CAG 7-04 (a)/2013 is limited purely to risk stratification for case finding. This was made absolutely clear in the CAG meeting of October 2012:https://www.hra.nhs.uk/documents/1337/CAG_Meeting_-_12_October_2017.pdf  (p.2-3)

“Upon review of the originally approved application and the applicant response, members unanimously agreed that the purpose of ‘population health analytics’ could not reasonably be considered to be an existing and approved purpose, based upon the original application documentation. It was agreed that the overarching purpose of the ‘risk stratification’ application, as originally described, was understood to be limited to activity intended to target vulnerable groups.”

No other purposes for such processing – including screening, research, medicines management etc, are permitted.

· CAG 7-04 (a)/2013 only permits the linkage of GP data with SUS data. No linkage with acute trust records, mental health data, community services records, or social care data is permitted

· CAG 7-04 (a)/2013 does not permit the “copying” of data from the processor to a separate database, out with the data controller

· CAG 7-04 (a)/2013 does not permit the provision of information, as a result of the processing, to anyone else but the GP surgery. There is no approval for onward disclosures of clearly identifiable outputs, pseudonymised outputs, or anonymised outputs.

Care Trak

There is precedent for s251 approval for the secondary uses proposed in this project.

Any organisation can apply to CAG for permission to undertake such processing, research or non-research.

And indeed, that’s exactly what NHS Southend CCG did, back in 2014, as an “Integrated Care Pioneer”.

https://southendccg.nhs.uk/news-events/governing-body-papers/2015-archive/28-may-2015/978-item-06-data-sharing-s251-280515/file

It sought non-research CAG approval for population health and some of the secondary use purposes proposed by Connected Care.And it received CAG approval (CAG 5-05(a)/2014).

Such disclosure was, however, out with any LHCR. It was, like risk stratification for case finding, a strictly defined GP dataset uploaded securely and directly to a data processor.

And (as far as I know) such authorised processing continues and remains out with the LHCR in that area (My Care Record).

It should be noted that access to social care data was excluded from CAG consideration, and only a handful of specified purposes were authorised:

1. Analysing the health of a population (“risk stratification for commissioning”)

2. Targeting additional preventive care interventions, [for example the support of a community matron], to high-risk patients (“risk stratification for case finding”).

3. Identify high cost individuals whose care may need to be reviewed by the multidisciplinary team with whom they have a legitimate relationship

4. Identify those with abnormal or perceived abnormal outcomes (for example emergency admissions) for alternative interventions

5. Commission new services in an affordable manner by identifying populations of clients with certain constellations of features

6. Assess whether new services are having the desired effects

GP practices in that area could not lawfully disclose confidential information to NHS Southend CCG’s commissioned data processor, for such purposes, without that CAG approval.

Within Connected Care, a single GP dataset is will be disclosed to Graphnet.That dataset will be released by the surgery is clearly identifiable, confidential information.

Subsequently, it will be processed for two purposes, direct care (shared record access) and secondary uses (in the way described earlier).

It initially appeared that this was the assumption upon which processing for secondary uses was made, both within the ISAs and the DPIA.

There appeared to be a presumption that, since confidential information is being disclosed – under implied permission – for the purposes of direct care already, that the common law of confidentiality can be disregarded when it comes to the multitude of secondary care processing envisaged by Connected Care.

There is no basis in law for such an assumption.

· The fact that confidential information is being disclosed to a data processor for direct care purposes at the same time does not obviate the need to meet the common law of confidentiality for any secondary uses processing

· The fact that patients might be able to object to the processing of their data for secondary purposes, after initial disclosure from the GP surgery, does not obviate the common law of confidentiality.That right to object is enshrined in the NHS Constitution and Article 21 of GDPR, and is in addition to, not instead of, compliance with CLoC.And it is an integral part of upholding Art 8 of the HRA, “autonomy”.As it happens, there is no such right to object in this project.

· The fact that ultimately data might be further released in an anonymised form once processed, after initial disclosure in a clearly identifiable format from the GP surgery, does not obviate the common law of confidentiality

Whether we are disclosing data to a processor purely for secondary uses or for both secondary and direct care uses, the common law of confidentiality applies. You cannot piggy-back secondary uses upon direct care disclosures, and “hide” from the CLoC.

Connected Care have subsequently put forward arguments for asserting why they believe the common law of confidentiality does not apply whatsoever for secondary uses processing within Connected Care.

1) That “no member of staff from Graphnet is involved in manual processing of identifiable data”

‘These processes are fully automated using Azure data factory and Azure SQL Server Integration services. No human sees data during these processes unless in direct response to a customer raised support call which requires investigation at a data level.’“The automated processes, up to the point of production of the three data marts in the diagram do not result in a disclosure of confidential information to an individual as no person is involved in these activities.”

“Section 79 in the GMC guidance requires there to be a disclosure for the common law of confidentiality to be engaged. The processes to develop the anonymised data mart and the pseudonymised data mart do not result in a disclosure.”

2) “The production of the Identifiable data mart and its subsequent use does result in a disclosure of confidential data. This is where it is crucial that the use of this data mart is only by staff who are involved in the direct care of the individual and already have access to other data sources on the individual(s) to conduct their services. The aim of this data mart is for the use of additional intelligence tools to support the direct care of the individual (i.e. altering interventions for individuals identified by risk stratification activities). Therefore, the common law of confidentiality is satisfied in the same way as the use of the live direct care database.”

“The pseudonymised data mart does contain a ‘tokenised ID’ replacing the full identity of the patient. With the appropriate access, this can be reversed, however this access is reserved only for users with the correct security permissions that would only be provided to staff with a direct care relationship with the patient.”

“The programme does not claim any ‘overriding public interest’ basis for the processing.”

And so, they assert, s251/CAG approval for such processing is not required.And so they haven’t even applied to CAG, for confirmation of that.

What does the National Data Guardian say about linking personal data?

The linkage of personal confidential data from more than one organisation for any purpose other than direct care, should only take place in specialist, well governed, independently scrutinised accredited environments called ‘accredited safe havens’

As with personal confidential data, the linking of de-identified data for limited disclosure or access from more than one organisation for any purpose other than direct care must only be done in ‘accredited safe havens’.

These accredited safe havens will need a clear legal basis to link data.

The Health and Social Care Act 2012 provides primary legislation for the creation of an accredited safe haven, called the Health and Social Care Information Centre (now called NHS Digital).

It should be noted that Graphnet is not listed as an “accredited safe haven”.

The CLoC can never be disregarded when confidential information is being provided to a third party.

The CLoC (nor GDPR, for that matter) does not apply when we disclose completely anonymised, or aggregate, data (such as QoF uploads to NHS Digital, or QSurveiilance data to the University of Nottingham).

Such information is not personal data (nor is it confidential, therefore).

But we are not disclosing anonymised, or aggregate data, to Graphnet/Microsoft for such secondary purposes. We are disclosing confidential information, "outside the data controller’s own boundaries" (to quote the ICO).

Disclosure does not simply mean providing confidential information to a third party who will access it.

It refers to providing information to a third party who could, and might, access it.

It refers to the flow of confidential, identifiable health information.

The fact that confidential information provided to a third party has not been looked at (yet) does not mean that disclosure has not occurred.

Disclosure occurred at the moment that information was electronically uploaded, or emailed, or posted, or handed on a USB drive, to a third party.

If a GP surgery accidentally sent confidential information to the wrong patient, then disclosure has occurred (and resulted in a breach of confidence as well as a data breach). It does not matter whether that patient actually opened the envelope and read the unintended information or not.

The Common Law of Confidence relates to the use of that information by the third party, whether anyone within that third party physically accesses the information or not.

It is entwined with Article 8 of the Human Rights Act, and as such concerns the reasonable expectations of the patient. The distinction between direct medical care uses and secondary uses is critical.

The courts now interpret an individual’s reasonable expectations of privacy as key to the duty of confidentiality.

GP records are collected and used to assist the surgery in providing medical care to its patients. That is the reasonable expectation of our patients. It is not a reasonable expectation for that information to be transmitted to a third party, for uses beyond direct medical care, and in the absence of both the knowledge of the patient and of their right to autonomy – of a meaningful way to object, specifically, to that processing.

The fact that Graphnet (and/or Microsoft) does not routinely access the confidential information provided to it, either in the Graphnet Data Repository or the Microsoft Azure Data “Factory is commendable.

It represents effective and appropriate data security, in line with obligations as data processors.

In the presence of a lawful data processor contract, it would reassure OHG, the data controller, that it was upholding Article 5(1)(f) – the data security principle (the absence of a contract obviates that).

It upholds the 4th Caldicott Principle – that access to personal data should be on a need to know basis. No-one from Graphnet/Microsoft should access the confidential information of our patients.

It upholds GMC guidance that surgeries should maintain and protect information.

But a good information security policy does not set aside or obviate the Common Law of Confidentiality.

Exemplary data security does not mean that disclosure has not occurred when a third party receives confidential information.

Graphnet and Microsoft both have a duty of confidentiality equivalent to that of the surgery.

Upholding that duty does not mean that information has not been disclosed to them.

It would be profoundly concerning if Graphnet/Microsoft did access confidential information during the processing of GP records for secondary uses.

Graphnet/Microsoft can access confidential information.It is not impossible for them to access the confidential data.

They must be able to access the information:

· In the event of a technical failure or data corruption

· If so required to produce it under a legal obligation

· If so required to produce it in the event of an investigation by a regulatory authority (ICO, GMC, QCQ)

· If so required to produce it under a SAR

Finally, the Common Law of Confidentiality is there to protect patients as well as uphold public trust in healthcare information management.

Any organisation – Microsoft, Facebook, Google Deepmind – could simply assert that “no human views” the petabytes, exabytes, zettabytes and yottabytes of information transmitted to it, and in so doing so could freely receive such information for purposes beyond direct medical care without regard to CLoC and “reasonable expectations”.

Given the state of computing power, and cloud-based storage and analysis, there would be no reason to ever seek s251/CAG support and the oversight and protection that it provides.

It would be a data free-for-all, that would result in a catastrophic loss of trust in the medical profession and vital medical research in general.

Back to Index

Caldicott Principles

1. Justify the purpose(s)How is this met?

This is not met. See “data protection principles”.

2. Don’t use personal confidential data unless it is absolutely necessaryHow is this met?

This is not met. See “data protection principles”.

3. Use the minimum necessary personal confidential dataHow is this met?

This is not met. See “data protection principles”.

4. Access to personal confidential data should be on a strict need-to-know basisHow is this met?

According to the DPIA:

The analytics data views are accessed through one of four user access profiles in the Connected Care role based access control (RBAC) model for analytics. These are:

a. Professional – which provides access to Data Mart 1 and permits analysis using identifiable data;

b. Management – which provides access to Data Mart 2 and permits analysis using pseudonymous data;

c. Commissioning – which provides access to Data Mart 3 and permits analysis using anonymous data; and

d. Administrator – which is used to control access and define analyses.

a. Data Mart 1 – Identifiable data for use by clinicians and social care professionals with a legitimate relationship and purpose

b. Data Mart 2 – Pseudonymised data for use by individuals involved in the management of cohorts of service users, services themselves, pathways, etc

c. Data Mart 3, - Fully anonymised data for use in activities such as commissioning and research

All such access is out with the control of the GP surgery – because on transfer of personal data to the data warehouse, Graphnet (the data professor) effectively becomes the data controller.

Pseudonymised data is personal data.

Access to Data Mart 2 is providing access to personal data – for purposes out with direct care, by individuals without a legitimate relationship to the patient, and providing access to non-healthcare professionals.

5. Everyone with access to personal confidential data should be aware of their responsibilitiesHow is this met?

We assume that this is the case with those that would be granted access to the information. But the surgery does not know who those individuals are, nor can we disallow any of them access. We have no control.

6. Comply with the lawHow is this met?

No. This data processing is manifestly unlawful as a breach of common law, Art8 HRA, and Article 28 GDPR.

7. The duty to share information can be as important as the duty to protect patient confidentialityHow is this met?

This principle does not apply (to data shared for secondary uses).

Back to Index

Article 5 GDPR – the data protection principles

The fundamental principles which aim to ensure compliance with the spirit of data protection law and the protection of the rights of individuals (data subjects).

Personal data shall be:

a) processed lawfully, fairly and in a transparent manner in relation to individuals (lawful purpose)

· A legal basis under GDPR

· Be otherwise compliant with the requirements of the GDPR and DPA 2018

· Be otherwise compliant with all other applicable laws, including the Common Law of Confidentiality and the Human Rights Act (Art 8)

· Not involve any otherwise unlawful processing or use of personal data

· Be fair towards the individual

· Avoid being unduly detrimental, unexpected, misleading or deceptive

· Clear and transparent to individuals and regulators

· Is this met?

“The reference to “lawfully” in the First Data Protection Principle applies to any form of conduct that is unlawful, including breach of confidence, libel, and harassment. As Patten J said in Murray v Express Newspapers Ltd [2007] EWHC 1908 (Ch) [200] EMLR 22 at para [72]:

“It seems to me that the reference to lawfully in Schedule 1, Part 1 must be construed by reference to the current state of the law in particular in relation to the misuse of confidential information. The draftsman of the Act has not attempted to give the word any wider or special meaning and it is therefore necessary to apply to the processor of the personal data the same obligations of confidentiality as would otherwise apply but for the Act”

LAW SOCIETY & others v KORDOWSKI ("Solicitors from Hell" website) ([2011] EWHC 3185 (QB))

The requirement to ensure that processing is fair, lawful and transparent is key to all aspects of processing but takes on particular importance when the processing impacts on a large volume of individuals and when it involves the use of sensitive personal data.ICO

The GDPR legal bases for the disclosure of confidential information to Graphnet, for both direct care and secondary uses, is stated as:

· Article 6(1)(e) – Official Authority

· Article 9(2)(h) – Provision of Health

It should be noted that neither

· Article 9(2)(g) – Public interest, nor

· Article 9(2)(j) – Research

are proposed as the legal basis for processing of special category data for secondary uses.

And that’s because, for Article 9(2)(j):

· A pre-condition of applying Article 9(2)(j) is that the processing has a basis in UK (or EU) law. This basis will include compliance with the common law duty of confidence, the provisions of DPA18 that relate to research, statistical purposes etc. and other relevant legislation, for example section 251 support

· The Article 89(1) requirement is to implement safeguards, in particular to respect the principle of data minimisation by measures such as pseudonymisation and the use of de-identified data wherever possible

· The application of these conditions does not remove the need for consent or an appropriate legal basis (e.g. section 251 support) that meets confidentiality and ethical requirements

· Such processing cannot meet the requirements of Section 19 of DPA 2018, in particular clearly demonstrating why anonymised data could not be used

And with respect to Article 9(2)(g)

· Such processing does not meet any of the 23 substantial public interest conditions as set out in paragraphs 6 to 28 of Schedule 1 of the DPA 2018

There is no lawful way that any organisation already disclosing confidential information to the data processor, for secondary purposes, can currently meet the common law of confidentiality requirements.

· No explicit permission is sought from individuals

· There is no legal obligation for any organisation to disclose such data to Graphnet

· There is no possible way to justify the disclosure under “public interests”

· There is no mechanism to set aside the need for explicit permission by means of a s251 HRA/CAG approved authority – there is no such authority

It is not clear, either to data controllers or to individual data subjects, as to who – exactly – will have access to their personal data via the data warehouse.

The absence of any data processor contract means that any such processing would not be lawful, not be transparent, and in breach of Article 28.

There are serious concerns about the right to object (see later) that render such processing manifestly unfair.

It would be unfair to commence any such processing (if and when rendered lawful) without the opportunity for patients to be informed. Without upholding the right to be informed, we cannot demonstrate that we have been transparent about processing.

b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes(purpose limitation)

· Specified, explicit, legitimate purposes

· Clear and open from the outset

· Purposes in line with individual’s reasonable expectations

· How is this met? How do we prevent function creep?

There are wide-ranging secondary purposes listed.

The purposes are vague, general, in no way specific or explicit.For example “screening” and “population health management”.

The purposes are not clear.

Patients do not expect the confidential information that they entrust to their GP surgery, to enable direct medical care, will be disclosed by their surgery, in a clearly identifiable way, for such purposes, without their knowledge, without their explicit permission, and without an opportunity to specifically object to such processing.

The process of making data anonymous is itself considered to be "processing" data, so if an organisation wants to anonymise personal data to bring it outside of the scope of Data Protection law, it must be done fairly, in accordance with the relevant law.

For example, in anonymising data, organisations are still normally subject to the principle of ‘purpose limitation’, provided by Article 5(1)(b) GDPR.

Organisations should inform data subjects when collecting personal data if one of the purposes of data collection is to anonymise the data for future use. If this has not been done, such anonymisation could be considered “further processing” of data for purposes beyond those for which it was originally obtained, which is subject to a number of limitations under the GDPR.

DPC, Guidance on Anonymisation and Pseudonymisation

There is a massive risk of mission creep.In fact, mission creep is already planned:

c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (data minimisation)

“Necessary”:

· It must be a targeted and proportionate way of achieving that purpose

· It must be more than just useful or habitual

· We cannot reasonably achieve the same purpose by some other less intrusive means – and in particular if we could do so by using non-special category data

· It is not enough to argue that processing is necessary because it is part of our particular business model, processes or procedures, or because it is standard practice

How is this met?

No reasons have been offered as to why truly anonymised data disclosed by the surgery will not suffice for many, if not all, of the purposes proposed for “system wide analysis”.

No reasons have been offered as to why confidential information from every patient needs to be disclosed by the surgery (the scope of the affected population).

In the DPIA suppled, the only reference to necessity and proportionality is:

“It is necessary and proportional to share the above spectrum of confidential data into a shared data repository on the grounds that:

1. The specific requirements of each instance of data use cannot reasonably be predicted in advance for some instances

2. And for others that the alternative of viewing data that is extracted in real-time from source systems is not technically feasible given the current capabilities offered by the data controllers’ source systems

3. The copying of identifiable confidential data into a shared data repository for the purposes above can be regarded as in the best interests of the data subjects.”

which appears to be in relation to the extraction and uploading of confidential information for direct care purposes – not secondary uses.

There is no reference to necessity, proportionality, or data minimisation with respect to disclosure of data from controller for secondary uses within the DPIA.

There has been no attempt to reduce the amount of identifiable information disclosed

· either from the GP surgery, or

· transferred to the “data warehouse” from the data repository

for secondary uses.

No justification has been provided as to why the cohort of data subjects, for the purposes proposed, should consist of the entire GP surgery population (save those that have opted out of direct care records sharing), including infants and young children.

We have not been provided with any information, or justification, as to the identifiers required for either

· linkage, or

· analysis

of the data.

There has been no justification as to why identifiable information needs to be used in the first place, and why anonymised or aggregate information supplied by the GP surgery would not suffice.

The only “explanation” provided is as follows:

“it is not practical for all the partner organisations to undertake the process of anonymisation separately, particularly when this can be done once, by one data processor for all partner agencies.”

But we are perfectly capable of providing anonymised or aggregate outputs, for secondary uses such as healthcare planning and commissioning. We output such datasets every day – that’s how we are paid (for enhanced services and QOF).

It is absolutely practicable for the information to be anonymised by the surgery, prior to it being supplied to Graphnet (or anyone else).

Guidance from regulatory authorities is clear:

Secondary uses of patient information include research, public health monitoring, health services planning and epidemiology.The GMC’s Confidentiality guidance recognises the importance of such secondary uses but states that non-identifiable information should, in most cases, be sufficient.MDU

Using information that does not identify individual patients is the surest way to protect confidentiality. Whenever possible, anonymised data should be used for all purposes other than direct care, including research.NDG

Could we achieve the objective without sharing the data or by anonymising it? If you can reasonably achieve the objective in another less intrusive way, you should not process the personal data. For example, where you could instead do this by sharing data that has been rendered anonymous (to which the GDPR doesn’t apply) then you should do so, as it would be inappropriate to share the personal data itself in this context.ICO

We have not been provided with justification as to why there is, allegedly, no practicable alternative to the disclosure of confidential patient information without consent in accordance with Section 251 (4) of the NHS Act 2006, taking into account the cost and technology available.

"4. Regulations under subsection (1) may not make provision requiring the processing of confidential patient information for any purpose if it would be reasonably practicable to achieve that purpose otherwise than pursuant to such regulations, having regard to the cost of and the technology available for achieving that purpose."

We have not been provided with any justification for not pseudonymising any such data disclosed from the GP surgery, for secondary uses purposes.

We have not been provided with an “exit strategy”, by which the disclosure of confidential information to Graphnet, for secondary uses, would cease in due course.

We do not require a data processor, or a new data processor, for many of the purposes listed.We already undertake in-house analysis for all our monitoring, screening, vaccination, and medicines management needs.We have our GP system to provide our population’s health management.We have an in-house pharmacist who helps use monitor medicines management.

We already have a proportionate, lawful, and well established risk stratification for case finding service. One that already has CAG approval.

We have the ability to purchase software (provided by EMIS) that will undertake risk stratification “in house”, without any disclosure to a processor being needed, should we wish to or need to (if our existing risk stratification service were to be decommissioned).

Secondary uses as envisaged by Connected Care is not necessary for our practice.

d) accurate and, where necessary, kept up to date (accuracy)How is this met?

The data as stored by our GP system is kept up to date.

e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed (storage limitation)How is this met?

We have been provided with some information about this.

f) processed in a manner that ensures appropriate security of the personal data (confidentiality)How is this met?

Remember that if a data controller failed to secure personal data of a confidential nature (e.g. loss of health personal data), then a breach of confidence can also be extended to include an Article 5(1)(f) breach.

We have no demonstrable data processor contract that fulfils Article 28.We cannot permit processing by a data processor without such a contract.

Any such processing would be in breach of Article 28, represent an Article 5(1)(f) breach, and be a personal data breach as any such processing would be unauthorised.

If Graphnet process our data without such a contract then:

· We are in breach of Article 28

· Graphnet would be processing data out with the explicit instructions of the data controller of Oakley Health Group’s GP records

· Graphnet would be a third party processing data outside of a lawful Processor-Controller contractual agreement, and then becomes the Data Controller for ultra vires processing

· In other words, we would have unlawfully disclosed confidential information to a third party, and they would be unlawfully holding and controlling it

https://www.supremecourt.uk/cases/uksc-2018-0213.html

where data is processed in a manner not explicitly permitted by the Data Controller, the Processor is in fact the de facto Data Controller for that processing activity.

 

https://www.bailii.org/ew/cases/EWCA/Civ/2017/121.html

“if they [a Processor] are processing personal data on their own behalves they will be data controllers as regards that processing and those data.”

We simply do not know who can and will have access to data within the data warehouse. It is clear that individuals outside of the GP surgery, including non-healthcare professionals, will be granted access to personal (pseudonymised) data, in the absence of a legitimate clinical relationship to the patient.

Graphnet effectively becomes the data controller for the data warehouse – the GP surgery (and the other contributing data controllers) no longer realistically control that personal data.

And Graphnet has no legal authority to be a data controller of medical confidential information – it can only be a processor.

Back to Index

No surprises

“…there must be no surprises to the citizen about how their health and care data is being used”“ Failing to offer this choice to people can accelerate discontent with how they are being informed and consulted, resulting in a growing rejection of the benefits of data sharing. “(NDG, Building trust in the use of data across health and social care)

“Trust is an essential part of the doctor-patient relationship and confidentiality is central to this. Patients may avoid seeking medical help, or may under-report symptoms, if they think their personal information will be disclosed by doctors without consent, or without the chance to have some control over the timing or amount of information shared.”(GMC)

The importance of there being no surprises for the public about the use of their data has long been a theme threaded through my work. This has run through work with my advisory panel to consider the role that the legal concept of ‘reasonable expectations’ should play in shaping the circumstances under which health and care data may be shared legitimately.(NDG)

Is this met?Does the data subject know that we are disclosing?

The explicit permission of patients is not being sought before the disclosure of their confidential information. Clearly, explicit permission ensures no surprises.

In the absence of explicit permission to satisfy the CLoC, legal authority will have to be provided by means of s251/HRA/CAG approval before the disclosure of confidential information from the GP surgery, for secondary purposes, can occur.

This is the case whether we are only disclosing data for secondary purposes or whether we are disclosing data for both secondary and direct care purposes.

Data subjects have the right to be informed, and that right helps to ensure “no surprises. But as the section on the Right to Be Informed states, it is currently extremely difficult for GP practices to uphold the right to be informed.

And without the right to be informed, patients cannot uphold their right to object. Not that there appears to be a reasonable way to object to secondary processing within this project.

Patients do not expect their confidential information, as held by their GP surgery, to be used in the multitude of ways proposed by Connected Care analytics, and absolutely not without their permission.

Data should not be used in ways that are not foreseeable to the individuals whose data it is.

Back to Index

GMC Confidentiality Principles

a Use the minimum necessary personal information. Use anonymised

information if it is practicable to do so and if it will serve the purpose.

b Manage and protect information. Make sure any personal

information you hold or control is effectively protected at all times

against improper access, disclosure or loss.

c Be aware of your responsibilities. Develop and maintain an

understanding of information governance that is appropriate to

your role.

d Comply with the law. Be satisfied that you are handling personal

information lawfully.

e Share relevant information for direct care in line with the

principles in this guidance unless the patient has objected.

f Ask for explicit consent to disclose identifiable information about

patients for purposes other than their care or local clinical audit,

unless the disclosure is required by law or can be justified in the

public interest.

g Tell patients about disclosures of personal information you make

that they would not reasonably expect, or check they have received

information about such disclosures, unless that is not practicable

or would undermine the purpose of the disclosure. Keep a record of

your decisions to disclose, or not to disclose, information.

h Support patients to access their information. Respect, and help

patients exercise, their legal rights to be informed about how their

information will be used and to have access to, or copies of, their

health records.https://www.gmc-uk.org/ethical-guidance/ethical-guidance-for-doctors/confidentiality/the-main-principles-of-this-guidance

Are these all met?

“respecting the confidentiality of health data is a vital principle in the legal systems of all contracting parties to the Convention”MS v Sweden, ECHR 27 AUG 1997

As a doctor, you have an ethical, legal and contractual duty to protect patient confidentiality.Under data protection law, those responsible for patient data are legally obliged to store it securely and protect it from unauthorised or unlawful processing.The GMC's guidance on confidentiality states that 'you must make sure any personal information about patients that you hold or control is effectively protected at all times against improper access, disclosure or loss'.You must make sure that identifiable patient data is not improperly disclosed in any circumstances. An inadvertent breach of patient confidentiality could result in you facing patient complaints or even a trust disciplinary or GMC investigation.Medical Defence Union, Protecting Patient Data

a – no, identifiable confidential information is being disclosed when anonymised data would almost certainly suffice

b – Without an Article 28 compliant data contract in place, unlawful disclosure and uncontrolled data processing will occur

c -

d – Without s251 authority, we will be breaching the Common Law of Confidentiality, resulting in unlawful disclosure

e – N/A

f – No s251 authority exists, no legal obligation exists, and we are not asking for explicit permission from our patients

g – Our ability to inform our patients, at the current time, is severely curtailed

h – N/A

The Human Rights Act 1998

Article 8 of the Human Rights Act protects our privacy, our family life, our home and our communications.“Everyone has the right to respect for his private and family life, his home and his correspondence “

Article 8 of the European Convention on Human Rights: Right to respect for private and family life

This means respect for private and confidential information, including the storing and sharing of data. And that very much includes medical information (which includes correspondence between the patient and their healthcare providers).

The Human Rights Act 1998 made the ECHR part of domestic law.

164. Respecting the confidentiality of health data is a vital principle in the legal systems of all the Contracting Parties to the Convention. It is crucial not only to respect the privacy of a patient, but also to preserve his or her confidence in the medical profession and in the health services in general.

Without such protection, those in need of medical assistance may be deterred from revealing such information of a personal and intimate nature as may be necessary in order to receive appropriate treatment and, even, from seeking such assistance. They may thereby endanger their own health and, in the case of communicable diseases, that of the community.

The domestic law must therefore afford appropriate safeguards to prevent any such communication or disclosure of personal health data as may be inconsistent with the guarantees in Article 8 of the ConventionZ v. Finland, § 95; Mockutė v. Lithuania, §§ 93-94

https://www.echr.coe.int/documents/guide_art_8_eng.pdf Guide on Article 8 of the European Convention on Human Rights, Dec 2018

“Information about the person's health is an important element of private life”S v United Kingdom (2009) 48 EHRR (para 66)

“It is unlawful for a public authority to act in a way which is incompatible with a Convention right.”HRA, s6

The unlawful disclosure of confidential information, especially in the absence of the explicit permission of the patient, their knowledge, and the affording to them of a meaningful opportunity and mechanism to object (before disclosure occurs), represents a breach of privacy.

This applies not only to the disclosure of confidential information by the GP surgery to Graphnet, but also to the onward disclosure of the identical, confidential, dataset from Graphnet to the Azure Data Warehouse (and therefore a sub-processor), and the subsequent disclosure of personal data – whether clearly identifiable or psuedonymised – to people who do not have a legitimate clinical relationship to the patient (“individuals involved in the management of cohorts of service users, services themselves, pathways, etc”).

The Law of Confidence has been reinterpreted – and has had to be reinterpreted - in the light of Article 8 of the European Convention on Human Rights.

As a result, for at least the past 20 years, the development of the common law has been in harmony with Articles 8 and 10 of the ECHR.

Article 8(1) of the HRA is absolutely engaged. Any identifiable patient data, held by a doctor or a hospital medical data, attracts a reasonable expectation of privacy.

" all identifiable patient data held by a doctor or a hospital must be treated as confidential".

"….reasonable expectations of patients that all of their data will be treated as private and confidential."R (on the application of W, X, Y and Z) v Secretary of State for Health and Home Office [2015]

As previously discussed, disclosure does not simply mean providing confidential information to a third party who will access it.It refers to providing information to a third party who can, and might, access it.It refers to the flow of confidential, identifiable health information.And it refers to the use of that information by the third party, whether anyone within that third party physically accesses the information or not.

If disclosure of personal information interferes with a reasonable expectation of privacy, without legal justification, then a legal wrong will be committed.

Article 8 is not an absolute right. It is a qualified right, but a public authority (such as a GP surgery) can only interfere where that interference is:

· In accordance with the law; and

· Necessary in a democratic society

But those two conditions are not met.

Patients absolutely have a reasonable expectation of privacy when it comes to their personal, confidential GP records.

Graphnet, System C, and Microsoft are not providers of direct medical care. There is no reasonable expectation by patients that their information would be provided to those organisations, especially for purposes beyond their direct care. The disclosure of their information -the flow, transmission from their surgery database, and use for secondary purposes – would not be consistent with his or her reasonable expectation of privacy.

Wherever their information was, the patient would expect that no-one that did not have authority to view their confidential data did so (including at their GP surgery). And that includes Graphnet/Microsoft. The fact that the policy is for no-one to access such data is simply evidence of a sound and commendable security policy. It does not diminish the patient’s right to privacy and it does not obviate adherence to the CLoC.

The right to privacy and the duty of confidence still apply even if the party receiving the confidential data would themselves maintain confidentiality (as Graphnet. System C and Microsoft must).

It would be an absolute breach of their privacy if anyone from Graphnet did access their data and would be of profound concern if that could happen, outside of technical investigations.

There is no triviality of information here - it is the entire GP record (with no attempt at data minimisation). Only if the information were, in privacy terms, ‘entirely trivial’ would it be outside the scope of protection.

.

Back to Index

Data Processors – Article 28

A controller determines the purposes and means of processing personal data.A processor is responsible for processing personal data on behalf of the controller and can act only upon the instructions of the controller.Does the practice retain full data controllership?How do we ensure that processors comply?

Does processing require the use of a data processor?YES

If yes:

Has a written data processor contract been provided?NO

Are both the controller and processor parties to the contract?NO

Are both controller and processor signatories to the contract?NO

Does the processor contract contain the following compulsory details?

· the name of the controller and the processorNO

· contact details for the controller and the processorNO

· the subject matter and duration of the processingNO

· the nature and purpose of the processingNO

· the type of personal data and categories of data subjectNO

· the obligations and rights of the controllerNO

Does the processor contract contain the following compulsory terms?

· the processor must only act on the written instructions of the controller (unless required by law to act without such instructions)NO

· the processor must ensure that people processing the data are subject to a duty of confidenceNO

· the processor must take appropriate measures to ensure the security of processingNO

· the processor must only engage a sub-processor with the prior consent of the data controller and a written contractNO

· the processor must assist the data controller in providing subject access and allowing data subjects to exercise their rights under the GDPRNO

· the processor must assist the data controller in meeting its GDPR obligations in relation to the security of processing, the notification of personal data breaches and data protection impact assessmentsNO

· the processor must delete or return all personal data to the controller as requested at the end of the contractNO

· the processor must submit to audits and inspections, provide the controller with whatever information it needs to ensure that they are both meeting their Article 28 obligations, and tell the controller immediately if it is asked to do something infringing the GDPR or other data protection law of the EU or a member stateNO

Does the processor contract?

· state that nothing within the contract relieves the processor of its own direct responsibilities and liabilities under the GDPRNO

· reflect any indemnity that has been agreedChoose an item.

· contain an expiration date for processing (after which all processing must cease)NO

· Make clear how either the data controller or the data processor may voluntarily terminate the contract, including the notice requiredNO

Is it clear that the data processor must?

· only act on the written instructions of the controller (Article 29)NO

· not use a sub-processor without the prior written authorisation of the controller (Article 28.2)NO

· co-operate with supervisory authorities (such as the ICO) in accordance with Article 31NO

· ensure the security of its processing in accordance with Article 32NO

· keep records of its processing activities in accordance with Article 30.2NO

· notify any personal data breaches to the controller in accordance with Article 33NO

· employ a data protection officer if required in accordance with Article 37NO

Does Oakley Health Group retain full data controllership over all aspects of processing?NO

Is Oakley Health Group inadvertently becoming a data controller for information out with the GP record?NO

We have not been provided with a data processor contract, between the data controller (OHG) and the data processor (Graphnet). We hold no such contract, in breach of Article 28.

It is not clear why we have not been provided with a contract. We hold contracts with every other data processor we use.

The commissioning organisation for Connected Care, NHS Berkshire West CCG, holds a service level contract with Graphnet (see this contract chain document).

Within that service level contract, they have inserted data processing terms. The CCG then asserts that contributing data controllers do not require to be signatories and parties to a data processor contract (or individual contracts) with Graphnet as they have been granted “3rd party benefits” under C(RTPA) 1999.

Connected Care asserts the following:

That a data processor contract meeting Article 28 can be met by:

· The data processing terms included within a commercial contract

· The data processing terms included within a confidentiality agreement

· Terms extended to third parties by way of the Contracts (Rights of Third Parties) Act 1999

“The Contracts (Rights of Third Parties) Act 1999 is a legitimate and appropriate means by which to extend the benefit of a data processing agreement to multiple data controllers without them each having to individually sign the agreement.”

“It is not necessary that the Contributing Data Controller(s) are a signatory to that contract; it is sufficient that they are a beneficiary of the contract, in line with the Contracts (Rights of Third Parties) Act 1999. This provides the same level of indemnity to Contributing Data Controllers against misuse of data as if they were signatories to the contract.”

“GDPR Article 28 requires that processing by a processor must be governed by a contract that is binding on the processor with regard to the controller: Article 28.3. In my view, this does not require that the controller must themselves be a party to the contract. It is sufficient if the controller can enforce the contract, under the 1999 Act.”

All the contributing data controllers are merely then “beneficiaries of the contractual terms and clauses”.

The CCG is neither a contributing data controller, not does it (or can it) access any information from the shared record. All it has done is to arbitrarily insert data processing terms into a service level contract, then

· declare itself a “data controller”

· declare itself a “joint data controller”

· assert that every contributing data controller no longer requires a data processor contract but instead is to rely on “3rd party benefits” generously bestowed to them by the CCG

Under the GDPR, when a ‘data controller’ engages a ‘data processor’, the two parties must enter in to a written contract.

Not “any two parties”, nor “any data processor”.

Any controller that is subject to the GDPR needs to have in place an appropriate Data Processing Contract with any third party that it shares data with where that third party is a processor as defined under the GDPR.

Failure to have in place a suitable Data Processing Contract is a breach of the law under GDPR.

Article 28 is unambiguous. It refers to the controller. Not any controller, not a “lead controller amongst joint controllers”, and not a controller that does not even provide the processor with data to process.

The controller, the one supplying their data, that it controls, to the processor.

We are not the data controller for a hospital trusts records, as extracted, upload and provided to Graphnet for processing on their behalf.

Equally, neither NHS West Berkshire CCG, not Frimley Health NHSFT, nor any other data controller, is the data controller for our patients’ GP records that we extract, upload and provide to Graphnet for processing on our behalf.

It is extremely important that we have a contract that determines the purposes of processing of the data that we provide to Graphnet. We may be happy for such data to be used for direct care purposes, as in the typical “shared clinical record” but not be happy for – and so refuse to permit – processing for secondary purposes. But we cannot control the processing if we are being denied a contract with our instructions detailed.

We may not be processing our personal data for all the same purposes as another controller.

We are not using the same set of personal data for this processing as another controller. We provide data from our GP records; other organisations provide data from the medical records that they alone hold and control.

We might be determined as a joint data controller for the shared, combined clinical record (which includes data that we provide), but we remain the data controller for the data that originates from our GP database.

We determine when any extraction, upload, and sharing of our data commences.

We determine when any extraction, upload, and sharing of our data ceases.

We determine whether any processing for direct care purposes happens at all.

We do not give up data controllership of our GP records as held by Graphnet – on our behalf.

Being a data controller amongst a group of “joint data controllers” does not absolve that organisation of meeting Article 28 by means of a processor contract that it is a party and signatory to.

A contract that it must hold.

There is no interpretation – whether via the golden rule, the literal rule, or the mischief rule – that arrives at the conclusion that the intention of Article 28 was anything other than that there must be a contract in place between the controller who’s data it is (i.e. that they control) and the processor handling that data on their behalf.

There is no ambiguity.

The ICO’s guidance is similarly explicit.

https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/contracts-and-liabilities-between-controllers-and-processors-multi/what-needs-to-be-included-in-the-contract/

· “the” controller needs to be very clear from the outset about the extent of the processing it is contracting out

· Processing only on the documented instructions of “the” controller

· “the” controller and processor may agree to supplement them with their own terms

· the processor may only process personal data in line with “the” controller’s documented instructions

· “the” controller, rather than the processor, that has overall control of what happens to the personal data

· If a processor acts outside of “the” controller’s instructions in such a way that it decides the purpose and means of processing, including to comply with a statutory obligation, then it will be considered to be a controller in respect of that processing and will have the same liability as a controller

It is nonsensical to conclude that the intention of Article 28 was to permit a contract between an unrelated 3rd party, asserting itself as “a” data controller, and the processor.

That data controller (NHS West Berkshire CCG) neither supplies nor controls the confidential information derived from our GP records.

Applying the general presumption that the legislators for GDPR have used legislative language “correctly and exactly” [Spillers Ltd v Cardiff (Borough) Assessment Committee [1931] 2 KB 21 at 43], the only interpretation supported by the language is that the contract must exist between the controller supplying the information and the processor handling it on their behalf.

Data controllers cannot rely on data processing terms included within a commercial contract to meet the requirements of Article 28.

Data controllers cannot rely on data processing terms included within a confidentiality agreement to meet the requirements of Article 28.

Data controllers cannot rely on terms extended to third parties by way of the Contracts (Rights of Third Parties) Act 1999 to meet the requirements of Article 28.

There is no interpretation of Article 28 that permits this.

The only relationship that NHS West Berkshire CCG have with Graphnet is that of commissioning (and paying for) Graphnet to provide data processing services to contributing data controllers. And as such, each data controller must be party to, and signatory to, an Article 28 compliant contract with Graphnet.

The organisation making decisions about the data is a Data Controller, regardless of the flow of money. And that is – and can only ever be – Oakley Health Group for our GP records.

Any contract is likely to be identical for all contributing data controllers, with the only variation being in the appendix detailing the data extracted and uploaded (which will necessarily vary between classes of organisation, such as GP surgery and hospital trust). But other types of contract are permissible (see email discussion with the ICO).

It would be nonsensical for there not to be a contract between OHG and Graphnet (that is, after all, the “mischief” that Art 28 seeks to avoid).

Third party rights do not suffice.Third party rights do not meet the requirements of Article 28.

The ICO is clear about that.

It is not correct to say that “Therefore via the Contracts (Rights of third parties) Act 1999, there would be a form of contract between OHG and Graphnet”.There is no “contractual arrangement between signatories of the ISA framework and Graphnet”.We hold no such contract with Graphnet.We are neither a signatory nor a party to any contract with Graphnet.It does not exist.

There is no legally binding contract between OHG and Graphnet. ISA’s do not magically create such a legally binding relationship, notwithstanding that Graphnet is not (and cannot be) a signatory to any of the ISAs.

The ISAs are not contracts, they are memorandums of understanding between the data controllers. ISAs are not a legal requirement (but regarded as best practice).

It should be noted that the detail about processing should be within the data processor contract, and not within the ISA. The data processing information in the service level contract that exists solely between the CCG and Graphnet is the “bare bones”. The real processing information is – inexplicably – within the ISAs.

“Data Controllership is a matter of fact and cannot be waived, re-assigned or delegated by contract terms. You can include warranties and indemnities in the contract to allow your organisation to recover losses from a problem you didn’t cause, but if you are the party making the decisions, then you ultimately remain accountable for the processing of the personal data”.Who’s in Control, Rowenna Fielding

If Graphnet process our data without such a contract then:

· We are in breach of Article 28

· We will not have a contractual relationship with the data processor

· We are not issuing instructions to GraphnetArticle 29 is clear:"The processor and any person acting under the authority of the controller or of the processor, who has access to personal data, shall not process those data except on instructions from the controller, unless required to do so by Union or Member State law."That’s the controller, not any controller

· Graphnet would be processing data out with the explicit instructions of the data controller of Oakley Health Group’s GP records

· OHG would not be in control of our data

· Graphnet would be a third party processing data outside of a lawful Processor-Controller contractual agreement, and then becomes the Data Controller for ultra vires processing

· In other words, we would have unlawfully disclosed confidential information to a third party, and they would be unlawfully holding and controlling it

https://www.supremecourt.uk/cases/uksc-2018-0213.html

“where data is processed in a manner not explicitly permitted by the Data Controller, the Processor is in fact the de facto Data Controller for that processing activity”.

https://www.bailii.org/ew/cases/EWCA/Civ/2017/121.html

“if they [a Processor] are processing personal data on their own behalves they will be data controllers as regards that processing and those data.”

There is no reason why there should not be individual contracts in place between the data controllers and Graphnet, or a single contract that all data controllers are a “multi-party” signatory to.

It is a deliberate decision to refuse to provide such contracts.

We have such contracts for every other data processor that we use.

“Organisations working as part of a LHCR will work as joint data controllers with other members of the LHCR areas, because between them they will decide on the purpose and manner for which personal data is collected; it will not be decided by one single organisation within the LHCR. As a LHCR is not a legal entity, joint data controllers will need to enter into binding contracts/processing agreements with data processers as a “grouping” of data controllers rather than appoint a single lead data controller to act on behalf of the grouping.”

NHS X

We cannot devolve data controllership to another organisation, such as a CCG or other “lead” data controller.

It should be noted that the contributing data controllers have not been provided with the service level contract, and the data processing terms inserted therein.

I had to specifically request it, and it was only provided to me under FOI.

It should also be noted that any variation of the contract needs only to be agreed between the CCG and Graphnet – no permission is required from OHG, not do we even have to be informed.

Guidance on Data controllers, Data processors and mandatory contracts:

https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/controllers-and-processors/

https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/contracts-and-liabilities-between-controllers-and-processors-multi/

https://www.dataprotection.ie/en/organisations/guidance-practical-guide-data-controller-data-processor-contracts

Back to Index

Article 25 (2) – Data Protection by Default

Data Protection by design and default is a legal requirement under GDPR.Article 25 specifies that, as the controller, we have responsibility for complying with data protection by design and by default

‘The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.’

103 Data protection by design

(1)Where a controller proposes that a particular type of processing of personal data be carried out by or on behalf of the controller, the controller must, prior to the processing, consider the impact of the proposed processing on the rights and freedoms of data subjects.(2)A controller must implement appropriate technical and organisational measures which are designed to ensure that—(a)the data protection principles are implemented, and(b)risks to the rights and freedoms of data subjects are minimised

(Data Protection Act 2018)

Are we “not processing additional data unless the individual decides we can”?Are we “providing individuals with sufficient controls and options to exercise their rights”? Are we using the least privacy intrusive approach possible to achieve our purpose?Is the planned collection and use of personal data necessary and proportionate?Have you demonstrated how privac