Purpose of this document

A data protection impact assessment (DPIA) is a useful tool to help organisations demonstrate how they comply with data protection law.

DPIAs are also a legal requirement where the processing of personal data is “likely to result in a high risk to the rights and freedoms of individuals”.

Definitions of specific terms used in this DPIA are included at Section 25.

NHS England (in this DPIA “we” and “our” refers to NHS England) has prepared and published this DPIA to describe generally the processing of personal data by the Federated Data Platform. NHS England reviews and maintains this DPIA regularly, and may update it periodically.

Scope

The Federated Data Platform (FDP) is a series of separate data platforms which we call “instances”. There are data platform Instances which are operated by NHS England, called “national instances”. There are separate data platforms instances which are operated by an NHS trust or an integrated care board in a local area, which we call “local instances”. These national and local instances of the Federated Data Platform work alongside privacy enhancing technology, which we call “NHS-PET”. NHS-PET records the data which is used in data platform Instances and can de-identify data where this is needed.

Each Instance of the Federated Data Platform uses the same underlying technology and software and has the same basic technical functionality. However, the Federated Data Platform uses the technology, software, and functionality in different ways for different purposes through what we call “products”. Some products are only designed for the national instances, some are only designed for the local instances, and some are designed to be used in both types of Instance.

Information about the FDP, including high-level deployment plans is made publicly available on the NHS England website.

1. Consultation with stakeholders

Seeking and understanding the views of stakeholders and the public and patients is an integral part of the NHS Federated Data Programme (FDP Programme). There is a regular programme of engagement supported by a number of formal advisory groups that form part of the programme governance. These include:  

• FDP check and Challenge Group. This group provides strategic advice to the FDP Programme on communications, engagement, and transparency. It considers patient, public, professional, and ethical context, and complements the Health Data Patient and Public Engagement and Communications Advisory Panel (PPECAP).  
• Health Data Public and Patient Engagement and Communications Advisory Panel. A panel consisting of public and patient members and representatives from national organisations who represent the views of the public. It supports the FDP FDP Programme to develop meaningful and accessible public communications.   
• External Information Governance (IG) Advisory Group. A group of external stakeholders with subject matter expertise in data and information governance. 
• The Data Governance Group. A national group established by NHS England to provide oversight to the approach to data processing and sharing across all Instances of the Federated Data Platform and NHS-PET which will include membership from across FDP User Organisations

Additionally, the FDP engagement portal, which is hosted on NHS England’s website, is a live tool to support the public to seek answers to their questions, provide feedback on the FDP Programme and to register their interest in future engagement activity.  

NHS England is committed to communicate and engaging with key stakeholders, the public, and patients in a meaningful way throughout the life of the FDP Programme. 

2. Data flow diagrams

The FDP allows organisations to hold and process data separately, while using common functionality, as shown below:

The flows of data into the FDP are shown below, with separate diagrams for national instances (NHS England) and local instances:

National instances

Local instances

Detailed data flow diagrams at each product level are contained within the separate product DPIAs.

All FDP instances are hosted in the UK and all dataflows in and out of the FDP start and finish in the UK.

3. Purpose of the processing

The Federated Data Platform (FDP) is a technology solution to support a variety of NHS organisations in the efficient delivery of their statutory functions, including delivering and supporting direct care. The FDP is made available for NHS organisations to use if they choose to do so. This is the purpose for which FDP user organisations process personal data in FDP (and for which commissioned health service Oorganisations may use FDP, if permitted).

The FDP is designed to be a common system that can be used by many different organisations. Each organisation has a separate space (called an “instance”), where their data is held securely, and separate from data belonging to other organisations.  The separate organisations are referred to as “FDP user organisations”, with each of those FDP user organisations retaining autonomy (and control over the identification of purpose) over the use of any data they choose to put in their Instance. 

As set out in Section 0, where NHS England is the FDP user organisation, this may be referred to as the “national instance” of FDP.  For all other FDP user organisations, the instances may be referred to as “local instances” of FDP.

The FDP enables FDP user organisations with an Instance to process data for the following five use cases:​

1. elective recovery – to get patients treated as quickly as possible, reducing the backlog of people waiting for appointments or treatments, including maximising capacity, supporting patient readiness and using innovation to streamline care
2. care coordination (joining up care) – to ensure that health and care organisations all have access to the information they need to support the patient, enabling care to be coordinated across NHS services
3. vaccination and immunisation – to ensure that there is fair and equal access, and uptake of vaccinations across different communities
4. population health management (planning NHS services) – to help local trusts, Integrated Care Boards (on behalf of the integrated care systems) and NHS England proactively plan services that meet the needs of their population
5. supply chain management (getting the best value for the NHS) – to help the NHS put resources where they are needed most and buy smarter so that we get the best value for money

FDP user organisations will use the FDP initially through products, each product being linked to one or more of the use cases. The FDP will help provide NHS staff (frontline clinicians, operational staff, and planners) with timely information and insight, promoting the efficient use of resources to support the delivery and planning of patient care.

FDP functionality is classified as 13 core capabilities which are:

• distribution
• citizens Invite
• cohorting
• load balancing
• remote monitoring interface
• patient comms interface
• pathway management
• scheduling
• medicines and equipment ordering
• supply chain management
• forecasting, monitoring and evaluation
• data enrichment
• data cleansing

Where these capabilities are used in a product, this will be described in the relevant product DPIA.

For trusts, the ambition is that the FDP will enable users to undertake data analysis and access applications designed to support and enable planning, pathway management and direct care. ​

At ICB level, the FDP will support population health management, tackling health inequalities and care coordination, enabling integrated care systems (ICSs) to respond to a more comprehensive and detailed understanding of their populations, supporting a targeted, more effective use of resources and planning services around the needs of their population.

