Frequently Asked Questions (FAQs)

We have compiled a list of Frequently Asked Questions below and divided them into two sections "GP FAQs" and "Local Authority FAQs". If you have a question that hasn't already been answered below, please get in touch with us, as we'd love to help if we can, and your questions help us to keep our FAQs updated. 

The proposal is to set up a near real-time person level linked dataset across Cheshire and Merseyside. This will enable combined intelligence to be produced that can support a set of COVID related population health analytics designed to inform both population level planning and targeting of direct care. The intelligence will be made available to appropriate users across the system in the form of a set of dashboards within an intelligence platform called Power BI.

It is proposed that the linked dataset will be used in three broad areas to produce population health intelligence in support of COVID recovery.

Automated Dashboards to support COVID Recovery: These split down into three ‘use cases’

Use Case 1: Capacity and Demand: This dashboard will monitor the changing demand across acute, community, mental health and local authority services in as near real time as possible, including the ability to understand if there is a possible surge or ‘second wave’ emerging. it will enable understanding of whether there is enough capacity to meet that demand. This dashboard is targeted at those user groups that are responsible for planning system capacity including Cheshire and Merseyside region, sub regional teams i.e. North Mersey, individual CCG’s and Primary Care Networks (PCNs).

Use Case 2: Epidemiology: This dashboard will enable monitoring of mortality and incidence over time at differing levels of geography. It will also provide insight in terms of demographic and health characteristics of individuals most affected by COVID. It will enable identification of geographical ‘hot spots’ of emerging infection. This dashboard is aimed at Public Health departments; The Out of Hospital and Acute Recovery Cells at Cheshire and Mersey Region that are responsible for planning and; those responsible for planning a COVID response with PCN’s.

Use Case 3: Population Stratification: This Dashboard enables GP practices and/or PCN’s responsible for a registered population to identify individuals with certain characteristics that will be vulnerable to adverse outcomes as a result of COVID and target services/interventions appropriately. (This is not the same as risk stratification in general practice that is most commonly used for stratifying the risk of unplanned admission to acute care)

Pseudonymised data for Place Based Intelligence Services (use Case 4); In addition to the reporting above being stepped up, the proposal is to make a set of person level pseudonymised data available to your local placed based intelligence teams that being the CCGs and Local Authorities. This will enable them to support the local system with COVID planning, which includes support to General Practice and PCN’s in intelligence required.

Pseudonymised and non re-identifiable data for COVID Research: In addition to the above, the intention would be to make a pseudonymised non-identifiable extract of the data available to the research community for COVID related research on a project by project basis. Applications to be made and to and approved by a Governance Board. See below sections for a description of Governance and Access Controls in this area.

Pseudonymised data is explained later in the FAQ.

Population stratification enables vulnerable individuals and their needs to be proactively identified and a more targeted individual response to be delivered from services that are available, to improve both their health and socio-economic outcomes.

Cheshire and Mersey region are responsible for planning enough system capacity to respond to any surge in demand due to the COVID pandemic, whilst also reintroducing planned care capacity across both acute, community and mental health providers. The demand and capacity report will enable Cheshire and Merseyside and the sub-regional geographies to be sighted on system demand to respond with capacity accordingly.

System C/Graphnet are a third-party supplier of data services. They offer a service that automates the near real time collection of data from NHS and Local Authority systems into one central warehouse/data store. The data can then be either pushed back to clinical systems to support a shared care record, or it can be used to create Business Intelligence about populations to inform planning and targeting of direct care.

Graphnet currently cover a population of 16 million with their services and are the provider of data services also to Bath and North East Somerset, Berkshire, Buckinghamshire, Cheshire, Greater Manchester, Kent, Northamptonshire, Staffordshire, St Helens, Whittington, Wolverhampton and Walsall.

For more information about Graphnet/System C, please visit their website

The data being flowed via Graphnet from GP systems will include patient identifiable data of names, address, date of birth and post code. It will also include other demographic and health information, test results and medications. It will not include free text.

Once the data flow has been switched on the data will be taken automatically, once daily.

