Month: July 2018

Record of Processing – No. 6

Record of Processing – No. 6

Introduction and comments

This week we looked at ‘record of processing’ which is a new requirement under the latest data privacy legislation. We also looked at the production of a Policy Document for the special categories of personal data (Data Protection Act 2018).

In case anyone is wondering where the timetable posting in “What, When and How” has gone, as it slipped off the list of recent blogs it has now been put as a menu item at the top of each page.

 

Review of action points from prior session

  • To do 14  Using the Information Asset Register you made in Blog No. 2, draw up a table identifying the contracts/DSAs/ISAs required for review.
  • To do 15  Review the contracts you have in the practice to ensure they are GDPR compliant using the exemplars and the checklist (see resources used).
  • To do 16  Where contracts should be in place but have not been found use the template letter to write to the contracted organisation requesting a GDPR compliant contract.
  • To do 17  Check the returned contracts from any external organisations you have contacted against the checklist provided.

Work covered this week

 

1) Record of Processing

What is a ‘record of processing’?

Under the new data protection regime, data controllers must now pay the Information Commissioner’s Office (ICO) a data protection fee. This fee replaces the need to ‘ notify’ or register (what was the case in the DPA 1998).  For further information on data protection fees, please visit the Information Commissioner’s website: https://ico.org.uk/media/for-organisations/documents/2259094/dp-fee-guide-for-controllers-20180601.pdf

There is a new requirement for Data Controllers to retain records of processing. This includes the purpose of processing, data sharing and retention. The Record of Processing must be made available to the Information Commissioner if required.

What information needs to go into a record of processing?

The following items must be included in your record of processing:

  • The name and contact details of your organisation (and where applicable, of other controllers, your representative and your data protection officer).
  • The purposes of your processing.
  • A description of the categories of individuals and categories of personal data.
  • The categories of recipients of personal data.
  • Details of your transfers to third countries including documenting the transfer mechanism safeguards in place.
  • Retention schedules.
  • A description of your technical and organisational security measures.

You can also use the record of processing to document your compliance with other aspects of GDPR and Data Protection Act 2018.

How do we complete a record of processing?

Your Information Asset and Data Flow registers (see Blog No.2) contain the information needed to complete the Record of Processing.

Use the template provided.

If you add a new information asset or flow, you will also need to update your record of processing at the same time.

You can publish your record of processing on your website. It can support your transparency requirements (Fair Processing/Privacy information to data subjects).

What do you need to consider?

Public authorities (including GP practices) cannot use ‘legitimate interest’ as a legal basis for processing.

You must identify the legal basis (Article 6 GDPR) for processing personal data from the list below.

You will need to consider lawful bases in relation to the assets and flows and this needs to be incorporated within the record of processing.

Processing shall be lawful only if and to the extent that at least one of the following applies:

  1. the data subject has given consent to the processing of his or her personal data for one or more specific purposes;
  2. processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;
  3. processing is necessary for compliance with a legal obligation to which the controller is subject;
  4. processing is necessary in order to protect the vital interests of the data subject or of another natural person;
  5. 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;

Special categories of data

For processing special categories of data (such as racial or ethnic origin, data concerning health etc) you also need one of the following legal bases (Article 9 GDPR).  The legal bases in bold are the ones which you are most likely to use.

  1. the data subject has given explicit consent to the processing of those personal data for one or more specified purposes, except where Union or Member State law provide that the prohibition referred to in paragraph 1 may not be lifted by the data subject;
  2. processing is necessary for the purposes of carrying out the obligations and exercising specific rights of the controller or of the data subject in the field of employment and social security and social protection law in so far as it is authorised by Union or Member State law or a collective agreement pursuant to Member State law providing for appropriate safeguards for the fundamental rights and the interests of the data subject;
  3. processing is necessary to protect the vital interests of the data subject or of another natural person where the data subject is physically or legally incapable of giving consent;
  4. processing is carried out in the course of its legitimate activities with appropriate safeguards by a foundation, association or any other not-for-profit body with a political, philosophical, religious or trade union aim and on condition that the processing relates solely to the members or to former members of the body or to persons who have regular contact with it in connection with its purposes and that the personal data are not disclosed outside that body without the consent of the data subjects;
  5. processing relates to personal data which are manifestly made public by the data subject;
  6. processing is necessary for the establishment, exercise or defence of legal claims or whenever courts are acting in their judicial capacity;
  7. processing is necessary for reasons of substantial public interest, on the basis of Union or Member State law which shall be proportionate to the aim pursued, respect the essence of the right to data protection and provide for suitable and specific measures to safeguard the fundamental rights and the interests of the data subject;
  8. processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services on the basis of Union or Member State law or pursuant to contract with a health professional and subject to the conditions and safeguards
  9. 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 quality and safety of healthcare and of medicinal products or medical devices, on the basis of Union or Member State law which provides for suitable and specific measures to safeguard the rights and freedoms of the data subject, in particular professional secrecy;
  10. processing is necessary for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89 (1) based on Union or Member State law which shall be proportionate to the aim pursued, respect the essence of the right to data protection and provide for suitable and specific measures to safeguard the fundamental rights and the interests of the data subject.

 

