key: cord-0162453-j0ov02e8
authors: Faggian, Marco; Urbani, Michele; Zanotto, Luca
title: Proximity: a recipe to break the outbreak
date: 2020-03-23
journal: nan
DOI: nan
sha: 6b3e69e6a80b291e4e2b6a9a38d1a9a9950a90dc
doc_id: 162453
cord_uid: j0ov02e8

We present a mobile app solution to help the containment of an epidemic outbreak by keeping track of possible infections in the incubation period. We consider the particular case of an infection which primarily spreads among people through proximal contact, via respiratory droplets. This smartphone application will work offline and will be able to detect other devices in close proximity and list all the interactions in an anonymous and encrypted way. If an app user is tested positive and so is certified as infected, the application notifies immediately the potential contagion to the devices in the list and suggests to start a voluntary quarantine and undergo a medical test. We believe this solution may be useful in particular in the current COVID-19 pandemic and moreover could be used to prevent similar events in the future.

What we can learn from the recent COVID-19 pandemic is that we were not ready for this kind of eventuality. [1] Our society has reached a level of global interconnection which makes an epidemic outbreak an event very problematic to contain with traditional quarantine measures. This means that a very contagious disease can easily spread around the globe putting health care systems under pressure, especially in countries where such systems are already in precarious conditions. Therefore, it is necessary to find a way to effectively limit pandemics as soon as possible. Nowadays, especially in the most technologically developed areas, a vast majority of people own a smartphone and have it constantly with themselves. This type of behavior is typical of our current lifestyle and can represent an advantage to contain the epidemic outbreak. An infectious disease primarily spreads among people due to their proximity, via respiratory droplets coming from coughs and sneezes or via direct contact. [3] In order to slow down the outbreak, the best procedure is to immediately identify the "patient zero" and quarantine those who have come into contact with them. [4] The recent outbreak of COVID-19 showed that this approach is difficult to pursue and unsustainable when the incubation period is long, because of the high number of Email address: mk.urbani.89@gmail.com (Michele Urbani) interactions and the lack of strategies to efficiently warn the people who could have gotten infected. The absence of an efficient method to track the spread of the epidemic may translate into an exponential growth of cases, and this, in turn, might lead to a pandemic which is hard to contain without severe restrictions on people's freedom. We propose a relatively simple but powerful tool, based on an smartphone application, to statistically slow down and contain an epidemic outbreak. The main idea is to treat each "positive patient" like the "patient zero" using a smartphone contact tracing strategy. This approach can be called "selective quarantine" and contrasts with the "traditional quarantine" which consists in isolating a geographical area (see Fig1) . This smartphone application should be able to track other devices in close proximity and to encrypt all the interactions into an anonymous "proximal contact list". In the case where a patient is infected, the medical authority provides a key to activate the app, which sends automatic notifications to the devices on the list, warning about the possible contagion.

In this section we describe the workflow of the proposed smartphone application, that we named Proximity [8] , together with its main technical features and further development.

The application works in two different modalities. One is the Tracking mode, which runs in background and enables the recording of devices in close proximity. The other is the Alert mode, which is activated only when the infection is identified and allows the device to send alerts to other potentially infected individuals. Proximity, in the Tracking mode, should be able to:

1. track all short range (distance of 2 − 3m) interactions between people with a smartphone with the same app installed, as illustrated in Fig. (2). 2. save at least the following information: date, time and the duration of the interaction, and the phonenumber of all the interacting mobile phones. 3. keep in the local memory a list (proximal contact list) of all the interactions occurred in a time duration at least equal to the incubation period of the infection. 4. be switched to the Alert mode, by inserting an activation key.

In the case a person is tested positive for the infection, the medical authority who certified the test, provides the key K m to activate the Alert mode. This key is a onetime password generated by an algorithm in a protected web page where only doctors with certified emails can access. The medical authority can generate the key K m introducing the user ID, provided by the patient, in the online key generator. Subsequently, the K m key is used by the patient to activate the Alert mode.

Once the Alert mode has been activated, the app will:

1. send an SMS notification to all the contacts in the proximal contact list. 2. alert all the devices receiving the notification from the activated one, in order to warn about the possible contagion. The alert should contain precise directions on the actions to be taken (e.g. undergo a test and/or start a voluntary quarantine).