Yes. People who opted out of data sharing for purposes other than direct care (Type 1 objections) will be excluded from the flow of data from the GP system into the Graphnet solution.  

Data will be stored on ‘Azure cloud’, which is compliant with Information Governance standards and is safe and secure. Azure is assessed to ISO 27001, ISO 27017, ISO 27018, and many other internationally recognized standards. The scope and proof of certification and assessment reports are published on Microsoft's Trust Centre. Once you're on the Trust Centre page, you can then click to view individual compliance documentation such as that for the ISO/IEC 27001:2013 Information Security Management Standards documentation, the assessment for which was performed by the BSI.

Role Based Access Controls (RBAC) will be implemented, which means the data will be split into four different categories and only those with the appropriate Information Governance approval will be able to access the data in each category. The four categories of data are explained below:

  1. Identifiable: Data will be wholly identifiable to the end user.
  2. Pseudonymised: This data will still be at person-level, but the identifiable fields will be removed from the data. This includes removal of names and addresses. Date of Birth will be formatted to age; post code will be shortened to the first 4 digits and the NHS number will be encrypted into an alpha-numeric. Pseudonyms will be linkable across datasets. Re-identification will be possible via a set of controlled processes.
  3. Pseudonymised not identifiable: This data will be the same as above with two differences. Pseudonyms will not be linkable across datasets and re-identification will not be possible.
  4. Anonymised-Aggregate: This data will be fully anonymised and aggregated against the national NHS anonymisation standard, meaning small number suppression (<5) will be implemented and no person level data will be available.

The table below explains who will have access to each category of data and how this will be governed:

Data Type

Reporting Examples

Who has access?

For what Purpose?

How is Access Granted?

Identifiable

Drill down patient lists in the Epidemiology and Patient Stratification reports on the portal

Those with a legitimate direct care relationship i.e. GP and PCN staff

 

Graphnet for the purposes of data processing

Direct Care

 

 

 

 

Via individual GP practices for the populations they serve

Pseudonymised:

The data is made available in a secure warehouse to Intelligence teams to run bespoke analysis

Placed Based intelligence teams including CCG and Local Authorities and teams supporting regional analytics, including those with honorary contracts

COVID Recovery Planning; responding to COVID intelligence needs of the local system including General Practice and Primary Care Networks

People from the organisations listed will be granted access via the Governance Approval Board

A Project Matrix will be published to general practice monthly

Pseudonymised not re identifiable :

The data will be made available in a secure warehouse to the research community

Projects and organisation to be determined via Governance Approval Process

COVID Recovery Planning and COVID Research

Project approved via the Governance Approval Board. A Project Matrix will be published to General Practice Monthly

Anonymised-Aggregate:

Aggregate views in the Epidemiology and Capacity and Demand Reports

Cheshire and Merseyside Providers, Commissioners and Local Authorities

COVID Recovery Planning

People from the organisations listed will be granted access  

The programme will maintain and strictly enforce a Data Access and Data Asset matrix to ensure requests to use the CIPHA regional data sources ensure full compliance to the COVID-19 purposes as outlined in the sharing agreement.

This process will be governed through a regional group that will draw its membership from: the regional Clinical Informatics Advisory Group (CIAG); GP and Local Medical Committees; clinical IG specialists; and the regional Data Services for Commissioners Regional Offices (DSCRO) service.

This matrix will detail projects undertaken with the pseudonymised data by the place-based intelligence teams and be made available to parties within the sharing agreement including GP Practices on a monthly basis, so they are informed of the specific uses of the data.

A process will be put in place for approval of projects on a case by case basis for organisations other than place-based intelligence teams e.g. research bodies using the following principles:

  • Purpose aligns with the purpose of this agreement
  • Any application includes a separate data sharing agreement where the group acts on behalf of the signatories to this agreement.
  • Individual data controllers will have five working days to opt out.

The legal basis under GDPR is 6 (1) (e) Necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller.

9(2)(h) Necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care, or treatment or the management of health or social care systems and service.

9(2)(i) Necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller.