For certain other types of data e.g. DBS checks for employment and Health Data, you require another legal basis under the Data Protection Act 2018. These are detailed in Schedule 1 of the Data Protection Act 2018. Most likely it will be one of the following, but it is important to check when carrying out this exercise.

Employment, social security and social protection

1.1 This condition is met if —

(a) the processing is necessary for the purposes of performing or exercising obligations or rights which are imposed or conferred by law on the controller or the data subject in connection with employment, social security or social protection, and

(b) when the processing is carried out, the controller has an appropriate policy document in place (see paragraph 39 in Part 4 of this Schedule

Health or social care purposes

2.1  This condition is met if the processing is necessary for health or social care purposes.

2.2  In this paragraph “health or social care purposes” means the purposes of

(a) preventive or occupational medicine,
(b) the assessment of the working capacity of an employee,
(c) medical diagnosis,
(d) the provision of health care or treatment,
(e) the provision of social care, or
(f) the management of health care systems or services or social care systems or services.

Template Record of Processing

2) Policy Document

There is a legal requirement for you to have a policy document for the special category of data listed within Schedule 1, DPA 2018 that you process.  This policy document must be referred to within your Record of Processing. This policy document demonstrates that you meet the requirements of the Data Protection Act 2018 and must be retained according to the data retention period plus six months.

What is needed within the Policy Document?

  1. Explain how the Data Controller’s procedures (for this asset) complies with the six GDPR principles (see the Policy Document Template for the list of six principles); and
  2. Retention and erasure information.

If it is decided that you will not comply with the retention and erasure processes, you will need to record the reason why within the record of processing.

 Policy Document Template

 

Resources Used

Output Documentation

Learning points

  • There is no longer any need to notify/register with ICO, but on renewal, you will still need to pay a fee as a Data Controller.
  • There is a legal requirement to keep a record of processing.
  • Legal bases for processing must be documented in the record of processing.
  • New data assets and flows must be updated in the record of processing.
  • There is a legal requirement to have a policy document for each category of data processed.


Practice checklist

  • To do 18 Check your renewal data for registration with ICO, you will need to change to the new payment regime on renewal.
  • To do 19 Complete the Template Record of Processing
  • To do 20 Check the legal bases for processing for different categories of data
  • To do 21 Using the Policy Document Template, create Policy Document for each category of data

Next session on 16.08.18

(Blog No.7 due 21.08.18)

We have a three-week break, and the next session will be mid-August when we will be looking at our fair processing notices (privacy notices).

 

The ISA and DPA – No.5

The ISA and DPA – No.5

Introduction and comments

This week we looked at Information Sharing Agreements (ISAs) and Data Processing Agreements (DPAs). A note first on definitions and terminology. Whilst information is often considered processed data, in this context they mean the same thing: so, an ISA might also be referred to as a Data Sharing Agreement (DSA) or a Data Sharing Protocol (DSP).

Under the section “work covered this week” we are discussing the basic difference between ISAs and DPAs in general practice. We consider when processing is done on our behalf directly – which requires an agreement or contract – and when it is done indirectly where a deed may be needed.

The main thrust of this week’s work is: to know when we need agreements or contracts in place for sharing or processing data; and to develop a checklist which identifies those agreements and ensures they are up-to-date and compliant with data protection legalisation (DPA2018 and GDPR). Creating the checklist can be done easily as part of this week’s work. Identifying the necessary contracts and agreements may involve contacting external organisations and reviewing existing documentation and is more likely to be a process which happens over a period of months. We will revisit this task in one of the later sessions to ensure that it is ‘closed’.

This week we cover a lot of information and work and there are two sections:

  • Theory; and
  • Practical.

Please read the theory section, but if you are keen to identify the work ahead, this is in the practical section.

Review of action points from prior session

  • To do 12  Review your Individual Rights Policy and procedures and update using advice and examples provided.
  • To do 13  Review and update your SAR policies and procedures.

Work covered this week (the theory)

Information Sharing Agreements

Information Sharing Agreements are used when two or more data controllers share data. For example, shared care records where GP Practices and Trusts share the data they have collected to use either for a joint purpose or for their sole benefit.