The national instance of FDP will improve the flow and analysis of reporting data. As a consequence, there will be a reduction in burden through the change from multiple systems using aged technology (e.g. Excel), and enhanced security and transparency. This will give NHS England teams more accurate and near-real-time data to undertake strategic and operational planning.​

The FDP information governance (IG) framework has been created to enable the management of the IG workflow for FDP.

The FDP IG Framework sets out minimum IG requirements to be applied in the implementation and operation of FDP, with the aim of ensuring a consistent approach and high standard of IG and transparency across the FDP User Organisation community. This framework includes: 

1. working within the contractual documentation associated with the FDP Programme. The FDP IG Framework identifies these and sets out how they work together.
2. clearly identifying the various parties involved in delivering the FDP Programme, explaining their data protection roles and setting out their IG responsibilities.
3. laying out the core IG principles of the FDP Programme.
4. identifying the IG documentation that will be required to be put in place and who is responsible for producing and supporting the production of the documentation.
5. setting out the procedure for reporting Security Breaches and Personal Data Breaches relating to data processed in the FDP.
6. setting out how requests under the Freedom of Information Act 2000 will be handled.
7. setting out the governance arrangements relating to how the parties will work together and the various governance groups to be established to facilitate those arrangements. This includes the Data Governance Group and the NHS FDP System IG Group referred to above. More details about the group can be found within the FDP IG framework
8. identifying the supporting IG documentation for the FDP Programme and where it can be accessed
9. explaining how the framework will be reviewed, changed and published to provide transparency over the FDP IG Framework

4. Identification of risks

NHS England has in this section identified inherent risks of FDP data processing and potential harm or damage that it might cause to individuals whether physical, emotional, moral, material or non-material e.g. inability to exercise rights; discrimination; loss of confidentiality; re-identification of pseudonymised data, etc.

This section is used to detail the risks arising from the proposed processing data if there are no steps in place to mitigate the risks. The sections below then set out steps taken to mitigate the risks followed by a second risk assessment which considers the residual risk once the mitigation steps are in place. 

5. Approach to risk

Documentation

Where data is processed in FDP, the data will be processed in products, inside an instance of the Federated Data Platform. The data protection risks associated with processing data are considered through a suite of risk assessments (DPIAs).

This DPIA is the overarching DPIA for the FDP,  including an overview of the generic system functionality required for integrating, managing, and operationalising data, describing the risks and mitigations associated with the Federated Data Platform which are relevant across any FDP instances. This approach should mean that common elements do not have to be described in the ontology DPIA and separate product DPIAs to be carried out.

The FDP uses a data model, referred to as an ontology. This model defines the tables, schemas and definitions of various NHS concepts such as “patient” and “encounter”. When the model is deployed in an instance, an ontology DPIA or product DPIA will assess the particular data processing to populate the model, as further described in section 7.

Each FDP user organisation should also consider risks through the use of products. Product DPIAs assess the risk in relation to specific processing activities. Each product will have its own DPIA, and when a product is deployed to an instance the FDP user organisation should consider the associated risks as they relate to their use of the product in their own Instance.

DPIAs will evolve over time to reflect the enhancements and development in core functionality, development of products and additional FDP user organisations. They are not static. This DPIA will therefore also evolve over time.

6. Description of the processing

The processing of data within FDP will be described in seven broad categories:

• data ingress (data arriving into the FDP)
• data transfer (data flowing between FDP instances)
• data egress (data leaving the FDP)
• data platform services (tools provided to enable data processing within the FDP)
• data linkage and analysis (data used within the FDP)
• auditing
• detailed processing

Data ingress (data landing into the FDP)

Personal data (including confidential patient information) can arrive in FDP instances via direct connection to source systems via REST APIs, HL7 streams, ODBC/JDBC connections, S3/ABFS sources, connections made to data warehouses, Secure FTP (SFTP) or MESH. FDP user organisations as controllers approve data ingress to FDP further to the FDP IG framework. All instances are hosted within cloud infrastructure. This aligns to the ‘cloud first’ policy for public sector IT introduced in 2013, endorsed by the National Information Board’s personalised health and care 2020 framework.

All personal data brought into the FDP will be registered through NHS-PET (there is a separate DPIA assessing risks in relation to NHS-PET). This registration process is documented elsewhere, but in summary the purpose is to provide transparency of what data is held within FDP. In future (but not in the initial deployment of FDP and NHS-PET), the NHS-PET will also “treat” data, de-identifying it as required (this DPIA will be updated before this occurs).

Any data landing in the FDP is limited to a specific instance until such time as it is transferred to another Instance (which in all cases is only with the approval of the relevant controller). Subject to the limitations of data use in the FDP (set out in the FDP IG framework). FDP user organisations are responsible for the data entering and leaving their instance.

Data transfer (data flowing between FDP instances)

Data, including personal data (including confidential patient information) can transfer between FDP instances without leaving the secure platform boundaries when authorised by the FDP user organisation (a copy of the data is created, this is not multi-user access to a single copy of data). 

Authorisation by the FDP user organisation is also subject to the appropriate governance arrangements being put in place for the transfer of any personal data (including confidential patient information), which includes data sharing agreements required under the FDP IG framework and any transfer being lawful under UK General Data Protection Regulation (GDPR) and the Common Law Duty of Confidentiality. Any transfer is subject to registration through NHS-PET, for transparency.

Data egress (data leaving the FDP)