The complete Proximity workflow is depicted in Fig.(3) .

The crucial feature of Proximity is the tracking of neighboring devices. This must occur offline and with high accuracy, for the measurement of the distance. The former requirement will ensure the users' privacy, as all the information will be stored locally in the device, in an encrypted form. Moreover, it will allow the app to operate even if the connection to the network is missing or weak. The range accuracy is crucial, in order to avoid having a large number of false alerts. With false alerts we mean devices recorded in the proximal contact list, which were out of the infection range (i.e. the maximum distance at which one can be infected by proximity). Clearly the closer the tracking range is to the infection range, the higher the identification accuracy of potentially infected people will be. We identified the Bluetooth technology as the most suitable option to satisfy the app's needs. Bluetooth allows for the direct communication of one device with multiple others, even out of the line-of-sight, thus enabling simultaneously tracking of multiple smartphones within the selected range. Furthermore, it is designed for low power consumption, enabling the app to be constantly active, without draining the battery. Another crucial parameter is the working range, in order to provide the required accuracy. Current Bluetooth (Class 2) devices operating on mobile phones have a range of about 10 meters [5] , variable depending on the presence of obstacles along the path, which can attenuate the signal. The infection range is usually on the order of a few meters, so Bluetooth antennas are a viable tool for this application. [5] One potentially interesting alternative to Bluetooth, would be Near Field Communication (NFC). This is a pretty recent technology implemented in most novel devices, which allows for radio communication on very short distances, used for example for wireless payments. This is promising for Proximity since it is a very low power consuming technology. [6] The drawback is the range, which currently is in the order of few centimeters, thus making it unsuitable for our app, for the moment.

After listing above the main operating features of our Proximity app, we propose here some further refinements. These improvements might help addressing some collateral issues linked to the use of the app, that we envision in an hypothetical epidemic scenario.

In the event of the activation of the Alert mode for a verified infected person, the number of people who have been in contact with them, and thus receiving the alert and potentially willing to undergo the medical examination could be very high. The number of notifications sent will then increase with a cascade effect, damping the epidemic outbreak. Such scenario could put the health care system under pressure, due to the great number of tests requested almost simultaneously. The solution we suggest is based on two different, but entangled, approaches.

The first relies on the fact that the app works as a detector of other devices. In this context we can define strong and weak interactions.

The strength of the interaction is defined based on both the duration of the interaction itself and the distance between the interacting devices. The former can be measured by keeping track of the period of time two smartphones stay within the interacting range, while the latter can be estimated from the intensity of the Bluetooth signal at the receiving end. The duration of the interaction can also be used to track multiple contacts with the same device, by simply summing the times of the single interactions.

Introducing a level of intensity of the interaction permits to establish a priority scale, which is directly correlated to the probability of infection. People who had longer interactions with an infected individual, will have a higher probability of incurring in the infection themselves, as well as people who have been much closer to an infected person. Once the priority is set, it is used to order the proximal contact list. At this point, it is possible to proceed by defining a threshold, taking into account for instance the capacity of the health care system to perform tests for the detection of the infection. This way, if the number of people who can potentially receive the alert is higher than such threshold, then the individuals with lower priority are excluded from the list. They can, for example, be held in a waiting list, and alerted at a subsequent time.

The second approach that we suggest makes use of two different kind of alerts, operating in a hierarchical way. The first, named red notification, corresponds to the notification system described above: once a person is tested positive, the proximal contact list of their own device gets a notification of the contact. The second notification, yellow notification, can be activated by a person who has received the red notification, but not been tested yet. The yellow notification is sent to the proximal contact list of this second individual. In the latter case, the alert must contain indications that are different compared to those sent with the red notification. For example, the app would only advise to take precautions but it would not request the medical examination, unless a further red notification is received. We recognize that this last solution might not always be possible or beneficial, because it could, for example, create more confusion in people receiving different alerts. We envision it as an optional functionality, whose activation can be authorized or not by the app provider, depending upon the specific conditions of the epidemic.

In order to show how it is possible to guarantee privacy and anonymity, we describe in more detail the encryption system and the operating scheme we propose for our app. We believe that the optimal encryption scheme for an application like this is the asymmetric encryption.

