Data protection impact assessment (DPIA) template
This template uses the recommended DPIA structure from the ICO and can be used by deploying organisations to support the development of a local DPIA.
Why is this DPIA needed?
Concentric, developed by Concentric Health, is a digital consent to treatment application. It is used in place of traditional paper-based consent forms for any operation, procedure, or treatment where written consent is documented.
The introduction of Concentric digital consent is being done in order to:
- digitally transform the consent process, allowing a paperless process
- reduce errors, omissions, and variation in the consent process
- improve patient understanding of the treatment and risks
A DPIA is required as the implementation of Concentric involves the processing - by Concentric Health as the data processor on behalf of the healthcare organisation as the data controller - of the following data:
- Patient: title, given name(s), family name, date of birth, gender, identification number, and contact details
- Special category data relating to the treatment and clinicians who have engaged with the record.
- Clinician: name, role, email address
Data processing description
Nature of the processing
The healthcare organisation is the source of the patient and clinician personal data, either through manual entry or via integration. Special category data relating to the consent episode is entered by the clinician.
Data is hosted securely on Google Cloud Platform in an appropriate location (e.g in a UK data centre for UK deployments).
With regard to deletion of data, data is stored encrypted at rest within GCP, so that on deletion request the encryption keys are first deleted ensuring that data in unreadable (cryptographic erasure), with the physical data later deleted and over time expired from backup systems. Additionally at end of life drives are securely sanitised.
Scope of the processing
Patient personal data used:
- Patient title, given name, and family name
- Patient date of birth
- Patient gender
- Patient hospital number and/or NHS number
- Patient contact details
- Contact details may be provided by the healthcare organisation or directly by the patient if this information is not previously held by the healthcare organisation
Justification: For clinical safety reasons this data must be displayed on-screen during all clinician interactions with a patient’s records, and also appears on the patient’s consent form. Since this information forms part of a consent record, it must be stored according to the same retention schedule as those records. Best practice states that patients are given a copy of their consent form, and therefore contact details are stored to allow communication of the consent interaction and outcome data collection.
For all consent episodes discussed (which may or may not have resulted in surgical consent being given), the following special category data (all relating to the patient’s health) is used:
- The surgical procedure (A)
- Details of the operation, specifically the side (if applicable) (A)
- The clinician responsible (A)
- The names of other clinicians who have viewed or modified the consent episode (B)
- Other treatment options discussed (B)
- The medical diagnosis which led to this procedure (A)
- The intended purpose of the procedure (A)
- The risks which the patient has been informed of (A)
- Free text notes added by the clinician (B)
- External resources shared (B)
Justification: Data marked (A) is a requirement for the consent form as per Department of Health guidelines, and thus must be maintained. In order to fully understand the context in which consent was discussed and taken, data marked (B) is also stored. In combination data (A) and (B) are cryptographically linked to the state of a consent episode at all points in time.
Clinician personal data used:
- Clinician name
- Clinician role
- Clinician email address, unless using shared identity and access management (IDAM)
Justification: As part of the audit trail of the application, all activity is tied to the identity of the logged in user, and in some cases is shown to other users of the system (for example the name of the clinician taking confirmation of consent). The clinician’s email address, where applicable, is used for login, and to support use cases such as password reset.
The volume of data processed is dependent on the scope of the deployment, up to a maximum equivalent number of consent episodes as the number of written consent episodes completed within the organisation.
All data relating to consent episodes is stored for a specified number of years as dictated by the individual healthcare organisation as the data controller. Concentric Health recommends that this time period is at least 8 years, as per best practice for electronic health record data. After the agreed number of years of full data retention, the data is reduced to a stub record containing patient details, procedure name, date, and responsible clinician.
Context of the processing
The clinician creating a consent episode with the patient has a direct care relationship with the patient, with consent information shared during or following a conversation between clinician and patient.
Processing may include children and young people if they may be cared for within the healthcare organisation.
There are no prior concerns relating to this type of processing, and is not considered novel data processing.
Purpose of the processing
The processing is required in order to facilitate the benefits of digital consent:
- digitally transform the consent process, allowing a paperless process
- reduce errors, omissions, and variation in the consent process
- improve patient understanding of the treatment and risks
Consultation process
The following are typically consulted as relevant stakeholders during the deployment process and will contribute to the identification and assessment of risks:
- Information governance representative
- Clinical team representative
- Digital / IT representative
- Cyber / IT security representative
- Patient representative
Necessity and proportionality
Concentric Health is the data processor on behalf of the healthcare organisation. The purpose of processing is for the delivery of direct care. The legal basis for processing is usually:
If public sector healthcare organisation:
- Art.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
- Art.9(2)(h) - 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
If private sector healthcare organisation:
- Art.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
- Art.9(2)(h) - 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
The data processing proposed meets the purpose of the processing and there is no acceptable alternative to proceeding with data processing to this extent.
The platform has been designed to meet the GDPR individual rights requirements by design, as requested by the data controller.
A data processing notice can be provided as part of the consent interaction with the patient. Service access requests, rectification requests, processing freeze requests, and data portability requests can be met by design.
A data processing agreement is required to be in place between Concentric Health and the healthcare organisation to state the agreed scope of processing.
Data processing risks
Staff misuse: Appropriately authenticated staff may access patients records not under their direct care, share care records inappropriately, or access Concentric using a device and browser that does not meet the browser support policy. Mitigated by appropriate information governance training.
Inappropriate access: Staff who should not be given access to patient data may be given access by error. Mitigated by additional training of administrative staff, and 2 factor authentication for the admin area.
Information shared with incorrect patient: It is possible for email/SMS to be sent to the incorrect patient, either via incorrect recorded contact details or manual entry error. Mitigated by consent information being protected behind additional layer of authentication (date of birth entry) and no special category data being shared within email/SMS.
Cloud provider data breach: A malicious external threat could compromise the consent database, exposing patient healthcare data. Mitigated by use of industry leading encryption technologies providing high levels of data security at rest and in transit.