Personal data (including confidential patient information) may leave an FDP instance via the same protocols and mechanism as ingress, subject to the FDP user organisation’s authorisation. In addition, industry standard APIs exist in FDP Instances to allow for egress of data by external systems when authorised. When authorised, external analytics tools used by FDP user organisations or with their permission can integrate with data in FDP, such as Tableau, Power BI, Excel and more. Any such use of data held within FDP but accessed from outside the Federated Data Platform must occur only where that processing is described by a product DPIA.

As described above, authorisation by the FDP user organisation is also subject to the appropriate governance arrangements being put in place for the transfer of any personal data (including confidential patient information), which includes data sharing agreements required under the FDP IG framework and any transfer being lawful under UK GDPR and the Common Law Duty of Confidentiality.

Data platform services (tools provided to enable data processing within the FDP)

The FDP provides tools to enable FDP user organisations to have access to their own individual Instance, and specific canonical data model (“CDM”), through the use of the data platform services (which include pipeline management; modelling and branching; and data and code versioning) to customise the data model via extensions appropriate to their deployment profile to enable the integration, management and operationalising of data.

A canonical model is a design pattern used to communicate between different data formats. Essentially: create a data model which is a superset of all the others (“canonical”) and create a “translator” module or layer to/from which all existing modules exchange data with other modules.

The FDP instance has a CDM, also referred to as the shared healthcare ontology, this model defines the tables, schemas and definitions of a various NHS concepts such as patient and encounter. When the model is deployed in the national instance, an ontology DPIA which will be published, will assess the particular data processing to populate the model. Local product DPIAs will describe the processing to populate local ontologies.

When the instance is configured, FDP user organisations can leverage the data platform services together with object layer services (including ontology manager, object monitoring, scenarios, actions and functions) to integrate data from third-party sources to a CDM which enables the systematic mapping of data to intuitive, operational NHS or FDP user organisation specific concepts.

Additionally, different types of data may be visible to individual users of the FDP, who may view that data, subject to role based access controls and purpose based access controls put in place by the FDP user organisation, for a specific purpose under one of the five use cases as detailed within a product DPIA. 

In line with the strict access controls in place, the information being displayed may be personal data which is directly identifiable data, pseudonymised data, anonymised data, aggregated data or operational data.

Data linkage and analysis (data used within the FDP)

Directly identifiable personal data may be linked with other directly identifiable personal data through the use of patient identifiers such as the NHS number, date of birth and postcode.

Pseudonymised data may be linked based on common pseudonyms, i.e. the direct identifiers have been replaced in a consistent manner across datasets, to allow linkage.

Specific analysis (including ad hoc analysis and reporting) will be detailed within product DPIAs, and must adhere to data protection principles, including using the minimum data necessary.

Auditing

Use of all FDP Instances will be audited, and logs will be held within the system.  The logs will enable troubleshooting activities and may be used to detect unusual activity within the system, or in the event of a suspected cyber incident or unlawful activity.

Audit logs containing details about user activities and data in the platform can be shared with the NHS Cyber Security Operations Centre (CSOC) operated by NHS England to enable monitoring and responses to unusual activity in the platform.

Users have access to their respective audit logs to enable monitoring of activities.

Detailed Processing

The canonical data model (CDM) is deployed to each FDP instance. As this is purely a model, there is no data at this point.

Products are developed using this model (to ensure consistency and ‘deployability’ between products).  Where a product requires data, the data must be present in the ontology. These products provide a wide range of capabilities ranging from dashboards and command centres for staff, alerting, data analysis tools, operational scheduling and data cleaning tools.

Any data ingested into FDP can be fully traced back from the product and canonical data model back to the original ingestion via the data lineage tool. Purpose based access control enforces that data ingested for a particular purpose, such as direct care, is only used for this approved purpose.

7. Compliance with the data protection principles

Compliance with the data protection principles, as set out in Article 5 of the UK General Data Protection Regulation, are addressed in this DPIA in the following sections: 

8. Describe the legal basis for the processing (collection, analysis or disclosure) of personal data?

The FDP is designed to be a common system that can be used by many different organisations, with each of those organisations retaining autonomy over the use of any data they choose to put there. Each organisation has a separate space (called an “instance”), where their data is held securely, and separate from data belonging to other organisations.  The separate organisations are referred to as “FDP user organisations”.

Data controllership in relation to local and national instances

• NHS England is the sole controller of the personal data which flows into and is processed within any approved products it chooses to use in the National Instance of FDP.
• Local FDP user organisations are the sole controllers of the personal data which flows into and is processed within any approved products they chose to use in their own local instance of the FDP, subject to what is said below regarding joint controllership.
• NHS England and each Local FDP User Organisation are Joint Controllers for design, governance, and service management of the Local FDP User Organisation’s Local Instances of FDP. This is because:
  • NHS England has procured, funds, broadly determines the parameters for use, and manages the security, of the Data Platform.
  • Local FDP User Organisations decide whether to use FDP, what Products to use, what data to commit to FDP and how to use it within these parameters.

NHS England and each Local FDP User Organisation are therefore Controllers for different aspects of how FDP operates at a national and local level, including in relation to their own FDP Instances. 

Controllership responsibilities between NHS England and FDP User Organisations are set out clearly in a Joint Controller table (at the end of this DPIA, and in the FDP IG Framework) and are agreed between NHS England and each Local FDP User Organisation further to the terms of the MoU through the contractual documentation they enter into. The essence of this arrangement will also be made publicly available in privacy material relating to the FDP so that this is readily and easily apparent to the public in line with Article 26 of UK GDPR.

The following explains firstly NHS England’s legal basis to procure and provide the FDP system, and then explains the likely legal basis for the processing of Personal Data within an Instance. In each case this will be specifically documented in the separate Product DPIAs and reflect the Processing of Personal Data within a Product.