ISAs facilitate the sharing of personal confidential data by setting out good governance mechanisms and each party’s expectations of each other. They are not usually legally binding unless incorporated within a contract but are intended to define good practice. The Information Commissioner’s Office (ICO) has published a Data Sharing: Code of Practice which includes details on what is required within an ISA. Wherever possible, be guided by these codes of practice. They show that you have considered all the necessary elements, and in the worst-case scenario of managing a complaint, you get the additional assurance that the ICO will support your approach.

From a DPA/GDPR perspective, little has changed with regard to ISAs, as they are not a statutory requirement. However, they should be considered a useful technical mechanism, which enables organisations to have secure and lawful controls to share and process data. It is important to update current ISAs to reflect the changes within GDPR and the 2018 Data Protection Act (DPA 2018). For example, organisations which previously documented ‘legitimate interests’ as a legal basis within their ISA will now need to use ‘processing as necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller’. This is because public authorities are no longer permitted to use the legitimate interest legal basis for their core functions.

GDPR also removes the term ‘Data Controllers in Common’ as defined within the Data Protection Act 1998. Under GDPR, the definition of Data Controller only includes ‘sole’ or ‘joint’. You may need to change these terms, depending on which is more appropriate for a given situation. For an integrated care record, the parties will share their data but may allow each other to read and write into the system. In this system, it is likely that the parties would be joint data controllers. If you search ‘In Common’ in your DSA that should bring up the term you need to review each time.

Data Processing Agreement or Contract

What is processing?

Processing includes a wide range of activity: creating, handling, storing, conducting analytics, retaining and destruction of data and it doesn’t matter whether it is electronic or paper records.

Data Processing Agreement/Contract

Data Processing Contracts are used when the Data Controller asks another party to process data on their behalf. For example, the GP Practice is a Controller, but a contracted-out IT team provide technical services to GPs e.g. implement systems to hold personal confidential data. Another example would be where a GP Practice wishes to write to their patients about a new service. The GP Practice may want to outsource this activity and ask an external company to write to them on their behalf. In order to do this, the external company, perhaps their Federation, will have access to patient names and address details. In this case, the external company is processing the GP Practice’s personal data and a data processing agreement or contract is required by law to detail the parties and processing activity. Note, that the GP Practice isn’t sharing the data with GP Federation, they are asking the GP Federation to process on their behalf – under their instruction. These examples are Data Controller to Data Processor relationships. Data Processing Contracts or Agreements (DPCs/DPAs) are legally binding and these types of contract have always been a requirement of privacy legislation. GDPR stipulates what needs to be included within such contracts, and these requirements are listed in Article 28.

To be valid, contracts require the following three elements:

  • Offer
  • Acceptance
  • Consideration (usually payment for services – see below)

What happens when you do not have consideration?

There may be a scenario where there is no monetary exchange (‘consideration’), e.g. a CCG purchases a service or software which processes personal confidential data on behalf of the GP Practice. There is no exchange of payment between the GP (the Data Controller) with the Data Processor. In this case, a Data Processing Deed will need to be put in place between the Data Controller and the Data Processor (making a formal link between them even though the contract and consideration are handled by another party). A Data Processing Deed is a legal document and binding on both parties. The deed needs to be explicitly ‘executed as a deed’ within the document and signatures on the deed must be witnessed.

From a GDPR perspective, processors may only process personal data on behalf of a controller where a written contract is in place which imposes a number of mandatory terms on the data processor, as set out in the GDPR. The Data Processor is not permitted to deviate from this instruction.

Contract reviews

Dame Fiona Caldicott, in her Information Governance Review, noted that the contract mechanism is key in providing protection and must be legally enforceable, and so practices should undertake a contract review. This will allow you as Data Controllers to see if there are adequate data protection and confidentiality within any given contract for the type of processing which is being undertaken.

The contracts should be reviewed, and the risks assessed, based on the organisational context. For example, a cleaner who inadvertently sees personal confidential data for an individual would have a different level of risk than that of a software provider which processes personal confidential data like SystmOne. So, the cleaning contract would not necessarily have the same terms and conditions when compared to a contract with SystmOne.

You only need to undertake a contract review when a processor has provided you with a contract, or you have contracts in place which will need updating in order to comply with the UK’s data protection legislation and the requirements of GDPR.

Work covered this week (practical)

  1. Identify the ISAs and DPAs required for review from our Information Asset Register.
  2. The contracts in our possession are being reviewed as exemplars and when this work has been done they will be published in the ‘Output Documentation’ section.
  3. Draft letters have been sent to companies to provide us with the contracts where the need has been identified.
  4. Once the contracts have been received we will review them against the checklist provided and they will be published under ‘Output Documentation’ in due course
  5. When these activities have been completed, we will have an up to date Contracts register and/or Data Sharing Agreement register.