Under the COPI notice for COVID-19 all providers of healthcare, GP Practices and Local Authorities have been given legal notice to support the processing and sharing of information to help the COVID-19 response under the Health Service Control of Patient Information Regulations 2002. This is to support the processing and sharing of information to help the COVID-19 response. This sets out that confidential patient information can be used and shared appropriately and lawfully for purposes related to the COVID-19 response.

This allows the processing of confidential patient information, including disseminating to a person or organisation permitted to process confidential patient information, including disseminating to a person or organisation permitted to process confidential patient information under Regulation 3(3) of COPI.

The first ‘Control of Patient Information Notice’ (COPI) for COVID-19 was issued on 17 March 2020, which you can view here.

A further COPI Notice was issued on 20 March 2020, which you can view here.

An extended COPI Notice was issued on 29 July 2020, which you can view here.

A further extended COPI Notice was issued on 27 January 2021, which you can view here.

The Common Law Duty of Confidentiality requires that there should be no use or disclosure of any confidential patient information for any purpose other than the direct clinical care of the patient to whom it relates, however there are some broad exceptions:-

  • The patient explicitly consents to the use or disclosure.
  • The disclosure is required by law, or the disclosure is permitted under a statutory process that sets aside the duty of confidentiality.
  • The disclosure can be justified in the public interest. Whilst the COPI Notice provides the lawful basis to set aside the Common Law Duty of Confidentiality, under this Data Sharing Agreement the Common Law Duty of Confidentiality will be upheld. This is explained below. Uses of data other than for direct care are known as ‘secondary uses’. Secondary uses of data include analysis done for population or service planning purposes that don’t directly relate to the individual. Despite the COPI Notice, the Common Law Duty of Confidentiality will be upheld in this project. This means that people using data for ‘secondary uses’ will only be granted access to the pseudonymised extract of data, therefore upholding the common law duty of confidentiality. Sometimes re-identification of individuals is required. This will be achieved in a controlled way and only to those who have a direct care relationship with the patient.

A group of Local Authority IG officers, data protection officers and other officers have met over a number of weeks and arrived at a data risk table with mitigations - these are given below

 

 

Identify risks, assess them and identify measures to reduce risks

Identifying privacy risks to the data subjects (people who the information is about) is the key part of a Data Protection Impact Assessment. This is where we identify the risks, the severity of the risks and propose solutions to the problems.

•            Try and put yourself in the shoes of the person you are collecting data about, would you object or have concerns?

•            What can you envisage going wrong in the project? How might data be lost or misused for example?

Describe the source of risk and nature of potential impact on individuals. Include associated compliance and corporate risks as necessary.

Likelihood of Harm

● Remote

● Possible

● Probable

Severity of Harm

● Minimal

● Significant

● Severe

Overall Risk

● Low

● Medium

● High

Identify measures you could take to reduce or eliminate risks

Effect on risk

● Eliminated

● Reduced

● Accepted

Residual Risk

● Low

● Medium

● High

Measure Approved

● Yes

● No

Failure to keep clients informed over how their data will be used could lead to a breach of GDPR Article 13 and 14 of the GDPR.

 

The current example Privacy Notice embedded into the Data Sharing Agreement, includes elements and processes which do not comply with the provisions under the Data Protection Act.

 

Possible

Significant

Medium

·         The example Privacy Notice from NHSX legally meets the terms of the COPI notice for COVID-19. This Tier 2 Data Sharing Agreement is governed under the COVID-19 COPI notice.

 

·         It is at the discretion of any partner organisation in the sharing agreement to add to the privacy notice. This would further meet GDPR 13(3) beyond the COPI notice under which this DSA is covered.

 

·         The management of the four levels of data - patient identifiable; pseudonymised; pseudonymised and non-reidentifiable; and anonymised/aggregate – are set out in the Tier 2 data sharing agreement.

 

·         The fair processing required for a solution of this type is the privacy notice. Each organisations web site should be updated to inform data subjects that the programme is in place and the legal basis that is being used to share data.

 

·         Consideration should be given to the use of both local media and existing communications channels to ensure transparency.

·          

Reduced

Low

Choose an item.

Failure to have processes in place to facilitate the following data protection rights requests could result in a breach Article 15, Article 16, Article 18 and Article 21

 