NHS England’s legal basis to procure and provide the FDP

1. Statutory authority

NHS England has various statutory functions that enable it to procure and provide FDP for itself and for other FDP User Organisations. These include:

• Section 270 of the Health and Social Care Act 2012 (2012 Act), to establish and provide FDP for as a service to NHS Trusts and ICBs pursuant to NHS England’s power to supply services to any person and provide new services. The supply of FDP involves, and is connected with, the collection, analysis, publication or other dissemination of information.
• Section 13D of the National Health Service Act 2006 (NHS Act), as part of its duty as to effectiveness, efficiency.
• Section 13K of the NHS Act, as part of its duty to promote innovation.
• Section 1H(2) of the NHS Act as part of its duty under Section 1(1) to promote a comprehensive health service.
• Section 2(2) to do anything which is calculated to facilitate, or is conducive or incidental to, the discharge of any of its functions. Under Section 13Y of the NHS Act this expressly includes the power to enter into agreements.
• The duty under Section 253(1)(ca) to have regard, in the exercise of its functions, to the need to respect and promote the privacy of recipients of health services and of adult social care in England

1.2 Legal basis – NHS England

In relation to the procurement and provision of FDP for itself and for other FDP User Organisations, NHS England relies on the following legal basis:

Article 6 – personal data

Article 6 (1)(e): processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller by virtue of the statutory functions referred to above (public task);

Article 9 – special category personal data

Article 9(2)(g): processing is necessary for reasons of substantial public interest (public interest). Under section 10(3) of the Data Protection Act 2018 (DPA), this requires a condition in Part 2 of Schedule 1 of the DPA. NHS England relies on paragraph 6 (statutory purpose), as the processing—

• is necessary for the exercise of a function conferred on a person by an enactment or rule of law. Processing is necessary to discharge NHS England’s statutory functions set out above, and
• is necessary for reasons of substantial public interest. This is to enable the safe, secure, efficient processing of patient data to deliver more effective and efficient healthcare services.

Legal Basis for Processing Personal Data in each Instance of FDP

Where NHS England or an FDP User Organisation is Processing Personal Data and Special Categories of Personal Data, they will each separately as Controllers identify:

• a relevant condition for Processing under Articles 6 and 9 of UK GDPR and Schedule 1 of the DPA, and
• in relation to Confidential Patient Data, a legal basis under the Common Law Duty of Confidentiality.

This will be determined at a Product level for the Personal Data being processed through FDP and reflected in the relevant national or local Product DPIA and Product Privacy Notice. The likely legal basis are set out below:

1.3 Legal basis – FDP user organisation

Under Article 6, it is expected that the legal basis for Processing Personal Data in FDP would include:

• Article 6(1)(c) Legal Obligation, for example where NHS England collects and analyses data under a Direction.
• Article 6(1)(e) Public Task, for example where an FDP User Organisations Processes Personal Data for the purposes of providing an individual with care and treatment. Also where NHS England shares data with NHS Trusts or ICBs through the Platform relying on its powers to disseminate data under Section 261 of the 2012 Act.

Under Article 9, it is expected that the legal basis for Processing Special Categories of Personal Data in FDP would include:

• Article 9(2)(g) Public Interest,
• Article 9(2)(h) for medical diagnosis, the provision of health care, or the treatment or management of health care services and system (health care),
• Article 9(2)(i) for public health purposes (public health)
• Article 9(2)(j) for statistical purposes (statistical purposes)

Under Schedule 1 of the DPA it is expected the additional conditions of Processing Special Categories of Personal Data would include:

• paragraph 2 (health care),
• paragraph 3 (public health),
• paragraph 4 (statistical purposes), and
• paragraph 6 (statutory purpose).

1.4 Common Law Duty of Confidentiality

Under the Common Law Duty of Confidentiality where confidential data, including Confidential Patient Information (Confidential Patient Data) is Processed within FDP, it is expected it would be lawful because of:

• implied consent where the Processing of Confidential Patient Data in any particular circumstances is carried out for the purpose of the Direct Care of a patient.
• legal obligation, including:
  • under section 254 of the 2012 Act in relation to data that NHS England has been directed to collect and/or analyse pursuant to a direction issued by the Secretary of State for Health and Social Care (Direction) that may be processed in the national Instances for purposes covered by a Direction.
• Under section 259 of the 2012 Act in relation to data that NHS England has required is supplied to it by an FDP User Organisation in response to a data provision notice so that it can comply with its duty to collect and analyse data under a Direction. This may apply to data shared from a local to a national Instance.
• statutory authority which expressly sets aside the Common Law Duty of Confidentiality including:
  • Regulation 3 of the National Health Services (Control of Patient Information) Regulations 2002 (“COPI Regulations”)
• Regulation 5 of the COPI Regulations in relation to medical purposes approved by the Secretary of State with support from the Confidentiality Advisory Group, also known as an approval under Section 251 of the NHS Act 2006.

It is not expected that any Processing of Confidential Data within the FDP would rely on a public interest justification.

9. Demonstrate the fairness of the processing

Each FDP User Organisation is responsible for ensuring that the patient information in their FDP Instance is used fairly and transparently.  Because the specific uses of the data are determined by the FDP User Organisation, it is not possible for this DPIA to demonstrate the fairness of each specific use/ Product, this will be detailed within the specific Product DPIA’s

The high-level uses of the FDP (repeated below) have been developed through consultation with stakeholders:

