Centralised autonomous contact tracing using Bluetooth proximity

Type of solution

Autonomous contact tracing (person-to-person proximity)

Examples

• UK
• Singapore
• France
• Australia

Main Characteristics

• Exchanges temporary identifiers during encounters
• Makes use of pseudonyms linked to a device or optionally a user
• Centralized data storage of all observed encounter identifiers by trusted third party
• Bluetooth proximity detection between devices equipped with an app that supports that same protocol
• Out-of-band attribution of ‘infection confirmation’ code by a government approved healthcare instance

Outcome Coverage

Informing Citizens	Transmission Tracing	Supporting healthcare provisioning	Informing Policy Making and monitoring effectiveness	Optimising resource allocation	Organising Quarantining	Enabling Research
Possible	Encounters	No	Possible	Possible	Interoperability possible	Possible

Requirements coverage - effectiveness

Effectiveness Factor	Assessment
Accuracy of information	Circumstances for false positives and false negatives in encounter detection have been described (see Solution Component - BlueTooth). The impact on the effectiveness is not quantified. Bluetooth only is not enough to assess the criticality of the encounter. Were people face-to-face, wearing face masks, having physical contact, …? Bluetooth as a distance indicator has limitations. Calibration could definitely help with the accuracy of the BLE proximity estimations (but is no silver bullet) See also: Solution Component - BlueTooth A mechanism is foreseen to have health authorities issue the confirmation of an infection Calibration could definitely help with the accuracy of the BLE proximity estimations (but is no silver bullet)
Speed of the process	After confirmation of infection, first degree contacts can immediately be informed Possible to model (and inform) up to 5th degree contacts The possibility to coordinate with other actions can further reduce the time between confirmation or suspicion of infection and affective isolation or quarantining.
Adaptability of the solution	The algorithm for deducing the criticality of the health exposure is central, hence easy to update.
Insights in transmission routes Person-to-person, environmental Presymptomatic Asymptomatic	Only encounters are detected (no visits, no health status beyond infection status, no movements Proximity tracking only covers person-to-person transmission. Environmental transmission is not covered. Contacts up to the 5th degree can be detected. There is not necessarily a filtering of the users being included in the contact graph (eg based on their risk profile) Non-users are not included in the contact graph. Presymptomatic and asymptomatic cases are covered.
Support of isolation and quarantining	Quarantining is triggered through a notification sent out by a trusted healthcare authority that links with other supporting instances Individuals who are advised to quarantine by authorized healthcare instances can be supported socially and economically (e.g. proof of absence for their employer)
Targeted measures	The collected data can be used for creating insights that can lead to targeted measures
Efficient use of resources Triage Testing Contact tracers	HCT can benefit from the data gathered via ACT and can alleviate their resources
Interoperability	With strict user consent, data can be made available for epidemiological research Research and modeling is possible on aggregated and/or filtered data sets while the pandemic lasts The use of a shared identifier enables many use cases
Acceptable side-effects	This cannot be stated in general. It is possible to implement this kind of solution with protection against unauthorised insight in the health status of the user through observation or coercion. But lack of attention for this aspect can be harmful. Abuse of data is not impossible.
Adoption and population coverage	The adoption rate could be hampered by the inherent distrust of uncertainty that comes with having to trust a central instance with valuable information
Feasibility and elapsed time (Experience, Initial TTM, Scaling)	The Bluetooth technology was not designed with this type of application in mind. Shortcomings include energy consumption and limitations in the support in Android and iOS. The improvements projected by Apple and Google for their Exposure Notification Framework is not available for apps with centralisation of data, so fallbacks are needed (see Solution Component - Bluetooth), none of which have proven to be satisfactory.
Technical dependability of the solution	If implemented with early centralisation of data (as opposed to uploading when an infection is confirmed) the working of the solution is not dependent on the availability of the user devices.
Evidence	Where this kind of solution has been used, uptake has been below expectations (e.g. Singapore) in number of downloads. It is not clear what the actual usage rate is. It is unclear what impact the use of the solution had.

Requirements coverage - Privacy and Security

Privacy Factor	Assessment
Minimal Requirements GDPR compliance	Compliance is possible, but is case-specific. Debate possible about the proportionality of the data collection: data of all users are processed regardless of their being infected or potentially affected. One can argue that this comes with the benefit of reduction of the elapsed time between a potentially risky encounter and a warning.
Augmented Requirements Adhere to the joint civil society statement: “States use of digital surveillance technologies to fight pandemic must respect human rights” (see Joint Civil Society Statement) Solution is temporary Purposes are limited to responding to the pandemic and phasing out the restrictive measures Principle of least privilege The way back to normality is known Full Transparency (code, data, algorithms) Granular user consent, regardless of the legal base No mandatory use by citizens No access to data except for public health authorities, subject to consent Strictly limited retention period No support for law and policy enforcement No commercial exploitation	Alignment is possible, but is case-specific.
Zero-Trust model specific requirements No trust must be expected from any party besides the developer The solution must only transfer and centralise truly anonymous data The anonymous nature of the data must be transparent and under scrutiny The remaining surface attack must be secured Transparency and scrutiny on the security measures	Not applicable
Trust-based specific requirements Proper governance and oversight on the Trusted Party to strictly limit the processing to the stated purpose Vetting of the personnel having access to the data Applying the Principle of Least Privilege among the personnel of the data processor Code of conduct for the personnel, actively enforced Strict application of encryption in transit and at rest until the latest possible moment before processing Reducing the attack surface to a minimum and securing it Systematically distrusting any party not under direct control of the Trusted Party (like infrastructure providers) Transparency and scrutiny on the security measures Pseudonymisation without storage of re-personalisation data Shortest possible retention period, preferably rolling Applying data minimisation, limit the data centralised	Compliance is possible, but is case-specific.

Trade-off Analysis

Bluetooth only:

• Avoids the privacy challenges linked to gathering location data
• Limits the transmission routes to person-to-person only

Shared identifier and centralisation of data:

• Allows linking to other data, allowing interoperability and efficient use of resources
• Rules out the use of Apple/Google Exposure Notification Framework and foregoes the Bluetooth improvements
• Requires more privacy and security safeguards in order to comply with the augmented requirements

Not being able to use the Apple/Google Exposure Notification Framework:

• Forces suboptimal Bluetooth functioning and resulting battery drain, which in turn might lead to a poorer adoption rate. (see Solution Component - Bluetooth)

Discussion and open topics

Discussion, including ethical considerations

The interoperability and adaptability that is enabled by this solution increases its value towards the other parties essential to the effectiveness of the overall system (human contact tracers, healthcare providers, social security, analysts and researchers and in turn policy makers).

This increases the beneficence of the solution, possibly in proportion to the increased privacy footprint. This proportionality is subject to the compliance with the specific requirements for trust-based solutions, which is a high bar to meet and can only be assessed case by case.

A trusted third party needs to be identified, empowered and shielded from forces that do not adhere to the core of the purpose set forth. Once found, the general public will need to be convinced of those guarantees as well, a tough challenge in any situation.

Open Topics

Do the benefits of a shared identifier, which enables many use cases for epidemiologists and other researchers and in turn policy makers, outweigh the inherent privacy concerns?

Is there value in 2nd and higher degrees of contact mapping?

Without any notion of location information, it is possible to use the available information be direct test capacity (affected individuals should be tested according to the protocols)

How well will the hybrid BLE approach for contact tracing work (especially compared to the Apple-Google protocol)?

How can the trust in the third party be guaranteed and how can we give credible assurances to the users that there is no way their data would fall in the hands of institutions outside of the scope of the battle against the pandemic?

And even if such guarantees could be provided, in theory and in practice, creating that perception with the end-users is yet another challenge that needs to be tackled.

Navigation

• Next: Human contact tracing
• Previous: Centralised autonomous contact tracing using Bluetooth proximity
• Back to overview