·         Right of Access

·         Right to Rectification

·         Right to Restrict Processing

·         Right to Object

 

 

Possible

Significant

High

·         Each Data Controller is accountable under GDPR, and will have their own measures in place to meet the eight Rights of Data Subjects.

·          

·         If a Data Subject of any partner organisation wishes to exercise or challenge one of their Rights, they would do that with their provider organisation(s).

·          

·         Each Data Controller will remain responsible and accountable under GDPR for their clients.

·          

·         The host Trust of the platform – St Helens and Knowsley Teaching Hospitals NHS Trust – have in place their data processing and cyber policies and procedures to maintain the rights of the data subjects.

·          

Reduced

Low

Choose an item.

Failure to ensure that the supplier is compliant with Government and National Cyber Security Standards for cloud based computing could lead to a breach of our security obligations under Article 32 of the GDPR

Possible

Significant

High

·         Data will be stored on ‘Azure cloud’, which is compliant with Information Governance standards and is safe and secure. Azure is assessed to ISO 27001, ISO 27017, ISO 27018, and many other internationally recognized standards. The scope and proof of certification and assessment reports are published on the Azure Trust Centre section for ISO certification here: https://www.microsoft.com/en-us/trustcenter/compliance/iso-iec27001. The ISO 27001 assessment was performed by the BSI.

·         SystemC and Graphnet Health Ltd comply with the 13 infrastructure as a service (IaaS) principles and are accredited as such e.g. Cyber essentials.

·          

·         Details are available on request contained within the “CareCentric population health cloud assurance” document.

·          

Reduced

Low

Choose an item.

Failure to define the process in which direct care providers outside of an LA area can access the records of patients outside of their area could result in data being accessed inappropriately leading to a Data Protection Act Section 170 offence

 

Possible

Severe

High

The following processes are in place

·         The supplier defines rigorous role based access (RBAC) protocols to ensure   access to data is limited to those authorised and maintains a register of RBAC

·         The supplier maintains an audit trail of access to data sources

·         The programme controls access to data assets through a ‘Data Asset and Access Group’ to ensure only legitimate access is granted to individual projects (use-cases). This is linked to the RBAC process

 

Reduced

Low

Choose an item.

Failure to have security processes in place to stop partners, with access to patient identifiable data, from accessing the portal from their own personal devices, this could result in a breach of each partner’s security obligations under Article 32 of the GDPR

Possible

Severe

High

The following mitigating processes are in place

·         Personal identifiable data can only be made available (re-identified) using the existing and approved ‘pseudo at source’ mechanism through the Data Services for Commissioners Regional Offices (DSCRO). This mechanism is obligated through the contract with the supplier

·         Through the RBAC processes and prior to approval to access any data those regional intelligence teams that can legitimately re-identify data using pseudo at source will be obliged to evidence their own procedures to ensure that personal identifiable information will not be accessible through personal devices

·         Access to the data storage service is based on best practice of whitelisting specific IP address ranges, this will reduce the risk of access via personal devices

·         When the service is accessed all actions are recorded within the audit trail

·         Access to local networks, be this direct or via virtual private network (VPN) will be subject to the acceptable usage policy of the organisation that the person making access works for. Each individual will be subject to the policies and procedures outlined by their employer

 

Reduced

Low

Choose an item.

Failure to have a process in place to audit access to patient identifiable data processes could result in a breach of our security obligations under Article 32.

Possible

Significant

High

The following mitigations are in place;

·         The Azure SQL environment logs all SQL queries which take place against the data marts to provide an audit trial of what identifiable data has been accessed and by whom

·         Requests for re-identification of cohorts through the Web Client application are recorded separately and will be provided on a regular basis to the CIPHA board

·         Access to the data will be subject to approval from the data controllers. The existing change control process would approve access and grant permissions

·         All activity reports are available as outlined above and would be provided to assist audit. Audit process and timeframes will be specific to each organisation

 

The programme controls access to data assets through a ‘Data Asset and Access Group’ to ensure only legitimate access is granted to individual projects (use-cases).

 

Reduced

Low

Choose an item.