1. Elective recovery (reducing waiting times) – to get patients treated as quickly as possible, reducing the backlog of people waiting for appointments or treatments which has resulted from the COVID-19 pandemic alongside winter pressures on the NHS.
2. Vaccination and immunisation – to ensure that there is fair and equal access, and uptake of vaccinations across different communities.
3. Population health management (Planning NHS services) – to help local NHS organisations to plan the right services, in the right places, for their local communities.
4. Care coordination (Joining up care) – to ensure that health and care organisations all have access to the information they need to support the patient, reducing the number of long stays in hospital and ensuring that everyone is cared for in the right place for them at the right time.
5. Supply chain management (Getting the best value for the NHS) – to help the NHS put resources where they are needed most and buy smarter so that we get the best value for money.

Where Directly Identifiable Personal Data, including Confidential Patient Information is used within the FDP (until such time as new activity is developed, and this DPIA is updated), it is for Direct Care only.

Where possible, Personal Data will be protected through the use of Pseudonymisation.

In all cases, where Personal Data is used within the FDP, it is the responsibility of the FDP User Organisation to ensure that there is sufficient transparency for the public, and that processing is both fair and lawful.

To assist FDP User Organisations with fulfilling their transparency obligations, NHS England publishes some information about the FDP, including information about the Use Cases. Until further Use Cases are developed and approved, processing of Personal Data within the FDP must only be carried out for the purposes of the initial five Use Cases.

Transparency needs to be achieved through a layered approach, describing various topics at a high level (such as FDP, NHS-PET, National and Local Instances, National and Local Products, etc.), alongside a more detailed FDP Privacy Notice, and more specific Product Privacy Notices. NHS England will be publishing this information on its website and Local FDP User Organisations will also need to publish appropriate transparency information on their websites.

10. What steps have you taken to ensure individuals are informed about the ways in which their personal data is being used?

In establishing the way in which the FDP will be delivered and operate for the NHS, there has been on-going engagement with several stakeholder groups (see “Consultation with Stakeholders” section) to co-design the approach to transparency.  This has ensured that FDP has taken a privacy-by-design approach, ensuring that the views of the data subjects have been included in the design of the FDP IG Framework and associated documentation.

NHS England will publish overarching generic information about the use cases, and about the FDP, as mentioned in the previous section.  In addition, NHS England is an FDP User Organisation in its own right, and has a responsibility to be transparent about processing within the NHS England Instance of FDP. NHS England is also therefore publishing a General FDP Privacy Notice, and separate Product Privacy Notices for every national and local Product on its website.

NHS England has taken a layered approach to providing the public with transparency information and UK GDPR required privacy notice information. The diagram below describes the approach that has been taken:

FDP Programme: privacy notice and transparency information suggested approach based on user research

Additionally, each Product will be approved by the Data Governance Group (with membership from across FDP User Organisations) and template approved IG documentation will be made available to any FDP User Organisation who wants to use the Product. This Product template documentation will include a DPIA and Level 4 Product Privacy Notice.

Each FDP User Organisation is responsible for its own data protection obligations, and any generic templates (provided to improve consistency, transparency, and understanding) may be altered or the information presented in other formats by an FDP User Organisation.

NHSE FDP Programme will be issuing regular FDP communications to be clear to the public about the approach to the roll out of the FPD Programme, what data is being processed for what purposes as products evolve, how FDP works and how privacy is protected, including how NHS-PET works, particularly when PET starts treating data later in 2024.

11. Is it necessary to collect and process all data items?

12. Describe if personal datasets are to be matched, combined or linked with other datasets? (internally or for external customers)

Datasets will be matched/combined/linked within FDP. Any such use of data will be described in Product DPIAs.

In general:

• Linkage may occur through data which is not directly Personal Data, but relates to other factors (e.g. linkage of data relating to a common location).
• Directly Identifiable Personal Data may be linked with other Directly Identifiable Personal Data through the use of direct patient identifiers,g. NHS Number.
• Pseudonymised Data may be linked based on common pseudonyms, i.e. the direct patient identifiers have been replaced in a consistent manner across datasets, to allow linkage but to protect Personal Data by preventing re-identification of individuals without additional information/resources.

Specific analysis will be detailed within Product DPIAs, and must adhere to data protection principles, including using the minimum data necessary.

13. Describe if the personal data is to be shared with other organisations and the arrangements you have in place

The FDP functionality allows for data to be transferred between Instances, or to be taken away from the FDP (Egress).

Any such transfer/flow will be subject to the FDP User Organisation’s approval, its governance processes, there being a legal basis, audit within FDP, and registration by the NHS-PET.

14. How long will the personal data be retained?

Retention of Personal Data within an Instance is subject to the FDP User Organisation’s policies.  Each Product may have a unique data retention period, this will be set by the FDP User Organisation and articulated within the Product DPIA.  

Each FDP User Organisation must abide by their own Records Management Policies and Retention Schedules, in compliance with the NHS Records Management Code of Practice 2021.

15. Where you are collecting personal data from the individual, describe how you will ensure it is accurate and if necessary, kept up to date

The FDP will not be directly collecting data from patients.

All FDP User Organisations are responsible for adhering to data protection law requirements such as transparency and maintaining accurate records.  There may be additional requirements around clinical record-keeping.

16. How are individuals made aware of their rights and what processes do you have in place to manage such requests?

Awareness

All FDP User Organisations must:

1. have the relevant policies and procedures to ensure that data subjects understand their rights in relation to their data.
2. have the policies and procedures in place to be able to answer any subject rights requests.

Process

All individual rights requests should be considered by the relevant Controller, i.e. NHS England do not have a central co-ordinating role.  If a request is received by the FDP Platform Contractor, it will be passed to the relevant FDP User Organisation(s).

FDP User Organisations will follow their own internal processes for determining how to progress with any rights request.  If this results in action being required within the FDP, then the FDP User Organisation will inform the FDP Platform Contractor to take the appropriate action (such as provision, amendment or deletion of information).

