Information sharing between NHS Scotland boards and Police Scotland: consultation

Data Protection Impact Assessment Guidance

DPIA GUIDANCE NOTES 

Question 2 - Special category personal data 

The special categories of personal data are specified in Article 9 of the General Data Protection Regulation and include data about: 

• racial or ethnic origin
• political opinions
• religious or philosophical beliefs
• trade union membership
• genetic data
• biometric data for the purpose of uniquely identifying a person
• health
• sex life or sexual orientation

Personal data relating to criminal convictions and offences should be regarded as having the same special nature as those in the categories listed above.

Question 3 – Legal condition 

It is illegal to process personal data without meeting adequately a legal condition.

For personal data which does not relate to any of the special categories (see definition above) the legal basis for the proposed processing must be one or more from the following list. Please note that ‘data subject’ means the person to whom the personal data relates.

• 6(1)(a) – Consent of the data subject
• 6(1)(b) – Processing is necessary for the performance of a contract with the data subject or to take steps to enter into a contract
• 6(1)(c) – Processing is necessary for compliance with a legal obligation
• 6(1)(d) – Processing is necessary to protect the vital interests of a data subject or another person
• 6(1)(e) – Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller
• 6(1)(f) – Processing is necessary for the purposes of legitimate interests pursued by the controller or a third party, except where such interests are overridden by the interests, rights or freedoms of the data subject.

In NHS Scotland, in many cases condition 6(1)(e) will be the most relevant. 

For personal data which relate to any of the special categories (see definition above) the legal basis for the proposed processing must be one or more from the following list:

• 9(2)(a) – Explicit consent of the data subject, unless reliance on consent is prohibited by EU or Member State law
• 9(2)(b) – Processing is necessary for carrying out obligations under employment, social security or social protection law, or a collective agreement
• 9(2)(c) – Processing is necessary to protect the vital interests of a data subject or another individual where the data subject is physically or legally incapable of giving consent
• 9(2)(d) – Processing carried out by a not-for-profit body with a political, philosophical, religious or trade union aim provided the processing relates only to members or former members (or those who have regular contact with it in connection with those purposes) and provided there is no disclosure to a third party without consent
• 9(2)(e) – Processing relates to personal data manifestly made public by the data subject
• 9(2)(f) – Processing is necessary for the establishment, exercise or defence of legal claims or where courts are acting in their judicial capacity
• 9(2)(g) – Processing is necessary for reasons of substantial public interest on the basis of Union or Member State law which is proportionate to the aim pursued and which contains appropriate safeguards
• 9(2)(h) – Processing is necessary for the purposes of preventative or occupational medicine, for assessing the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or management of health or social care systems and services on the basis of Union or Member State law or a contract with a health professional
• 9(2)(i) – Processing is necessary for reasons of public interest in the area of public health, such as protecting against serious cross-border threats to health or ensuring high standards of healthcare and of medicinal products or medical devices
• 9(2)(j) – Processing is necessary for archiving purposes in the public interest, or scientific and historical research purposes or statistical purposes in accordance with Article 89(1)

In NHS Scotland, in many cases condition 9(2)(h) will be the most relevant.

The Information Commissioner’s Office (ICO) advises that public authorities will find using consent as a legal basis difficult.  Therefore, if the proposed processing is to use consent as its legal basis you need to indicate why this is necessary and seek the advice of an appropriate IG professional.

Question 9 –Processor

Article 4 of the General Data Protection Regulation defines a Processor as a natural or legal person, public authority, agency or other body which processes personal data on behalf of the Controller.  In practice, it includes organisations and companies that provide services such as records storage, transport and destruction and IT services, where we ask them to carry out specific tasks using personal data on our behalf.  IT suppliers, even if only accessing data/systems for support issues or bug fixes, are legally defined as a Processor.  Processors may only be used to process personal information where they have provided sufficient guarantees to implement appropriate technical and organisational measures to comply with the law.

Question 15 – Risk Assessment

Assessing The Level (Grade) Of The Risk

1. Determine the Likelihood (L) of recurrence for the event using Figure 1 (see below).

When determining the likelihood you should consider: 

• The frequency of any previous occurrences e.g. how many times a data breach was reported due to this type of issue (e.g. lost records or records accessed without authorisation) in the last month? in the last year? in the last 5 years?
• You may need to check the Information Governance, Data Protection and Information Security incidents reported in your organisation in order to assess the likelihood. 

Figure 1: Likelihood of Recurrence definitions

2. Determine the Consequence (C) rating using  Figure 2 (see below)

Look at events that could lead to the consequence, not the consequence itself

e.g. Examples of Events:

• records lost in transit (e.g. paper records sent by post)
• information recorded inaccurately or not recorded in the record 
• data not available due to ransom-ware attack
• data lost due to error in IT systems – no useful backup available.
• confidential personal data sent by email to wrong addressee
• confidential personal data made available to external people due to poor role access definition and testing
• new system or changes in a system went life without appropriate change management (new or changes in data processing started without IG approval)

Examples of Consequence

• only 1 data subject affected but significant or extreme consequences
• e.g. missed vital treatment as a consequence of information not being issued to the Individual or health professional leading to death or major permanent incapacity or
• very sensitive data being exposed to people who don’t need to know causes extreme distress (could be Individual or staff data)
• large amount of non-sensitive but personal identifiable data lost in the wind when in transit causing organisational embarrassment in the news for a week
• excessive health data shared with social worker (husband under domestic abuse investigation) causing direct threats and stalking. 
• personal health data shared by a charity with private business for commercial/marketing purposes causing unwanted disturbance.
• reportable data breach to ICO causing monetary penalty.
• complaint from Individual to ICO results in undertaking for better access to health records.
• 1.6 million Individuals in Google Deepmind
• compliance Audit recommended
• Controller action required
• undertaking served
• advisory Visit recommended
• improvement Action Plan agreed
• enforcement Notice pursued
• criminal Investigation pursued
• civil Monetary Penalty pursued

Which consequence do you opt for?

NOT worst-case scenario and NOT most likely scenario

Opt for the “Reasonably foreseeable, worst case scenario” –

• If you got a phone call to tell you it had happened, you wouldn’t be surprised

Figure 2: Consequence Table

Based on: Australian/New Zealand Standard: Risk Management (AS/NZS4360:2004) Risk Management Standard), (2004) Standards Australia/Standards New Zealand

Clinical Governance and Risk Management Standards (2005), NHS Quality Improvement Scotland

3.  Use the risk matrix shown in Figure 3 below to determine the risk grading for the risk. L x C =R

Figure 3: Risk Assessment Matrix

In terms of grading risks, the following grades have been assigned within the matrix.