We focussed on contracts where the data processor is processing personal confidential data on behalf of a GP Practice. Our first port of call was to review our Information Asset Register which was drawn up in Data Mapping Blog No.2. This shows whether the assets which have been listed require a contract/Data Sharing Agreement and also possibly a Data Protection Impact Assessment (DPIA) as explained in The DPIA Blog No. 3.  The table below lists the circumstances where we need either a GDPR compliant Data Sharing Agreement or an Information Processing Agreement.

DPA/ISA list exemplar

Not every item on this spreadsheet will apply, and each practice will have to check their own asset register. We have included this table as an exemplar (as completed to date by us) in the ‘output documentation’ section and also as a blank template in the ‘resources used’ section. We will need to revisit this document over the coming months as the information becomes available and each contract is confirmed as GDPR compliant. The responsibility for doing so will always rest with the practice, but you can expect services commissioned through the CCG to have a GDPR compliant Data Sharing Protocol (DSP) provided. When looking at contracts between the local provider and your surgery, many of these providers will have their own GDPR compliant contract for you to sign. If your contract is with a small cleaning company, for example, the practice would be required to provide the contract. In this event, the Caldicott contract checklist will detail those sections which are required.

Note: NHS Contracts is more than likely to have NHS Standard Contract clauses, and these will not need to be reviewed.

You will only need to review external contracts if there are any variations or changes to the law (as now in the case of DPA2018/GDPR) or when you undertake a new contract. When a service/product is commissioned by the CCG or other parties, you should ask them for the review they have completed on the contract by way of assuring GDPR compliance.

To assess whether the contracts are GDPR compliant, we have used the checklist recommended by Dame Fiona Caldicott in conjunction with the Template Data Processing Terms and Conditions document (see below under Resources Used).

A significant amount of work has been identified in this week’s blog and that this will take some months to complete. As we update our contracts we will publish them for information. Whilst you cannot use these as is, if you are using the same service or company it will inform you that the contract is available and GDPR compliant and can be signed in your name.

Resources Used

General:

Specific to this blog:

Output Documentation

Learning points

  • ISAs are used when there are two or more Data Controllers sharing data jointly or as a sole data controller.
  • ISAs a usually not legally binding. They are good practice and demonstrate the controls you have in place to secure and lawfully process personal confidential data.
  • GDPR does not change how we use ISAs as they are not a statutory requirement under the law. However, GDPR does change the legal basis for sharing data used by public authorities and also removes the ‘data controllers in common’ definition from the law.
  • GDPR places stricter statutory requirements on Data Processors and all processing undertaken by a Data processor requires a Data Processing Contract.
  • Data Processing Contracts are used when the Data Processor is processing personal confidential data on behalf of and with instruction from the Data Controller. These types of scenarios are more likely when one party provides services to another.
  • Data Processing Contracts are legally binding and if there is no consideration, a deed may be used and is legally binding if ‘executed as a deed’ and witnessed.

Practice checklist

  • To do 14  Using the Information Asset Register you made in Blog No. 2, draw up a table identifying the contracts/DSAs/ISAs required for review.
  • To do 15  Review the contracts you have in the practice to ensure they are GDPR compliant using the exemplars and the checklist (see resources used).
  • To do 16  Where contracts should be in place but have not been found use the template letter to write to the contracted organisation requesting a GDPR compliant contract.
  • To do 17  Check the returned contracts from any external organisations you have contacted against the checklist provided.

Next session on 19.07.18

(Blog No.6 due 24.07.18)

Next week we will be looking at records of processing and how data controller and their representatives need to maintain a record of the activities they undertake in managing the data which they are responsible for.

Individual Rights & SARs – No. 4

Individual Rights & SARs – No. 4

Intro and comments

This week we looked at the individual rights of data subjects, which GPs as data controllers must now be able to provide under GDPR. They are detailed below. Discussing these new rights in practice meetings can be a good way of helping your team to understand and meet them. We have now reviewed our practices’ current policies and procedures to bring them up-to-date.

We also covered the topic of Subject Access Requests (SARs), again to ensure that we meet the latest requirements.

SARs have been the source of much discussion. There is some anxiety that if we are expected to respond to them in volume, without being able to charge, that the time and effort they require might overload our practices. It is possible to negotiate the terms of a SAR and also in a certain circumstance to charge a fee (e.g. where the purpose is for the production of a medical report). But the concern is understandable because it does seem likely that a significant number of SARs will need to be provided without charge, and the effort needed, other than in a tiny minority of cases where they are “unfounded and excessive”, is not a consideration of the law.