The general (Level 2) FDP Privacy Notice provides general information about an individual’s rights under UK GDPR and the specific (Level 4) Product Privacy Notices identify which rights apply to the data processed in the Product.  

17. What technical and organisational controls for “information security” have been put in place?

Encryption and security:

All data stored in the FDP will be protected via industry good practice layers of protection including encryption at rest and transit, regular penetration testing, firewall, anti-virus and intrusion protection.

The central data platforms are penetration tested to provide assurance and confirmation that all data is secure in accordance with an agreed schedule.

Both the FDP Platform Contractor and the national Cyber Security team will monitor technical systems for signs of suspicious activity.

All access to the FDP must be authenticated using Multi-Factor Authentication (MFA). Each FDP Instance can integrate with the FDP User Organisation’s chosen Single Sign-On (SSO) provider, commonly NHSmail. MFA must be enforced by the SSO provider via either smartcard, application based, hardware token, or phone based.

FDP utilises Role Based Access Controls and Purpose-Based Access Control to ensure all access to data for users is approved and with justification. Access of individual users and groups of users can be audited at any time by the FDP User Organisation to view when, why and how access was approved. The FDP User Organisation remains fully in control of data access and must approve any requests for access to data to enable the relevant processing or support.

Purpose-Based Access Control enforces that data ingested for a particular purpose, such as Direct Care, is only used for this approved purpose. Information on what data is being ingested, and the associated purpose, can be viewed in FDP and NHS-PET by the FDP User Organisation.

More detail on Purpose-Based Access Controls is available within Part 2 of Schedule 3 of the FDP IG Framework.

Further detailed system and technical level security policies apply, which are not published.

18. In which country/territory will personal data be stored or processed?

All processing of patient information will be within the UK only. This is a contractual requirement and one of the key principles of the FDP IG Framework. This is enforced through technical controls within FDP.

19. Do Opt Outs apply to the processing?

There will be a wide range of Products available for use within the FDP by FDP User Organisations.

National Data Opt Out

The National Data Opt-Out provides an individual with a right to opt out of their Confidential Patient Information being used for purposes beyond their Direct Care, unless an exemption applies under the National Data Opt-Out Operational Policy Guidance.

At the start of the Transition Phase of the FDP Programme there are no existing Products where the National Data Opt Out would be applicable because:

• No Confidential Patient Information is being processed by a Product in the National Instances of FDP to which the National Data Opt-Out would apply.
• Confidential Patient Information that is being used in the FDP in a Product in a Local Instance is only being used for the purposes of Direct Care and therefore the National Data Opt-Out does not apply.

Product DPIAs and (Level 4) Product Privacy Notices will explain why the National Data Opt Out does not apply.

Type 1 Opt Outs

A Type 1 opt-outs registered with a GP Practice prevents an individual’s confidential patient information from being shared outside of their GP Practice except when it is being used for the purposes of their individual care.

At the start of the Transition Phase of the FDP Programme there are no existing Products where Type 1 Opt Outs would be applicable because:

• No Confidential Patient Information that has come from a GP Practice is being processed by a Product in the National Instances of FDP.
• Any Confidential Patient Information that has come from a GP Practice which is being used in the FDP in a Product in a Local Instance is only being used for the purposes of individual care.

Product DPIAs and (Level 4) Product Privacy Notices will explain why the Type 1 Opt Out does not apply.

Future changes

If this changes in the future because a new Product processes Confidential Patient Information in a way which would mean that one of the above opt-outs would apply, the relevant FDP User Organisation would be responsible for ensuring that the opt-out was applied, the relevant (Level 4) Product Privacy Notice would identify this and the general (Level 2) FPD Privacy Notice and general (Level 1) transparency information would be updated to make this clear.

It is a core principle of the FDP IG Framework and also a contractual obligation of the suppliers of both FDP and NHS-PET that National Data Opt-Outs and Type 1 Opt Outs are respected and applied where they should be applied.

20. Risk mitigation and residual risks

The “identification of risks” section of this DPIA sets out the inherent risks arising from the proposed data processing. This section summarises the steps to mitigate those risks (which are explained in detail above) and assesses the residual risks, i.e. the level of risk which remains once the mitigations are in place.

Against each risk that have been identified, record the options/controls you have put in place to mitigate the risk and what impact this has had on the risk. Make an assessment as to the residual risk.

Also indicate who has approved the measure and confirm that responsibility and timescales for completion have been integrated back into the project plan.

Download a copy of the risk mitigation table.

21. Actions

NHS England through FDP Programme governance and management arrangements regularly reviews this DPIA and identifies and manages to completion actions to ensure it is accurate and updated.

22. Definitions

Definitions which may be useful in the review of this document.

