Guidance

NHS COVID-19 app: anonymisation, definitions and user data journeys

Updated 27 October 2021

The following page sets out key information about the NHS COVID-19 app, the terms we use to describe how we work with data and some brief summaries of different scenarios and what data would be generated.

The NHS COVID-19 app (“the app”) collects analytical data to ensure the app is working properly, safely and helping manage the COVID-19 public health emergency. There are key controls throughout the apps functionality that reduces or removes the ability to identify app users. We need to make sure that we update your app with the correct test results if you require a COVID-19 test. Other than this instance:

• The Apple Google Contact Tracing functionality requires users to anonymous and this is a condition of our use of the GAEN

• The app holds personal data, however, we do not collect personal data. For example, your app will hold details of the venues you have visited but this is not shared with us

• The analytical data set is based on summaries and counts of functions. It is not cumulative and does not hold specific details. From the point it is collected throughout its analysis and use, we have safeguards to ensure that individuals are not identifiable

• We monitor and consider our controls to make sure we maintain this standard and look for ways to improve them. See the Privacy Risk in the DPIA for a description of this work

Definitions

We use the following definitions in our Data Protection Impact Assessment and Privacy Notices, and in evaluating privacy risks and controls.

Term	Definitions
Aggregate	Aggregated data: Combined data from one or more data sources, potentially including summated or summary data or information or statistics based upon living natural persons’ data sourced from or related to one or more individuals to show general trends or values or analyses without identifying individual personal information or data within the data set.
Anonymised	Anonymisation: The process of rendering data into a form which does not identify individual living natural persons or makes the risk of re-identification sufficiently low in a particular context that it does not constitute personal data.
Anonymous	Data that cannot identify a living natural person.
Data minimisation	Is the principle that personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed. Personal data should be sufficient to fulfil the purposes for which they are acquired, processed or retained
De-personalised	De-personalised data: This is information that does not identify a living natural person, because all relevant identifiers or identifiable data have been scrambled or removed from the non-identifiable information about the living natural person to whom it relates. Because the information relates directly to a living natural person it must be protected in law. It might, in theory, be possible to re-identify the individual if the data was not adequately protected, for example if it was combined with different sources of information.
De-identified:	This refers to personal confidential data relating to a living natural person, which has been through anonymisation in a manner conforming to the ICO Anonymisation code of practice. There are two categories of de-identified data: 1) De-identified data for limited access: this is deemed to have a high risk of re-identification if published, but a low risk if held in an accredited safe haven such as an approved secure operational data store and subject to contractual protection to prevent re-identification; 2) Anonymised data for publication: this is deemed to have a low risk of re-identification, enabling publication.
Linked data	Linked data: The result of merging data from two or more sources with the object of consolidating facts, potentially including those relating to a living natural person, or an event that are not available in any separate record.
Personal	Personally identifiable data: This term describes personal information about identified or identifiable living natural persons, which should be kept private or secret. It includes the definition of personal data in the Data Protection Act, but may also include data relating to people who have died and information given in confidence under the Duty of Confidentiality. It includes, for example, Personally Identifiable Information (PII) and Sensitive Personal Information (SPI).
Personal Confidential Data (PCD):	Personal Confidential Data (PCD): Personal information about identified or identifiable living natural persons, which should be kept private or secret. For the purposes of this Review ‘Personal’ includes the DPA definition of personal data, but it is adapted to include dead as well as living people and ‘confidential’ includes both information ‘given in confidence’ and ‘that which is owed a duty of confidence’ and is adapted to include ‘sensitive’ as defined in the Data Protection Act.
Personal Data	Personal data: Data which relate to a living natural person who can be identified from those data, or from those data and other information which are in the possession of, or are likely to come into the possession of, the data controller, and includes any expression of opinion about the living natural person and any indication of the intentions of the data controller or any other person in respect of the individual.
Pseudonym	Pseudonym: Individuals distinguished in a data set by a unique identifier which does not reveal their ‘real world’ identity.
Pseudonymised	Pseudonymisation: The process of distinguishing living natural persons in a data set by using a unique identifier, which does not reveal their ‘real world’ identity (see also Anonymisation and De-personalised data).
Pseudonymised (as defined in GDPR)	In GDPR (Article 4) ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject 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 living natural person.

Definitions are based on the National Data Guardian for Health and Care’s Review of Data Security, Consent and Opt-Outs and Connected Health Cities Data Glossary

Data and the app