Failure to ensure adequate controls are in place to ensure that de-identified data can’t be re-identified could result in disclosure of personal information leading to a data breach and could lead to a breach of our security obligations in relation to anonymisation / pseudonymisation processes under Article 32

Remote

Severe

High

Direct Care data marts hold the full PID along with field level configuration for both anonymisation and sensitive clinical coding reference data. Stored procedures query tables using filed level configuration to anonymise data at the point of extract. SSIS package cross references data with sensitive clinical coding to further remove restricted data. Fully anonymised data is written to the research data mart in the same format as the direct care source. Key masking uses a customer specific SALT value + SHA2_256 hashing.

 

 

Security

·         Separate cloud security helpdesk with one request per user

·         IP addresses must be whitelisted for access to data marts

·         Azure AD named user access must be used

·         Data access can be controlled by mirroring CareCentric RBAC configuration

·         Full SQL row level security

·         Unique RBAC groups can be implemented within analytics solution if required

 

Anonymisation

·         Source is the Direct Care mart holding all data

·         Data is copied to the Anonymised mart

·         Sensitive Clinical Codes stripped out in flight

·         Field level configuration for anonymisation

o    No change

o    Blank

o    Truncate

o    Mask Dates

·         Key fields undergo one way encryption, maintaining referential integrity

 

Pseudonymisation

o    Source is the Direct Care mart holding all data

o    Data is copied to the Pseudonymised mart

o    Opted Out patients and Sensitive Clinical Codes stripped out in flight

o    Field level configuration for Pseudonymisation

o    No change

o    Blank

o    Truncate

o    Mask Dates

o    Tokenised IDs Can be re identified

o    National DE ID / RE ID or encrypted local values

o    Secured data table which stores mapping

o    User interface to reidentify

o    Key fields undergo two way encryption, maintaining referential integrity

 

A white box penetration test has been completed with a Black box full test scheduled for 2020.

 

Reduced

Low

Choose an item.

Failure to have a process in place to verify, audit and test the merging of data from multiple data sources to ensure that data is matched correctly to ensure that a data breach does not occur

Remote

Severe

High

Graphnet merges data into it’s longitudinal patient record based on the patient NHS Number, name and date of birth.

Where the NHS number is a verified number we would match on this. If this is not the case we use the three items described above.

Reports are available that outline the match success and Graphnet have performed audits for clients to ensure data integrity. The tools available to client are designed to support the on going data quality process which is the responsibility of each data controller.

 

Eliminated

Low

Choose an item.

Failure to provide / develop a process / technical solution to facilitate clients opting out of their data being shared could lead to a breach of the Common Law Duty of confidence, Data Protection Act and Human Rights Act

Possible

Significant

High

Type 1 opts out (those who do not want their information shared outside of General Practice for purposes other than direct care) will be upheld. This means that data for people who have objected to sharing their data will not flow from the GP record into the Graphnet solution.

 

Once the national solution for opt out is live with NHSD, these patients will automatically be removed from the datamart.

This removal includes all data sources. The ability to opt out for direct patient care would only be instigated subject to a successful application by the data subject under article 21 of GDPR.

 

Eliminated

Low

Choose an item.

Failure to ensure that a process is in place to remove a client’s data when the partner has closed the record on their systems could result in data being retained inappropriately

Possible

Significant

High

The Records Management Code of Practice for Health and Social Care 2016 sets out what people working with or in NHS organisations in England need to do to manage records correctly. It's based on current legal requirements and professional best practice.

 

All organisations that contribute to the solution will be governed by the above.

 

Each organisation will have its own records management policy and define both the duration of retentions and removal policy.

 

The data processor will hold data in line with the contract terms. All data will be returned and purged at contract end, or as set out in the contractual terms.

 

 

Reduced

Low

Choose an item.

Failure to ensure that the appropriate international transfer safeguards are in place should the note data be stored on servers outside of the UK could result in a breach of Article 44-56

Remote

Significant

High

The supplier, Graphnet Health, are a UK based company. All data is stored in the UK and there is no server storage outside of the UK.

All information can be found in the CareCentric population health cloud assurance document.

 