Fear of the unknown plays a part here, and as yet there has been no sign of the floodgates opening, although we are still in early stages post-GDPR. However, if there is any potential for a torrent of SARs, we should be considering any possible mitigation. Perhaps the most promising option will be to respond to a SAR by making patient records available to them electronically. We already have the means for doing this through our clinical systems, but the work required to make patient records fit for purpose (excluding 3rd party and potentially harmful data) is potentially a daunting one. However, the SAR scenario now adds to the imperative of a task which has been our mark on the horizon for some time. The bonus to this approach is that there will be clear benefits both to patients and practices. Consider the advantage to your patients, and the saving in reception and GP time if they were able to obtain their path results on-line and could be pointed to an NWL resource explaining the finer details of blood tests in plain English.

Historically the job of excluding 3rd party and harmful data has been the remit of GPs, and it is now law that a health professional needs to review the response prior to disclosure, but does this need to be the GP? The inclusion of third-party data in records is not that common and the presence of harmful data is exceptionally rare. It would not be difficult to train non-clinical staff to identify this information and defer to a clinician where identified and doing so would significantly reduce the clinical workload in this process. If we wish to share patient data widely with our patients (and there are many other reasons beyond the scope of this blog why we should), this work may become one of our high priorities following on from GDPR.

Review of action points from the prior session:

Below are last week’s action points, but please don’t forget to work through the blogs and actions points in order.  For instance, our first action point is to assign appoint a GDPR lead for your practice and let us know their name and email address by sending this and your practice details to nwl.infogovernance@nhs.net.

  • To do 08  Assess whether you need to complete a DPIA using the DPIA Process Flow Map
  • To do 09  Complete the DPIA (only if necessary)
  • To do 10   Practice Data Protection Officer to review and approve DPIA (if complete Action 09)
  • To do 11    Action and document mitigation actions from DPIA (if complete Action 09)

Work covered this week:

Below are details of the new rights which patients can expect you to deliver post-GDPR. After reviewing these we have updated our Individual Rights Policy and procedures and have published an Individual Rights Policy Document. Guided by the information below on the requirements for SARs and using a Managing SARs Flowsheet we have updated our SAR process and also produced a SAR template response to patients. You may wish to use these as templates for your own practice.

A) Individual Rights

  1. The right to be informed

Individuals have the right to be informed about the collection and use of their personal data. Privacy notices must provide individuals with information regarding the organisation’s purposes for processing their personal data, the retention periods for that personal data, and who it will be shared with. The organisation is required by law to provide its privacy notice to individuals at the time you collect their personal data from them. Your response to a request for personal data from other sources must provide individuals with privacy information within a reasonable period of obtaining the data and no later than one month. The information the organisation provides to individuals must be concise, transparent, intelligible, easily accessible, and it must use clear and plain language.

  1. The right of access – Subject Access Requests (SARs)

EU GDPR provides individuals with the right to access their information. Subject access requests can be made verbally or in writing and the organisation has one month to respond to the request. It is important to note, that under GDPR, organisations are not permitted to charge the data subject in most circumstances. We cover SARs in more detail below in Section B this week.

  1. The right to rectification

EU GDPR and the Data Protection Act 2018 provides a right for individuals to have inaccurate personal data rectified or completed if it is incomplete. The right to rectification can be applied for verbally or in writing and the organisation is required to respond within one month to a request. Some rights are not absolute and there are circumstances where a request can be refused. This will need to be reviewed on a case by case basis or advice sought from the legal team (your medical defence organisation).

  1. The right to erasure – doesn’t apply to Health Records

The EU GDPR and the Data Protection Act 2018 introduces a right for individuals to have personal data erased. The right to erasure can be applied for verbally or in writing and the organisation is required to respond within one month to a request. As noted, some rights are not absolute and there are circumstances where a request can be refused. This will need to be reviewed on a case by case basis or advice sought from the legal team (your medical defence organisation).

  1. The right to restrict processing

The EU GDPR and the Data Protection Act 2018 gives individuals the right to request the restriction or suppression of their personal data. For example, if the Data Controller is holding incorrect information on an individual, the individual can ask for the restriction of processing their data until the data is accurate or complete (restricted to store the information but not use it). The right to restrict processing can be applied for verbally or in writing and the organisation is required to respond within one month to a request. The right to restrict processing is not an absolute right and there are circumstances where a request can be refused. This will need to be reviewed on a case by case basis or advice sought from the legal team (your medical defence organisation).

  1. The right to data portability – doesn’t apply to health records

… unless it is an explicit consented process/pathway and/or if you are conducting automated decision making.