Asymmetric encryption involves a two-key system: a public key K p which is shared between the sender and the receiver, and a private or secret key K s which is known only to the receiver. The sender, who knows the plain-text message n, generates the encrypted message n * through a "one-way function" Cr and a public key K p . The receiver, who knows both K p and K s keys, is able to decrypt the message through Dr, the decryption function.

The strength of this system is that, despite being K p and K s keys dependent on each other, the knowledge of K p does not lead back to K s . Therefore, Cr and K p alone do not allow the decryption of n * . There are several algorithms that allow asymmetric encryption. The first of these, most famous and widely used, is the RSA algorithm [7] .

Asymmetric cryptography is the ideal ingredient to develop our recipe. Indeed, each user of the app can be considered as a sender of information (their phone number) in the encrypted form n * . Users interacting with each other exchange this encrypted information, which is temporarily registered in the proximal contact list:

which is absolutely indecipherable for any user. The whole set of users therefore represents an encrypted distributed database D * which turns out to be really challenging to break.

As previously specified, the user needs an additional key K m , which is provided by the medical authority, to enables the activation of the Alert mode. Once the Alert mode is active, the proximal contacts list L * is sent to the decryption server S erver I, which eventually sends notifications to all the contacts present in the list. The K m key is generated at the moment of the request from the authority, by a different server S erver II, providing the user ID of the person tested positive and the name of the requesting doctor. In this way, S erver I only receives data from the j -th user, which is the one who is in possession of the k m key. This procedure adds an additional constraint that limits data sharing.

The intrinsic security of such a system relies first of all in the lack of a central database, since the data is distributed on all smartphones, in an encrypted form. The only party able to decrypt the data is the one who generates the keys, who is also the owner of the system. However, it is important to underline that they do not own the data of all the users, but only the small part, of those who need to be alerted. The asymmetric encryption algorithm can only be violated with an incredible computational cost. [7] However, further improvements, like increasing the size of the keys to a number greater than 2048 bits and changing the public key often (e.g. daily), would make the system safe from any possible reasonable attack.

Intuitively, it is clear that promptly warning all the proximal contacts of an infected person allows for slowing down the epidemic. Nonetheless, in order to show the app efficiency we modeled the functioning of the app using a simplified Monte Carlo simulation. We have not modeled the entire evolution of the epidemic, since we are only interested in the initial phase, the exponential growth.

Inspired by the SIR model [2] , we introduce the quantity R 0 the "basic reproductive rate" as the expected number of secondary cases directly generated by a single positive case during the incubation time ∆T inc . The quantity R 0 represents the crucial parameter which describes the epidemic evolution.

The idea is that by acting on this coefficient R 0 , it is possible to slow down and even stop the epidemic. This is exactly what the app aims to do; by promptly alerting the infected people, with an adaptive confinement conceptually described in Fig.(1) , the rate of epidemic growth is significantly reduced. The assumptions for the Monte Carlo numerical simulation is the following:

• the average incubation period of the disease ∆T inc is constant.

• during the incubation period, the "basic reproductive rate" R 0 is constant.

• the incubation period ∆T inc is equivalent to the duration of infectiousness. We assume that once the symptoms appeared the patient is strictly quarantined. Therefore, for any time t > ∆T inc we set R Positive 0 = 0.

• once an individual receives the alert from the app, they can start a voluntary quarantine, which de-creases R 0 of a factor k, R Alert 0 = R 0 /k, and undergoes the test.

• once the epidemic is ongoing, we assume that the activation of the app into the Alert mode from the i-th day (corresponding to T ith ). Until the i-th day, the app is in a silent mode: just tracking but not alerting.

• we assume a linear gradual diffusion of the alert during the days following the i-th day (this period is defined T delay ), in order to roughly model two events: the progressive mitigation of the sudden test request, which can hardly be satisfied by the health care system, and the gradual increase of the app users number.

We believe that these assumptions can sufficiently describe the dynamics of the spread of the infection under the effect of the app. The results are shown in Fig.(5) , the grow of the infection is exponential as expected, and from the i-th day the app starts to be activated gradually and the outbreak drops dramatically. According to these simulations, the app's intrinsic efficiency, which is based on the adaptive confinement/quarantine, seems to be excellent. On the other hand, the silent assumption that all the infected individuals would be users of the app is not realistic, as well as the assumption that all the possible infected people could be on the proximity list. Therefore, in Fig.(6) we show the results of several simulations with a lower efficiency. The efficiency could be interpreted in at least two ways, or a combination of both:

• the fraction of app users with respect to the totality of infected,

• the fraction of infected individuals that can not be reached/tracked by the app due to technical reasons, for instance: smartphones shutdown or indirect contacts such as those through contaminated surfaces.

Independent of the former interpretations adopted for the efficiency, it is relevant to highlight that, according to our model, with an efficiency of about 60% the app could still slow down the outbreak very well.

The k parameter represents the effectiveness of the quarantine of those who know they have been exposed to a If the alert is completely ignored, the value of the parameter would be k = 1, instead we expect many people to consider seriously the contagion risk notification and intensify the voluntary quarantine and undergo the test as soon as possible.

These precautions involve an increase in the parameter k which we assume is probably around the value k = 10. In Fig. (7) we studied the dependence of our model on changing the parameter k.

The T delay parameter represents the effectiveness and quickness of the national health system (NHS) in testing and communicating the outcome to positive patients. The delay is considered from the day when the Alert activation protocol is introduced to full operation. Another cause of this possible delay is the gradual increase in the number of users of the app. We probably expect a week, ten days.

In Fig. (8) we studied the dependence of our model on changing the parameter k It is possible to interpret this parameter as the effectiveness of the quarantine of those who know they have been exposed to a contagion risk. Assuming sensible and prudent behavior we expect k 1. The parameters of the simulation are: ∆T inc = 14 days, R 0 = 3, T ith = 30, ∆T delay = 10 days. Data have been averaged over 50 simulations.

Although to contain the epidemic other apps have been proposed [10] or are under construction, we believe that our Proximity app recipe gathers a large number of advantages. In this section we will try to highlight its strengths and its weaknesses that require a further development.

temporarily collected by the app in an encrypted list.

2. The app does not require any central database, all the data are distributed in the local storage of the smartphones. Only the proximal contact list of people certified as infected are sent to a remote server to be decrypted to allow contacts to be notified anonymously.

3. Proximal contacts are detected directly and with an offline system: there is no need of an internet connection at this stage. 

A direct detection of the proximal contact is potentially more accurate than the geolocation, and it can be carried out in places where satellite coverage is absent or scarce. Thanks to the intensity of the signal, the proximity radius can be tuned more precisely. Further development of mobile phones technology can help to improving these aspects.

5. The possibility of alerting unknown people directly and in complete anonymity.

6. To avoid spreading unwanted or fake alerts, the activation of the alert can happen only thanks to a key provided by the medical authority who certifies the case of epidemic contagion.

7. The app is relatively simple, low energy consuming, low memory and low computational cost are required. On the other hand, it requires at least a solid encryption system, the development of a brand new communication system with the current technology available (Bluetooth) and an anonymous way to send the alert (preferably via a SMS). 8 . The app provides a system of priorities based on the duration and the distance of the contact, which enhances its efficiency and lowers the numbers of false alerts.

9. The app can be disabled when there is no ongoing epidemic. A warning to switch on the app should be send in case of epidemic risk. Furthermore, the app can be temporarily disabled by the user or paused at his discretion.

We believe that protecting humanity from epidemics is of crucial importance and of interest to all. For this reason, we are sure that a system like the one we have proposed will inevitably be adopted in the future. The hope is that this will happen in the shortest time possible and especially in respect of rights like privacy and freedom. We believe this solution may be useful in particular in the current COVID-19 pandemic and moreover could be used to prevent similar events in the future.

The authors claim to have developed the content of this paper independently without taking inspiration from others. Despite this, they recognize in the TraceTogheter app [11] presented in Singapore on March 20, 2020 a realization very similar to what is described in this work, albeit with some important differences. Proximity [8] does not require a centralized database, whereas this is envisaged in TraceTogheter [11].

We thank Colin Pavan and Joel Klinger for useful suggestions and comments and for reviewing the English version and Clmence Doliget for the French translation.

The next outbreak? Were not ready

The Mathematics of Infectious Diseases

Q&A on coronaviruses". World Health Organization (WHO)

Finding patient zero. Acute pain

Basics | Bluetooth Technology Website

Near Field Communication Versus Bluetooth

Proximity: a recipe to break the outbreak

Epimap: Towards quantifying contact networks for understanding epidemiology in developing countries