Eliminated

Low

Choose an item.

Failure to define the retention of closed records data on the system could result be held on the portal inappropriately

Possible

Significant

Medium

The Records Management Code of Practice for Health and Social Care 2016 sets out what people working with or in NHS organisations in England need to do to manage records correctly. It's based on current legal requirements and professional best practice.

 

Each organisation that contributes to the solution will have a record retention policy. The elements of the record, when combined, creates a holistic view of a care recipients journey. As a result this new record would be retained for the duration of the longest term for which the record is retained within the social care community, If the contract is continued beyond March 2021c then the retention period for the combined record will be subject to an agreement from the social care providers.

 

Eliminated

Low

Choose an item.

 

 

 

You will already have a privacy notice that explains to patients how their data is used. You can update your existing notice by adapting the example COVID specific privacy notice from NHS X.

If you adapt this notice, then we suggest you insert the following paragraph where it states ‘[Is there anyone else information will be shared with, for purposes beyond individual care relating to Covid-19?]’

Locally across Cheshire and Merseyside, data is being shared securely with a data processor called System C for the purposes of protecting public health, providing healthcare services to the public and monitoring and managing the outbreak. No data that identifies a person will be used for purposes other than direct care. If you have previously opted out of data sharing your data will not be used.

The Cheshire and Merseyside Data Sharing Agreement (DSA) for COVID-19 specific purposes remains in place whilst the COPI Notice applies (see below). This sets aside the Common Law Duty of Confidentiality. The data flow is UK GDPR compliant as explained in the DSA.

The longer-term aim was to set up a broader (than COVID) population health intelligence approach. However in 2020, we recognised that we were on a journey with data sharing, and an incremental approach was needed to build trust in the system and process.

We returned to data controllers in January 2021 to engage with them on the benefits of the project to date, and also to establish a broader purpose for population intelligence with a new legal basis for data sharing beyond the COPI Notice (currently due to expire on 30 September 2021), that would satisfy both UK GDPR and the Common Law Duty of Confidentiality, negating the need for the use of COPI.

This has now been done, and a new Data Sharing Agreement was issued in July 2021:

Cheshire and Merseyside Health and Care Partnership

Combined Intelligence for Population Health Action (CIPHA): Data Sharing Agreement (Tier Two)

Workstream: Population Health

"Link will be added to pop health DSA"

The Population Stratification report will bring various data sources together to identify vulnerable groups and will give practices and PCN’s a better understanding of vulnerable populations and their needs. Services can then be planned and targeted more appropriately. The epidemiology report will allow PCN’s to understand how COVID related mortality and incidence are changing within their geography and explore the characteristics of people who are affected by COVID in their populations. It will also enable PCNs to identify if infection hotspots are occurring in their local geography and to respond appropriately.

The data being flowed via Graphnet from GP systems will include patient identifiable data of names, address, date of birth and post code. It will also include other demographic and health information, test results and medications. It will not include free text.

Once the data flow has been switched on the data will be taken automatically, once daily.

  • Workshops on use case and target operating model design with LA intelligence teams
  • Worked with LA IG leads and other officers to provide additional detail for the data sharing agreement that includes;
    • An addendum with a reduced data extract and COVID data extract specification with justification for categories of data and data items
    • An additional data risk assessment table covering data use; data security; protection of client data confidentiality; and respect for opt-out
  • Engagement with CHaMPS in unifying an approach to COVID reporting and outbreak prediction.

  • Through sharing to become a consumer of regional integrated data and partner with the NHS to support
  • Directors of Public Health (CHaMPS) in unifying an approach to COVID reporting and outbreak prediction
  • Building upon and augmenting place-based COVID intelligence
  • Taking an active role in the use of regional data to support the funded programme for a regional telehealth provision to include care homes
  • To receive flu (and future COVID) vaccination data that can be stratified to target at risk groups
  • To have a basis for considering the use of regional integrated data sets to support prevention and early intervention.

Responsive image

What's New..

Buckinghamshire
Lancashire and South Cumbria
Northamptonshire HCP
Surrey Heartlands
Manchester Community Central
Cheshire and Merseyside