# Framework in practice

Contact tracing as a personalization framework

Published: April 8, 2021

### Summary

• Several rule-based predictors and recommenders for PCT framework are discussed

### Setup

In this post, we discuss how the framework is realizable in practice. The peer-to-peer Bluetooth communication protocols like GAEN, Covid Watch, and COVI were proposed earlier in the course of the pandemic. For our purposes, we assume a simplified protocol that exchanges a unique key every time two PCT-configured devices are within 2 meters for at least 15 minutes. We will also assume that these devices can communicate warning signals (i.e., N-bits or an integer between 0 and $$2^N - 1$$) via these keys at any time in the future. Note that this is similar to COVI protocol. However, we speculate that other protocols can also exhibit similar functionality.

We also assume that the app is designed to gather information such as pre-existing conditions, daily symptoms, or diagnostic test results from users. This basic UX exists in most of the existing contact tracing apps (e.g., NHS COVID-19, COVID Alert). Finally, under the framework, we assume that warning signals of varying intensities received by the user device are also available to the predictor.

Since the warning signals from the predictor feedback into itself, we want these predictions to be increasingly monotonic in warning signals’ intensity. To be specific, for some fixed inputs, replacing the highest intensity warning signal with a warning signal of lower intensity should not increase the estimated viral load. This way, these warning signals will die out as one moves away from the source if there is no additional information (e.g., user symptoms) available along the course.

Formally, this problem is at the heart of distributed inference, which requires agents operating in a network to infer a global hidden state using locally available inputs. In our setting, a global hidden state is the viral load of each individual in the population. The predictor’s task is to estimate app users’ viral load using the locally available information. The existing techniques for distributed inference require some visibility into the contact graph, i.e., who meets whom, which has been a hindrance from the privacy point of view. Our reliance on warning signals eliminates the need to store contact graphs, thereby complying with privacy constraints. However, it makes the task of distributed inference even more challenging. Thus, in this and the following post, we will discuss predictors with gradually increasing sophistication.

Finally, we expect the predictor to estimate individual viral load for today and some days in the past. For SARS-CoV-2, we predict viral load for 14 days in the past as per the guidelines earlier in the pandemic. This way, the estimated viral load for a particular encounter-day is discretized into an integer between 0 and $$N$$ and sent to the other device as a warning signal. The user is recommended appropriate precautions depending on the estimated viral load for the current day. Thus, the following sections will also discuss the design of a recommender after designing a predictor.

### BTT from PCT

The binary test-and-trace (BTT) system uses only the diagnostic test results as its input and recommends self-isolation to everyone who encountered this user in the past 14 days. Therefore, the following predictor and recommender enables BTT (N=2)

Predictor Recommender
• Set the warning signal for today and the past 14-days to 4 if the user reports a verified positive test result
• Set the warning signal for today and the past 14-days to 2 if the user receives a warning signal with intensity of 1
• Set the warning signal to 0 otherwise.
• If the current warning signal is greater than 1 recommend self-isolation else do nothing
Table 1: Predictor-recommender pair for the PCT framework to yield BTT.

### NHSx from PCT

NHS COVID-19 has a clever scoring mechanism NHSx to infer the risk of contagion due to the user who reports symptoms. The following predictor and recommender show their approximate formulation on the PCT framework with 2 bits allowed to be passed between the devices.

Predictor Recommender
• Set the current warning signal as 4 if the user reports symptoms informative of COVID-19. If the symptoms are reported on day ts, then the past 14-day's viral load is inferred using a gaussian distribution with the mean at ts-0.3 days and some fixed variance (section 2.1 of Briers et al.). The offset of 0.3 is to accommodate the empirical studies suggesting the viral load peaks 0.3 days on an average before the symptoms appear. Finally, according to a scoring mechanism that uses this estimated viral load and other encounter attributes (e.g., signal attenuation and duration), a likelihood of contagion is calculated for that encounter. This likelihood is discretized into a warning signal and sent to the other user involved in that encounter.
• Set the current warning signal to 2 if the sum of warning signals received by the user is greater than some calibrated threshold. Note that we do not need viral load estimation for the user away from the source as we do not propagate this information further.
• If the current warning signal is greater than 1 recommend self-isolation else do nothing
Table 2: Predictor-recommender pair for the PCT framework to yield NHSx.