EU GDPR and the Data Protection Act 2018 allows individuals to obtain and reuse their personal data for their own purposes across different services. It allows them to move, copy or transfer personal data easily from one IT environment to another in a safe and secure way, without hindrance to usability. The organisation must respond without undue delay, and within one month. This can be extended by two months where the request is complex or you receive a number of requests. The organisation must inform the individual within one month of the receipt of the request and explain why the extension is necessary.

Where the organisation is not taking action in response to a request, they must explain why to the individual, informing them of their right to complain to the supervisory authority and to a judicial remedy without undue delay and at the latest within one month.

  1. The right to object

Under the EU GDPR and the Data Protection Act 2018, individuals have an absolute right to object, unless there is a compelling reason that the organisation is required to continue processing.

Individuals must have an objection on “grounds relating to his or her particular situation” and if they do, the organisation must stop processing the personal data unless:

  • the organisation can demonstrate compelling legitimate grounds for the processing, which override the interests, rights and freedoms of the individual; or
  • the processing is for the establishment, exercise or defence of legal claims.

The organisation is required to inform individuals of their right to object “at the point of first communication” and in the organisation’s privacy notice and this must be “explicitly brought to the attention of the data subject and shall be presented clearly and separately from any other information”.

The organisation must stop processing personal data for direct marketing purposes as soon as it receives an objection. There are no exemptions or grounds to refuse.

The organisation must deal with an objection to processing for direct marketing at any time and free of charge and the organisation must inform individuals of their right to object “at the point of first communication” and in your privacy notice.

  1. Rights in relation to automated decision making and profiling

Individuals have the right to object to automated decision making and profiling. Automated decision making means a process/pathway whereby the decision is based on automated means (e.g. electronic decision). Profiling means where an organisation is using personal data to evaluate certain things about an individual and includes using automated means to do this. Both scenarios do not have or only partly have a human component to the decision making. There are additional requirements to meet if you are solely utilising automated means without intervention – but GDPR restricts this processing if the processing has a legal or similar significant effect on the individual e.g. the decision would have a serious negative impact on the individual. The impact would impact the individual’s legal rights or something similar which would have an impact e.g. refusal of online loan application or using automated means for recruitment based on algorithms. In a health context, if you profile a group of patients (based on their sensitive health data) to whom you automatically provide a service, a patient may be able to object if there has not been any human input into the decision making process.

GDPR considers this type of processing as high risk, therefore, a Data Protection Impact Assessment (DPIA) is required to be completed. This is in order to identify the risks and document the mitigating actions which are to be implemented.

If there is a human component to the automated decision making, you will still be required to have a lawful basis to do so.  And ensure you have a process in place to process the request for objecting to this type of processing. GDPR states that it is important to bring this to the attention of the Data Subject and how they could object to this processing. To honour the data subject’s right to object to automated decision making, it is important to put in place an independent human review process.

Whilst this external resource is not related specifically related to health services, but it goes into more detail to explain the underlying principles related to rights in automated decision making.

Action Point: Through our review, we have developed an Individual rights policy which covers all rights and associated processes which you can adapt to your practice process. Please ensure that you have appropriate mechanisms in place to honour individual rights. 

B) Subject Access Requests (SARs)

EU GDPR provides individuals with the right to access their information which an organisation may hold on them. Subject access requests can be made verbally or in writing and the organisation has one month to respond to the request. The data subject is required to know the following:

  • Confirmation that you are processing their data
  • A copy of their personal data
  • Other supplementary documentation e.g. correspondence

There hasn’t been much change in how you process the request in itself, the following points still apply:

  • You can ‘stop the clock’ of the one-month time frame when you a) ask for identification and b) any further information to support the request e.g. ask for specific dates and times of information they are asking for.
  • You still need to verify the identification of the data subject
  • You still need to redact third-party information if you risk disclosing the third-party identity unless you have received consent from them or it is reasonable to comply with the request without the third-party consent.
  • It was a good standard practice that a clinician would review the requestor’s information prior to disclosure to the data subject. This is now a requirement in law under the provisions of the Data Protection Act 2018 (Schedule 3, Part 2(6) Data Protection Act 2018).

Changes to the SAR process:

The previous timeframe for responses was 40 days, which has now been decreased to one month. One month means:

  • An organisation receives a request on 3 September. The time limit will start from the next day (4 September). This gives the organisation until 4 October to comply with the request.
  • An organisation receives a request on 30 March. The time limit starts from the next day (31 March). As there is no equivalent date in April, the organisation has until 30 April to comply with the request.
  • If 30 April falls on a weekend or is a public holiday, the organisation has until the end of the next working day to comply.