Your app retains data within the app around specific interactions. The logs of who you have interacted with are retained within the Apple/Google GAEN and are not visible or accessible to us. Details of which venues you have visited again are only on your app. The app will hold details of a relevant test result but only for as long as necessary, 14 days after any self-isolation period this data is no longer recorded. As detailed below you can delete the app, or just some data items (specific venues) or all the data it contains.

Data provided to the app by the central systems

The app is updated by the central systems (product environment), on average, every 2 hours. The central system provides all app users with three key sets of data. Every app user receives the same information, called reference material, which the app uses to determine if you need to receive an alert or advice. These are:

• the list of Diagnosis Keys from app users who have tested positive. This functionality keeps the identity of app users anonymous to other app users
• the list of all postcode districts and their current risk level
• the list of venues that could pose a risk, as determined by Health Protection Teams and the Joint Biosecurity Centre (JBC)

Systems also provide you with an update to your status if you used a test code provided through the app. Where an app user has tested positive for COVID-19 they will be prompted to share their protected ID. Once these are processed by the central system, they are provided to all app users. The Apple Google functionality uses these codes to determine if you should be alerted.

Once the data is provided to the app user, the app checks whether any alerts or notifications need to be displayed to you. This is based on how the app works, is supported by automated decision making and uses the reference material provided to all app users.

Analytical data

Each 6-hour period, the app collects a summary count of key information. This is called the analytical data set and helps us monitor the use, performance and information about the app and its use. The data is prepared and will be sent to central systems where it used for assurance of the app, technical checks and the public health functions. It does not include the data held on your app about specific venues or your close contacts.

Data generated and collected

This section sets out different aspects of the data why it is generated or collected and what function the data serves.

Apple Google GAEN

Your app will hold the following, subject to the controls of the Apple Google Functionality and provided via the Exposure Notification API.

• the app holds the broadcast keys from other app users you have been in contact with, including the details that allow the app to determine whether you might be at risk;

• these broadcast keys are changed every 15 minutes and are not accessible to you as an app user or us as data controller.

This system is designed by Apple and Google to protect the privacy and identity of app users, making their use of the app anonymous.

Data held on the app

Beyond the digital contact tracing all app users will have the details listed below on their app. The same reference material is on everyone’s app. Other details will vary with how you use the app but are only held on your phone.

The app

The app will retain your declared postcode district, latest virology test result and any venues visited. This data can be deleted when you delete the app, through the app and even for individual venues. No history of postcode districts or virology test results are retained.

Data about the user

• QR venues visited (details of the venues checked into)
• postcode district (the users current declared postcode district)
• virology test results (the last test result retained for the isolation period plus 14 days)

Reference Material (used to appropriately update the app user)

In addition, to the diagnosis key detailed above, the app holds two sets of reference material which enable the app to function and appropriately update you. For example, the list of risk status for postcode district allows you to be notified about any changes to the risk score for their postcode district as well as display the baseline risk.

• Risk status for every postcode district within the app [Postcode District Area Risks];

• Full list of venues that are “at risk” with details of the relevant time period [Hotspot QR Venues];

Analytical data set

Using the app will populate the analytical data set. As noted above, the majority are summaries or counts of function use and do not list data items.

This data is not only important to understanding if the app is working as expected, to manage the transmission of COVID-19, but it also supports us in meeting our statutory obligations to app users.

For example, our obligations include equalities and health inequalities. Monitoring the data, storage and use of the pause function allows us to understand the potential impacts of the app and its use. This helps to ensure that the app supports as many communities and users as possible. For example, if the app uses large amount of data then those on limited data plans may not be getting the service we want to provide.

All users potentially generate the following data items in the analytical data set.

Core details

The app collects the following details about your phone, the app and the analytical period the data applies to:

• Start Date – when the period for the analytical data began

• End Date – when the period for the analytical data ended

• Postcode District – the current postcode district of the user

• Device Model – the device model

• Operating System Version – the operating system in use on the phone

• Latest Application Version – the application version of the app

Data usage of the app and data submitted to the app

The data usage of the app on your phone. This helps us to monitor how much data the app is using and whether this in line with expectations.

• Cumulative Download Bytes (Data to App)

• Cumulative Upload Bytes (Data from App)

• Cumulative Cellular Download Bytes (Data to app by cellular)

• Cumulative Cellular Upload Bytes (Data from app by cellular)