• Aggregated data: Counts of data presented as statistics so that data cannot directly or indirectly identify an individual.
• Anonymisation anonymisation: involves the application of one or more anonymisation techniques to personal data. When done effectively, the anonymised information cannot be used by the user or recipient to identify an individual either directly or indirectly, taking into account all the means reasonably likely to be used by them. This is otherwise known as a state of being rendered anonymous in the hands of the user or recipient.
• Anonymised data: Personal data that has undergone anonymisation.
• Anonymous data: Anonymised data, aggregated data and operational data.
• Approved use cases: Means one of the five initial broad purposes for which Products in the Data Platform can be used as outlined in the FDP IG Framework (Part 1 of Schedule 2 (Approved Use Cases and Products)), or any subsequent broad purpose agreed to be a use case through the Data Governance Group.
• Commissioned Health Service Organisations: Means organisations who provide health services in England pursuant to arrangements made with an NHS Body exercising functions in connection with the provision of such services.
• Common Law Duty of Confidentiality: The common law duty which arises when one person discloses information to another (e.g. patient to clinician) in circumstances where it is reasonable to expect that the information will be held in confidence.
• Confidential patient data: Information about a patient which has been provided in circumstances where it is reasonable to expect that the information will be held in confidence, including Confidential Patient Information.
• Confidential patient information: Has the meaning given in section 251(11) of the National Health Service Act 2006. See Appendix 6 of the National Data Opt Out Operational Policy Guidance for more information .
• Controller: Has the meaning given in UK GDPR being the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the Processing of Personal Data (subject to Section 6 of the Data Protection Act 2018)
• Data Governance Group: Means a national group established by NHS England to provide oversight to the approach to data Processing and sharing across all Instances of the FDP and NHS-PET which will include membership from across FDP User Organisations
• Data platform: The NHS Federated Data Platform
• Data Security and Protection Toolkit (DSPT): The Data Security and Protection Toolkit is an online self-assessment tool that FDP User Organisations are required to complete annually to demonstrate they are meeting required data protection and security standards
• Direct care: A clinical, social, or public health activity concerned with the prevention, investigation and treatment of illness and the alleviation of suffering of individuals. It includes supporting individuals’ ability to function and improve their participation in life and society. It includes the assurance of safe and high-quality care and treatment through local audit, the management of untoward or adverse incidents, person satisfaction including measurement of outcomes undertaken by one or more registered and regulated health or social care professionals and their team with whom the individual has a legitimate relationship for their care.
• Directly identifiable personal data: Personal Data that can directly identify an individual.
• DPIA: Data Protection Impact Assessments in a form that meets the requirements of UK GDPR
• FDP: Federated Data Platform
• FDP IG framework: The FDP IG Framework attached at section 27 (as the same may be updated from time to time) has been created to enable the management of the information governance (IG) workflow for FDP.
• FDP Programme: The NHS England Programme responsible for the procurement and implementation of the FDP across the NHS
• External IG advisory group: The advisory group established by NHS England to provide specialist IG advice to the FDP Programme which includes membership from external organisations including the Office of the National Data Guardian and the Information Commissioner’s Office
• FDP user organisations: NHS England, ICBs, NHS trusts and other NHS bodies (including a commissioned health service organisation) who wish to have an instance of the FDP.
• General FDP privacy notice: A privacy notice providing information on the Personal Data Processed in the FDP and by NHS-PET generally, including the Approved Use Cases for which Products will Process Personal Data.
• ICB: Integrated care board
• ICS: Integrated care system
• Instance: A separate instance or instances of the FDP deployed into the technology infrastructure of an individual FDP user organisation
• Joint controller: Has the meaning given in UK GDPR, being where two or more Controllers jointly determine the purposes and means of Processing Personal Data
• Joint controller arrangement: Has the meaning given in UK GDPR being an arrangement between two or more Joint Controllers who shall in a transparent manner determine their respective responsibilities for compliance with the obligations under UK GDPR, in particular as regards the exercising of the rights of the data subject and their respective duties to provide the information referred to in Articles 13 and 14 of UK GDPR and reflecting the roles and relationships of the Joint Controllers vis-à-vis the data subjects. The essence of the arrangement shall be made available to the data subject.
• Local FDP user organisation: Any organisation which holds an instance of FDP other than NHS England.
• MoU: The Memorandum of Understanding signed between NHS England and an NHS Trust, ICB or other NHS Body as may be amended from time to time in accordance with its terms.
• National Data Opt Out: The Department of Health and Social Care’s policy on the National Data Opt Out which applies to the use and disclosure of Confidential Patient Information for purposes beyond individual care across the health and adult social care system in England. See the National Data Opt Out Overview and Operational Policy Guidance for more information.
• NHS body: Has the meaning given in the National Health Service Act 2006, which includes ICBs, NHS trusts, NHS foundation trusts and other bodies concerned with NHS service delivery
• NHS FDP System IG Group: The user group established by NHS England for local IG leads to discuss and agree IG documentation for the initial and the subsequent deployment of other local Products
  NHS-PET The privacy enhancing technology (PET) solution which records data flows into the FDP and, where required, treats data flows to pseudonymise or anonymise them
• NHS-PET contractor: IQVIA Limited
• Ontology: Is a layer that sits on top of the digital assets (datasets and models). The ontology creates a complete picture by mapping datasets and models used in products to object types, properties, link types, and action types. The ontology creates a real-life representation of data, linking activity to places and to people.
• Operational data: Items of data that are not about individuals.
• Parties: NHS England, the platform contractor, the NHS-PET contractor and FDP userorganisations
• Personal data: Has the meaning given in UK GDPR being any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person . For the purposes of the DPIA this also includes information relating to deceased patients or service users. Personal data can be directly identifiable personal data or pseudonymised data.
• Personal Data Breach: Has the meaning given in UK GDPR being a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.
• Platform contract: The agreement between NHS England and the platform contractor in relation to the FDP dated 21 November 2023 as may be amended from time to time in accordance with its terms.
• Platform contractor: Palantir Technologies, UK Ltd
• Product A: product providing specific functionality enabling a solution to a business problem of an FDP user organisation operating on the FDP. A list of approved products is maintained in the IG Framework (set out in the Appendix at section 27).
• Product privacy notice: A privacy notice providing information on the personal data processed in the FDP and by NHS-PET in relation to each product, including the purposes for which the product processes personal data
• Process or processing: Has the meaning given in UK GDPR being any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
• Pseudonymisation: Has the meaning given in UK GDPR being the processing of personal data in such a manner that the personal data can no longer be attributed to a specific individual without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the Personal Data are not attributed to an identified or identifiable natural person.
• Pseudonymised data: Personal data that has undergone pseudonymisation.
• Purpose based access Ccontrols or PBAC: Means user access to data is based on the purpose for which an individual needs to use data rather than their role alone as described more fully in the IG Framework.
• Role based access controls: Means user access controls is restricted to systems or data based on their role within an organisation. The individual’s role will determine what they can access as well as permission and privileges they will be granted as described more fully in the IG Framework.
• Security breach: Is a breach of security, and includes in the case of the Platform Contractor, a Breach of Security as defined in Schedule 2.4 (Security Management) of the Platform Contract.
• Special category personal data: Refers to the special categories of Personal Data defined in Article 9(1) of UK GDPR being Personal Data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation.
• UK GDPR: is as defined and referred to in the Data Protection Act 2018

