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