• Cumulative Wifi Download Bytes (Data to app by wifi

• Cumulative Wifi Upload Bytes (Data from app by wifi)

Service and system checks

These data items are used to ensure the service and system is working correctly.

• total background tasks

• running normally background tick

• completed onboarding – whether the app user has completed the onboarding process and the app requirements assessment as a “in use”

• includesMultipleApplicationVersions – a check that only one of version of the app is in use.

See below for an overview what background tasks are and this data set.

Function specific data in the analytical data set

The following data items are present for all users but vary by the functions you use. Where not used your data return will be zero (or nil) for the relevant entry.

Venue check-in

• checked in (count of venue check ins)

• canceled check in (count of venue check ins cancelled - not check outs)

Test results (into the app)

• received void test result (test not conclusive)

• received positive test result

• received negative test result

Pause functionality

• Encounter Detection Paused Background Tick – allows us to judge how the long the app was paused for

Symptom checker use and results

• completed questionnaire and started isolation – when the symptom checker was used and recommended a test and self-isolation

• completed questionnaire but did not start isolation – when you used the symptom checker but self-isolation wasn’t started regardless of result

Isolation trigger

The following provide an overview of whether an app user is isolating and for how long. It cannot be used for any enforcement.

• is isolating background tick

• has had risky contact background tick

• has self diagnosed positive background tick

Analytical Data upon arrival at the central system

No identifiers are provided to the data as it leaves the app, preventing you from being identified across analytical data packets (subject to additional controls). On landing data will be placed into a row.

• Row Level

Background tasks

In line with most apps, the NHS COVID-19 app uses “background tasks” as a way for the app to keep content up to data and for the app to function in the background of your phone. For example, when you are using another app or have the app minimised. These background tasks are normal functions of your app interacting with your phone’s operating system.

Background tasks do not enable us to track the location of users, or to read any other information from the phone for example about other apps and how you use them.

Protecting your privacy and identity

We use the following techniques to protect every app user’s privacy and identity, as well as our analysis of the risks from particular data items. We try to make sure that an app user can use the app anonymously whenever possible, with the minimum data collected that is necessary to deliver the functions of the app. However, the data collected must provide an effective service to app users and help us understand and manage the COVID-19 public health emergency.

We have included a review of the risks and protections for each environment within our Data Protection Impact Assessment.

Personal Identification Risk

The analytics data relating to app operation is collected as summary counts, for example the number of exposure events and QR code check-ins. We cannot access any information on your specific contacts or location check-ins.

Anonymisation strategy: technical data items

The analytics data is collected and held in such a way that it cannot be used to identify the user. 

• No data is collected which would allow us directly to identify an individual – we do not collect details of the user’s name, address, phone number, device IMEI or any other unique piece of identification;

• The data that we do collect is held so it cannot be put together (“linked”) to identify a user – specifically, we separate all  technical data relating to the phone, used to ensure the app is functioning properly, from the public health data that we need to manage the pandemic.

This is done by using different environments to manage the data with additional controls around the public health data and broader analytical functions.

IP Addresses (Not used by the app)

Your IP address (a unique identifier for your phone when you use the internet) is automatically shared with the Department for Health and Social Care (DHSC) when you share data through the App. DHSC does not use your IP address however and deletes it as soon as it is received. Like every other app, our app uses the internet to work which requires the use of the IP address.

The application is reviewed and tested to make sure that there never exists functionality that collects, logs, retransmits or stores the IP addresses received within HTTP headers. This minimises the possibility of recombining IP address and payload data. 

We have no intention of collecting IP addresses to attempt to identify app users and have these technical safeguards to remove any possibility of this being attempted. Protecting the identity of users, and demonstrating those protections, is a core condition of the use of the Apple/Google Contact Tracing functionality.

Anonymisation Strategy: public health data items

The same anonymisation, data minimisation and tests to ensure the items are necessary are used with data items that are used either solely for public health or for both functions. A key requirement is to protect the identity and privacy of you as an app user.

Risks of Identification outside of the app

Small numbers of contacts. 

While it is unlikely ever to happen, our privacy notice makes users aware that there are some unusual circumstances in which another person might be able to identify that they were the person who had tested positive when they receive an alert.

For example, if an App user had only been in contact with a single person and no one else, they would be able to infer who the infected person was when they received an alert (i.e. the only person with whom they had been in contact). This risk exists with manual contact tracing. 

We have noted the privacy risk in our risk register but recognise that this is an underlying risk in the context of contagious diseases and public health management.

Digital contact tracing (exposure logging and notification)

The methodology and protections that maintain the anonymity of app users through contact tracing are determined by Apple and Google. The functionality and Exposure Notification API (GAEN) that provides this service has strict conditions of access and use, which the NHS COVID-19 app uses. For both contact tracing functionality and any analysis delivered by the app – non-identification of users is a condition of access for Apple and Google. We are happy to comply with that standard.

The user data journey

These scenarios provide examples of the data generated and collected when you use the app. We have included the most relevant ways we protect your identity and privacy, through anonymising and aggregating data along with other safeguards.

Scenario: all app users

For all users who complete onboarding and are using the app, key information will be collected in the app and as part of the analytical data set. Data will be held within:

• the Apple Google functionality (the contact tracing)
• with the app (and will always be retained only within the app)
• as part of the analytical data set which will remain on the app until the app triggers the upload to the APIs that interact will the central system

Digital contact tracing

The Apple Google functionality generates a daily code for the app user, a broadcast key (changed every 15 minutes) is passed to other app users who are in contact (via Low Energy Bluetooth). An app user who tests positive for COVID-19 and who chooses to share their codes (protected as diagnosis keys) have this code added to the list of “potential risk” users provided to all app users.

Each individual user’s app will check whether they have a broadcast key associated with a diagnosis key on their phone. If a derived (i.e. a broadcast code produced from the diagnosis key) code is present and meets the set criteria – the app will alert the user. This functionality and the identity protection within this process are provided by Apple Google. However, the NHS app sets the criteria for when an alert should be issued.

Working with health services in Gibraltar, Jersey, Northern Ireland and Scotland allows app users across all of the digital contact tracing apps to support this functionality. By giving permission to share diagnosis keys, app users in England and Wales can make sure that other app users receive alerts when appropriate. This is regardless of which digital contact tracing app they use or which jurisdiction they are in.

Apple Google Exposure Notification (GAEN)

A user’s app will hold, subject to the controls of the Apple Google Functionality and provided via the GAEN.

• The broadcast keys from other app users they have been in contact with, including the details that allow the app to determine whether the user might be at risk

This enables that routine checking of whether an app user needs to be alerted of a potential COVID-19 risk from another app user. You won’t know which user from the details the app provides and we, the DHSC, cannot identify either you or the app user who generated your alert.

Data held on the app

Outside of the digital contact tracing all app users will have the details listed below on their app. The same reference material is on every user’s app.

Other, non reference, details vary with how you use the app but are only held on your phone.

The app

The app will retain the users declared postcode district, latest virology test result and any venues visited. This data can be deleted when you delete the app, through the app and even for individual venues. No history of postcode districts or virology test results are retained.

Data about the user

• QR Venues Visited - details of the venues checked into;

• Postcode District - the users current declared postcode district;

• Virology Test Results - the last test result retained for the isolation period plus 14 days.

Reference material (used to appropriately update the app user)

The app holds two sets of reference material which enable the app to function and appropriately update the user. For example, the list of risk status for postcode district allows the user to be notified about any changes to the risk score for their postcode district as well as display the baseline risk.

• Risk status for every postcode district within the app (Postcode District Area Risks)

• Full list of venues that are “at risk” with details of the relevant time period (Hotspot QR Venues)

Analytical Data

Use of the app will start to populate the analytical data set. As noted above, most are summaries or counts of function use and do not list data items. The data is generated over the 6-hour analytical period and then prepared for submission.

All users will start to generate the following data items:

Core Details

• Details about the analytical period, the postcode district, device model, Operating System and App Version;

Data Usage of the app and data submitted to the app

• Cumulative data usage for the app during the analytical period;

Service and system checks

• Key checks to ensure that the app is working as expected

Function specific

The following data items are present for all users but vary by the functions used. Where not used the data, collected will only show a zero (or nil). So if you receive no test results all of the three test results fields will be zero.

• Venue Check-In

• Test Results (into the app)

• Pause functionality

• Symptom Checker Use and Results

• Isolation Trigger

Analytical Data upon arrival at the central system

No identifiers are provided to the data as it leaves the app, preventing a user from being identified across analytical data packets (subject to additional controls). On landing data will be placed into a row and time stamp of when the data arrived.

• Row Level

Processes used to prevent re-identification

The process of alerts for digital contact tracing prevents the app user being identifiable through data provided through the app’s functionality. The matching of diagnosis keys with broadcast keys, that are derived from them, protects the identity and privacy of app users.

The following techniques are used to prevent re-identification of data received from the app (the analytical data set)

• Each data packet is sent each day without an identifier that would allow for the linking data of a user across multiple periods
• Each device sends their data packets at a random time after the analytics window closes
• Upon arrival information is removed from any data packet (such as the IP address), and processes are undertaken to protect the identity of users – such as small postcode district grouping and small number suppression
• Further reviews and safeguards are in place for the performance view and data passed to the analytical environment

Scenario: Venue Check-Ins

This example is a walkthrough of the use of the venue check-in function. This will help demonstrate what data is generated as a result.

Digital contact tracing

Venue check-in has no impact on the digital contact tracing function.

Data held on the app

For each venue successfully checked into an entry is added to the app about each venue. It will include a time stamp of when the venue was booked into as well as an accessible description of the venue (i.e. its name and location). Deletion of these details is described above.

Analytical data

Venue check-ins add a count of the venue check-ins during the 6-hour analytical period. Where the check-in fails or is abandoned this is counted as well. This data is used to ensure the QR venue check in is working as expected as well as give a sense of how app users are using the function and the potential impacts.

At the start of each 6-hour period, both counts are reset to zero.

• Venue check-in

Processes used to prevent re-identification

Only those with access to the app will have details of the venues checked into. No details about which venues a user has checked into is included in the analytical data set or provided to the use.

Scenario: contact tracing only (No test results sought, no alerts received)

You choose to just download the app and use it solely for contact tracing purposes. The app is only used for the baseline contact tracing.

The app is not used for any other purpose such as test results. They have not interacted with any other app user who tested positive for COVID-19, updated their app status and choose to share their diagnosis key alerting other app users (including you).

Outside of the app

If you test positive for COVID-19, the relevant Contact Tracing Team are likely to be in contact to establish who you have been in contact with and where you may have visited. This does not relate to your use of the app but is the normal manual contact tracing practice in public health emergencies.

In addition, if someone you know tests positive and they provide your details to the Contact Tracing team, this team will contact you. This will happen regardless of whether you have the app or not.

Digital contact tracing

In this scenario, the user is not generating any data from the use of the functions of the app.

Apple Google GAEN

As detailed for all app users. The app will hold the broadcast keys of other app users that the user has interacted with. As the users has received no alerts, none of the diagnosis keys within the reference set are relevant to the user. You would not receive an alert or a recommendation to self-isolate.

Data held on the app

Your postcode district will be held on the app, along with all the reference material provided to every app user. There will be no venue or virology test results.

Analytical Data

The core details will be collected, in addition to the amount of data used and submitted by the app. The service and system checks data items will be present and populated, indicating that the app is working as expected.

Function specific

No function specific data will be generated for inclusion as the functions aren’t being used.

Risk of reidentification

By the data controller

The data collected from app users in this scenario and provided as part of the analytical data set include a minimal amount of data about the user and their use of the app. The baseline risk of a reidentification (from small postcode district, rare phone make and model) is present but cannot be combined with other data associated with the app. No other data is held about the app user with a means of identifying them across systems. As they have not sought a test via the app or returned results to the app, even the possibility of linkage to other data sets does not exist.

By other app users

As no alerts sent or received by the user, the app user will not be identifiable to other app users even outside of the app’s functionality.

Scenario: Using all the app’s functionality

You have downloaded the app and are using all of the app’s functions. You use the app to routinely check symptoms, and where prompted will seek a test and add your test results to the app. When asked you choose to share details so that other app users can be alerted if appropriately. You use venue check-ins when prompted.

Outside the use of the app, the app user may be contacted separately to the use of the app. This will happen regardless of whether you have the app or not.

Digital contact tracing

The app user will provide their diagnosis key when prompted to the central system. This will be provided to all other app users, so the risk the user is to other app users can be assessed and when needed alerts issued whilst maintaining everyone’s privacy.

 Apple Google GAEN

• Broadcast codes of other app users along with key details that allow the proximity and length of contact to be assessed. These are not accessible to you as an app user or us (contacts detected)

• List of diagnosis keys from the GAEN that were requested from user confirmed positive and shared with other users [Diagnosis Key Sets – reference material]

Data held on the app

The app will hold details of all the venues checked into, unless deleted, test results and postcode district of the user. The key differences with other app users will be the amount of venues listed and the current test result.

The same reference material is available to all app users.

Analytical Data

The set of analytical data will reflect the use of all the app functions. However, the data is a count or sum of data use. It will hold the: Core Details, Data Receipt and Transmission, as well as Service and system checks.

Function specific

All of the function specific data items will be collected. The combination may be particular to a user but (a) would, in part, reset every 6 hours and (b) be unable to be linked to the particular app user from the data retained.

For most data items, they are unlikely to be unique to any particular user. They cannot be linked to other data sets and would not identifiable in themselves.

Risk of reidentification

By the data controller

Despite the greater use of app functionality there is not a significantly greater risk of identification beyond the baseline. The data controller would need to know more details about the app user and their phone than is retained in the analytical data set.

Protections in place to ensure that test results are appropriately returned are crucial for maintaining the privacy and identity of the user. This is supported by the prompt deletion of the test code once results are returned to the correct app user.

By other app users

Other app users would need additional information outside of the context of the app in order to identify another app user. The protections within the app ensure that the app ensures the privacy of all app users. In the “rural postman” scenario, an app user would have a limited number of contacts during the week and would be able to make an educated guess about which other app user had triggered an alert and has tested positive for COVID-19.

However, in such circumstances the individuals are likely to also be in contact with local Health Protection Teams (HPTs) and manual contact tracers. In such circumstances, which are routine for communicable diseases (as defined in law) and the COVID-19 public health emergency. The risk from users from the app is no greater and considerably less likely than the baseline risk of identification in public health situations which is necessary for the management of health risks to the public.

Scenario: Testing (via the App)

You have used the symptom checker and have been recommended to take a test. The user generates a code through the app, which accesses the test code generating API. The test code is passed to the relevant testing website. These websites are external to the app (and is treated as a separate “data ecosystem”) and data associated with testing is held separately to data about app users. The app token is short-lived and created specifically upon requested.

Scenario 1: test booked via mobile app

Scenario 1: test booked via mobile app

The swab sample taken from the user, whether at home or via on-site testing, is linked to a barcode no identifiable data accompanies the test and no app token is included (the app test code). The test results are returned to the person seeking the test via email and SMS (text message).

The app system is informed of the test result associated with the token (app test code). No identifiable data flows to the app from testing. The app periodically checks if a result is available, when it is the app is updated and the result deleted from the central systems once confirmed as sent to the correct app user.

The test result must be returned to the correct app user which is regardless of whether the result is positive, negative or void.

Returning the results and protecting the user’s privacy

The technique used to provide app users with their correct result also ensure that the identity of the user is protected. When the app recommends a test for users it requests three separate tokens. These are generated by services outside of the app and are not recorded in the app. They are unique and anonymous and cannot be derived from each other or any other information.

These three tokens allow the correct information to be returned to the correct user whilst maintaining their privacy and ensuring that data cannot be linked. We dealt the tokens promptly once we’ve updated the relevant app.

Digital contact tracing

If you test’s positive for COVID-19 and receive or add your results to the app, you are prompted to share your diagnosis key with the app’s central system. If you choose to do so, this key is added to the list of diagnosis keys provided to all app users.

Once received by other app users, the app’s functionality (using the risk algorithm) combines with Apple Google’s functionality to see if they need to be alerted.

This enables the app to check the broadcast keys it holds to determine if any are derived from any diagnosis keys in the reference pack. As broadcast keys change every 15 minutes, diagnosis keys are associated with the daily code and the checking mechanism is in the hands of Apple Google, the app user’s privacy and identity is protected. The anonymity of the user is preserved from the DHSC (government) and other app users by the functionality of the app.

Apple Google GAEN

Data held will be in line with other app users.

Data held on the app

In addition, to other data held on the app it will hold the app user’s test result for the relevant isolation period plus 14 days. A positive test result will trigger the self-isolation timer to commence.

Analytical data

For void or negative test results this will be added to the analytical data set. For positive test results this will also be included for a period of 14 days In addition, the self-isolation countdown will commence and relevant background checks will check in. These monitor the users compliance with isolation but are not used for enforcement and privacy safeguards prevent the app for being used for this purpose.

Relevant data items

• Test Results (into the app)

• Symptom Checker Use and Results

• Isolation Trigger

Processes used to prevent re-identification

Within the app and with contact tracing

The process of alerts for digital contact tracing prevents the app user being identifiable through data provided through the app’s functionality. The matching of diagnosis keys with broadcast keys, that are derived from them, protects the identity and privacy of app users.

Within the analytical environment

No data specific to the test process, code or process (other than the result) is retained in the app analytical environment.

Within the testing system from website through to the return of the results

See above for how the use of tokens and testing system protects the identity of users.