23. Joint Controller table

NHS England and Local FDP User Organisation Joint Controller Table – V1.0 13 March 2024

1. Introduction

The purpose of this table is to set out the Joint controller arrangement between NHS England and each Local FDP user organisation (each a party in this schedule) regarding the personal data processed in the Federated Data Platform and NHS-PET in order to clarify roles and responsibilities for the purposes of Article 26 of the UK GDPR. 

Article 26 of the UK GDPR governs the relationship between joint controllers. Article 26(1) of the UK GDPR provides that “Where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers. They shall in a transparent manner determine their respective responsibilities for compliance with the obligations under this Regulation, in particular as regards the exercising of the rights of the data subject and their respective duties to provide the information referred to in Articles 13 and 14, by means of an arrangement between them unless, and in so far as, the respective responsibilities of the controllers are determined by Union or Member State law to which the controllers are subject. The arrangement may designate a contact point for data subjects.”

Under Article 26(2) of the UK GDPR, “The arrangement referred to in paragraph 1 shall duly reflect the respective roles and relationships of the joint controllers vis-à-vis the data subjects. The essence of the arrangement shall be made available to the data subject.”

2. Transparent manner

The table below can be referred to in relevant Data Protection Impact Assessments (DPIAs). It will also stand as a stand-alone document which can be issued to anyone who requests it. It transparently sets out each Party’s respective obligations and responsibilities as joint Controllers in relation to the Data Platform and NHS-PET.

3. Respective responsibilities for compliance, in particular with regard to exercise of data subject rights and duties to provide information in Articles 13 and 14

The table below sets out each controller’s responsibilities for:

• compliance with the obligations under UK GDPR which apply to controllers,
• compliance with duties to provide the information referred to in Article 13 and Article 14, and
• compliance with the obligations under UK GDPR as regards the exercise of data subjects’ rights. 

This table constitutes the arrangement referred to in Article 26.

4. The arrangement may designate a contact point for data subjects

NHS England is designated as a contact point, for data subjects,

• in the table below for FDP Programme-wide queries and queries concerning the national instance; and
• in the General FDP privacy notice and in the transparency information, for queries concerning each product in the national instance.  

NHS England’s data protection officer is also named in the general FDP privacy notice and the transparency information for each product in the national instance of FDP as a contact point. 

Local FDP user organisations are designated as a contact point, for data subjects,

• in the table below for queries concerning their use of the local Instances; and
• in the General FDP privacy notice for each product in their local Instance;
• in the transparency information they provide for each Product in the local Instance which they deploy.

The Local FDP User Organisation’s Data Protection Officer should also be named in such transparency information of the Local FDP User Organisation.

5. The arrangement must reflect the respective roles and relationships of the joint controllers vis-à-vis the data subjects

In accordance with Article 26 of the of the UK GDPR this table sets out the roles and responsibilities of the following Parties:

• NHS England
• Local FDP user organisations

(together referred to as the FDP user organisations), in relation to the processing of personal data in the data platform and, when processing of personal data commences, in the NHS-PET.  

The FDP is a series of individual platforms referred to as Instances and each of NHS England and the Local FDP user organisations have their own instance and they each control the personal data held and processed within their own Instances.  

NHS England is the controller for the personal data which flows into, and is processed within, any approved Products it chooses to use within the national Instance.  

NHS England is a joint controller with each Local FDP user organisation in relation to the local Instances for design, governance, and service management of the data platform. This is because NHS England broadly determines the parameters for the use of the data platform.  

Local FDP user organisations are controllers for the personal data they flow into and process in their local Instances.  Each local FDP user organisation decides whether to use the Federated Data Platform, what data to commit to the Federated Data Platform and how to use it within those parameters.

Where the NHS–PET Contractor Processes Personal Data prior to it entering or leaving the national Instance then NHS England is the Controller of such Personal Data Processing.

Where the NHS-PET Contractor Processes Personal Data prior to it entering or leaving the local Instance then the Local FDP User Organisation is the Controller of such Personal Data Processing.

NHS England are a joint Controller with each Local FDP User Organisation in relation to the Local FDP User Organisation’s engagement of the NHS-PET Contractor to Process Personal Data prior to it entering or leaving a local Instance, specifically in relation to the design, governance, and service management of NHS-PET.

6. The essence of the arrangement shall be made available to the data subject

The essence of this arrangement is described in the General FDP Privacy Notice referred to above. This document is publicly available and can also be provided to data subjects on request to NHS England.

Key to roles and responsibilities in the table below.

To assist, where a party:

• has compliance responsibilities this has been identified with a ‘tick’
• does not have compliance responsibilities, this has been identified with a ‘cross’

Download a word version of this table.

24. Appendix – information governance framework

• Federated Data Platform: information governance framework