Modular approach

Introduction

In this section, we discuss a concept of modular solution encompassing multiple building blocks. We explore their contribution to the overall system and to the outcomes expected and explore data capture with the best level of data minimisation. Finally, we discuss scenarios for assembling the building blocks.

Principles for data capture

Based on the requirements and the technical solution components (see Bluetooth proximity tracking and Geolocation tracking following data capturing techniques seem adequate:

Encounters

For person-to-person transmission

Use BlueTooth proximity tracking augmented with information about the context.

• 1 degree, up to 2nd degree contacts can be warned without centralisation
• For more degrees a centralised graph is required

Visits

Expected outcome is to be able to identify places where environmental transmission might have happened, sanitize the place and warn visitors

Use Filtered location data targeted to Points of Interest:

• Keep all location and movement registrations local
• Match location and movement registrations with a curated list of points of interest. This list can be changed.
• When infected, upload the list of visited locations to the server. Allow the user to curate the list.
• Make anonymous counts of unique visits of people per time-slot to a point of interest in a predetermined list.
• Analyse the risk of a location being the cause of infections (either through environmental transmission or through presence of non-users) based on visit counts and infection counts.
• Confirm the location’s suspected status and risks for visitors through observations.
• If confirmed, distribute a list of suspected time-slots per point-of-interest to charged phones and have them match their location and movement data. Alternatively, have phones check their visits against the server (whatever is safe and performant).
• Ask affected users to contact the contact tracers to assess their risk profile and define appropriate measures.

For achieving the outcome of identifying suspected points-of-interest and warn visitors, there is no need for matching all location and movement data, visits to suspected points-of-interest are sufficient.

Participation in public transports

Expected outcome: identify transport modes that could be a source of environmental transmission

• Detect transportation modes and times on the phone, ask confirmation and context.
• Upload when infected.
• Treat as visits, but instead of having a curated list of transports, create a list based on the uploaded transports.

Caveat: see [[Geolocation tracking]

For movements / flow analysis

Expected outcome: map the past, current and expected evolution of the epidemic

Work with aggregated locations comparable to cell phone data aggregation, with thresholds to ensure anonymity. Correlate with health status aggregations at the same level. Value is in having leading indicators on health (not waiting for consultations or diagnosis). For privacy reasons, refrain from combining movement and health status (to avoid abuse for law enforcement).

Share encounters and visits information

• With contact tracers for avoiding double work, allow follow-up on the inquiries so as to ensure isolation and self-quarantining are enabled.
• With healthcare providers
• With facilitators of quarantining

Building Blocks

• Proximity tracking via Apple/Google Framework
• Proximity tracking via DP3T framework without Apple/Google
• Proximity tracking with context and upload
• Visits and transport tracking through location data with context and upload
• Visits and transport tracking through QR code scanning with context and upload
• Visits and transport tracking through BT beacons with context and upload
• Symptoms diary and pre-anamnesis
• Contacts diary
• Certificates workflow
• Targeted communication
• General communication
• Interface with human contact tracing
• Interface with epidemiological mapping

Proximity tracking with Apple/Google Framework

Using the A/G Framework would force to implement the other functions in a separate solution, as A/G prohibits the use of location data and the centralisation of non-anonymous data.

Proximity tracking via DP3T framework without Apple/Google

As the framework is open source, it could be used for building a part of an app that also performs other functions. Whether the DP3T consortium would back and/or support the development of an app with a location component and centralisation of anonymous data is to be discussed.

Proximity tracking with context and upload

• Context:
  • use location to locally detect the context of the encounter (inside or outside, shop, event, ...)
  • Ask the user for type of interaction (face-to-face, physical contact, face mask)
  • Ask the user whether the other party is known
• Use case:
  • Use the context in the risk algorithm
  • Upload the proximity tracks and the context to the contact tracers system for assessment and follow-up

Visits and transport tracking through location data with context and upload

• Visits and transport:
  • Use location to detect (locally on the phone) if a user is visiting a point-of-interest or is using public transport
  • (see description of protocol higher)
• Context:
  • Deduce context from the point of interest
  • Ask the user for the context of possible interactions (face mask, crowd, touching objects, physical contact, social distancing, ...)

Visits and transport tracking through QR code scanning with context and upload

• Use case: only for managed locations, eg meeting rooms, public transport, buildings
• “If you want to easily track your visits/transports, scan here”

Visits and transport tracking through BT beacons with context and upload

• Use case: only for managed locations, eg meeting rooms, public transport, buildings
• Fixed certified beacons.

Symptoms diary and pre-anamnesis

• Use cases:
  • Pre-disease self-diagnosing (eg health / symptoms diary)
  • Preparing a doctor’s visit (eg pre-anamnesis / medical history / triage)
  • Post-diagnosis contact on treatment and symptoms evolution
  • Epidemiological surveillance based on symptoms self-diagnosis, with the expected benefit to be leading indicators of outbreaks
• Specific requirements:
  • As these are sensitive data, they need to be specifically protected, assuring that only an MD with a declared and verifiable therapeutic relationship with the patient has access to it. Only summarised normalised data (infection indicator, appearance of specific symptoms) can be shared for epidemiological surveillance after consent of the user.
  • eHealth libraries and services and eHealth compliant hubs can be leveraged for creating a proper storage and access solution. This requires the custodian of these data to be certified by eHealth.

Contacts diary

Assist the user in keeping track of encounters, visits and transportations so as to support a potential interview with a contact tracer.

This could be any combination of multiple techniques:

• Manual input
• Having individuals meeting each other scanning their mutual QR codes
• Having users scan the QR code of a place or public transportation vehicle
• Having an app prompt the user when no movement is detected to confirm a possible encounter
• Having the app prompt the user when multiple Bluetooth signals are detected to confirm the presence of a crowd
• Having the app detect the crossing of a geofence and ask the user to confirm a visit
• Having the app add location and timestamp to any observation
• Voluntary anonymous participation in surveys
• Voluntary sharing of (filtered) location data.

Certificates workflow

• In order to lower thresholds for compliance with the self-quarantining instructions, people need to have easy access to whatever official information and certificates are needed for them to obtain leave of absence from their work, allowances, priority access to testing, to PPE material or to any kind of appropriate support. Also, non-professional caregivers should be mobilised and supported also.
• This requires coordination and protocols among the entities involved. Triggers for this workflow need to be certified as we are talking about non-yet-diagnosed individuals (as opposed to a workflow for medical care which is triggered by the MD).

Targeted communication

• Types of information:
  • Targeted preventative guidelines and warnings need to reach the right individual.
  • Notifications for other building blocks
• There could be value in messages triggered by time, duration thresholds, crossing geo-fences, ...
• These messages can be triggered by local logic running on the device or be authored and sent by a central system or a human. Logic and content need to be adaptable to new insights and improvements in information protocols.

General communication

• Types of information:
  • General preventative guidelines and warnings
  • Information about the status of the pandemic
  • Information about the measures and policies
• This requires a content management system and content managers / editors.

Interface with human contact tracing

• As the coverage and methods for autonomous and human contact tracing are complementary, there is value in giving the human contact tracer insight in the information gathered by the autonomous contact tracing solution (see ‘upload’ functions in other building blocks) and the ability for the human contact tracers to reach out to the contacts of the index cases.
• Following measures can be taken to preserve the privacy of the contacts:
  • Upload only the number of contacts without further consent.
  • Send a request to the affected users for uploading their contact details.
  • Match the contact details with the details provided by the index case, so as to be able to tick off who was already identified and tracked.

Interface with epidemiological mapping

• There is value in having information about the dynamics of the virus. This encompasses following information at an aggregated level:
  • [see elsewhere]

Scenarios

As Apple/Google and DP3T are opinionated on the type of information and the architecture of solutions, solution builders are constrained in their choices.

Basically, the use of the Apple/Google framework (and the included improvements of background use of BLE) prohibits any use of location data or centralisation. This means that Apple/Google framework based solutions must be limited to proximity tracking without coordination with human contact tracers. This cuts out some legitimate improvements on effectiveness.

DP3T is justly based on privacy by design and by default, heavily emphasising data minimisation. When defining the scope to the autonomous detection of contacts, this eliminates the need for location data and for centralisation. However, one can argue that more public health benefits can be obtained when extending the scope to include visits and transports, added context for encounters, and collaboration with contact tracers. This could still be proportionate to the purpose. The authors open up their reasoning for scrutiny by anyone.

If some building blocks cannot be endorsed by the DP3T consortium, a solution can still be maximally based on the strong insights of DP3T for privacy-preserving proximity detection. Aspects where the solution departs from the DP3T principles need to be highlighted and argued for maximal transparency.

Navigation

• Next: List of scenarios
• Previous: Geolocation tracking
• Back to overview