Privacy Impact Assessment and Project Overview …...2017/02/24 · 2.2 Appendices re-configured...
Transcript of Privacy Impact Assessment and Project Overview …...2017/02/24 · 2.2 Appendices re-configured...
SPIRE Privacy Impact Assessment v3.1 Page 1 of 61 20-Feb-17
Privacy Impact Assessment
and
Project Overview
Scottish Primary Care
Information Resource
(SPIRE)
Project
SPIRE Privacy Impact Assessment v3.1 Page 2 of 61 20-Feb-17
DOCUMENT CONTROL SHEET
KEY INFORMATION
Name Privacy Impact Assessment Questionnaire (SPIRE Project)
Date Published/ Issued 01 Feb 2017
Date Effective From 10 Feb 2017
Version/ Issue Number 3.1
Document Type Privacy Impact Assessment
Document Status Approved
Author SPIRE Project Team
Owner SPIRE Steering Group
Intended Audience
SPIRE stakeholders including representatives for patients, the medical profession and general practices incl. quality leads.
Medical research professionals.
Privacy experts.
Specialist journalists.
Approvers see Approvals table below
Contact [email protected]
File Name SPIRE Privacy Impact Assessment v3.1
Word version .docx with 97-2003 compatibility
REVISION HISTORY
Version Date Summary of Changes Name Changes Marked
0.1 11/07/13 Initial draft Eddie Adie N/A
0.2 31/07/13 Revisions to section 3.8, 7 & 8 Service Delivery Workstream
No
0.3 01/08/13 Revisions to section 1, 3.2, 3.5, 3.8, 4 & 5.
Service Delivery Workstream
No
0.4 06/09/13 Revisions throughout document after meeting with Libby Morris
Service Delivery Workstream
No
0.5 02/06/15 Updated to new PIA template and revisions throughout document
Eddie Adie No
0.6 29/07/15 Revisions to section 2.2 & 3.8. Eddie Adie No
0.7 27/01/16 Revisions throughout document Eddie Adie Catherine Thomson Hester Ward
No
0.8 29/01/16 Revisions throughout document Eddie Adie Scott Heald Libby Morris Hester Ward Janet Murray
No
SPIRE Privacy Impact Assessment v3.1 Page 3 of 61 20-Feb-17
0.9 12/02/16 Added appendix 5b Eddie Adie No
0.10 02/03/16 Minor change to appendix 4 Eddie Adie No
0.11 05/04/16 Revisions to sections1.3, 1.4, 2.2, 2.3, 3.33.6, 6 and 7 following discussion with Janet Murray. Also added appendix 5
Eddie Adie No
1.0 25/04/16 Final Version for approval Eddie Adie No
1.1 22/06/16 Changes following comments from Colin Brown/Frances Elliot/Libby Morris
Eddie Adie No
1.2 01/07/16 Further changes to section 1.3 from Libby Morris.
Libby Morris Yes
2.0 29/09/16 Revisions throughout document following Caldicott 3 and care.data cancellation.
Colin Brown Eddie Adie Hester Ward Janet Murray
No
2.1 Revisions throughout Colin Brown SCIMP Janet Murray
Yes
2.2 Appendices re-configured Colin Brown Yes
2.3 Revisions throughout Colin Brown Maureen Falconer
Yes
2.4 Revisions Post SSG Hester Ward Janet Murray Libby Morris
No
2.5 02/11/16 Changes by HW, JM and LM, and prepare for meeting with ICO
Jill Thomas changes in red
2.6 16/11/16 Revised Info Sec after meeting Jill Thomas David Proud and Colin Brown
Eddie Adie (based on JT notes)
Yes
2.7 23/11/16 IG sections and definitions updated after ICO meeting
Colin Brown Eddie Adie
Yes
2.8 21/12/16 Access management, Info Security updates, AAA, "Secondary Uses"
Colin Brown Jonathan Cameron
Yes
2.9 18/01/17 Intro re-configured Appx 2 diagrams reconfigured Appx 6 update re SSG/PPBP Appx 11 Data Sharing Agreement added Appx 12 Secondary Uses example list. Bookmarks to Appendices added
Colin Brown Eddie Adie Janet Murray Hester Ward
Yes
3.0 01/02/17 Version for approval Eddie Adie No
3.1 20/02/17 Minor amendments to S2.5, 8 & App 1 (Approved by FE/JM/SH)
Eddie Adie Colin Brown
No
APPROVALS
Version Date Name Designation
1.0 25/04/2016 Janet Murray ISD Caldicott Guardian
1.0 25/04/2016 Scott Heald Assoc. Director & Head of Profession for Statistics
3.0 06/02/2017 Janet Murray ISD Caldicott Guardian
3.0 10/02/2017 Frances Elliot Chair, SPIRE Steering Group
3.0 02/02/2017 Scott Heald Assoc. Director & Head of Profession for Statistics
SPIRE Privacy Impact Assessment v3.1 Page 4 of 61 20-Feb-17
Contents Background & Summary 6
0. Legal data handling role of NHS National Services Scotland (NSS) 8
1. Collecting personal information 9
1.1. List / describe personal information & frequency of data transfers / updates 9
1.2. Whose information is being collected? 9
1.3. Is the data personally identifiable? 10
1.4. How will you receive the information? 13
1.5. What is the source of the personal information? 13
1.6. Is the data collection part of an existing process & how are data subjects informed? 13
1.7. What is the legitimate purpose for which personal information is obtained? 15
2. Will the project bring a new way of processing personal information? 16
2.1. Is a new linkage to other datasets intended, or is there potential to link? 16
2.2. What do you perceive the privacy risks to be? 17
2.3. Will processing bring any change to privacy risk? 19
2.4. Are these risks entered into the appropriate risk register? 20
2.5. How have data subjects been informed about processing? 20
3. Use and Disclosure 20
3.1. Describe how the information will be used 20
3.2. Who will have access & are they appropriately trained in privacy/data protection? 21
3.3. Will the information be modified prior to access to enhance privacy? 22
3.4. How will access levels be decided? 23
3.5. What safeguards will be in place to control & monitor access to data? 23
3.6. What technical/procedural measures will safeguard security of personal information? 24
3.7. Will safeguards change depending on the level of information made available? 24
3.8. Describe the processes for monitoring information Governance issues 25
4. Data Quality 26
4.1. Will there be monitoring to assess the personal information’s fitness for purpose? 26
4.2. Will there be monitoring to assess the personal information’s relevance? 26
4.3. Will there be monitoring to assess the personal information remains up-to-date? 26
SPIRE Privacy Impact Assessment v3.1 Page 5 of 61 20-Feb-17
5. Retention and Destruction 27
5.1. For how long will the data be retained? 27
5.2. Is the personal information covered by the NSS Document Storage & Retention Policy? 27
5.3. How will the data be securely disposed of when no longer required? 27
6. Recommendations 28
7. Is a more detailed assessment needed? 29
8. Completed function / policy 30
Appendix 1: Content of GP Reporting Database 31
Appendix 2a: SPIRE Extract & Processing Overview 32
Appendix 2b: SPIRE Extract Process Diagram & Example 33
Appendix 2c: Standard eDRIS Linkage process 36
Appendix 3: Legal Provisions to support Data Processing without Explicit Consent 37
Appendix 4: Patient Opt-out Form Final 39
Appendix 5a: SPIRE Access Assurance 40
Appendix 5b: SPIRE Advanced Access Assurance 42
Appendix 6: SPIRE Steering Group and Public Benefit & Privacy Panel 43
Appendix 7: Patient Consent Model 44
Appendix 8: SPIRE Physical Security Overview 53
Appendix 9: SPIRE and NSS System Security Standards 54
Appendix 10: SPIRE Pseudonymisation & Encoding Paper 55
Appendix 11: Extract of specimen GP – SPIRE Data Sharing Agreement 58
Appendix 12: Examples of secondary uses of Data 61
SPIRE Privacy Impact Assessment v3.1 Page 6 of 61 20-Feb-17
Background and Summary of the project for which this Privacy Impact Assessment is being carried out:
In 2011, the Scottish Government convened a short life working group (SLWG) to consider the potential benefits of accessing data
from electronic patient records held at General Practices nationwide.
A major conclusion was that although clinical data were being used effectively to support the Direct Care and treatment of individual
patients, there could be more system-wide Secondary Use1 of these data to improve the health and wellbeing of the Scottish
population.
Such Secondary Uses would require data from practices to be collated in a more systematic way across Scotland, transformed into
intelligence and fed back to practices and other stakeholders. In particular it was recognised that consistent system-wide data could:
inform and improve quality assurance and service management of NHS and care services, such as policy planning, service development and implementation, audit, and performance management
inform national policy
support research.
It was also seen as essential that that no person's privacy was reduced by wider access to their Personal Identifiable Data and the
intelligence produced from it.
The group proposed that:
a new national service be developed by NHS National Services Scotland (NSS) to facilitate the extraction of data and to improve its utilisation to inform or answer questions of quality assurance and service management, and for research
the service should be underpinned by robust information governance policies and procedures to ensure patient confidentiality is effectively protected, including use of Privacy Enhancing Techniques such as those developed under the SHIP Programme, and that any use of data be subject to the agreement of participating practices, and
participation would be open to all consenting GP practices, with a single extraction mechanism transferring data securely from GP IT systems without impacting on practice or NHS Board workload or clinical care Further, unifying the current extract mechanisms into a single national extract mechanism would streamline and reduce the workload that practices currently have in collating and reporting the data they hold electronically.
1 "Direct Care" is defined for this paper, at section 1.6, as: “Care delivered both when ill, and when engaging with screening or preventive services when well."
Secondary Uses of NHS data are illustrated by example at appendix 12
SPIRE Privacy Impact Assessment v3.1 Page 7 of 61 20-Feb-17
These recommendations were endorsed in December 2012 and the Scottish Government Primary Care Division asked NSS to take
this work forward through a (then) new service called the Scottish Primary Care Information Resource (SPIRE).
In summary, the SPIRE project aims to deliver this service through a wide-ranging program to manage the development of several
existing information systems across NHS Scotland at these 4 architectural levels2:
Socio-cultural: have a national conversation on the public benefits of sharing NHS data for quality assurance, service management or research, while protecting privacy, by a communication campaign to inform the public and key stakeholders
Roles and responsibilities: develop the discourse3 around Information Governance, to form questions about NHS quality assurance, service management and research, and inform or answer them, including
o the scrutiny and approval processes before any specific data extraction
o analyse data extracted and share reports and findings with other parts of NHSScotland, policy makers or researchers.
Informatics: develop the informational content of the data extracted to answer these questions, by setting up a new team of data managers and analysts to support the service, and to
o design, schedule and deploy routines to extract data from GP practices for each such question
o develop reports for GP practices to use locally to improve their care
o develop reports customised for each NHS quality assurance, service management or research question
o manage the processing of and access to the data returned to NSS
Engineering: upgrade the infrastructure, by developing and implementing the Information Technology required including
o a new single data extraction and reporting system, that also provides support to practices with data reporting, and that will
manage the extraction of data from practices
o improving communication links with GP practices to transfer the extracted data securely and efficiently to NSS
o new data processing facilities to receive and store data, manage it over its lifecycle and manage user access
The diagram at appendix 2a outlines how the data flow and processing meets these aims at the Informatics and Engineering levels.
This Privacy Impact Assessment follows the questionnaire format used by NHS National Services Scotland for healthcare IT projects,
which is adapted, in consultation with the ICO's office in Scotland, from that published by the ICO at PIA code of practice
2 Enterprise Modeling
3 Conversation Theory
SPIRE Privacy Impact Assessment v3.1 Page 8 of 61 20-Feb-17
CONSIDERATIONS ANSWERS ACTIONS
0. What legal data handling role does NHS National Services Scotland (NSS) have in relation to the personal information involved
in the project?
Data Controller?
(NSS alone decides the purposes
for, and manner in which, the
personal information is used and
disclosed)
Yes.
Each GP Practice alone is the Data Controller until the data is in transit to NSS, which
becomes sole Data Controller thereafter.
NSS takes on Data Controller status while data is in transit (via eLinks) and when
data reaches the NSS Secure Storage Area, and implements the Secondary Uses
and lifecycle management of the data.
This is under the general governance of the SSG, and specific projects may also be
governed by the Public Benefit and Privacy Panel (PBPP).
NSS will use the data only in accordance with the purposes defined in each SPIRE
request, authorised by the individual GP Practices.
The Secure Storage Area will have all the technical and other measures required by a
Data Controller.
Data Controller, jointly or in
common with other Data
Controller(s)?
(NSS works either jointly or
alongside another Data Controller
in deciding the purposes for, and
manner in which, the personal
information is used and disclosed)
No.
NSS works as sole Data Controller under the governance of the SSG (as above).
SPIRE Privacy Impact Assessment v3.1 Page 9 of 61 20-Feb-17
1. Will the project involve the collection / obtaining of personal information?
1.1 List /
describe the
personal
information to be
collected /
obtained, and the
frequency of data
transfers and/or
updates.
Personal information is collected in regular extracts using, as their source, a "GP reporting database"
generated overnight in each GP Practice. This is a temporary working copy of selected parts of the full
data in the GP Record, and is a table of patient records.
The maximum possible content of each dataset is attached as appendix 1 and shows in bold those
items considered to be "personal identifiers" within the Personal Identifiable Data (PID)4.
Extracts also include Read codes for clinical features, conditions, procedures and tests, prescribing
data, and selected other data for disease surveillance, and for some NHS management such as
payment verification. These data are known also as "payload" data, and in some circumstances may
be partly identifiable: see sections 1.3 and 2.2.3.
Each data extract will only contain the minimum data items required for the purpose of that extract (as
discussed at section 3) and for its duration, after which it is destroyed.
The frequency of data extracts and transfers will be flexible subject to the capacity and usage of the
eLinks transport system.
Update the
Privacy
Impact
Assessment
if the
content of
the GP
reporting
database
changes.
1.2 Whose
information is
being collected /
obtained e.g.
patient, donor,
family health
Information is collected about
Persons registered with a GP practice in Scotland.
Clinicians engaged in clinical and management activity in these GP practices.
Other NHS staff engaged in supporting this clinical activity.
4 Not every item of data comprising Personal Identifiable Data will always be confidential: for example, some data may already be in the public domain as the person may have lost privacy by disclosing such
data on the internet e.g. on Facebook.
PID that has not been disclosed is often referred to as Personal Confidential Data, in particular by the Data Protection Act which applies only to PCD.
As it cannot reliably be predicted which items in PID may no longer be confidential, this system design document assumes that all PID is still all confidential, and so uses the term PID.
"Personal" is also the DPA 1998 term for ‘identifiable data’ applied to living people, so as SPIRE applies to data about people living & dead, the term ‘identifiable' is appropriate here, as in "PID".
SPIRE Privacy Impact Assessment v3.1 Page 10 of 61 20-Feb-17
services
contractor or
NHS staff data?
1.3 Is the data
personally
identifiable?
How are non-
identifiable data
and identifiable
data processed
appropriately?
This section summarises the data processing within SPIRE, details are later in the document.
The extracted data has variable content of personally identifiable data
clear personal identifiers such as CHI, names, date of birth, postcode, and
clinical data, as at section 1.1 above
SPIRE uses three models to process raw data with information governance appropriate to the level
of risk of re-identification due to the personally identifiable content of the data, and to its purpose.
Each model requires that the GP practice has given consent to the extract before it leaves the
practice, but has different processes for obtaining personal consent.
Each model is currently in use in NSS or elsewhere in NHS Scotland, but differing in scale,
extraction and processing methods.
A. Aggregate: data are aggregated to include everybody in a group, and will be presented for
analysis initially in the form of total numbers per GP practice.
This is much the most common type of information output, the best-known purpose being for the
Quality and Outcomes Framework (QOF), and soon for NHS Scotland's new Transitional Quality
Arrangements.
Other purposes are NHS quality assurance, service management and research at levels starting
with the GP practice, then for local clusters of GP practices, NHS Boards, and finally Scotland-wide
Consent is required from GP practices for these extracts, but there is no consent process for each
person to opt out of “aggregate” extracts as this information is anonymised5.
5 When numbers are very small, further de-identification is ensured by use of Statistical Disclosure Protocol - see Section 3.6
SPIRE Privacy Impact Assessment v3.1 Page 11 of 61 20-Feb-17
B. Limited Personally Identifiable Data: a limited selection of data are presented for analysis for
each person's record. These datasets support the purpose of population-level inclusion of persons
including those in hard-to-reach groups.
The data may be "personally identifiable" to an extent that varies with each record, which contains
variable amounts of clear personal identifiers such as CHI, names, date of birth, postcode; and also
clinical data. The richer the clinical payload data, the more it is also potentially identifiable.
For each extract, PID will be minimised, by extracting only the minimum no. of data6 items required
for each report. For example:
no free text or narrative data is extracted, but only clinical terminology codes for clinical
features, conditions and procedures
each extract is retained in the GP Practice until they, as Data Controllers, approve its
release to SPIRE.
Further, it is used for the minimum time and is then destroyed: it is not stored or "warehoused".
Personal identifiers are used within NSS for the purposes of
linking each person's data to their data in other datasets, or
creating ‘derived items’ such as age and Scottish Index of Multiple Deprivation score7. They
are then deleted, and only the clinical payload and derived items passed to those granted
controlled access to the data, e.g. researchers approved by the Farr Institute8: see section 3
When personal identifiers are required, they will be routinely separated from the clinical payload
data before leaving the GP practice. The personal identifiers’ file is then encrypted before both files
are transmitted separately to NSS over the secure Scottish Wide Area Network (SWAN) using
6 “The Least Principle” from "Fair Shares for All" British Computer Society 2012
"The risk of de-identified data being re-identified depends on the way it is shared and with whom, as well as its intrinsic content.... It is greatest with rich data ..... where anyone may take it and use it for any
purpose(s). In such cases the risk may be so high that ‘de-identified data’ should be treated as if it were identifiable data. In the light of this, we advocate that, where possible, data are collected for specific
purposes. Applying the “Least Principle” - the least data, copied the least number of times, held for the least time and used by the least number of people necessary for the purpose - substantially reduces
the privacy risk" 7 In future the derivation of items such as SIMD score could be performed by SPIRE Local within the GP practice, to further reduce export of data. This would be a Change Request.
8 Farr Institute: What is Health Informatics Research?
SPIRE Privacy Impact Assessment v3.1 Page 12 of 61 20-Feb-17
eLinks, which also encrypts all files during transfer. (see section 3.3)
This pseudonymisation of the data at its source greatly reduces the identifiability of the dataset.
Re-identification is easy only for NSS staff in legitimate possession of the decryption keys, in the
above example to create derived items (see section 3.3), but with extreme difficulty by others: see
section 2.2.3.
No staff in NSS will ever have access to both the identifiers and the clinical payload data, this being
a key principle of the SHIP blueprint: see appendix 2c and appendix 10.
Further, no end-user staff outwith the NHS will ever have access to PID from this type of data.
These data are considered suitable for processing without explicit consent if
using de-identification methods such as the above, and also if
consistent with legal requirements such as those of the Data Protection Act, and the
common law: see section 1.7 and appendix 3.
Processes for consent or its withdrawal (dissent) give additional safeguards for each person
and for GP practices
an individual's dissent applies to all extracts of this type.
the GP practice consents to each extracted dataset based on the practice's view of the
benefits and risks of each one.
A further safeguard is provided by a Data Sharing Agreement, which is a legal framework for the
use by NSS of the limited PID that is extracted from GP records: see appendix 11.
C. Fully Personally Identifiable Data: Where identifiable data are requested to be released for
purposes that do not meet the above provisions, such as clear personal identifiers for direct,
repeated or long-term access by researchers (e.g. a research request on individual patients such
as those in a specific disease register, or those found to be at risk) explicit consent will also be
required from each patient. Each request would need approval of SSG and PBPP: see appendix 6.
This is the current process for research on individual persons using GP Records, and consent is
normally managed directly by researchers, or on their behalf by GPs, using paper systems.
SPIRE Privacy Impact Assessment v3.1 Page 13 of 61 20-Feb-17
It is proposed that the unified SPIRE data extract technology can also be used for these custom
extracts, and that the SPIRE team will work with researchers and the Farr Institute to facilitate the
management of these research projects: see section 3.1.
1.4 How will you
receive the
information (e.g.
CD, network
transfer, etc)?
When Personal Identifiable Data (PID) are requested, an automated data extract process will deliver
the data as two files: one, encrypted, containing all clear personal identifiers as listed in appendix 1,
and the other containing the remaining limited clinical information requested.
This data transfer uses eLinks to further encrypt both files in transit over the secure SWAN NHS
network to a temporary storage area within NSS: see section 3.3 and appendix 10.
If the information requested does not identify individual persons (e.g. aggregated data such as a count
of the number of patients in a practice aged over 65 with a common condition) then only one file will be
transferred, using the automated data extract process described above.
1.5 What is the
source of the
personal
information?
Clinical systems within General Practices across Scotland.
1.6 Is the data
collection /
obtaining part of
an existing
process and if so,
how are data
subjects informed
about the current
and proposed
processing?
If data subjects
are not informed,
explain why.
Data are currently routinely provided to and recorded by GP practices as part of their provision of
General Medical Services to NHSScotland, of which people are informed when registering with a GP
practice, and when accessing healthcare. This use for Direct Care applies both when ill, and when
engaging with screening or preventive services when well.
Some clinical data are currently extracted and used for limited Secondary Uses e.g. aggregate data to
support payments to practices, currently by the Quality & Outcomes Framework (QOF) see section 3.1
Currently there are different mechanisms for informing and for opting out of some of these extracts,
each administered by GP practices. Information about them and about SPIRE is available in leaflets on
NHS premises such as GP practices, and on NHS Inform; see also section 2.4.
SPIRE will not go live until a Public Information Campaign, using print and radio media, with patient
leaflets and posters available at the point of contact with the service, has taken place. The Public
Information Campaign is planned to cover 93% of the population, will provide general information about
SPIRE, and will also clearly describe each person's method to opt out of all individual limited data
SPIRE Privacy Impact Assessment v3.1 Page 14 of 61 20-Feb-17
extractions, by completing a standard opt-out form, available in practices or online to download: see
appendix 4.
The patient’s dissent from these limited data extracts will be recorded using the Read code 9NuD. so
that all these extracts exclude data from those who opt-out. This dissent status can be applied at any
time, or rescinded by use of Read code 9NuF, the code for “dissent withdrawn”. Since SPIRE data is
deleted once its approval period expires any data in SPIRE will be destroyed: see section 5.3.
The opt-out will not apply to aggregated data, because that data is not identifiable.
Further, the GP practice has the option to dissent from the transmission of each extract to SPIRE, for
instance if that extract's Secondary Use is not supported by the practice.
SPIRE will publish the purposes approved for each proposed extract: see section 2.5.
There is currently no proposal to inform individual persons directly about each specific Secondary Use
to which their PID may be put, nor to enable them to directly specify consent to these different
Secondary Uses.9
There is now UK-wide consultation on Caldicott's 3rd Report, in which Chapter 3 discusses granularity
of consent.10 International research is also ongoing into the types of such uses that will be most
meaningful for the public,11 for example to represent more granular consent using broad, dynamic or
meta-consent 12 13 models.
There is potential for an individual person to specify their own consent choices via a portal such as
My Account at www.mygov.scot, with storage in the new electronic Master Patient Index recently
procured to replace the Community Health Index.
Some technical issues are discussed here14 15 and in a paper published by SCIMP: see appendix 7.
9 Call for electronic consent for secondary uses
10 Review of Data Security, Consent and Opt-Outs (Caldicott 3)
11 Wellcome: public attitudes to commercial access to health data
12 Meta consent – a flexible solution to the problem of secondary use of health data
13 A dynamic model of patient consent
14 SCIMP Consent Archetype Nov 2013 presentation
SPIRE Privacy Impact Assessment v3.1 Page 15 of 61 20-Feb-17
1.7 What is the
legitimate basis
or stated
business purpose
for which the
personal
information is
obtained?
Administration of Health and Care Services (as described in the Data Protection Register Z5801192).
This term includes Secondary Uses such as NHS quality assurance and service management uses.
This accords with the founding duty of the NHS in relation to the health and wellbeing of the population
in the National Health Service (Scotland) Act 1978, The statutory functions of NSS are defined in the
National Health Service (Functions of the Common Services Agency)(Scotland) Order 2008,
Two conditions for lawful processing of personal health data apply under the Data Protection Act 1998:
1. DPA 1998 Schedule 3 (8): “processing is necessary for “medical purposes" which is defined as
including the ‘…purposes of preventative medicine, medical diagnosis, medical research, the
provision of care and treatment and the management of healthcare services.'
2. The Data Protection Statutory Instrument 2000 number 417 research condition is processing that is
is in the substantial public interest
is necessary for research purposes
does not support measures or decision with respect to any particular individual, and
does not cause, nor is likely to cause, substantial damage or substantial distress.
See appendix 3 for fuller discussion of legal supports for SPIRE's approach to Information Governance.
There is no risk of Government access under the Health & Social Care Act 2012 because this does not
apply in Scotland.
15 A proposed consent model
SPIRE Privacy Impact Assessment v3.1 Page 16 of 61 20-Feb-17
2. Will the project bring a new way of processing personal information?
2.1 Is a new
linkage to other
datasets intended,
or is there
potential to link to
other datasets? if
so, describe,
including whether
an application has
been made to the
Public Benefit and
Privacy Panel
Yes, there will be requests to link SPIRE extracts to other data sources.
These will not be routine: all requests for new data linkage will be considered by the SPIRE Steering
Group, and then by the Public Benefit and Privacy Panel (PBPP): see appendix 6.
If the linkage is required as part of a request from an approved researcher, then the process identified
for the electronic Data Research and Innovation Service (eDRIS) will be followed (described further in
appendix 2c and appendix 10) and linkage will be carried out using standard eDRIS processes.
These are automated wherever possible, to minimise the number of analysts processing Personal
Identifiable Data, normally to no more than 216: see appendix 2c.
These processes have been established for use in NSS with Farr-accredited Research Organisations
in Scotland following the development of the SHIP Information Governance Toolkit and related secure
processes under the earlier SHIP Program since 2010.
This current work by NSS in partnership with the Farr Institute governs a number of researchers both
local, national and international using NHS data for many research activities.
SPIRE's GP data extracts can be specified to complement that other NHS data, and will have security
governed as above.
Researchers employed by the pharmaceutical industry do not have direct access to any PID made
available by NSS through eDRIS at the Farr Institute: only aggregated data (anonymised, see section
1.3) and results of analyses are shared with them.
Pharmaceutical companies may also develop and commission research in collaboration with the NHS
or academic institutions. In such a collaboration, only their NHS/academic partners would have
16 In a few exceptional cases, e.g. to cover staff absence, a third person may need to be involved; we do not expect more than three analysts to have sight of the same set of PID.
SPIRE Privacy Impact Assessment v3.1 Page 17 of 61 20-Feb-17
access to PID, as approved by SSG and PBPP, and through the eDRIS team at Farr Safe Haven.
The pharmaceutical industry-employed researchers would only have access to the final non-
disclosive, aggregated outputs (e.g. anonymised data in tabular form) and only via eDRIS staff at Farr
working directly with them to ensure all privacy protection systems are fully implemented.
2.2 What
do you
perceive the
privacy risks
to be?
Risk Actions Risk
Owner
2.2.1
There may
be a data
breach due
to
accidental,
intentional
or
fraudulent
access to
information.
All steps in the SPIRE technical solution are described in a System Security Policy (SSP).
Please see sections 1.3B, 3.5 and appendix 9 for details including ISO27000 status.
Some specific security examples
the frequency of data extracts, transfers, and transmission schedules is unpredictable
when personal identifiers are extracted they will be encrypted before being securely
transferred from the practice
access is authorised by individual logons and passwords
physical security is also addressed17 to current requirements.
information via a web browser is available only through SWAN and secure private network.
user access is secured by 2-factor authentication, and users are required to access only
using encrypted PCs & laptops, and are subject to password training and guidance
underpinned by standard NHS procedures:
there are five server environments: Production, UAT, Report Development, System Test
and Development, hosted in the Atos Data Centre.
This meets all NHS data security standards, is supported by a Service Level Agreement
and meets the requirements set out in NHS Scotland Information Security Policy at
eHealth standards library.
GP data is only ever held within the Secure Storage Area in the Production environment.
before releasing statistical data, the ISD Disclosure Control Protocol will be followed to
ensure that individual persons are not identified e.g. due to small numbers: see section 3.6.
Assoc.
Director
17 Appendix 8: Summary of NSS Physical Security
SPIRE Privacy Impact Assessment v3.1 Page 18 of 61 20-Feb-17
2.2.2
Personal
Identifiable
Data (PID)
may be
accessed,
used and
viewed
without the
knowledge
or consent
of patients.
Access control is fully discussed at section 3.2, and includes these features:
Only the minimum number of staff will have access to PID, most commonly 1 and normally no
more than 2; see also appendix 2c. This is a key design feature for approval by the PBPP and the
SPIRE Steering Group: see section 3.5.
Each staff member will only be granted access to personal identifiers or clinical payload data, but
not both. This separation of roles is a feature of the SHIP Blueprint.
There are full audit trails of all accesses to PID. This retrospective assurance on all accesses
made is administered by NSS on request from individual persons via their GP practice managers,
NHS24 or NSS. Advanced Access Assurance (see appendix 5b) will also be available to persons
who can give a name of specific NHS staff alleged to be a potential adversary.
Section 3.2 expands the Human Resource issues in managing access, and appendix 5 expands
the mitigation of risk for intentional data breach.
Service
Mgr.
2.2.3
Inference
threat:
combining
rich clinical
data from
breach or
other in-
appropriate
access, with
public data
to re-
identify.
This risk cannot be generally quantified as it requires details of the scale of Personal Identifiable
Data (PID) in each dataset, and assessment of the related information that may be available to an
adversary. Assessment can then be made of the privacy risks to individual persons from re-
identification, to inform the assessment by the SPIRE Steering Group and PBPP before approval.
Each data extract will only contain the minimum data items required for the purpose of that extract
(e.g. to support an NHS research study) and for its duration, after which it is destroyed.
As an example of related information, an adversary may already know dates to apply to coded
items in a target person's payload data, to link with their dates at a postcode from public data.
A review by Yakowitz18 states that while such inference attacks have been shown in public
datasets, there were no known instances of a successful such attack on a medical research
dataset.
Service
Mgr.
18 Jane Yakowitz: Tragedy of the Commons pp35-39
SPIRE Privacy Impact Assessment v3.1 Page 19 of 61 20-Feb-17
For further protection, in SPIRE:
data is not in human-readable document format
any person's data may be absent due to opt out from the limited extracts program, and
any GP practice' data may be absent due to opt out of any extract. Thus an adversary cannot know if or how any person's data has been coded, nor if it exists in any one dataset, nor the dates between which any dataset may exist.
These form major obstacles to illicit re-identification of individuals by inference.
2.3 Will
processing
bring any
change to
privacy risk?
If so, describe.
As SPIRE will provide more data to a wider range of people, there might be an increase to privacy risk from
current NHS Scotland practice.
However, there is no large persistent dataset, but multiple smaller, temporary datasets. These can be easily
regenerated as needed, this being feasible due to the small datasets and speed of current extract technology.
Stable data persists only in the GP record, where it is cumulative and curated for Direct Care by the GP practice
as its Data Controller.
SPIRE thus avoids data storage or "warehousing" with the risks of large rich datasets: see section 2.2.3.
SPIRE's pseudonymisation of the data at source provides both major technical barriers, and the deterrence of
being illicit, to reduce the privacy breach risks compared to current extraction practices.
Some GP practices in Scotland already contribute PID to other large UK-national datasets e.g. CPRD, THIN,
QResearch and their discussions of pseudonymisation and data linkage methods may be referenced:.19 Some
research projects use other software e.g. the North node of NHSScotland Primary Care Research Network uses
OpenPseud within Albasoft software: see appendix 10.
SPIRE introduces no additional types of risk to these.
19 QResearch Openpseudonymiser; also see appendix 10
ResearchOne Research One
SAIL SAIL Databank
THIN The Health Improvement Network
CPRD Clinical Practice Research Datalink
Also Sapior Safemerge
SPIRE Privacy Impact Assessment v3.1 Page 20 of 61 20-Feb-17
2.4 Are these risks entered into
the appropriate risk register?
Yes, the above risks are covered by risk numbers 3694, 3740, 3745 and 3831.
The Risk Register holds regularly updated values for Likelihood and Impact of all risks; each
risk is allocated an owner.
2.5 How have data subjects
been informed about
processing? If not, how will it?
See section 1.6 above for details of SPIRE Public Information Campaign.20
As a Notice of Fair Processing to the public, the SPIRE website will publish decisions of the
SPIRE Steering Group (SSG). This will clearly identify those applications that have been
approved along with relevant details about the purpose of the extract and how long data will
be retained for. This information will help people make informed decisions about whether or
not to opt-out of SPIRE.
3. Use and Disclosure
3.1 Describe
how the
information will
be used.
Each data extract is designed to inform or answer each research, quality assurance, or service management
question21. A wide range of such Secondary Uses is listed at appendix 12.
Information will be fed back to GP Practices, clusters and NHS Boards to support and inform local decision
making, including quality improvement, benchmarking and performance management.
SPIRE will enable data from GP records to be extracted across Scotland in a consistent manner and used
more widely than currently.
Collation, analysis and production of intelligence from these data will contribute to improvements in the quality
20 Also, until September 2014, GP records at about 60 practices across Scotland supplied limited data for the Practice Team Information (PTI) scheme.
Patients of these PTI practices received general information about this on notices and leaflets from those GP practices who took part. 21
The processes of forming questions and informing the answers are generally included within those known as Secondary Uses of the data: see appendix 12
"Secondary Uses" have been suggested to be known as "Indirect Care Uses" as a better complement to the term “Direct Care” when classifying the multiple uses of data in the NHS.
These definition issues are under professional debate.
SPIRE Privacy Impact Assessment v3.1 Page 21 of 61 20-Feb-17
and outcomes of health and social care in Scotland; the management and improvement of NHS services and
their resource allocation; national policy on the NHS in Scotland; public health surveillance and healthcare
research.
There is a recognised value in the potential of linking to other datasets, however, no routine linkage is
planned. Requests to link SPIRE data with any other datasets will require approval from both the SPIRE
Steering Group and the Public Benefit & Privacy Panel (PBPP): see appendix 5 & appendix 6.
Further use of SPIRE data i.e. by researchers other than NSS, is recommended to be onsite through eDRIS
at Farr Institute i.e. via the National Safe Haven which is wholly within NSS systems.
The Safe Haven is a secure penetration-tested Citrix Virtual Desktop Infrastructure for remote access that
removes all functions except selected analysis functions that it alone provides. Therefore no data can be
copied or saved outside the Safe Haven; further, all researcher activities are recorded on video.
Other research requests e.g. for use of SPIRE data off-site, which might include for use outside the UK, would
depend on the project’s assessment by the SSG and then PBPP, in favour of research design that does not
require off-site copy.
Since routine access to SPIRE by researchers would be recommended through eDRIS at Farr Institute, off-
site access requests would be rare events, and so considered as they arise by the SSG and PBPP to ensure
benefits are realised with minimum privacy and security risks. If there is any intention to use PID, then no off-
site copy will be approved, only access is provided under these strict conditions:
Researchers may access remotely from outside Safe Haven premises only on workstations provided by their
host institution, and for limited periods of time. When researchers are from non-UK academic institutions they
must work in partnership with researchers in UK Universities, which are responsible for providing the evidence
that they and their employing Institution are bona fide.
All users and their employing institutions sign a user agreement defining their responsibilities and sanctions
which may be applied to the individual and institution.
UK Institutions are also liable for any breach of the agreement by non-UK partners.
3.2 Who will
have access
and are they
appropriately
Within NSS: all staff are vetted prior to employment. Dependent on the post, checks will include some or all
of the following: verification of identity; right to work; professional registration and qualification; employment
history and reference; criminal record checks; and occupational health checks.
SPIRE Privacy Impact Assessment v3.1 Page 22 of 61 20-Feb-17
trained in
relation to
privacy / data
protection?
Provide this
information for
persons:
within our
organisation
e.g. have our
relevant staff
signed the
corpor-ate
Confid-entiality
Policy, when
within the
wider NHS
outwith the
wider NHS
All PHI staff complete specific training in confidentiality, and the rules in the NSS Confidentiality Policy that
govern the care and release of confidential data.
New staff must sign that they understand and accept them; all staff renew this declaration annually.
Our staff contracts lay out the need to respect and preserve confidentiality. In addition, all PHI staff must
complete the intermediate level IG online training module, and update every three years. For example, PHI
staff will be able to apply Statistical Disclosure Control: see section 3.6.
Access can only be given with special permission for a set time period, on NSS premises only.
Type A aggregate data (not containing PID) may be seen by several members of Public Health Intelligence.
For type B data extracts containing limited PID, in the great majority of cases the PID will be seen by one or
two analysts22 selected from a small number of appropriately authorised staff within the SPIRE service team
within Public Health & Intelligence (PHI) Strategic Business Unit (e.g. data managers and data analysts).
Within or outwith the wider NHS: approved researchers may request access to SPIRE data, and this will
follow the process developed as part of the eDRIS service and must also comply with requirements of the
SPIRE Steering Group: see appendix 6. Researchers must complete training to ensure they are fully aware of
the policies and procedures governing individual privacy, data protection and freedom of information.
For more detail on the content of this training, please see the links below:
Health and Social Care Information Centre Information Governance Training Tool (for NHS staff only)
MRC Regulatory Support Centre: Research Data and Confidentiality e-learning
Administrative Data Research Network - Safe Users of Research Environment Training
3.3 Will the
information be
modified prior to
access to
enhance privacy
Before transfer of PID from GP Practices (via eLinks) to the Secure Storage Area in NSS, personal identifiers
and clinical data will be split into two files and transferred separately. At the same time encryption will be
applied to the file containing personal identifiers, providing pseudonymisation of the dataset.
This process follows the established SHIP Blueprint, and is more fully discussed in appendix 10.
22 In a few exceptional cases, e.g. to cover staff absence, a third person may need to be involved. We do not expect more than three analysts to have sight of the same set of PID
SPIRE Privacy Impact Assessment v3.1 Page 23 of 61 20-Feb-17
e.g. anonymised
or ‘pseudo-
nymised’?
Additionally, eLinks encrypts all files that it transfers using SWAN.
For some extracts, subject to those extracts being approved by the SSG and Public Benefit & Privacy Panel
(PBPP), reversal of the encryption by NSS’s SPIRE team will be allowed to permit:
Temporary recovery of the patient’s CHI number to allow data linkage with other national datasets, as
described in appendix 2c, such as those relating to the patient’s Hospital Episodes of Care
Temporary recovery of patient identifiers to allow data linkage with other datasets (where the CHI
number is not available)
The generation of Personal Identifiable Data (PID) where its use can be justified and it is approved by
the SSG
There may also be a requirement to gain the consent of the patients involved if, for instance, personal
identifiers are required for research purposes that occasionally arise during analysis.
For example, a new research question may be generated by the early results of limited data research, such as
identifying a risk profile for a new adverse drug reaction. In such a case, identification of the individuals
affected would require reversal of the encryption of demographics, which would involve the GP practice.
The general framework for these uses of the data is specified in a Data Sharing Agreement, see appendix 11.
3.4 How will
access levels be
decided?
This will depend on the roles and responsibilities of individual staff.
For each data extract, it will be agreed who will be required to manage and analyse data; only those
individuals will be granted access.
The numbers of analysts with access to PID will be minimised, normally to 1 or 2 individual staff, this being a
key feature of approval by the SSG and PBPP: see section 3.2.
Access levels for authorised NSS staff will be agreed by senior staff following standard procedures.
3.5 What
safeguards will
be in place to
control and
monitor access
Access at NSS to SPIRE
is controlled by individual user identifiers and passwords
uses several profiles for each user with separate credentials, to reduce risk if any one credential set is
compromised i.e. there is no Single Sign-On system which can be a single point of weakness
SPIRE Privacy Impact Assessment v3.1 Page 24 of 61 20-Feb-17
to data?
e.g. an audit trail
with date and
user authentic-
ation.
uses security profiles that define level of access on a least-privilege basis23
places time-limits on all accesses to PID
uses only fully-encrypted devices with machine access also secured by 2 factor authentication.
Usage is monitored by system monitoring reports currently using full file-level access logs24.
Staff who have accessed PID are monitored by maintaining an audit trail to record, retain and report on each
staff member's accesses to view PID.
This information will be available to the public if requested, administered by NSS on request from patients via
their GP practice managers, NHS24 or NSS.
PHI will also maintain a list of those staff with potential access to PID to support Advanced Access Assurance;
this applies to all SPIRE data and is available should a request be made: see appendix 5.
3.6 What
technical
/procedural
measures will
safe guard the
security of the
personal
information?
In addition to those described in section 3.5, ISD has developed over many years a Statistical Disclosure
Control policy to ensure that where statistics provide information on small numbers of individuals that those
individual persons are not directly, or indirectly, identified, by hiding, combining, or modifying data before
release.
ISD's Statistical Disclosure Protocol25 complies with the Anonymisation Code of Practice26 of the Information
Commissioner’s Office (ICO)
All steps in the SPIRE technical solution are described in a System Security Policy: see appendix 9.
3.7 Will
safeguards
change depend-
ing on the level
Access will be controlled as described in section 3.5 above, and as data may be sensitive even if it is
aggregated, for instance when numbers are very small, also as at section 3.6 above.
Users will be granted different levels of access depending upon their individual roles in each project.
23 see Principle of Least Privilege
24 NSS is also evaluating specific audit software tools from a number of suppliers
25 ISD Statistical Disclosure Control Protocol sets out how the organisation reduces the risk of disclosure by suppressing, aggregating or modifying data before release.
26 ICO Guide to data protection: anonymisation
SPIRE Privacy Impact Assessment v3.1 Page 25 of 61 20-Feb-17
of information
made available?
No single NSS user has access to all the PID associated with all the projects.
3.8 Describe
the processes
for monitoring
Information
Governance
issues that will
be in place.
All members of NSS and those working on behalf of NSS have the responsibility to ensure that incidents,
actual or suspected, are reported in line with section 5 of the NSS Corporate Information Security Policy and
the Information Security Policy Guidelines (section 1.6).
An online incident reporting form has been developed for easy use by someone reporting an incident. This will
inform the 'alert manager' who will have the responsibility to investigate the incident, implement procedures
etc. to assist with reducing the risk of the incident happening again or the potential impact.
Alert Managers should investigate how the incident occurred and implement any recommendations to prevent
repeat of the incident or to reduce its impact. The 'Alert Manager' should also update the online follow-up form
which is also available on-screen, and collects further details of the incident, its investigation and
recommendations to be implemented.
SPIRE will be overseen by the SSG who will ensure adherence to the agreed set of Information Governance
Principles and Standard Operating Procedures arising from these. The SSG includes representation from
patients, GPs, Scottish Government, relevant professional bodies such as BMA and RCGP, and NHS
Caldicott Guardians.
NHS Boards and GP Practices are required to notify PHI of any breaches of non-trivial risk to privacy.
PHI will consider these for learning points, and any need for report to ICO.
SPIRE Privacy Impact Assessment v3.1 Page 26 of 61 20-Feb-17
4. Data Quality
4.1 Will there be monitoring to
assess the personal information’s
fitness for purpose? If so how will it
be done?
SPIRE software is designed to enhance and improve GP data quality where it is
acknowledged there is wide variation.
GPs can generate and view a local report on data before consenting to its release to
SPIRE. A data quality module with Toolkit is supplied to support GPs and GPs may
choose to address data quality issues before re-running the extract before release of an
updated extract to SPIRE.
4.2 Will there be monitoring to
assess the personal information’s
relevance? If so how will it be
done?
The Secondary Uses which the PID serves will be controlled by the SSG and PBPP's
approval of each specific project: see appendix 6 and appendix 12.
The default position is that PID is destroyed routinely, rather than retained: see section 5.3.
If a further use is required, the PID will be re-extracted for the new purpose, thus being
subject again to the IG safeguards.
For example, the use of prescribing data for NHS management is different from that for
pharmaceutical research, and has different public support. Either may use aggregate data,
but if using limited data containing PID it would be subject to patient and GP opt-out.
In this example, if new risks of adverse reactions to drug combinations are discovered in
some individual persons' records, to investigate this will require full details incl. PID in each
case, which would be undertaken in collaboration with the GP practice and include explicit
consent from each individual.
4.3 Will there be monitoring to
assess the personal information
remains up to date? If so how?
Yes, see above 4.1.
SPIRE Privacy Impact Assessment v3.1 Page 27 of 61 20-Feb-17
5. Retention and Destruction
5.1 For how long will the data be retained? Data will only be retained for the minimal time necessary to allow the original
purpose of the extract to be met as approved by the SPIRE Steering Group.
The application must clearly state for how long data is needed. The justified
retention period will depend on the purpose, and be in line with the NSS
records management policy.
5.2 Is the personal information covered by the
NSS Document Storage and Retention Policy? If
so which section(s)?
Yes. There is an entry for SPIRE data in appendix A, section 9 (Public Health
& Intelligence).
5.3 How will the data be securely disposed of
when no longer required? This should include the
medium e.g. CD, USB data storage device we
received the original data on.
Will follow standard NSS procedures for Lifecycle Management of the data.
SPIRE Privacy Impact Assessment v3.1 Page 28 of 61 20-Feb-17
6. Recommendations
These should include agreed actions, timescales and task owner taken to address identified risks.
Recommendation Action Timescale Task Owner
Provide Advanced Access Assurance controls. Maintain a list of PHI staff who can
access individual level data.
January 2017 Associate Director
(Data Management)
Update Privacy Impact Assessment Update PIA (Appendix 1) if the
content of the GP Reporting
database changes.
Ongoing Service Manager
(SPIRE Team)
SPIRE Privacy Impact Assessment v3.1 Page 29 of 61 20-Feb-17
7. Is a more detailed assessment needed?
A more detailed PIA may be needed where the project
a. includes new or intrusive technology
b. identifying previously anonymised information or
transactions
c. joining up or data sharing with other agencies
d. significantly new or sensitive information
e. a significant increase to the volume or cross-
referencing of personal information already
processed by ISD
f. relates to law enforcement or national security
activities
g. involves disclosure of personal information to third
parties that are not subject to comparable privacy
regulation. If so, for what reason?
No, a more detailed assessment is not considered necessary because
at an early stage in the project, a set of Information Governance principles
were agreed, following discussion with stakeholders including patients,
GPs, the BMA, RCGP and NHS Board Caldicott Guardians
the Information Governance principles have been made available since
2014 on a publicly accessible website – see SPIRE
this PIA links to public documentation (or if on security held appropriately)
In response to these issues:
a. no - extract encryption and linkage technologies are established
b. no
c. yes - as discussed at sections 1.6 and 2.1
d. no - access to coded GP data is established practice
e. yes - purpose of project
f. no
g. no
SPIRE Privacy Impact Assessment v3.1 Page 30 of 61 20-Feb-17
8. Completed function / policy
Who will sign off the PIA? Dr Janet Murray, ISD Caldicott Guardian.
Dr Frances Elliot, Chair SPIRE Steering Group.
Scott Heald, Associate Director & Head of Profession for
Statistics
Complete:
February 2017
Who will complete the on-line Notification of
processing of Personal Data form (on geNSS) at the
appropriate stage in the project?
As processing will not differ from that recorded in the Data
Protection Register (see section 1.7) there is no need to
complete the online notification form.
Review date for PIA The PIA will be reviewed every 3 months after the first data
extracts commence.
Date: July 2017
SPIRE Privacy Impact Assessment v3.1 Page 31 of 61 20-Feb-17
Appendix 1: Content of GP Reporting Database The GP Reporting database is retained at each GP Practice and SPIRE queries are run against this. All of
these fields could be extracted by SPIRE Local, and the full range of items is available for use in local
reports that are available only to GP Practices. Items identified with * are normally retained locally.
Queries from SPIRE Central will minimise the number of items to be sent, and these will be identified in the
application for approval by the SPIRE Steering Group.
Items in bold are those considered Personal Identifiers which, if to be transmitted, are de-identified by
pseudonymisation - see section 1.3B.
Patient Type e.g. NHS, private, temp, other
Registration status e.g. temporary, full
Deregistration date
Deregistration reason
Marital status ID
Registered GP
Usual GP
Clinical event date
Read V2 code
Read term ID (term ID adds further detail)
Value 1 numeral e.g. for BP, wt, ht, drug quantity
Value 2 e.g. diastolic BP
Episode type e.g. acute/repeat for prescriptions
Sex
Drug name
Drug dosage
Drug form
Drug prescribing source
Drug print date time
Drug issue method
Drug strength
British National Formulary code
Encounter ID
Dictionary of Medicines & Devices code
Health Care Professional type
Health Care Professional identifier *
Date of death *
Registration date *
Date of birth
Surname*
Forenames*
Title*
NHS number
CHI number
Address 1*
Address 2*
Address 3*
Address 4*
Address 5*
Postcode
Home telephone*
Work telephone*
Mobile telephone*
Previous surname*
SPIRE Privacy Impact Assessment v3.1 Page 32 of 61 20-Feb-17
Appendix 2a: SPIRE Extract and Processing Overview
SPIRE Privacy Impact Assessment v3.1 Page 33 of 61 20-Feb-17
Appendix 2b: SPIRE extract process diagram
Extract of data with patient identifiers to create Derived Items: example
1. SPIRE Steering Group (SSG) approves the application to extract SPIRE data.
2. Analyst team write a query in SPIRE Central to request the following variables in this example:
Read Codes (for diabetes) / Sex / Postcode
3. SPIRE Team publish the query to SPIRE Local at each Practice.
4. The query runs in SPIRE Local.
5. The results of the query are viewable in SPIRE Local by the Practice only;
in this example this is a case-listing for the 200 diabetes patients.
6. The Practice decides whether to opt-in to the data extract;
if the practice does not opt-in, then no data leave the practice.
7. If the Practice does opt-in, then a data file is created at the practice:
Table 1 (contains 200 records)
CHI Pseudonym Read Code Sex Postcode
CHI PS 1 Read1 M PC1
CHI PS 2 Read2 F PC2
CHI PS 3 Read3 F PC3
Etc. Etc. Etc. Etc
SPIRE Privacy Impact Assessment v3.1 Page 34 of 61 20-Feb-17
CHI PS 200 Read200 M PC200
8. Automatic check for patient opt-out Read code, if found then
9. Those records are removed (e.g. 4 records).
10. The file now contains 196 records, with for example CHI PS 2 having opted-out
Table 2 (Now contains 196 records)
CHI Pseudonym Read Code Sex Postcode
CHI PS 1 Read1 M PC1
CHI PS 3 Read3 F PC3
Etc. Etc. Etc. Etc
CHI PS 200 Read200 M PC200
11. Split PID data from non-PID data; both files contain the CHI pseudonym
(see Table 3: PID and Table 4: non-PID below for this example – both contain 196 records).
Table 3 (PID File) Table 4 (Non-PID File)
CHI Pseudonym Postcode CHI Pseudonym Sex Read Code
CHI PS 1 PC1 CHI PS 1 M Read1
CHI PS 3 PC3 CHI PS 3 F Read3
Etc. Etc Etc. Etc. Etc.
CHI PS 200 PC200 CHI PS 200 M Read200
12. Apply encryption to PID file at the Practice.
13. Transfer both files to the Secure Storage Area at NSS securely over the SWAN network;
during this transfer the files are further encrypted.
14. An automatic check is carried out to ensure that there are 196 records in the non-PID file.
15. An automatic check is carried out to ensure that there are 196 records in the PID file.
16. The encrypted PID file is sent by the Data Management team to the Derived Data role.
17. The Derived Data role decrypts the PID file (although the CHI is left as a pseudonym).
If an analyst is involved in derived data role then they will not be involved in final analysis.
18. Using the decrypted file, the Derived Data role creates the derived variable, in this example the Scottish
Index of Multiple Deprivation (SIMD) score
Table 5 (Contains 196 records)
CHI Pseudonym Postcode SIMD
CHI PS 1 PC1 Dep1
CHI PS 3 PC3 Dep3
Etc. Etc Etc.
CHI PS 200 PC200 Dep200
19. Derived Data role removes any PID variables
Table 6 (Contains 196 records)
CHI Pseudonym SIMD
CHI PS 1 Dep1
CHI PS 3 Dep3
Etc. Etc.
CHI PS 200 Dep200
20. Derived Data role returns file with CHI Pseudonym and derived variable (Deprivation Category) to Data
Management team.
SPIRE Privacy Impact Assessment v3.1 Page 35 of 61 20-Feb-17
21. Data Management Team combines the derived variables with the non-PID file using the CHI Pseudonym
to create a file as shown in Table 7 below and passes it to the Analyst team.
Table 7 (Contains 196 records)
CHI Pseudonym Read Code Sex SIMD
CHI PS 1 Read1 M Dep1
CHI PS 3 Read3 F Dep3
Etc. Etc. Etc. Etc.
CHI PS 200 Read200 M Dep200
22. Analysis carried out. For this example, a breakdown of Read codes by sex and deprivation categories, or
even just a breakdown of the numbers of diabetes patients by deprivation category etc
23. If publication of the analysis (either hardcopy or online) is required, then the ISD Disclosure Control
Protocol is followed to reduce the risk of disclosing personally identifiable information (DC Protocol
available here: Disclosure Control).
24. Publish analysis if required.
SPIRE Privacy Impact Assessment v3.1 Page 36 of 61 20-Feb-17
Appendix 2c: Standard eDRIS Linkage Process
Approved linkage uses established probability matching techniques based on the Howard Newcombe
principles (refs 27
28
) and developed over 25 years in Scotland by Kendrick et al to form the foundation of the
Linked Scottish Health Records, and SHIP programs. Linkage will be undertaken by a Trusted Third Party
automated agent and a Population Spine used as an intermediary linkage tool. The Population Spine
contains the personal identifiers of all individuals in Scotland who have been in contact with NHS Scotland.
The steps describing the process of linking data are detailed below:
1. Data Providers will supply personal identifiers (only) plus their own organisation’s person or record ID
number to the indexing team.
2. The indexing team will probability-match the identifiers to the Population Spine using complex
algorithms.
3. The Data Provider will receive a file back with their own organisation’s person or record ID number
and a unique person index ID number specific to that dataset. This is generated by the indexing team.
4. The Data Provider will attached the received index ID number to the remaining content of the dataset
to be provided for linkage and send it to their Research Coordinator.
5. The Research Coordinator will confirm that the agreed data has been received and send the file to the
linkage agent. The linkage agent is an automated computer program which carries out the linkage.
6. The linkage agent will receive 2 files: all the datasets and their unique person ID numbers plus a
master control file containing a master person ID and all the dataset unique Person index ID numbers.
7. The linkage agent will then replace all the dataset unique Person ID numbers with the master Person
ID number on each of the content data files.
8. This allows the researcher analysing the data to see all the records belonging to a person across all
the datasets without the need to see the personal identifiers.
N.B. as described in section 1.1, only those data that are required will be included in the data extract.
For further details on eDRIS, see ISD Scotland FAQ eDRIS and Guiding Principles for Data Linkage
27 ISD: The Scottish Record Linkage System
28 Farr Institute: what is health informatics research
SPIRE Privacy Impact Assessment v3.1 Page 37 of 61 20-Feb-17
Appendix 3:
Legal Provisions to support Data Processing without Explicit Consent
This provides further detail on section 1.3B and section 1.7.
Due to the low identifiability of the data in type B extracts if using de-identification methods such as
described in this PIA, they are considered suitable for processing without explicit consent if their purposes
meet these further legal validations:
1. for healthcare business purposes such as in section 1.7
Statute defining the legitimate purpose of NSS (i.e. National Services Scotland which is the common name for the Common Services Agency):
The Official Statistics Order 200829
The National Health Service (Functions of the Common Services Agency) (Scotland) Order 2008
30
Public Health Act (Scotland) 200831
Public Bodies (Joint Working) Scotland Act 201432
Research use of data is covered by DPA 1998 schedules as above plus Section 33.
GPs are Data Controllers, and are able to process data for SPIRE, according to the same
considerations as NSS.
A key element of SPIRE is that GPs must consent to release data for every extract request.
2. consistent with the Data Protection Act 1998:
The following conditions are relevant to the use of data for epidemiology and statistical analysis to support planning and evaluation of health services and public health, and research.
The conditions depended on are in
Schedule 2 (6): “legitimate interests pursued by the Data Controller or the third party.”
Schedule 2 (5) (b): The processing is necessary for the exercise of any functions conferred on any person by or under legislation.
Schedule 2 (5) (d): for the exercise of any other functions of a public nature exercised in the public interest by any person.
Schedule 3 (8): “processing is necessary for “medical purposes which is defined as including the ‘…purposes of preventative medicine, medical diagnosis, medical research, the provision of care and treatment and the management of healthcare services.
Schedule 3 (8) also adds “and is undertaken by
29 http://www.legislation.gov.uk/sdsi/2008/9780110815039/pdfs/sdsi_9780110815039_en.pdf
30 http://www.legislation.gov.uk/sdsi/2013/9780111020623
31 http://www.gov.scot/Topics/Health/Policy/Public-Health-Act
32 http://www.gov.scot/Topics/Health/Policy/Adult-Health-SocialCare-Integration/About-the-Bill
SPIRE Privacy Impact Assessment v3.1 Page 38 of 61 20-Feb-17
a) a health professional, or
b) a person who in the circumstances owes a duty of confidentiality which is equivalent to that which would arise if that person were a health professional.”
This applies to all users of identifiable SPIRE data, who must meet the training and other professional standards in section 3.2.
3. consistent with the common law duty of confidentiality:
This allows confidential data to be shared lawfully under the condition (among others) of public interest. Confidentiality is not an absolute right, and sharing with just cause, or when acting in the public interest supports defences against legal complaint.
Consent: Confidentiality and Security Advisory Group (CSAGS) 2002 recommended
o explicit consent should become the norm for uses of identifiable data, BUT where consent is not being sought (impractical, not ethical, may invalidate data), there must be clear information to patients
o implied consent was accepted as a minimum standard for most ‘secondary uses’, on the assumption that the NHS would move towards full consent
SPIRE has an opt-out model of consent for type B extracts
Public interest: SPIRE Steering Group has public representatives to assist in understanding the public interest in the development. All requests for SPIRE data will be considered by the SPIRE Steering Group. Similarly, public representatives contribute to the Public Benefit & Privacy Panel for Health and
Social Care. Its remit is to carry out information governance (IG) scrutiny of requests for access to health data for purposes of health and social care administration, research and other well-defined and bona fide purposes, on behalf of individual data controllers.
SPIRE Privacy Impact Assessment v3.1 Page 39 of 61 20-Feb-17
Appendix 4: Patient Opt-out Form Final
SPIRE Privacy Impact Assessment v3.1 Page 40 of 61 20-Feb-17
Appendix 5A: SPIRE Access Assurance extract from
Background
The Scottish Primary Care Information Resource (SPIRE) uses software that enables data,
following approval by SSG & PBPP to be extracted from GP Practice systems in Scotland and then
securely transferred to a Secure Storage Area (SSA) in NSS.
The data can then be used for Secondary Uses e.g. for analysis, payment purposes etc.
These data can, with appropriate approvals, contain Personally Identifiable Data (PID) and
Personal Identifiers – see Privacy Impact Assessment appendix 1 – e.g. CHI number, date of birth,
postcode etc.
All staff working in NHSScotland have a legal duty of confidentiality which they must sign up to
annually.
Should a patient have a concern over an employee of NSS accessing their PID through SPIRE,
there are various assurances and procedures in place within NSS, which this document
summarises.
Access Controls
Access to the Secure Storage Area is controlled in the following ways:
Access to SPIRE data extracts in the SSA is authorised to NSS staff by individual user identifiers and passwords;
User authentication is secure and users are required to access using NSS encrypted PCs/Laptops;
In the case of personally identifiable data (PID), access is granted to NSS staff for a maximum period of 6 months. Access to PID is also reviewed every 6 months, when access must be re-authorised;
The NSS IT Acceptable Use Policy section 5 paragraph 2 (see appendix A) states “Most access to computers, data, and the internet and email services is electronically logged. These audit data provide the service provider with technical service usage data in the event of service issues or inappropriate user usage/activities.”
NSS staff required to access PID are monitored (in line with the NSS IT Acceptable Use Policy) by maintaining an audit trail to record, retain and report on activity. This information may be made available to individuals on receipt of a valid data Subject Access Request;
Only the minimum number of staff, most commonly one and normally no more than two, selected from a small number of appropriately authorised staff within the SPIRE Service Team within Public Health & Intelligence (PHI) Strategic Business Unit (e.g. Data Managers and Data Analysts), will ever have access to any single set of PID. In a few exceptional cases, e.g. to cover staff absence, a third person may need to be involved; and
Each staff member will only be granted access to personal identifiers OR clinical payload data, but not both.
HR Controls and Contractual Obligations
All NSS staff are vetted prior to employment. Dependent on the post, checks will include some or all of the following: Verification of Identity; Right to Work; Professional Registration and Qualification; Employment History and Reference; Criminal Record Checks; and Occupational Health Checks.
SPIRE Privacy Impact Assessment v3.1 Page 41 of 61 20-Feb-17
All PHI staff complete specific training in confidentiality, and the rules in the corporate Confidentiality Policy (see appendix B) that govern the care and release of confidential data.
New staff must sign that they understand and accept them; all staff renew this declaration annually. PHI staff contracts lay out the need to respect and preserve confidentiality.
In addition, all PHI staff must complete the intermediate level Information Governance online training module, and update this every three years.
Rights of Individuals
Individuals have a number of standard rights that they can exercise:
The right to opt-out of SPIRE by completing a standard opt-out form (PIA appendix 4) available in practices or online to download, if they do not want their PID to leave the GP practice as part of SPIRE;
The right of subjects to access data held about them and how it has been handled within NSS
The right to contact NSS if there is suspicion of a privacy breach i.e. someone in the course of their work, has accessed their PID inappropriately. In such instances, the NSS Adverse Events Management Policy (see appendix C) will be followed.
Appendix A – NSS IT Acceptable Use Policy
Appendix B – NSS Confidentiality Policy
Appendix C – NSS Adverse Events Management Policy
SPIRE Privacy Impact Assessment v3.1 Page 42 of 61 20-Feb-17
Appendix 5B: SPIRE Advanced Access Assurance (AAA)
Why might a person reasonably consider opting-out?
They may feel themselves to be at special risk that a health professional may misuse their legitimate NHS
access to their Personal Identifiable Data (PID) held by NHS National Services Scotland (NSS) e.g.
a neighbour/relative may be known to work in the NHS e.g. to work as a hospital manager; and/or
the person may be a celebrity, or have a rare or sensational condition feared to be of public interest.
The misuse by “insiders” of their legitimate workplace access is an increasing public concern, especially
since some well-publicised large disclosures of documents.
Unfortunately it is not well understood by the public that:
NSS is a small part of all of NHS Scotland,
there are substantial access controls already in place throughout the NHS
only a very small no. of analytic staff, normally 1 or 2, may ever have temporary access to PID in
SPIRE's pseudonymised limited datasets.
there is no single analyst with access to all the datasets,
any person's data are distributed over several temporary datasets and
personal data are not in a human-readable document format, but coded.
AAA aims to provide the general public with reassurance that their privacy is protected, by enabling
individual persons to check if alleged "adversaries" among any NHS staff are among the very small no. of
NSS staff with legitimate access to some of their Personal Identifiable Data (PID) in SPIRE.
This is the “motivated insider” risk33 of inappropriate use of legitimate access, and can in theory enable re-
identification by an “inference” or “jigsaw” attack, wherever this data may be rich enough to combine with that
in public datasets. However in practice, according to Yakowitz' review 34
, there were no known releases
from, nor effective external attacks on, a medical research dataset.
Since in NSS the number of analysts with access to PID is very small (because there are many individual
time-limited datasets instead of a single large persisting “rich” dataset) in practice the perceived risk very
rarely becomes a confirmed privacy issue. It can thus be managed at an individual level as cases arise.
It requires that NSS maintains for each extract a list of those staff who may have access to PID, as part of
normal NHS research governance. The number of analysts processing PID is minimised normally to no
more than 235
.
Any person may make an AAA request, by supplying to NSS a name for the NHS staff who allegedly might
misuse their legitimate access as if an adversary. On receiving an AAA request, NSS is responsible for
assessing the privacy risk to the person making the application by checking whether or not:
the alleged means of access is or has been legitimately available to the named NHS staff alleged to
be adversarial by the applicant i.e. is on the staff of NSS and has access to this person's PID?
if so, if the named NSS staff is also known to have used their legitimate access?
Nearly all alleged adversaries will be refuted on check 1: if their perceived means of access does not include
NSS access to PID it is then sufficient to advise the applicant that the suspected name is not on the list of
names with legitimate NSS access.
There is no need to publish names of any NSS staff whether or not they may have access.
However, if test 2 is also positive, then the person's privacy may have been at risk, and will be managed in
accordance with NSS Policies and Procedures, as in appendix 5A.
33 The risks of this inappropriate access are similar to those due to the “motivated intruder” or external “hacker”, discussed in the
Information Commissioner’s Office (ICO) Anonymisation Code of Practice. 34
Jane Yakowitz: Tragedy of the Commons pp35-39 35
In a few exceptional cases, e.g. to cover staff absence, a third person may need to be involved; we do not expect more than three
analysts to have sight of the same set of PID.
SPIRE Privacy Impact Assessment v3.1 Page 43 of 61 20-Feb-17
Appendix 6: SPIRE Steering Group and
NHSScotland Public Benefit and Privacy Panel (PBPP)
The SPIRE Steering Group (SSG) is the body responsible for scrutinising requests for access to
SPIRE data and ensuring that the SPIRE service conforms to agreed Information Governance
principles.
Further information is available at http://www.spire.scot/professional/safeguards/steering-group/.
The purposes of the SSG include:
to offer access to those with a legitimate interest and appropriate expertise e.g. if they are
partners of accredited academic partners of NHS organisations
to ensure that applicants are aware of previous or concurrent applications so that
duplication of analysis is not inadvertently undertaken
to ensure confidentiality issues are addressed, including, as appropriate, ethics approval,
before information is released.
to ensure that the data requested is relevant, proportionate and necessary to inform or
answer each query
to ensure that, if the data extract includes any personal identifiers, patients have had the
opportunity to opt-out of SPIRE extracts
to consider the interests of the GP body as Caldicott Guardians of the information and who
have undertaken the collection of the information
maintenance of SPIRE Data Sharing Agreement (DSA):
o add new organisations, terminate old ones
o review and update the Privacy Impact Assessment and DSA
The current Terms of Reference document for the SSG is included via this link
Add link to URL when known
If the request is from an approved researcher, and includes linkage to other data, then the
application must also be approved by the Public Benefit & Privacy Panel for Health and Social
Care, a single application and scrutiny process now operating across Scotland36.
Further information about the PBPP is available here:
Overview
Terms of Reference
Guiding Principles
Application Form
36 since 1st May 2015, Community Health Index Advisory Group (CHIAG), NHS National Services Scotland Privacy Advisory Committee
(PAC), and National Caldicott Guardians application processes have been merged.
SPIRE Privacy Impact Assessment v3.1 Page 44 of 61 20-Feb-17
Appendix 7: Patient Consent Model
For Scottish Government eHealth Division
Feasibility Study Draft v 0.5 October 2015 Updated version Dec 2016
Introduction: Document Purpose
This report is the NSS deliverable for a commission from the Scottish Government eHealth Division to
investigate the feasibility of designing and implementing a generic consent mechanism based on archetypes
in order to record and store patient consents to share data with other clinical IT systems.
Background
The current process for recording patient consent in clinical IT systems largely relies upon the ticking of
bespoke check boxes on specially designed and developed screens. In some systems, these check boxes
generate Read codes that are added to the system’s database and which then control the extraction of, and /
or access to, the patient information. In other systems, access to the patient information is controlled directly
by user login permissions within the system.
This approach to recording and utilising patient consent has met the requirements of patient, clinicians and
administration staff until now, but the increasing use and analysis of electronically held patient information
along with the desire to give patients more control over their information and how it is used, means the
current approach will become increasingly untenable in the future. The proposed withdrawal of Read over
the next few years and its replacement by SNOMED CT adds to the problem.
The proposal therefore, is for a new approach that combines the advantages of using a computable set of
generic SNOMED CT “consent/dissent” codes, with the localisation afforded by the use of separate
SNOMED CT “project name” and “extract service” codes to identify specific local sharing projects and the
extract service contractually responsible.
Sponsor
This work is jointly sponsored by:-
eHealth Division of Scottish Government
National Services Scotland (NSS).
Scottish Clinical Information Management in Practice (SCIMP)
Intended Audience
Julie Falconer, eHealth Division, Scottish Government
Libby Morris, PRSB and SCIMP
Ian Thompson, eHealth and SCIMP
Adrianos Evangelidis, Information Architecture (eHealth)
Daniel Beaumont, eHealth, Scottish Government
Lorna Ramsay, Medical Director NSS IT
Scott Heald, SPIRE Project Lead, NSS PHI
Janice Watson, Terminology Lead, NSS
Paul Miller, SCIMP
Leo Fogarty, SCIMP
eHealth Leads
Structure and Content
Chapter 1: Introduces the report, provides some background, and gives the purpose and structure of the
document.
Chapter 2: Explains the current situation being addressed and gives a strategic context
Chapter 3: Details the proposal being considered
Chapter 4: Records the observations made during the study
SPIRE Privacy Impact Assessment v3.1 Page 45 of 61 20-Feb-17
Chapter 5: Draws the conclusion from the study
References
1. A Health and Biomedical Informatics Research Strategy for Scotland, 2014
http://www.gov.scot/Resource/0047/00475145.pdf
2. Caldicott review: information governance in the health and care system, DoH, 26 April 2013
Information: To Share Or Not To Share? The Information Governance Review
3. GMC Good Medical Practice:
http://www.gmc-uk.org/guidance/good_medical_practice/continuity_care.asp
4. eHealth Strategy 2014-17
http://www.ehealth.scot.nhs.uk/strategies/
5. Route Map to the 2020 Vision for Health and Social Care
http://www.gov.scot/Resource/0042/00423188.pdf
Definitions and Acronyms
NSS National Service Scotland
OBC Outline Business Case
PRSB Professional Records Standards Body
SCIMP Scottish Clinical Information Management in Practice
SPIRE Scottish Primary Care Information Resource
SNOMED CT Systemised Nomenclature of Medicine – Clinical Terms
UKTC UK Terminology Centre
INPS In Practice Systems
EMIS Egton Medical Information Systems
PCS GP Clinical System
PID Personal Identifiable Data
2 Current Situation
2.1 Strategic Context
Whilst the eHealth Strategy 2014 – 2017 maintains a significant focus on healthcare and the needs of
NHSScotland, it has been redeveloped to recognise the rapidly evolving environment of integrated health &
social care and the need to address not only NHSScotland requirements, but also the expectations and
requirements of partnership organisations, and citizens for electronic information and digital services.
One of its aims is for significant further development of current capability to support:
the use of integrated and person-centred information and intelligence for decision making,
quality evaluation and improvement, which can be used to assess performance and improve
patient care;
the analysis, interpretation and use of data, information and intelligence.
There will also need to be parallel and ongoing development of information governance arrangements and
patient consent models to retain the public’s confidence, and to ensure it keeps pace with developments. In
addition to supporting NHS related research, this infrastructure will impact positively on the wider field of
informatics for health and biomedical research as set out in the recent draft strategy for this area - A Health
and Biomedical Informatics Research Strategy for Scotland, 2014 (Ref. 1)
2.2 Existing Arrangements for recording patient consent
Although there are many e-Health information-sharing projects across the UK, for both primary and
secondary uses which record patient consent, there are primarily 2 broad approaches:
2.2.1 Patient consent/dissent is recorded using ‘generic’ Read codes
SPIRE Privacy Impact Assessment v3.1 Page 46 of 61 20-Feb-17
The advantage of this approach is that by relying on generic Read codes, there is no need to request new
codes from the UK Terminology Centre (UKTC). The disadvantages are that the project to which consent
applies is undefined, unless associated in free text. As there are increasing numbers of local and national
sharing projects requiring the recording of patent consent it becomes almost impossible for suppliers of GP
systems to apply consent/dissent to requests for extracts correctly, particularly as patients move areas or
countries. An example listing of how consent codes may appear in a patient record is shown below, and
illustrates some of the complexity inherent in this method:
2.2.2 Project specific patient consent/dissent Read codes
This approach requires a set of custom consent/dissent Read codes to be created by the UKTC for each
individual project. Each project requires a minimum of four codes to represent explicit consent, implicit
consent and explicit dissent, implicit dissent.
Although this approach allows the project to which consent is applied to be accurately identified it will result
in a high level of demand and dependency on the UKTC to create new sets of project specific codes. There
are already a very high number of such consent /dissent codes in UK SNOMED CT and Read often with
conflicting hierarchies. This presents difficulties for GP systems.
2.3 Read Coding Withdrawal
The current de facto standard for clinical terminology in the UK is Read Clinical Terms (in Scotland this is
mostly the Scottish specific edition of Read Version 2. The Department of Health in England has approved
SNOMED CT as a fundamental standard which would be implemented in England during 2016 to 2020.
Read Version 2 is now officially classed as a supported deprecated product by the publishers (the United
Kingdom Terminology Centre (UKTC). Given that its final updated release was on 1st April 2016 and the
date of withdrawal is 1st April 2020, it is likely that Read will rapidly become unfit for purpose for many use
cases once it ceases to be updated.
This decision to replace Read Clinical Terms with SNOMED CT will undoubtedly affect their use within NHS
Scotland. UKTC may not have the resources to continue to maintain both terminologies and their crossmaps
safely for an indefinite period. 37
The possible implications may be that support for Read V2 is reduced or
discontinued all together, either within or outwith a timescale of NHS Scotland’s choosing.
3 Proposal:
3.1 A Patient Sharing Consent Record
Rather than relying wholly on a single ‘date with code’ structure to record consent, it is proposed that
systems suppliers are asked to manage patient record consent as an information structure suitable for
primary and secondary record sharing consents to be recorded and, over time, be self-managed by patients
via a patient portal, where appropriate. The aim is to provide sufficient information for patients, or their
advocates, to understand which consents are in place, of what type (anonymised, pseudonymised,
identifiable) and whether consent has been explicitly granted or refused.
The proposed consent record is a structured set of data elements that are pre-defined in content type.
Essentially this means that any system using this record type would be able to exchange the data with any
other; that suppliers can use the data structure to reliably compute consent status for any user or system
purposes; and that suppliers are able to provide different views of the data on different platforms without
compromising the underlying records. In real life use, not all data elements will need to be used on forms
and interfaces, but will still be available in the data if required.
37 UPDATE Dec 2016: Read v2 is now frozen in the state it was at the time of its last release, April 2016
SPIRE Privacy Impact Assessment v3.1 Page 47 of 61 20-Feb-17
3.1.1 Consent Status Date
The date at which the consent status was set.
3.1.2 Consent status
The consent status of the project, either ‘Consent’ or ‘No Consent’. Terms exist in SNOMED CT to allow this
currently. Going forward greater granularity and better implementations could be achieved with the provision
of new codes for implicit and explicit forms of consent, but this is not required for initial implementations.
3.1.3 Consent Type
Whether the consent is derived or implied from project defaults and other consent records, or explicit.
3.1.4 Extract Service
The name of the responsible organisation/service and type of extract.
For example: “SPIRE anonymous extract”
“SPIRE patient-identifiable extract”
These will be represented as a SNOMED CT “SPIRE namespace” term.
3.1.5 Project name
The name of the specific data sharing project to which the consent applies.
For example: “SPIRE Hypertension Dataset”
“University of Dundee Childhood Asthma project”
These will be represented as a SNOMED CT “SPIRE namespace” term.
3.1.6 Project URL
A link to further information about the project, to allow patients or advocates to understand the project in
more depth or to follow project results.
3.1.7 Current record status
This consent record should be managed as a ‘current status’ such that in normal circumstances only a single
consent record (the most recently recorded one) is current for each project. Previous versions need to be
available for medico-legal purposes and to allow users to understand the patient’s consent history.
3.2 Terminology requirements
SNOMED CT has been proposed as the preferred terminology as it is now supported by all UK GP clinical
systems, and would be ‘hard-wired’ into data entry screens - there is no expectation that practices would
enter patient consent via a SNOMED CT or Read code browser screen.
SPIRE Privacy Impact Assessment v3.1 Page 48 of 61 20-Feb-17
3.3 Namespacing
The approach limits the dependency on the UKTC to issue new codes for each project and service by
instead making use of SNOMED CT ‘namespacing’ which allows any organisation or company to issue their
own ‘local’ SNOMED CT terms. These are labelled uniquely so that there is no possible confusion with
codes created by other namespaces. SNOMED CT namespacing is a formal, controlled and structured part
of SNOMED CT designed for precisely this type of purpose.
This approach would require a request for a ‘namespace’ from International Health Terminology Standards
Development Organisation (IHTSDO), perhaps via the UK Terminology Centre. This is a routine situation,
used by most UK companies, and ISD Terminology Services should be able to assist in this.
3.4 Current status codes
Some generic consent status codes are already provided which may be suitable
Consent given for electronic record sharing (finding) Concept ID: 425691002
No consent for electronic record sharing (finding) Concept ID: 414859005
In due course new codes would be requested, for example:
Explicit consent for electronic record sharing (finding)
Explicit dissent for electronic record sharing (finding)
Implicit consent for electronic record sharing (finding)
Implicit dissent for electronic record sharing (finding)
These will increase the utility of consent records
3.5 Example of potential use within SPIRE
The following sections describe the potential use of the approach in SPIRE
3.6 Data Extract Types
3.6.1 Type A - Aggregate Data (Low risk)
This is data grouped together (aggregated) and will not contain any personal identifiable data (PID). An
example is Quality and Outcomes Framework (QOF) data, but similar aggregate requests may apply to
some enhanced service reporting. It is proposed that patients will not be able to refuse to have their data
included in such extracts as the NHS GP service is dependent on data use at this level for basic operation,
and data is considered to be effectively anonymised.
3.6.2 Type B – Pseudonymised data with Limited PID (Medium risk)
This is data that will be extracted ‘pseudonymised’; that is with personal identifiers removed or scrambled
such that re-identification becomes very difficult, requiring access to encryption keys.
3.6.3 Type C - Data with Full PID (High risk)
Some data extract projects will require full PID to be included for their planned purpose.
3.7 Consent Records for SPIRE
The proposed business process is for the patient’s General Practice to record the patient’s status in the
patient’s primary care electronic medical record. At present in NHS Scotland this means into INPS Vision or
EMIS PCS. It is possible, however, that the consent records could be stored on a SPIRE application, but the
requirements from the practice perspective – to view, add, delete and edit such records, remain the same
regardless of the application holding the consent records data. GP practices will need to be able to access
the functionality for managing SPIRE consent records seamlessly using their usual clinical information
systems ensuring patient context is always explicit, regardless of application. For consent records to
interoperate via GP2GP the consent records will need to be stored in the GP record.
There are three types of consent record that need to be implemented for SPIRE:
SPIRE Privacy Impact Assessment v3.1 Page 49 of 61 20-Feb-17
3.7.1 SPIRE Master Consent
Patients can request the setting of an overarching SPIRE Consent value in their GP system record.
This will be an implicit ‘consent’ until a patient expresses a preference.
This consent record status will affect types B and C data extracts only. Where the consent record status for
the SPIRE Master is ‘dissent’ it will take precedence over any other service specific consent records of these
types. Type C data extractions will still require specific consent per project even if the current status for the
master consent is ‘consent’.
3.7.2 SPIRE Type B Consents
This type of consent is for pseudonymised data extracts. The proposed consent process for these type of
extracts is to assume consent following adequate publicity (implicit consent). Patients will be able to opt out
of all such extracts, or opt into all such extracts. Thus there is no project specific consent record for each
project of this type – consent for these extracts is effectively all or none. A future requirement may be to
allow patients the option of consenting in or out of specific projects of this type.
3.7.3 SPIRE Type C Consents
This type of consent is for data extracts which will use full PID.
For this type of extract patients will be asked and give (or refuse) consent to the project explicitly. Consent
will be for each named project of this type. That is, a patient will need to give consent to each identified
project of this type as required – there is no ‘All or None’ switch for these types of project at this time. It
would be a reasonable requirement in the future to provide an overall consent control for PID extracts to
allow patients to ‘Always decline’, ‘Always accept’ or ‘Always ask’ for this type of extract. This could be
implemented in the future by creating a sharing record that would apply to any consent records of this type,
and could be supported using the consent template approach described in this document.
A patient with no record for a Type C extract has a status 'implicit dissent.'
3.7.4 A note to which consent type to use
It is worth considering for the future that the appropriateness of "implicit with opt out" (for type B) and "explicit
with opt in" (for type C) should be considered against the overall sensitivity and privacy risks of the extract,
regardless of the methodology of that extract (pseudonymised or with PID).
3.8 Consent Interactions
The following tables show the effective consent for each extract type by cross referencing the SPIRE Master
Consent record with project specific consent records for Type B and Type C data extracts.
3.8.1 Type B Extract Consent Records cross ref SPIRE Master Consent
SPIRE Master Consent Status
Absent Consent Dissent
Type B Projects
Consent Status
Absent Implicit Implicit Implicit
Consent Consent Dissent
Consent Explicit Explicit Implicit
Consent Consent Dissent
Dissent Explicit Explicit Explicit
Dissent Dissent Dissent
SPIRE Privacy Impact Assessment v3.1 Page 50 of 61 20-Feb-17
3.8.2 Type C Extract Consent Records cross ref SPIRE Master Consent
SPIRE Master Consent Status
Absent Consent Dissent
Type C Named
Projects Consent
Status
Absent Implicit Implicit Implicit
Dissent Dissent Dissent
Consent Explicit Explicit Implicit
Consent Consent Dissent
Dissent Explicit Explicit Explicit
Dissent Dissent Dissent
4 Observations
4.1 Benefits of introducing this approach
The archetype proposal, detailed above, combines the advantages of using a computable set of generic
SNOMED CT ‘consent/dissent to share’ codes, with the localisation afforded by the use of separate
SNOMED CT ‘project name’ and ‘extract service’ codes to identify specific local sharing projects and the
extract service contractually responsible.
Patient consent would be managed as an Information Structure that would allow all primary and secondary
record sharing consents to be recorded. The aim is to provide sufficient information for patients, or their
advocates, to understand which consents are in place, of what type (anonymised, pseudonymised,
identifiable) and whether consent has been explicitly granted or refused.
The consent record is a structured set of data elements that are pre-defined in content type. This means that
any system using this record type is able to exchange the data with any other. Suppliers can use the data
structure to reliably compute consent status for any user or system purposes and are able to provide
different views of the data on different platforms without compromising the underlying records.
4.2 SPIRE
The proposed consent model was originally produced to support the various patient consent statuses for
SPIRE data extracts. In order to meet the delivery timescales it was decided to implement SPIRE using
Read coding albeit with the intention to change to SNOMED CT over the next five years. The decision
precluded the introduction of this proposal at this time, but was not rejected as a potential way for the future.
4.3 Additional Considerations
There are a number of other areas for consideration that have a direct bearing on the introduction of this
proposal and require further discussion and exploration to ensure that the overall consent requirements
across the whole Health and Social Care spectrum is fully understood.
4.4 The Landscape of consent is changing:
4.4.1 Policy & Strategic Direction
The refreshed eHealth Strategy (Ref. 2) states an intention to simplify Information Governance arrangements
across NHS Scotland. It is expected that this will include simplifying and ensuring consistency of approach to
consent to share patient data across the major national IT systems.
4.4.2 Patient and public expectations
Public opinion and expectation in relation to sharing of health data have changed over the years. Patients, in
the main, accept and indeed expect that data is shared among those clinicians directly involved with their
care and understand that care is provided by a variety of professionals working across traditional
boundaries.
4.4.3 Professional expectations
SPIRE Privacy Impact Assessment v3.1 Page 51 of 61 20-Feb-17
The opinion of care professionals in relation to data sharing has also evolved. Whereas there was previously
a greater emphasis placed on protection of privacy, there is now an understanding of the need to strike the
best balance between protecting privacy and sharing information for the benefit of the patient. Additionally,
the model of care delivery is much more team and multidisciplinary based, and sharing of relevant
information with appropriate colleagues is regarded as part of providing quality care.
4.4.4 National guidance & regulatory body expectations
A number of important UK-wide position statements have been made which highlight not just the importance
but also the professional requirement to share relevant information with appropriate staff to support effective
patient care and safety. This may have a bearing in whether consent models adopt an “opt in” or “opt out”
approach. Two of particular relevance are:
a) ‘Caldicott 2’: (Ref. 3) “...good sharing of information, when sharing is appropriate, is as
important as maintaining confidentiality”
b) GMC guidance (Ref. 4). As the UK regulatory body for doctors, the GMC sets expected
standards of practice and issues supporting guidance. This includes: “you must share all
relevant information with colleagues involved in your patients’ care within and outside
the team, including when you hand over care as you go off duty, and when you delegate care
or refer patients to other health or social care providers.”
4.4.5 European Union Data Protection Regulation
It is currently believed that, whether we leave Europe or not, the GDPR will apply in the UK from38
May
2018.. This is likely to impact the recording of consent though the details have yet to be agreed.
4.5 National Solution
This proposal primarily addresses and presents a solution to the current situation around recording consent
in GP practices. However, as it states, it has the potential to address similar issues in Secondary and other
care sectors where consent for patients’ data to be shared also requires to be recorded for a variety of
clinical trials, research, etc. Whilst the nature of the consent recording and maintenance by GPs is well
understood and documented in the proposal, there is a need to investigate the situation in Secondary Care
where at present it is done in various diverse ways. This would ensure a single solution could be introduced
covering all areas.
4.6 Availability of consent information across systems
Whilst this proposal suggests how consent information can be entered and held as an Information Structure
and notes necessary changes to GP IT systems, changes will have to be made to a number of other
systems where consent information will require to be accessed. The most appropriate location(s) for this
information to be entered and stored where GP practices are not involved would need to be determined.
4.7 UK wide solution
With the introduction of GP2GPand the increasing number of patients being treated both ways across the
border, the lack of a consistent UK approach to the recording of consent will inevitably lead to difficulties.
The issues that the proposed consent model addresses are not unique to NHS Scotland. A formal
collaborative approach to the solution across the UK would ensure this consistency.
4.8 Person centric
The Scottish Government’s Route Map to the 2020 vision for health and social care (Ref. 5), aims to have
the person at the centre of all decisions. Health and care workers cannot provide person-centred, safe and
effective services to people without appropriate access to the quality information they need.
Patients however need assurance that their wishes regarding consent to share are being accurately
recorded and acted upon especially with the planned closer working across the health / social care
boundary. The capability to view and update their consent personally would give the assurance that it was
recorded correctly.
38 Updated Jan 2017
SPIRE Privacy Impact Assessment v3.1 Page 52 of 61 20-Feb-17
4.9 Patient Portals
The introduction of Patient Portals allows patients to access information on their health and, more
pertinently, maintain their own electronic information including the potential to record their consent wishes in
all care settings.
4.10 GP IT Re-provisioning Exercise
The GP IT Re-Provisioning exercise is current and the programme has been broken into two phases:
Phase 1 is focused on scope/requirements definition culminating in the creation of a Contract, Commercial
and Procurement Strategy and the creation of an Outline Business Case, now completed.
Phase 2 will be the Contract and Procurement Exercise which is forecast to commence in
November/December and culminate in new contract arrangements being available by September 2017.
These timescales present potential challenges in fully engaging with GP IT suppliers.
4.11 FairWarning
Nearly all Boards have now implemented or are about to implement privacy breach detection software,
Fairwarning39
. This has significantly assisted in the identification of potential breaches and has raised staff
awareness of inappropriate access to IT systems. Consideration should be given as to whether its use can
be extended to include access to any consent information structure, which could introduce a check as to the
validity of accesses in accordance with consent wishes.
5 Conclusion
The proposal to introduce archetypes to manage consent has potential for use in all the care settings
However, at this time (Oct 2015), there is not a strong enough business case for the development of
the consent model.
o Higher priority issues are not being progressed currently due to unavailability of resources
o There is no pressing demand for the implementation of this proposal from key potential
sponsors
It is therefore suggested that the next step should be to focus on the use of the archetype solution in
the medicines model to show proof of concept.
Thereafter other opportunities should be explored to demonstrate the flexibility of the approach
o The planned GP registration project could provide a mechanism to introduce the consent
model in the future
Note October 2016:
The recent procurement of a new electronic Master Patient Index (eMPI) to replace CHI raises other options.
This has the design potential and capacity to store a person's data-sharing consent choices, for reference by
any NHSScotland Accredited Business Systems when upgraded to interoperate with eMPI.
Once a person's consent choices are made, and available automatically to NHSScotland's ABS, many layers
of IG process and risk can be removed from routine clinical practice, with cumulative benefit at each data-
sharing use of the service for Direct Care.
SPIRE is an example of the benefit of wider use of the same routine data for Secondary Uses.
Interoperable consent systems are now being deployed in Belgium and The Netherlands40
, and are under
consideration in NHS England41
42
. Many issues of consent require further work, such as the methods for a
person to specify their own consent choices e.g. via My Account at www.mygov.scot, and the granularity of
these choices.
Such a consent-data-sharing infrastructure is a strategic requirement, after which systems may then be
configured to a granularity of consent as and when it is locally agreed.
39 However it was considered unsuitable for use in NSS
40 Forcare IHE platform
41 National Information Board's Domain J #33, 34 Public Trust and Security:
“We will provide the means for citizens to set their consent preferences. We will provide confidence that clinical and citizen information is held safely and securely and protect health and care systems from external threats.” 42
NIB_Annual_Report_NovA.pdf p28
SPIRE Privacy Impact Assessment v3.1 Page 53 of 61 20-Feb-17
Appendix 8: SPIRE Physical Security Overview
All data is stored on secure servers that have a planned backup regime with an agreed
frequency of restore points.
Standard approach is for a daily backup of any changes to the data to a separate location and
weekly full backup of all data.
Data is backed up to disc and, in addition there is a monthly back-up to tape.
The servers are physically located in data centres managed by Atos Origin as part of the NHS
Scotland National Contract which meets all NHS data security standards and is supported by
an SLA that meets the requirements set out in NHS Scotland Information Security Policy:
https://security.scot.nhs.uk/guidance/
Access to PID is controlled is restricted to people who have a role and purpose that requires
access to the data and the person has been given explicit approval by the data controller
through the User Access System.
There are no test or development systems with direct access to PID.
Physical access to NSS personal computers or workstations is restricted. All employees have
identification badges that are needed to pass through security gates to access the NSS
buildings. Any visitors are signed in and escorted at all times. Mobile devices such as laptops
or tablets are encrypted and employees need a pass-phrase to start up the device before using
two-factor authentication to remotely connect to the network. Guidance is given to all
employees regarding appropriate locations to access the network (usually another NHS or
government building or the employee’s home address).
Physical access to the data centres is limited and controlled through a change control process
requiring approval by a senior manager. Atos security will only permit access if the change
request is approved by a named senior manager and access to the building is controlled with a
unique access code and a physical fob.
Any change to the location of physical servers is approved through controlled programme of
work. Project documentation will include details of people involved in the move and map server
start and end location. All servers are hosted within Atos facilities. Moving servers is a rare
activity and needs engagement with all relevant stakeholders to ensure the arrangements
continue to meet the policies and standards.
Disposal of servers is strictly controlled and conforms to WEEE standards and the disposal
process ensures that there is certification of the secure destruction and disposal of all hard
disks. NSS servers are never sold or transferred to another organisation; all servers leaving
NSS will have the hard drive destroyed.
SPIRE Privacy Impact Assessment v3.1 Page 54 of 61 20-Feb-17
Appendix 9: SPIRE and NSS System Security standards
The ISO/IEC standards of the 27000 series are the most extensive Information Security standards
available. Caldicott's latest report43 on Data Security in the NHS describes them as "generally
regarded as too expensive and time-consuming."
Nonetheless SPIRE, as part of NSS44 meets or exceeds these standards in these sections:
Security Policy
Organisation of System Security
Asset Management
Human Resources
Physical and Environmental
Communications and Operations
Access Control
System Development
Incident Management
Business Continuity
More specific details are not appropriate here, but for guidance, the "10 Steps to Cyber Security"
framework, which Caldicott recommends as a minimum standard, has been updated by CESG, the
Information Security Arm of GCHQ: see Common cyber attacks: reducing impact
This is an overview of the controls contained in Cyber Essentials, and their implementation:
boundary firewalls and internet gateways - establish network perimeter defences, particularly web proxy, web filtering, content checking, and firewall policies to detect and block executable downloads, block access to known malicious domains and prevent users’ computers from communicating directly with the Internet
malware protection - establish and maintain malware defences to detect and respond to known attack code and methods e.g. ransomware delivered by phishing email
patch management - patch known vulnerabilities with the latest version of the software, to prevent attacks which exploit software bugs
whitelisting and execution control - prevent unknown software from being able to run or install itself, including AutoRun on USB and CD drives
secure configuration - restrict the functionality of every device, operating system and application to the minimum needed for business to function
password policy - ensure that an appropriate password policy is in place and followed
user access control - include limiting normal users’ execution permissions by enforcing the principle of least privilege45, and full logging of file-level accesses
These additional controls are set out in the 10 Steps to Cyber Security:
security monitoring - to identify any unexpected or suspicious activity
user training education and awareness - staff should understand their role in keeping the organisation secure and report any unusual activity
security incident management - plans in place to deal with an attack as an effective response will reduce the business impact
43 Caldicott: Data Security in the NHS Sn 1.14 p4
44 The SWAN network also is newly installed to modern security standards, for instance including frequent penetration testing
45 Principle_of_least_privilege
SPIRE Privacy Impact Assessment v3.1 Page 55 of 61 20-Feb-17
Appendix 10: SPIRE Pseudonymisation and Encoding paper The purpose of this note is to provide some background information to the discussion of pseudonymisation
and encoding of personal identifiable data within SPIRE.
It includes a description of the SPIRE Requirements, the SHIP Blueprint and the University of Nottingham
Open Pseudonymiser.
A. SPIRE Requirements
SPIRE data extracts may include personal identifiable data (PID) and may also use anonymised or
aggregated data. All SPIRE data extractions including PID must be agreed by the SPIRE Steering Group.
The SPIRE Business Requirements include the following requirements for the extraction, transfer and
storage of PID.
a) Personal Identifiers will be pseudonymised, after it leaves the GP clinical system but before it is
transported to the SPIRE Secure Storage Area (SSA.
b) Pseudonymisation will normally use the CHI number as the main patient identifier.
c) Pseudonymisation will be one-way or reversible.
d) To re-identify pseudonymised data which is reversible, an appropriate decryption key will be
required.
e) This decryption key will not be held or transported with the data.
f) All Personal Identifiers data will undergo further encryption before transport.
g) To decrypt Personal Identifiers data an appropriate decryption key is required
h) If patient data is re-identified in the SSA, then identifiable and non-identifiable data will be stored
separately.
i) Any decryption keys will be stored separately from the data in the SSA.
j) Access to the decryption keys will be limited to a set of named staff.
k) Use of decryption keys will be restricted to those purposes as agreed by the SPIRE Steering Group.
l) The default state for Personal Identifiers in the SPIRE SSA is that it will be remain encrypted with
analysts accessing a pseudonymised identifier.
One-way or Reversible Pseudonymisation
There are three reasons why SPIRE requires both reversible and one-way pseudonymisation.
1) There will be some SPIRE information requests which require the extraction of personal identifiable
data (PID). [All such requests must be scrutinised and agreed by the SPIRE Steering Group (SSG) in
advance to ensure that access to PID is justified before any data extraction is carried out].
The calculation of some derived data items in the SPIRE datasets will require access to Personal
Identifiers. Examples of these derived data items include patient age relative to a specific reference
date, geographical data items (e.g. data zone) and deprivation scores. The calculation of these
derived data items requires access to the full patient date of birth and postcode. Again, the process to
obtain these derivations will be encapsulated within a system process and will be inaccessible to
SPIRE users.
2) If SPIRE data is to undergo data linkage, then the pseudonymised CHI number for those data records
must be decrypted. For more information see “The SHIP Blueprint” below.
B. The SHIP Blueprint
All SPIRE information requests which originate from the research community will be channelled through the
Farr Institute. The SPIRE information team will only liaise indirectly with researchers through the Farr
research coordinators.
All SPIRE information requests which involve data linkage will use the SHIP Blueprint. This applies to all
information requests whether or not they originate from the research community. The indexing service for
the SHIP Blueprint requires access to personal identifiers and therefore all SPIRE data which requires data
linkage will need their pseudonymised CHI numbers decrypted prior to linkage.
Data linkage in the SHIP Blueprint protects personal data by partitioning the personal identifiers and the
‘payload’ data. The separation of the indexing service from the record linkage agent provides an additional
safeguard. The SHIP Blueprint publication can be found here.
SPIRE Privacy Impact Assessment v3.1 Page 56 of 61 20-Feb-17
A simplified summary of the data linkage process in SHIP is given below.
There are two steps to the process the Indexing Service and the Linkage Agent.
1. Indexing Service
Inputs:
Dataset A (Personal Identifiers, Project Identifier)
Dataset B (Personal Identifiers, Project Identifier)
Outputs:
Dataset A (Encrypted Pseudonymised Identifiers, Project Identifier)
Dataset B (Encrypted Pseudonymised Identifiers, Project Identifier)
2. Linkage Agent
Inputs:
Dataset A (Encrypted Pseudonymised Identifiers, Project Identifier, Payload Data)
Dataset B (Encrypted Pseudonymised Identifiers, Project Identifier, Payload Data)
Decryption Key (from Indexing Service)
Outputs: Linked Dataset (Project Id, Pseudonymised Identifiers, Payload Data)
The key features of this process are that the linkage agent doesn’t receive any personal identifiable data and
the Indexing Service doesn’t receive any payload data.
C. The Open Pseudonymiser
Open Pseudonymiser is an open source standalone application produced by Professor Julia Hippisley-Cox
at the University of Nottingham, to facilitate the safe encryption of personal identifiable data for data linkage.
The web site www.openpseudonymiser.org holds background information, documentation and the source
code for Open Pseudonymiser. A Windows and a Java implementation of the software are also available.
Open Pseudonymiser can be used in such a way that the agent carrying out the linkage and the
recipient of the linked data remain unaware of the identity of an individual during and after the
linkage process.
If Open Pseudonymiser is applied to maximise encryption, it will not be possible to reverse engineer
the linkage process and opportunistically relink data, even if one has access to all of the encrypted
base data and linked files.
Open Pseudonymiser uses the industry standard SHA-256 one way hashing algorithm.
The Open Pseudonymiser encryption process is strengthened by the addition of a ‘salt key’ which
means that the same identifiable data can be encrypted for two different purposes and the resulting
encrypted key (the ‘digest’) will be different for the same person. The personal data is the same but
the salt keys are different.
Salt keys can be plain text or encrypted. The University of Nottingham provides a salt key encryption
service which Open Pseudonymiser users can access to produce encrypted salt key files. This
provides a further layer of security.
Open Pseudonymiser software encrypts CSV files.
The following is a simplification of the algorithm implemented in the Open Pseudonymiser software:
1. read in the CSV data records
2. identify the personal identifiable data items which will be used to create the encrypted key
3. concatenate these personal identifiable data items together
4. append the salt key (either plain text or encrypted) to the concatenated personal data items
5. encrypt the resulting string using the SHA-256 algorithm to obtain the encrypted key
6. write out the data file which now consists of the encrypted key and the remainder of the record
(excluding the personal identifiable data items).
D A comparison of the SHIP Blueprint (used by SPIRE) and Open Pseudonymiser
Open Pseudonymiser SHIP Blueprint
Pseudonymisation Encoding by SHA-256 hashing Indexing function: allocating
SPIRE Privacy Impact Assessment v3.1 Page 57 of 61 20-Feb-17
Open Pseudonymiser SHIP Blueprint
algorithm pseudonymous identifiers (study
numbers) to replace personal identifiers
Avoidance of
opportunistic relinkage
Application of project specific
“salt” keys
Pseudonymous identifiers are project
specific
Minimising re-
identification of
individual persons
Repeated application of “salt”
keys. Separation of encoding
and linkage functions
Separation of indexing function and
linkage agent
E Detail of SPIRE Encryption and Data Linkage process
Encryption of
Personal
Identifiers file
Personal Identifiers file encrypted using PGP; this complies with industry standard.
when query published, SPIRE Central produces a Public/Private key pair in PGP format.
public key sent with query to Practice via eLinks.
private key sent via SFTP to Secure location in SSA for use by NSS.
at practice Personal Identifiers file is encrypted using public key.
if NSS need to decrypt Personal Identifiers file that is achieved by using the PGP private key.
access to private key restricted to those fulfilling role.
Pseudonymis
ation of CHI
(unique
patient
identifier)
when query published, SPIRE Central produces a Public/Private key pair in RSA format (produced at same time as Personal Identifiers encryption keys; so there are 2 pairs).
public key sent with query to Practice via eLinks.
private key sent via SFTP to Secure location in Secure Storage Area for use by NSS.
software creates CHI pseudonym using public key & replaces CHI number
if NSS need to decrypt CHI pseudonym, that is achieved by using the PGP private key.
access to private key restricted to those fulfilling role.
F SPIRE – CHI Pseudonymisation/PID File Encryption
Key Management
1. The pseudonymisation key pair and PID file encryption key pair are generated by SPIRE Central when
the query is created.
- Pseudonymisation keys are generated using RSA encryption with 2048 key bit length.
- PID file encryption keys are generated using PGP encryption with 2048 key bit length.
2. Public Keys sent to SPIRE Local with the query securely via eLinks.
3. Private Keys are placed in the appropriate directory of the SPIRE Secure Storage Area.
4. Further security is applied in that the PID file encryption keys themselves require credentials: when
creating the PID file encryption key pair, a username and passphrase are specified.
- when encrypting a file, the username must be specified.
- when decrypting a file the passphrase is required to access the private key.
5. For security reasons, no technical details of the username/passphrase are included here.
Bill Boyd 6 June 2014
Colin Brown, Eddie Adie, Jonathan Cameron updates 23 September 2016, 27 Jan 2017
SPIRE Privacy Impact Assessment v3.1 Page 58 of 61 20-Feb-17
Appendix 11: extract of specimen GP - SPIRE Data Sharing Agreement
Purpose This purpose of this document is to record an agreement between
GP Practices in NHSScotland
and
NHS National Services Scotland
Public Health & Intelligence Strategic Business Unit
That data specified below can be extracted for use in
the Scottish Primary Care Information Resource (SPIRE) system and
the development of SPIRE GP Reports.
This document is to be understood as
implemented in conjunction with the SPIRE Licence Agreement between GP Practices as Data Controllers, and MSDi as suppliers of software on behalf of SPIRE - see URL
read in conjunction with the SPIRE Privacy Impact Assessment or "PIA" to which reference is made by section or appendix - see URL
The control of a data extract from GP practice, and its subsequent processing, is outlined in this diagram,
and summarised below:
Data Extraction Data that may be extracted is listed in Appendix 1 of the PIA, which describes the maximum contents of the
GP Reporting Database retained at each practice.
Items in bold are those considered Personal Identifiers and are pseudonymised, as described below and at
PIA Section 1.3B and 3.3.
Potentially, any of these fields could be extracted by SPIRE; however in most extracts only a subset of the
items will be extracted, which will be detailed within the SPIRE query sent to each practice to be relevant,
proportionate and necessary to inform or answer each query.
SPIRE Privacy Impact Assessment v3.1 Page 59 of 61 20-Feb-17
Before data are transferred, each GP Practice is the Data Controller.
NHS National Services Scotland (NSS) becomes the Data Controller whilst the data is in transfer via eLinks
and when data reaches the Secure Storage Area in NSS; thereafter only processing data in line with details
of the application agreed by the SSG and by GPs when they consent to the extract.
Data extracts use “SPIRE Local” software (see figure above) which is installed at each practice in Scotland.
Data will only be extracted if the following are in place:
the SPIRE Steering Group has approved the request to extract data: PIA appendix 6 if the request is from an approved researcher, and involves links to other data, then the application must
also be approved by the Public Benefit & Privacy Panel for Health &Social Care PIA section 3.1 GP practices give consent for the data extract, which is recorded electronically using SPIRE Local
software and: PIA section 1.6 if the data extract includes any personal identifiers, patients have had the opportunity to opt-out of
SPIRE extracts: PIA section 1.6
A SPIRE query is developed using “SPIRE Central” software (see figure above) installed at NHS National
Services Scotland (NSS). That query is published to practices included in the data extract request and
becomes visible to those practices within SPIRE Local.
The query also contains details of the data extract including:
data to be extracted
why the extract is needed
the start and end dates between which data is to be extracted
whether the extract is recurring (e.g. monthly); and
for how long the data will be retained before being destroyed.
If the data extract includes any personal identifiers then, before leaving the practice, the data extracted is
split into two separate files: (a) personal identifiers and (b) clinical data or "payload" that is effectively
anonymised, or "pseudonymised" ‘The file containing personal identifiers is then encrypted before being
transferred to NSS (see figure above).
SPIRE Local software provides practices with a facility to review the content of any extract, should they so
wish, before deciding whether to give consent for the extract to be submitted. . Once the extract is complete,
the practice can choose whether to submit to NSS46
.
So that patients can make an informed choice on whether to opt-out of SPIRE, a public information
campaign including media adverts and information in public places will take place before any data are
extracted: PIA section 1.6
Data Transfer When practices consent to an extract, data will be transferred at a time known only to NSS to the Secure
Storage Area (SSA) in NHS National Services Scotland (NSS) over the NHS SWAN network using eLinks,
the standard method already in use to transfer data from practices (e.g. data for registration at PSD, for the
Emergency Care Summary or for QOF). All files are encrypted whilst in transfer to NSS via eLinks.
Data Storage and Access Data extracts for service management will be stored on a secure server within NSS.
Access to this data will be restricted to a limited number of NSS staff, with multiple levels of security to
govern their access : PIA sections 3.2 and 3.5
SPIRE Privacy Impact Assessment v3.1 Page 60 of 61 20-Feb-17
For each SPIRE extract, only the staff individuals required to manage and analyse data will be given access.
If personal identifiers are included, these are stored in an encrypted file, separate from the non-identifiable
data; no individual staff will have access to both files.
A list of those staff with access to SPIRE data extracts will be maintained, so that
Advanced Access Assurance will be in place for all SPIRE data: PIA appendix 5B
Data extracts for research will be stored in the NSS National Safe Haven and further information is available
here: Use-of-the-National-Safe-Haven
Data Use Data will only be used for the purposes laid out in the applications submitted to the SPIRE Steering Group:
PIA section 3.1, appendix 6
These purposes will be included within the SPIRE query that is sent to practices as part of each request for
an extract.
Data will only be retained for the minimum time necessary to allow the original purpose of the extract to be
met, which must be clearly stated within the application process. PIA section 5
Anonymised aggregated datasets and graphs will be published on the NSS website in the same manner as
the previous QOF data (ref)
Cluster and NHS Board reports will only be sent to NSS' Secure Storage Area with the consent and approval
of each GP practice and these will only be available to the relevant clusters and NHS Boards. Comparative
reports may be developed but practices will have the option whether to participate in these or not.
Researchers e.g. from the pharmaceutical industry will have access to aggregated datasets published on the
website. Any other requests will only be available if they are partners of accredited academic partners of
NHS organisations: PIA sections 3.1, 3.2
All presentations and publications based on SPIRE data, will acknowledge (in general terms) the work of the
GPs, practice nurses and others in the Primary Care team as appropriate e.g. smoking cessation services,
exercise referral scheme, pharmacy compliance scheme, who have contributed to data collection as part of
the structured care of the patients.
SPIRE will support and promote legitimate access to the information and ensure the widest use of these
invaluable data for the benefits of healthcare and research.
Data Governance The full Privacy Impact Assessment also describes
how the SPIRE Steering Group (SSG) oversees data extraction through SPIRE, and the roles and
remit of the SSG and PBPP are outlined in PIA appendix 6
privacy risks, and their mitigations by technical security, staff training or other governance methods
PIA section 3
patient’s rights and how SPIRE manages consent, objections, access requests, enquiries and
complaints PIA section 1.6
policies and procedures for data retention and for managing data loss or data breach
PIA sections 3.8, 5
the legal implications of sharing this data: PIA sections 1.3, 1.7 and appendix 3
SPIRE Privacy Impact Assessment v3.1 Page 61 of 61 20-Feb-17
Appendix 12: examples of Secondary Uses of data (adapted from CRDB47)
Checking quality of care
ensuring the needs of patients within special groups are being met e.g. children at risk, chronically
sick, frail and elderly.
testing the safety and effectiveness of new treatments
comparing the cost effectiveness and quality of treatments in use
clinical audit
supporting national audit studies for cancer, heart disease, diabetes, etc; and
comparative performance analysis across primary care clusters and other clinical networks,
Protecting the health of the general public
identifying groups of patients most at risk of a condition that could benefit from targeted treatment or
other intervention
monitoring the incidence of ill health and identifying associated risk factors,
surveillance of disease and exposures to environmental hazards or infections and immediate
response to detected threats or events
analysis of outcomes following public health interventions
linking with existing national registries for diseases / conditions
vaccine safety reviews
drug surveillance (pharmacovigilance) and other research-based evidence to support the regulatory
functions of the Medicines and Healthcare products Regulatory Agency;
safety monitoring of devices used in healthcare e.g. by Scottish Health Technologies Group
Managing the Health Service
measurement of clinical indicators
capacity and demand planning
work force planning
information for standards and performance setting and monitoring
evidence to support the work of the National Institute for Health and Clinical Excellence
measuring and monitoring waiting times, in support of the 18 week target
data to support productivity Initiatives (e.g. the GP and Consultant contracts)
Agenda for Change
Supporting research
assessing the feasibility of specific clinical trials designed to test the safety and/or effectiveness
and/or cost-effectiveness of healthcare interventions
identification of potential participants in specific clinical trials, to seek their consent
providing data from routine care for analysis according to epidemiological principles, to identify
trends and unusual patterns indicative of more detailed research
providing specific datasets for defined approved research projects
Managing NHS spending
information for resource allocation
information for management by locality such as GP clusters, and
information for payment of GPs using aggregated Transitional Quality Arrangement (was QOF)
indicators
Investigating complaints about healthcare
Information to support or refute complaint
Teaching healthcare workers
information to support teaching materials