It is important to note that under GDPR, in most cases, organisations are no longer permitted to charge a fee for subject access requests. However, where the request is ‘manifestly unfounded or excessive’ you may charge a fee for administrative costs to comply with the request. You may also charge if you receive a request for further copies of their data following their request. Again, the charge must be based on administrative costs. Determining whether a request is unfounded or excessive must be made by the practice and decisions will be required to be documented. Should the practice decide not to comply with the request, the practice is required to explain the rationale and notify the data subject how to make a complaint to the Information Commissioner if they wish to do so.

We have received some questions from practices regarding when they can and can’t charge and what about AMRA (Access to Medical Reports Act 1988) where you are permitted to charge. The Access to Medical Reports Act 1988 is explicit in that where the medical reports produced are for insurance or employment purposes, the data controller is allowed to charge for the report. It is the purpose for requesting the SAR which is pivotal here. Subject access requests may come from a third party acting on behalf of the data subject with their consent, therefore, any request for information unrelated to a medical report and not creating information should be processed in line with the subject access request process which will not be chargeable.

You are now also required to provide certain information to the data subject regarding the information you hold on them. This includes:

  • The purpose(s) of the processing (this could be treatment and care or for the performance of a contract (e.g. employment)
  • The categories of personal data being processed (special category of data e.g. physical and mental health, ethnicity, Sexual Life, Trade Union membership)
  • The recipients or categories of recipients (who receives the data e.g. clinicians from the acute trust, the data subject)
  • The envisaged retention period or the criteria that determine it (as per your practice retention schedules which should reflect Information Governance Alliance: Records Management Code of Practice).
  • The rights of rectification, restriction, objection and where applicable erasure.
  • The right to complain to the ICO (Contract details can be found on the Information Commissioner’s website).
  • The right to know more about the source if it is not from the Data Subject (has the information come from a third party other than what the data subject has provided you).
  • The existence of and logic behind and consequences of any automated processing (why you are utilising automated decision processing, what are the benefits, what are the consequences).

It would be beneficial if you utilise the templates provided and use the bullet list in order to fulfil the requirements specified within GDPR.

There is further detail in the two blogs (below under resources used) by Dr Paul Cundy in relation to SARs which make essential reading.

Action point: Update your Subject Access Request Process and the other Individual Rights processes.

Resources used

Output documentation:

Learning points:

  • Patients have a series of new rights related to how data controllers manage their data
  • Discussing these new rights at practice meetings can be a good way of helping your staff to understand and meet them
  • GDPR has made significant changes to the timescales, fees and content of Subject Access Requests
  • Many SARs will no longer be chargeable. However, when a third party (e.g. an insurance company or lawyer) request a SAR, you should be told the purpose. If that purpose is for the provision of a medical report then you are entitled to charge for the service under the Access to Medical Reports Act (AMRA)
  • To date, there has not been a massive increase in the number of requests for SARs. However, you may wish to consider making your patients’ data available to them online (after excluding 3rd party and harmful data) as one way of meeting the potential demand.

Practice checklist:

  • To do 12  Review your Individual Rights Policy and procedures and update using advice and examples provided
  • To do 13  Review and update your SAR policies and procedures

Work planned for next session on 12.07.18

  • Next week will be focused on contract reviews. We will be looking at the requirements for processing contracts and what to look out for.
The “DPIA” – No. 3

The “DPIA” – No. 3

Intro and comments

In order to meet the latest privacy legislation, we need to consider data risks early in the design stage of any project. This week we will be looking at the Data Protection Impact Assessment (DPIA) which is a tool which allows us to do this and which supports ‘privacy by design’.

A data protection impact assessment (DPIA) is an evaluation and analysis of the risk to data privacy which might result from any action carried out in your practice. It is often done in projects where personal data is being shared, but it can and should be considered in any significant undertaking where there may be a risk to sensitive data.

Most practices will not need to undertake a DPIA, as one has already been commissioned by the NWL IG group for the sharing of personal information for direct health care.  Please ask your CCG for a copy of this when a new service is procured where you are sharing data. But if there are any changes to the way you process or share data, or if you are looking to share data in new ways, you will be required to do one. We have listed the criteria you need to assess whether or not a DPIA needs to be done and given some examples.

Our practices will shortly be moving to new premises, so we decided to carry out a DPIA to look at any risk to our data which might result from that move. You can see this as an example DPIA in the output documentation section.

Lastly, before we move into the nitty-gritty of DPIAs I wanted to close a point related to last weeks blog on data registration and mapping. Do remember that the mitigation of any significant risks identified through our data maps will, in due course, be reflected in our practice policies, protocols, guidelines and procedures (which will be dealt with in blog 9).

Review of action points from the prior session:

If you have not already completed them, here is a reminder of the actions from last week:

  • To do 01: Appoint a GDPR lead for your practice and let us know their name and email address by sending this and your practice details to infogovernance@nhs.net.
  • To do 02: Review the email and GP GDPR resource pack sent on 24th May
  • To do 03: If you are happy to use the interim FPN supplied (which we recommend) then publish this to a Fair Process Notice section on your practice website, with links to your local CCG sharing website. Please note that even if you had already uploaded the interim FPN to your website, you should repeat this process with the latest document (v1.03) which contains minor revisions as per the version control section.
  • To do 04: Add a link to the A3 poster which points to the FPN section on your practice website and display the A3 Poster in your practice.
  • To do 05: Build an information asset register and map the flows of data in and out of your practice
  • To do 06: Consider using an online resource (e.g. Blue Stream Academy, there are others) which has a module on GDPR theory which practice staff can go through
  • To do 07: Let us know at intervals how you are progressing on these checklists

Work covered this week:

Our Practice Managers are learning each week, as well as doing!  So below is some background about the importance of privacy by design and Data Protection Impact Assessments.

A) Privacy by Design and DPIAs – a bit of background

