Dynamic quarantine: a proposal for combatting COVID-19 with pinpointed action based on real-time information

This post provides more details on the “Dynamic Quarantine” exit path from the COVID-19 pandemic that I listed in a previous post.

The problem

We need to reduce transmission of the virus to a level where the number of infected people at any time shrinks, rather than grows.

Absent vaccines or other medications, this requires reduction of in-person contact between people (“social distancing”).

However, this makes normal functioning of the economy largely impossible. For example, the state of California just ordered all “non-essential businesses” to be closed. While this may work in the short term, the longer the lock-down continues, the more things “break”: from mass unemployment and resulting poverty/defaults/bankruptcies, to the availability of replacement parts and eventually essentials such as food.

Such “social distancing” may need to continue until a vaccine is available, which may take many months (12-18 months is a common estimate). It is unclear how to keep the economy functioning enough for such an extended period of time.

We need better ideas.

The basic idea

Instead of a blanket shutdown of all “non-essential” businesses, confining “everybody” to their residence, we could shut down only those businesses in which infection is likely, and confine only those people to isolation whose likelihood of infecting somebody is higher than a certain threshold. In this approach, those likelihoods are dynamically determined by means of data collection mostly through mobile phones, and an algorithm that produces a corresponding score for each person from the collected data.

The likelihood of a subject infecting somebody is determined as a function of what is known about the health of the subject so far, plus a history of the subject’s interactions with other people and those people’s likelihood of infecting somebody.

By tracking this information in real time, the blanket closure of businesses and blanket shelter-in-place of the population can be avoided, and instead be replaced with a sharp, pinpointed focus on isolating those that are most likely contributing to the spread of the disease. The remainder of the economy and population can continue to function.

Certain parameters in the algorithm can be tuned to provide different tradeoffs between reducing spread and inhibiting (or not) the economy.

Infectiousness score

The infectiousness score in this approach is an estimate for the likelihood that one person infects another when exposed for a certain time period (e.g. 5 min).

For our purposes here, the infectiousness score is a number between 0 and 1, where 0 means: not infectious (e.g. because a highly reliable test has just cleared the subject) and 1 means: known to be maximally infectious (e.g. because viral loads have been found to be high, and the subject behaves promiscuously).

Details

A few definitions first:

• P: a person (aka subject)
• S(P,t): the infectiousness score of person P at time t. Ranges between 0 (not infectious) and 1 (maximally infectious).

The core algorithm is as follows. It deals with direct infection between two people only, but an extension is discussed below.

• At each time unit (e.g. every hour), S(P,t) is calculated as a function of:
  • S(P,t-1): the infectiousness score of the person at the time prior;
  • S(Pi,τ): the infectiousness score of all people Pi that the subject interacted with in the time period τ = (t-tw) ... (t-1) (where tw is a parameter that determines the length of the time window that’s being considered; selection of this parameter depends on characteristics of the disease, such as incubation times, as well as the characteristics of enacted community interventions such as availability, frequency and accuracy of testing);
  • a rating of the subject’s current health derived from the subject’s self-assessment;
  • a rating of the subject’s current health based on information from the future (see below).

Rewriting history:

• Test results come in with a delay (e.g. one day between tTest and current time t). Once available, the estimate for the infectiousness of the subject between tTest and t will be “overwritten” with an updated, more accurate estimate for that already-passed time period that takes the results of the test into account.
• Similarly, subjects may be infectious prior to experiencing any symptoms. Once symptoms are apparent, all prior estimates of infectiousness of the subject will be recalculated over some time window whose length is determined by some assumptions about the disease (incubation time, time of infectiousness prior to symptoms etc).
• When subject P’s history is rewritten, the histories (and current score) need to be recalculated and rewritten of all subjects that have previously taken the history of subject P into account for their own scores. They need to now use the rewritten history. This may happen recursively. History may be overwritten repeatedly for a given subject, which again triggers rewrites for other subjects. (More efficient algorithms producing the same result can be found.)

Additional potential inputs to the algorithm:

• A rating of a subject’s interventions that may modify their infectiousness, such as:
  • wearing a mask;
  • intentionally exhaling at others;
  • etc.

Extension to other forms of transmission

So far, we have assumed that transmission can only occur between two people in the same location. However, there are other forms of transmissions, such as:

• transmission via a contaminated surface within a certain time interval that the virus remains active on that surface;
• transmission via air droplets in an enclosed space with a certain time interval.

To account for these forms of transmission, the algorithm is extended to also include estimates of the infectiousness of objects in certain locations. Similar to people, these objects have an infectiousness score that is a function of which people (and their scores) have interacted with it in times prior, its previous infectiousness score and the passage of time.

The score of objects in the vicinity is considered as part of the algorithm to update S(P,t) in a corresponding manner to that of people.

