GDPR - GPC - Blog 13
13 Blog Thirteen, Data Privacy Impact Assessment(s)
Revised 30th April 2018
Data Privacy Impact Assessment, D.P.I.A, well that rolls easily enough off the tongue, just a bit shorter than D.I.V.O.R.C.E.
Now what’s it all about?
GDPR, original text, page 15, recital 841, is where it all begins but Article 35 is where its specified. Under the soon to be retired DPA there is a general and ill-defined obligation to refer any “personal data processing” to the ICO. As this happens just about every time you touch the screen on your smart phone the EU realised that, 1) no one was doing this and 2) if they did the ICO and her equivalents in the Europe would be drowned in a tsunami of referrals from just about every IMEI address on the planet. That young upstart Mr Zuckerberg would have had to make at least 89 million applications under the old DPA, so this blanket general all encompassing requirement has been sensibly changed to a new process, the process of carrying out Data Privacy Impact Assessments or DPIAs as I shall henceforth call them.
So what does Article 35 actually say?
Well here it is verbatim;
Data protection impact assessment
- 1. Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. A single assessment may address a set of similar processing operations that present similar high risks.
Not what it says on the tin
Now reading the available advice on a variety of web sites you’d think a DPIA was a set piece of work associated with your next big proposed data extraction, the sort of thing you’ll see mentioned by head honcho CCG or NHSE IG guy in a project meeting. But not so. Read that Article again, DPIAs are not item by item events; they are the by-product of a deeper darker underlying process.
How so you ask?
So, to understand my logic you need to read the next Article, Article 36, here it is;
- The controller shall consult the supervisory authority prior to processing where a data protection impact assessment under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk.
To make the point we start at the end, which is the ICO (ICO = the English Supervisory Authority) approving the proposed processing. The DC has acted according to Article 36 and consulted the ICO. Important point to note, when a formal DPIA is lodged with the ICO there is one cardinal rule, you cannot proceed with the processing until the ICO has agreed to it or you’ve incorporated any changes she has suggested. So ICO sign off is the outcome. Incidentally she has a total of 14 weeks to respond.
Take one step back, sign off is a response to the application submitted by the DC. Another step back, the application is the DPIA submitted by the
DC. And another back step, the formal DPIA arose because the DC decided that the proposed process met the referral criteria.
Now play it forward. The DC has a bright new idea to process some data. The DC does a DPIA. It reaches the DPIA submission threshold. They submit the formal DPIA to the ICO. The ICO considers it and responds.
But, this DC is having lots of bright ideas all of the frickin time.
How do you know which bright idea needs the ICO’s sign off?
Exactly, you can only know which bright idea needs a formal DPIA application by assessing each bright against the DPIA criteria. Some will trigger the application threshold, some will not.
DPIA is not an intermittent action, it’s a process, an attitude, a train of thought, a way of life, a continuous approach that you must have in your mind all the time and apply to everything you do and all your bright ideas. Whenever you think about doing something new or even changing an existing process, procedure, program, data collection or extraction, hard disk or bit of kit; you must “think DPIA”.
And there’s another reversal to ponder
So, in the past everything was supposed to be referred to the ICO and they had to sift the wheat from the chaff, now the grassroots DCs must inspect the crop, asses how much wheat is present, and if they see enough for a wholegrain breakfast bap, lay down their scythes and seek permission to carry on with the harvest from the uber controller. A neat way of getting us, the data serfs, to do the work. But that’s just the cynic in me.
You might argue that GDPR has shifted the responsibility of this surveillance from the ICO to the DC.
…..and you’d be right although others will says its actually a way of getting the DC to comply with GDPR…….
And the GDPR Official Guidance says exactly that
“DPIAs are important tools for accountability, as they help controllers not only to comply with requirements of the GDPR, but also to demonstrate that appropriate measures have been taken to ensure compliance with the Regulation (see also article 24)5. In other words, a DPIA is a process for building and demonstrating compliance.”
So lets run that process again “thinking DPIA”
It begins with the DC. They have an idea about a new data process, collecting it, disclosing it, or in any way processing data, this could include the latest risk strat scheme or moving processing to an new server. They then “think DPIA”. They asses whether the new idea meets the necessary threshold. If it reaches the necessary threshold they are then required to submit a formal DPIA it to the ICO. Rather like a Death Certificate, a DPIA has to have certain things in it. If a DPIA has been submitted the DC must not go ahead with the processing. The ICO will decide and respond, sometimes with suggestions for changes or enhancements. Only when the ICO is satisfied can the DC go ahead.
So whats the trigger threshold?
The threshold for submission to the ICO is any processing that is “likely to result in a high risk to the rights and freedoms of natural persons”, as above.
So what constitutes “likely to result in a high risk to the rights and freedoms of natural persons” (Article 35(1))?
It helps to break that rather grand but lacking in detail expectation into two sections, firstly; “the rights and freedoms” bit. This means the rights to data protection and privacy but also can include other fundamental rights such as freedom of speech, thought, movement, and protection from discrimination, right to liberty, conscience and religion. Now obviously for GPs we’ll be mainly immersed in the “data protection” bit dealing as we do with patient and employee data.
OK so that’s the “rights and freedoms” bit, what does “likely to result in high risks” mean?
High risk for GPs means there is “processing on a large scale of special categories of data referred to in Article 9(1)”.
So there are two conditionalities; Article 9(1) data and large scale.
Do we have any examples of “data refered to in Article 9(1)”?
Yes, usefully provided by the WP29 documents, they list 9 scenarios that would be classed as Article 9(1). Thankfully only five of them apply to GPs;
- profiling and predicting, especially from data “concerning the data subject's performance at work, economic situation, health,”Health data, well that’s a pretty clear qualifier
4) “a general hospital keeping patients’ medical records”
The relevance here is the reference to medical records
5) Data processed on a large scale
But large scale is a justification on its own. See later.
6) Matching or combining datasets, for example originating from two or more data processing operations performed for different purposes and/or by different data controllers in a way that would exceed the reasonable expectations of the data subject.
Now that’s beginning to look interesting and reminds me of some of the “Big data” projects. They’d all undoubtedly qualify under this criterion.
7) Vulnerable segments of the population requiring special protection (mentally ill persons, asylum seekers, or the elderly, patients, etc.).
OK those are the conditions that could apply. What next?
Well GDPR expects that, where a proposed process qualifies under 2 or more of these examples then a formal DPIA is likely.
See again what I said earlier about the need for constant surveillance and “thinking DPIA”?
Its pretty obvious that there’s virtually nothing a GP can do that won’t be covered by two of those qualifying conditions.
Lets assume we have 2 conditions that both apply, what next?
We now look to the “large scale” criterion.
We’ve seen what “Large scale” means in my other Blog on DPOs.
To remind you the characteristics that indicate largeness of scale are;
a. the number of DSs involved
b. the volume and/or the range of data being processed;
c. the duration and or permanence of the processing;
d. the geographical extent of the processing.
Elsewhere in GDPR and its associated guidance large scale is alternatively described as employing more than 250 staff or dealing with patients on a hospital scale.
My conclusion, and it’s an important one
General Practices holding GMS or PMS contracts, unless you are in a mega partnership, are not “large scale”. Given all the “large scale” examples and factors noted above, if the threshold for “Large Scale” is set at the level of a hospital, a geographical area or employing more than 250 people it seems clear to me that traditional UK general practices are not “large” as regarded by GDPR.
It therefore follows that NHS General Practice Data Controllers are
rarely likely to need to submit a formal DPIA to the ICO.
So that rather stops the process and the need for this Blog in its tracks. If practices are hardly ever going to need to submit DPIA applications why type anymore?
And actually why couldn’t you have treated it as one of your “?????-Not” blogs and finished it on the first page?
Because there is a message about thinking DPIA that needed to be got across. Unlikely to never need to be having to produce a formal DPIA to the ICO is not a reason for not being aware of privacy. Think DPIA.
So just for completeness’s sake and not in any great detail;
Things will be clearer because GDPR gives the ICO the right to draw up lists of the sorts of activities that she will not expect to result in DPIAs.
A sort of “if you’re proposing to do a, b or c then no need to inform me.” List. That is Article 35(4) and the public consultation on those lists ended recently.
So lets just reassess that requirement to report any significant result from a re-assesment. Doesn’t that mean we have to reassess EVERY future processing proposal?
And if the assessment is positive, according to GDPR, refer it to the ICO
Yes, but see above. Rarely likely to be necessary for a GP surgery.
And if we submit a DPIA we mustn’t proceed with the new processing until the ICO has approved?
So how’s it different from under the old DPA?
You might argue its not, you must now asses everything and report the positive vs report everything and act on the feedback.
OK you’re thinking, so its up to us to raise it with the ICO, so we’ll just very conveniently decide to ignore it all and not do any DPIAs.
well boyo read and digest Blog 9 on fines, if you;
don’t do a DPIA when you should have
do one but do it wrong
do one, correctly or not, and don’t consult the ICO when you should have
you’re in the firing line for a hefty fine with added factors for wilfulness, negligence or belligerence. That’s a potential 10 million euro fine. Please note both a) and c) above require a continuous “think DPIA” approach. Ignorance, bleating that you didn’t think it was necessary, is not a defence. Always “think DPIA” and you won’t miss.
You do not have to carry out DPIAs for pre-existing processing. Full stop, period, end off, finished, done and dusted.
Correct. Whilst they remain unchanged. Changing an established processing activity should provoke a DPIA rethink.
So its only new data processes?
Yes, and any other older ones that are being changed. GDPR is prospective and so are DPIAs, they only apply to proposed future processing or any pre-existing processing that is substantially changed, after 25th May 2018.
As the GDPR guidance says; “The requirement to carry out a DPIA applies to existing processing operations likely to result in a high risk to the rights and freedoms of natural persons and for which there has been a change of the risks, taking into account the nature, scope, context and purposes of the processing.”
So if no DPIA is necessary we can put our feet up?
It goes on to say; “The mere fact that the conditions triggering the obligation to carry out DPIA have not been met does not, however, diminish controllers’ general obligation to implement measures to appropriately manage risks for the rights and freedoms of data subjects.”. The answer is the question, is guess what, no, think DPIA.
Not only that but
“A DPIA may also become necessary because the organisational or societal context for the processing activity has changed”. Think Cambridge Analytics, Facebook, err, if only we had known…..
And what goes up can come down.
It may be that the risk to rights and freedoms can be diminished. If you change to a better lock on your door or adopt a newer tighter password policy you’ve effectively reduced that risk. Your DPIA related concerns can be taken down one notch.
OK so have you got some examples?
Yes, and it illustrates an important point about GP records. For patient records duration plays into the concept of scale. Many of us have EPRs dating back to the 1980s. We have many patients for whom the Lloyd George stands alone, unwanted, unfulfilled and empty. An aspect of “at large scale” not explored above is volume of records. My practice of 12,000 active patients is not hospital sized when taken as a snapshot of activity today, but look back over the 12,000 active records and the 40,000 odd patients who’ve passed through our doors since 1988 and we suddenly begin to see a rather large scale dataset. The lifetime of GP records plays into the large scale assessment. In the world of GP2GP transfer, when I transfer a record to your practice you may inherit 30 years worth of EPR.
So if I want, in a practice with 12,000 patients, to do something that affects all 12,000 patients data, then that’s beginning to look “at large scale”.
So a practice moving from one supplier to another, a system change under GPSoC. That’s a barn door “at large scale”; you are considering moving every single patient record you have held, ever. Its also a barn door high risk activity; if you get it wrong then you risk the health care of all of your patients. That’s a DPIA submission open and shut case. Plan ahead because the DPIA submission and return process can take 14 weeks. Good luck in Wales!
Alternatively three smaller practices want to merge (well want is a euphemism for Mr Hunt’s demoralised and penalised them so much they see no other way out). They may have 15,000 patients between them. They may all be with the same supplier anyway and on hosted systems. Switching the access controls on those records may large scale but the risks not so high. Probably no DPIA.
My clinical pharmacist wants to trace every patient on Aloe vera and any homeopathic remedy aged over 93 who’s not been prescribed Melatonin. Small scale search. In house. Unlikely to harm. Do you think the ICO wants to know? No DPIA.
But f we did have to do a DPIA what’s the bottom line?
i.e. How to do it. If you did GDPR lays down some explicit rules about how and what must be in a DPIA.
How, who has to do it?
The controller, with the DPO and any relevant processors. The controller is responsible for ensuring that the DPIA is carried out (Article 35(2)). Carrying out the DPIA may be delegated to someone else, inside or outside the organization, but the controller remains ultimately accountable for that task.
Only stipulation is “prior to the processing” (Articles 35(1) and 35(10). Its up to you how long you wait before applying for sign off the bright idea.
The DC must also seek the advice of the Data Protection Officer (DPO)
The DPO’s advice, and the decisions taken by the controller, should be documented within the DPIA. The DPO should also monitor the performance of the DPIA, see Article 39(1)(c).
What about processors, i.e. our GPSoC supplier?
If the processing is wholly or partly performed by a data processor, the processor should assist the controller in carrying out the DPIA, see Article 28(3)(f).
The controller must “seek the views of data subjects or their representatives”, Article 35(9), “where appropriate”. For GPs that means your patients, and ideally via a note in the waiting room, alert on your web site and of course the PPG.
If the DCs view differs from the DS’s then these differences need to be documented. I can’t imagine that happening very often in GP land.
If the DC doesn’t consult with his DSs, then they need, in the formal DPIA, to document and reason why.
Content, what MUST be in a DPIA application
Best just leave this to the Article itself;
Article 35(7) with recitals 84 and 90):
- “a description of the envisaged processing operations and the purposes of the processing”;
- “an assessment of the necessity and proportionality of the processing”;
- “an assessment of the risks to the rights and freedoms of data subjects”;
- and the measures envisaged to:
- address the risks
- demonstrate compliance with this Regulation
The DPIA must be drawn up either in accordance with an Annex 2 methodology or one compliant with it.
To publish or not?
Publishing a DPIA is not a legal requirement of the GDPR, it is the DCs’s decision to do so. Generally, if you are introducing a new process, it would be sensible to publish it at least to those whom it affects.
Now that’s interesting, whilst its highly unlikely any general practice is going t need to go through a formal DPIA submission its almost certain anyone seeking data from general practices will need to have completed a DPIA by virtue of scale and risk. So when you are approached about the next big data project, think DPIA and ask for theirs.
DPIA cover more than one process
“a single assessment may address a set of similar processing operations that present similar high risks”. Obviously they’d need to be processing operations that are similar in terms of nature, scope, context, purpose, and risks.
No need to repeat
There is no need to carry out a DPIA in cases (i.e. processing operations performed in a specific context and for a specific purpose) that have already been DPIA’d by others.
joint controllers, if joined in a DPIA, need to define their respective obligations precisely. Their DPIA should set out which party is responsible for the various parts of it.
Keep DPIA decision in register
“shall maintain a record of processing activities under its responsibility” including inter alia the purposes of processing, a description of the categories of data and recipients of the data and “where possible, a general description of the technical and organisational security measures referred to in Article 32(1)” (Article 30(1)) and must assess whether a high risk is likely, even if they ultimately decide not to carry out a DPIA.
Exceptions specifically when a DPIA is not needed
When else isn’t a DPIA required, other than;
when the processing is not "likely to result in a high risk"
or a similar DPIA exists
or it has been authorized prior to May 2018
or it has a legal basis
or it is in the list of processing operations for which a DPIA is not required (to be published by the ICO).
The answer is if it doesn’t fit one of the above exceptions, never.
Dr Paul Cundy
GPC IT Policy Lead
1st May 2018