Difference between revisions of "Decentralized autonomous contact tracing using Bluetooth proximity"

From Appiaplus
Jump to navigation Jump to search
(Blanked the page)
Tag: Blanking
Line 1: Line 1:
= 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 =
 
 
{| class="wikitable"
 
| '''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 =
 
 
{| class="wikitable"
 
| width="30%" | '''Effectiveness Factor'''
 
| width="50%" | '''Assessment'''
 
|-
 
| Accuracy of information
 
|
 
* Circumstances for false positives and false negatives in encounter detection have been described (see [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing 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: [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing 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 [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing 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 =
 
 
{| class="wikitable"
 
| width="30%" | '''Privacy Factor'''
 
| width="50%" | '''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 [https://www.hrw.org/news/2020/04/02/joint-civil-society-statement-states-use-digital-surveillance-technologies-fight 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 [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing 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 =
 
 
* [[Human contact tracing|Next: Human contact tracing]]
 
* [[Centralised autonomous contact tracing using Bluetooth proximity|Previous: Centralised autonomous contact tracing using Bluetooth proximity]]
 
* [[Overview|Back to overview]]
 
 
[[Category:Solution]]
 

Revision as of 11:23, 21 May 2020