User experience

• Users run an app on their mobile phones.

• From time to time, the app asks the user about how they feel. Specifically it asks about symptoms related to COVID-19, such as fever, fatigue, cough etc.

• The app’s main screen shows an easy-to-understand visual representation of the likely infectiousness score, such as a color code (e.g. green: unlikely to infect).

• When the app reports a score above a certain threshold, the subject goes into shelter-in-place or quarantine. (Legal questions about whether this is voluntary or legally required are out of scope for this discussion; certainly regulations such as “must be sheltered-in-place unless score is green” would be possible.)

• Before two (or more) people meet in person, they can agree on a maximum score that participants are allowed to have to be allowed to participate in the meeting. (Such a maximum score may also be legally mandated.) The participants in the meeting check each others’ scores before the meeting.

• Before a business admits a customer (or employee) onto the premises, they require the customer or employee to share their score. They will be denied access if the score is above a certain threshold. They may also deny access to those visitors who do not have, or are unwilling to display their score.

• When the user gets tested, they enable the testing provider to add the test results to their record so it can be used to calculate the score going forward.

• Depending on the implementation choices made, the mobile phone may need to be connected to the internet, to a local WiFi network and/or have Bluetooth on as sender or receiver or both.

Assumptions / challenges

• Test results can be brought into the system in a way that defeats tampering: we cannot allow a subject to fake negative test results, for example, or eliminate from consideration positive test results.

• Individuals may be tempted to fake their scores in order to enter a certain venue, for example, such as by displaying a static screen shot on their phone instead of their live score. Technical means (e.g. timestamping the display, or simultaneously broadcasting the score via wireless networking) can be employed to make this more difficult. This approach would also use technical means (e.g. public keys, app stores) to prevent “rogue apps” with false scores to participate.

• In a naive implementation, the entire record of each subject (e.g. the entire world population) would be centrally collected. This would create a privacy nightmare and enable substantial future harm from dangers that are not biological in nature. So we assume that the implementation would need to be performed in a fashion that does not have a central point of data collection.

• Location accuracy for this app is paramount. The absolute coordinates are less important; but relative coordinates between two subjects need to be determined as well as possible, as a distance of 2ft vs 8ft has substantially different impact on likelihood of transmission. This could be addressed with technical means (e.g. Bluetooth, NFC), user input (e.g. verify / enter into the app the people currently in close proximity) or a combination.

• The space in which an encounter occurs is highly relevant. For example, a 10 min contact at 6ft inside a small, enclosed space without ventilation has dramatically different transmission characteristics than contact of the the same duration and distance in open nature with a slight wind. This also could be addressed with technical means (e.g. mapping information), use input (e.g. enter into the app whether the surroundings are enclosed space, ventilated, open window, city street, open nature etc) or a combination.

Approach to Privacy

It appears possible to keep most information needed for the functioning of the system on individual users’ mobile phones without requiring a centralized data repository:

• The algorithm can run locally on local data.
• Detection of other people in the neighborhood can be performed via local wireless networking (e.g. WiFi, zeroconf, Bluetooth).
• The communication between mobile phones of people in an encounter to exchange scores can be performed using secure end-to-end encryption between the phones using any networking technology including through a centralized backend. This would not compromise privacy significantly.
• To trigger history rewrites in other phones, those connections to other phones can be remembered and re-activated (including identity / encryption keys). This may use some existing centralized communication network (e.g. instant messenger) or a decentralized alternative with a distributed hash table for lookup, for example.
• None of the functionality, or communications require more than pseudonymous identity. No centralized account, or identity verification is required, with the potential exception of entering verified testing results. However, in this case, the identity correlation remains local on the user’s device and is never shared beyond.

Public health reporting and management

• The app can report scores to the public health authorities, who have the ability to track actual – and best-guess estimates – of the spread of the disease in real time.
• For privacy reasons, scores do not need to be associated with other identifying attributes, although it may be advantageous to share demographic info such as age, and approximate (maybe rasterized) geographic location of the subject.
• Key parameters of the algorithm – e.g. thresholds for “acceptable” scores for certain activities – could be centrally updated by the public health authorities, in order to “shape” the progression of the disease in real time.

Algorithmic improvements

• The intentional distribution of data and computation, instead of centrally collecting it all, for privacy reasons, needs to be weighed against the need to continually debug, and improve the algorithm.
• To be able to understand the functioning of the algorithm in the field, and to make improvements, it appears sufficient to report the time histories of scores centrally, including rewritten histories. It does not appear necessary to identify the specific other people whose scores were used as input to the algorithm, nor the locations where encounters took place.
• Should more detailed information be required, collecting such more detailed information from a relatively small sample of volunteers should be sufficient.