### Covid Watch App from PCT

Covid Watch App being used at the University of Arizona has another clever risk scoring mechanism that can be formulated in the PCT framework.

Predictor Recommender
• Set warning signal for the current day and the past 14-days using the GAEN API's transmitter risk assessment. This happens at the source i.e. the user who reports symptoms or test results. The risk assessment protocol might differ depending on the implementation.
• Compute the risk for the user receiving the risks from the source according to a well calibrated model that captures physics of interaction. Specifically, if the user receives a risk score of rm for an encounter m, compute their likelihood of getting infected according to a model that considers several possible viral load transmission scenarios in an interaction. These scenarios include various trajectories that a viral load blob might take depending on the encounter's distance and duration. For further details, refer to the Figure 1 of Wilson et al..
• if the (receiving) user's computed risk is greater than some threshold, recommend behaviors according to the tables in Figure 3b and 3c of Wilson et al., which depending on the attenuation of bluetooth signal (measure of encounter distance).
Table 3: Predictor-recommender pair for the PCT framework to yield Covid Watch App.

### An example heuristic for PCT

The above predictor-recommender pairs do not propagate the risk scores (or warning signals) beyond 1-hop distance away from the source. As a simple example, consider the set of rules in Table 4 that generates warning signals for users 2-hop away from the source (N=2 bits is assumed). We have divided the inference into two categories depending on the type of input used. User-dependent inferences rely on observable signals like symptoms or test results. In contrast, warning-signal inferences rely on the warning signals received from other users. These inferences result in their respective warning signal estimates for the current and the past 14-days. The final warning signal for a day is the maximum of these estimates.

Predictor Recommender
• (user-dependent) Estimate the warning signal as 3 for the current day and the past 14 days if the user reports a positive test result
• (user-dependent) Estimate the warning signal as 2 for the current day and the past 8 days if the user reports highly informative symptoms. We use 8 to add a safety margin of 3 days to the incubation period of 5 days.
• (user-dependent) Estimate the warning signal to 1 for for the current day and the past 8 days if the user reports less informative symptoms (e.g., cold symptoms)
• (warning-signal-dependent) For each day d in the past 14-days and the current day, apply the following rules
• Estimate warning signal for d to 2 if a warning signal of 3 is recieved on day d
• Estimate warning signal for d to 1 if a warning signal of 2 is recieved on day d
• Estimate warning signal for d to 0 otherwise
• (aggregation) Finally, set the warning signal for the day d as the maximum of the above estimations
• If the current warning signal is 3 or 2, recommend self-isolation
• If the current warning signal is 1 recommend certain cautionary behaviors like to avoid unnecessary contacts or public transport
• Otherwise there will be baseline recommendations
Table 4: A simplified example of a predictor-recommender pair for the PCT framework that propagates warning signals to the user 2-hop away from the source of positive test results.

Through these rules, users 1-hop away from the source of positive test results are asked to be as cautious as the source that reports informative symptoms. Hence, it resembles the previous predictor-recommender pairs. In addition to that, users 2-hop away from the source of a positive test result are asked to be as cautious as users 1-hop away from the source of highly informative symptoms. Thus, the users 2-hop away are cautioned earlier than in the rest of the above methods.

Finally, with the help of domain expertise, these rules can be modified to be smarter. We can also replace the scoring mechanism in the above rules with that of NHSx or CovidApp Watch. In the same spirit, we explore the use of a machine learning-based approach to design such predictor-recommender pairs.