The DPIA enables data controllers to ensure that services are compliant with GDPR and Data Protection Act 2018. It integrates core privacy considerations into existing project management and risk management methodologies and policies.

DPIAs identify the information risks in relation to personal data and special categories of data but can also be used to assess information risk surrounding business sensitive data.

Complete a DPIA:

  • when you are sharing information between organisations; or
  • for any new or changes made to projects, services, products or systems.

By incorporating the privacy by design approach, data controllers are able to use it as an essential tool to minimise privacy risks and build trust.

Benefits of a DPIA include:

  • potential problems are identified at an early stage when addressing them will often be simpler and less costly;
  • increased awareness of privacy and data protection across an organisation;
  • organisations are more likely to meet their legal obligations and less likely to breach GDPR and Data Protection Act 2018;
  • actions are less likely to be privacy intrusive and have a negative impact on individuals; and
  • establish data processing instructions required within contracts or if Data Sharing Agreements need to be drafted.

B) Should I do a Data Protection Impact Assessment (DPIA)?

We used a data processing flow map, to assess if we needed to complete a DPIA.  Our two GP practices will be moving to new premises and under GDPR, this significant change requires us to complete a DPIA.

Below are some examples of when you need to complete a DPIA and when you don’t, and the DPIA Process Flow map we used.

Action point: 

Check to see if you need to undertake a DPIA, using the DPIA Process Flow Map and examples above.

If you are not sure if you need to complete a DPIA, enquire through the  Support Email

C)  How do I complete a Data Protection Impact Assessment?

Our consultants provided us with a DPIA template, and we worked through each of the tabs in turn to identify the information risks.  We have included a copy of our completed DPIA to help guide you through the process, as well as a template for you to complete (if necessary).

  • Complete tab one – Project details and provide an explanation of the new or change to process, service, product or system.
  • Complete the screening questions. If you have a ‘red’ answer you will need to complete each DPIA sheet/tab. If your answers are ‘green’ you do not need to complete the other DPIA sheet/tabs. This will be your evidence to demonstrate there are no information risks.
  • Complete DPIA Questionnaire 1 – and make notes against your answers.
  • Complete DPIA Questionnaire 2 – using the information you answered within screening ‘red’ and questionnaire 1, complete the questions (questionnaire 2) providing as much information as possible.

With all your answers, you should have identified the information risks. Complete the information risks and associated mitigating actions within sheet/tab 4.

Your Practice Data Protection Officer would normally review and approve the completed DPIA. However, as we are currently using an interim DPO we suggest that you engage your practice Caldicott Guardian in this process. If there are problems or questions please make any enquiries through the Support Email

. We anticipate that most practices will not need to undertake a DPIA, but where one has been done and requires formal approval this can be obtained through their DPO.

Actions must be completed and documented, to show compliance with GDPR and the Data Protection Act 2018.

Resources used

Output documentation:

Learning points:

  • Consider any changes or new projects that might have an impact on how you share or process information – always check to see if you need to complete a DPIA

Practice checklist:

  • To do 08  Assess whether you need to complete a DPIA using the DPIA Process Flow Map
  • To do 09  Complete the DPIA (only if necessary)
  • To do 10   Practice Data Protection Officer to review and approve DPIA (if complete Action 09)
  • To do 11    Action and document mitigation actions from DPIA (if complete Action 09)

Work planned for next session on 05.07.18

  • Review current processes for meeting individual rights to ensure compliance with GDPR and Data Protection Act 2018