Privacy Impact Assessment and Project Overview …...2017/02/24 · 2.2 Appendices re-configured Colin Brown Yes 2.3 Revisions throughout Colin Brown Maureen Falconer Yes 2.4 Revisions

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


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

mailto:[email protected]


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


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


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


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


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

https://ico.org.uk/media/for-organisations/documents/1595/pia-code-of-practice.pdf

http://www.ncl.ac.uk/kite/assets/downloads/root.htm

http://www.ncl.ac.uk/kite/assets/downloads/conversation1.htm


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).


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".


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


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?

http://www.bcs.org/upload/pdf/fair-shares-for-all.pdf

http://www.farrinstitute.org/public-engagement-involvement/what-is-health-informatics-research


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.


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

http://www.nhsinform.co.uk/


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

http://www.mygov.scot/myaccount


http://www.digitalhealth.net/news/22930/call-for-electronic-consent-for-secondary-uses

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/535024/data-security-review.PDF

https://wellcome.ac.uk/sites/default/files/public-attitudes-to-commercial-access-to-health-data-wellcome-mar16.pdf

http://onlinelibrary.wiley.com/doi/10.1111/bioe.12286/full

http://www.bmj.com/content/348/bmj.g1294

https://www.openhealthhub.org/uploads/default/original/1X/a9e238d54a38b38928ac7cff2bee947f242729b6.pdf


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

http://www.legislation.gov.uk/sdsi/2013/9780111020623

http://www.xml-solutions.com/a-proposed-consent-model/


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.

http://www.scot-ship.ac.uk/


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

http://www.ehealth.nhs.scot/resources/standards-library/

http://www.ehealth.nhs.scot/resources/standards-library/


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

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1789749%20


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

http://www.openpseudonymiser.org/Default.aspx

http://www.researchone.org/about/

http://www.saildatabank.com/

http://www.ucl.ac.uk/pcph/research-groups-themes/thin-pub/database

https://www.cprd.com/governance/

http://www.sapior.com/news/safemerge-v2-released/


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.


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.


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

https://www.igtt.hscic.gov.uk/igte/index.cfm

http://byglearning.co.uk/mrcrsc-lms/course/category.php?id=1

https://adrn.ac.uk/getting-data/researcher-training/sure-training/


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


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

http://en.wikipedia.org/wiki/Principle_of_least_privilege

http://www.isdscotland.org/About-ISD/Confidentiality/Disclosure-Protocol-Version-2-3_webversion.pdf

https://ico.org.uk/for-organisations/guide-to-data-protection/anonymisation/


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.

http://spire.scot/professional/safeguards/supplementary



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.


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.


assess the personal information

remains up to date? If so how?

Yes, see above 4.1.


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.

http://genss.nss.scot.nhs.uk/pls/portal/url/ITEM/18863D7F37985E98E0440003BA08EF28


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)


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

http://www.spire.scot.nhs.uk/


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


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*


Appendix 2a: SPIRE Extract and Processing Overview


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


Etc. Etc. Etc. Etc



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



Etc. Etc. Etc. Etc


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


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.


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.


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.

http://www.isdscotland.org/About-ISD/Confidentiality/disclosure_protocol_v3.pdf


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

http://www.isdscotland.org/Products-and-Services/EDRIS/FAQ-eDRIS/index.asp#h1

http://www.gov.scot/Topics/Statistics/datalinkageframework/GuidingPrinciples

http://www.isdscotland.org/isd/files/The%20Scottish%20Record%20Linkage%20System.doc

http://www.farrinstitute.org/public-engagement-involvement/what-is-health-informatics-research


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

http://www.legislation.gov.uk/sdsi/2008/9780110815039/pdfs/sdsi_9780110815039_en.pdf

http://www.legislation.gov.uk/sdsi/2013/9780111020623

http://www.gov.scot/Topics/Health/Policy/Public-Health-Act

http://www.gov.scot/Topics/Health/Policy/Adult-Health-SocialCare-Integration/About-the-Bill


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.


Appendix 4: Patient Opt-out Form Final


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.


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





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.

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1789749%20


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.

http://www.spire.scot/professional/safeguards/steering-group/

http://www.informationgovernance.scot.nhs.uk/pbpphsc/

http://www.informationgovernance.scot.nhs.uk/pbpphsc/home/about-the-panel/

http://www.informationgovernance.scot.nhs.uk/pbpphsc/wp-content/uploads/sites/2/2015/04/Guiding-Principles.docx

http://www.informationgovernance.scot.nhs.uk/pbpphsc/wp-content/uploads/sites/2/2015/04/Application-Form.docx

http://www.scot-ship-toolkit.org.uk/roles-and-responsibilities/chiag

http://www.nhsnss.org/pages/corporate/privacy_advisory_committee.php

http://www.knowledge.scot.nhs.uk/caldicottguardians.aspx


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


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


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


https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/192572/2900774_InfoGovernance_accv2.pdf

http://www.gmc-uk.org/guidance/good_medical_practice/continuity_care.asp

http://www.ehealth.scot.nhs.uk/strategies/



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


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.


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:


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


Dissent Explicit Explicit Explicit

Dissent Dissent Dissent


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


Consent Explicit Explicit Implicit


Dissent Explicit Explicit Explicit


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


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


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


http://www.forcare.com/ihe-platform

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/433177/NIB_WS_4.pdf

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/572415/NIB_Annual_Report_NovA.pdf


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.

https://security.scot.nhs.uk/guidance/


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

http://www.cesg.gov.uk/white-papers/common-cyber-attacks-reducing-impact

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/535024/data-security-review.PDF

http://en.wikipedia.org/wiki/Principle_of_least_privilege


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.

http://www.scot-ship.ac.uk/publications.html


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

http://www.openpseudonymiser.org/


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


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.


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


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

http://www.isdscotland.org/Products-and-Services/eDRIS/Use-of-the-National-Safe-Haven/


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

Documents

Privacy Impact Assessment and Project Overview …...2017/02/24 · 2.2 Appendices re-configured Colin Brown Yes 2.3 Revisions throughout Colin Brown Maureen Falconer Yes 2.4 Revisions