5 On the mobile app side, bugs in the development of the software could lead to the same data being sent over and over again, whereas the frequency of sending data had inherent limitations and differences with respect to different platforms (Android vs. iOS). From an analytics perspective, it was also a matter of discussion *how* the local data on the smartphones should be pre-processed before being sent to the database in the backend.

secure and privacy preserving as possible. In this section, we elaborate on some of these measures and associated challenges.

#### **<IP_ADDRESS> Overview of security measures**

The Smittestopp backend relies on the Microsoft Azure cloud infrastructure at an enterprise service tier, thereby inheriting all generic security measures available for business solutions. All Azure services employed by the Smittestopp backend use the Azure AD B2C enterprise identity service to provide single sign-on and multi-factor authentication.

**Data in transit:** The Smittestopp backend uses encrypted communications in all mobile app and web interactions (see Sections 3.2.3 and 3.2.5), firewalls in authentication processes and hidden APIs (see Section <IP_ADDRESS>), and HTTPS access to all servers with TLS certificates (see Section <IP_ADDRESS>).

**Data at rest:** All storage in Azure SQL Database, storage containers, and so on, as well as the respective backups are secured with encryption at rest, and the encryption keys are stored in the customer key vault service. The backend also employs multilevel access, limited user groups (depending on the level of authorisation), and crossorganisation data splitting (according to the scope of authority).

#### **<IP_ADDRESS> Data anonymisation**

Data anonymisation refers to the removal of personally identifiable information from data sets, so that the individuals the data describes remain anonymous [23]. Within the Smittestopp system, all operations after the registration are based on devices (not users) and are undertaken through the use of non–human-readable UUIDs.

In the Smittestopp backend, with the exception of AD (component 1 in Figure 3.5), none of the components use any identifier that can be associated with an individual or phone number. All data operations within the backend (components 2 − 8 in Figure 3.5, including IoT Hub, Data Lake, and SQL Database) use the device handle UUID, as mentioned above. AD lookups in the prod environment are subject to extremely tight restrictions and strict auditing, with no more than two people in the entire project having access to the directory.

Although it is not possible to run a completely privacy-preserving operation within the centralised confines of our operation (see Sections 3.1 and 3.2.1 to review the design specifications, and Section 3.3.1 for a general discussion of centralised vs. distributed architectures), a certain level of privacy has been ensured in this regard. We refer readers to Chapter 7 for a detailed discussion of anonymity within the context of aggregated statistics.

#### **<IP_ADDRESS> Data storage**

From the start of the project, it was a priority that the physical storage of any user data associated with Smittestopp complied with the jurisdiction of the European GDPR. In this regard, all Smittestopp backend components resided in Europe since the first day. Major components such as Data Lake and SQL Database were located in Norway from the beginning. However, at the time we went into production, Microsoft's data centre in Norway had just recently opened, and a number of Azure services were not yet available in Norway. Some components, such as the IoTHub and Stream Analytics engine, were located in the Northern Europe data centre (Ireland) for a few weeks. Afterwards, in the second phase, the backend was reconfigured, and most of the services were relocated to Norway. During the reconfiguration, we also scrapped Stream Analytics and moved to a data load from file approach, as mentioned in Sections <IP_ADDRESS> and <IP_ADDRESS>.

#### **<IP_ADDRESS> Data access**

Access to the Smittestopp backend operates on a component level, with only a handful of people having access to critical components such as Data Lake and SQL Database (notwithstanding the differentiation between the dev and prod environments). All access to customer assets in the Azure subscription were controlled and audited by NHN.

**Access by Microsoft:** The Data Processing Agreement (DPA) between Microsoft and NHN is the judicial framework that Microsoft depends on with respect to GDPR [11]. According to this agreement, Microsoft is contractually obligated to provide sufficient guarantees to meet key requirements of GDPR.

**Access by developers:** Access to any services related to data storage and data processing were granted to vetted developers by NHN on a subscription basis. Developer access was granted to a limited number of Simula and NIPH personnel.

#### **<IP_ADDRESS> Bluetooth IDs**

A weakness in the first release of Smittestopp was the use of static client IDs for tracing BT pairings. The client ID is exchanged with another instance of Smittestopp when two devices are within BT range of each other. With static IDs, it is possible to non-continuously track users through BT beacons, placed at strategic locations, that scan for the presence of specific IDs. To avoid this type of tracking, the client ID should change over time, which can be achieved by rotating IDs. Therefore, an endpoint (see Section <IP_ADDRESS>) for providing rotating client IDs was implemented, and support for rotating client IDs was added to the mobile app. Using this endpoint, the mobile app can request a set of random client IDs and use each ID for a period before it is changed. When the mobile app runs out of IDs, it requests a new set of IDs from the backend. This feature was implemented and tested, but never released to the general public.

#### **<IP_ADDRESS> Research and development data**

The acquisition of data to use for research and development is often challenging in situations involving personal information. According to the sandbox approach described in Section 3.2, we maintained two instances of the backend system, namely, the dev and prod environments. Here, the prod environment was completely out of reach for the majority of the team, and data collected in the dev database, contributed by the informed volunteers from Simula and NIPH, were available for development purposes. Although this helped us build our algorithms and prototypes, the fact that we were never able to test at the real scale remained a challenge. Nevertheless, this was an important measure to protect the production user data from potentially unstable development versions of the services and functions.

# **3.4 Summary and conclusions**

In this chapter, we presented an overview of the Smittestopp backend solution, elaborating on its purpose, design, implementation, and operations. We traced the evolution of the solution over time as a response to project goals and requirements, reflected upon various aspects of performance, and, finally, touched upon the open challenges that can hopefully motivate future work. The overall Smittestopp system was deployed for public use in only about give weeks, reaching a record 1.5 million registrations in a short time and collecting hundreds of millions of data records. Despite the issues and challenges that still remain to be open, we hope that our experiences and insights can support future projects of a similar nature, by allowing other teams to learn from our mistakes and use our preliminary results.

# **References**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 4 Smittestopp analytics: Analysis of position data**

Vajira Thambawita, Steven A. Hicks, Ewan Jaouen, Pål Halvorsen, and Michael A. Riegler

**Abstract** Contact tracing applications generally rely on Bluetooth data. This type of data works well to determine whether a contact occurred (smartphones were close to each other) but cannot offer the contextual information GPS data can offer. Did the contact happen on a bus? In a building? And of which type? Are some places recurrent contact locations? By answering such questions, GPS data can help develop more accurate and better-informed contact tracing applications. This chapter describes the ideas and approaches implemented for GPS data within the Smittestopp contact tracing application. We will present the pipeline used and the contribution of GPS data for contextual information, using inferred transport modes and surrounding POIs, showcasing the opportunities in the use of GPS information. Finally, we discuss ethical and privacy considerations, as well as some lessons learned.

V. Thambawita

S. A. Hicks

E. Jaouen

Department of Machine Intelligence, Simula Metropolitan Center for Digital Engineering, e-mail<EMAIL_ADDRESS>
P. Halvorsen

M. Riegler

Department of Holistic Systems, Simula Metropolitan Center for Digital Engineering, e-mail<EMAIL_ADDRESS>
Department of Holistic Systems, Simula Metropolitan Center for Digital Engineering, e-mail<EMAIL_ADDRESS>
Department of Holistic Systems, Simula Metropolitan Center for Digital Engineering, Department of Computer Science, Oslo Metropolitan University, Department of Informatics, University of Oslo e-mail<EMAIL_ADDRESS>
Department of Holistic Systems, Simula Metropolitan Center for Digital Engineering, Department of Computer Science, UiT The Arctic University of Norway e-mail<EMAIL_ADDRESS>
Fig. 4.1: Examples of map prototypes used during the development process. We can see different metadata plotted, such as pathways, buildings, and GPS data points. To create the maps, we used the Kepler library (kepler.gl). Maps created for this pipeline were only used for development and not provided in the final build, due to resource consumption and privacy concerns.

# **4.1 Introduction**

One of the information sources that Smittestopp was supposed to rely on for contact tracing was the position data collected from people's smartphones. Such position data can help determine if people crossed paths and can provide information about the places they visited, such as if someone was in a store or used public transport. Position data, often also referred to as Global Positioning System (GPS) data, usually consist of the position as a longitude and a latitude, as well as a timestamp. Suppose the position data are collected via smartphones. In that case, one can also obtain additional information, such as speed (from one GPS data point to the next), altitude, and accuracy (an approximation of how accurate the obtained position data might be). On the other hand, some GPS data sets contain manually collected data, such as transport modes. For example, the GeoLife GPS Trajectories [11] data set contains annotated trajectories, with labels for the transportation mode (bus, train, walking, and car), latitude, longitude, altitude, and timestamp.

To render raw position data usable for tasks such as contact tracing, pre-processing and pre-analysis are required. First, one needs to extract trajectories from the raw GPS data. These trajectories can be used to find possible intersections and travel paths, among other things. Trajectories and GPS point data are essential for map matching, that is, to connect the GPS information to information obtained from a map. For example, was a person at a bus stop waiting for a bus, was a person in a store, did people walk together, and so on. In addition to map matching and trajectories, identifying a contact also requires analysing which mode of transportation was used (walking, driving, biking, public transportation, etc.) [7]. Moreover, necessary but straightforward pre-processing methods such as bounding box and polygon creation based on GPS points are required. One final challenge that needs to be addressed is that the amount of GPS data is usually massive, with huge numbers of data points (also depending on the granularity of time). Thus, one needs efficient methods to

Fig. 4.2: Overview of Smittestopp's GPS analysis pipeline. Raw GPS data are first transformed into trajectories and then combined with metadata from public maps and classified into different transport modes. The processed and enriched data are then used in the contact tracing algorithm.

process the data, especially if nationwide contact tracing is a final goal. Figure 4.1 shows some of the maps used during the development process. The maps contain different types of information, including possible walk paths (left), buildings and GPS data points, (middle), and a more detailed view of certain buildings that shows metadata information such as the name of the school (last).

Based on these general requirements for GPS data analysis, several main objectives arose that needed to be addressed to make the position data useful and usable for the Smittestopp application. These are as follows:

Figure 4.2 depicts the complete pipeline for the GPS analytics part of Smittestopp. The whole pipeline is implemented in Python and uses different libraries. Details about the libraries used are provided in the respective sections. The pipeline starts with the user data queried from the database. The data can be queried by user, groups of users, or geographical area. Once the raw GPS data are in the pipeline, they pass through the different building blocks.

In the following sections, we describe these different components in more detail.

# **4.2 Trajectory pre-processing**

A GPS trajectory is a collection of GPS points describing an object's movement along a specific path. No clear definition is available on how long a trajectory is and what it should contain, and these often depend on the use case. For example, in an application used to track running, different trajectories could be segments of 1 kilometre or specific times, such as a new trajectory every 10 minutes. Another approach could involve a new trajectory for every trip, resulting in a collection of runs. For Smittestopp, we experimented with different ways of creating trajectories from GPS data. The experiments were inspired by related work by [9, 8, 12, 4]. Unlike the related work, we did not have labelled data for our trajectories, so we decided to develop methods that could work unsupervised. The main goal was to keep the methods simple, understandable, and explainable.

From the raw GPS data, we extracted GPS trajectories that could then be used in other analysis steps, such as to find intersections, points of interest (POIs), visited buildings, travel paths, and so forth. Looking at existing systems and the literature, we saw no clear way to extract trajectories that worked the best, but there were different suggestions. For our pipeline, we decided on three different methods:

The input data for the trajectory pre-processing are GPS data obtained from smartphones per user per time or region. The outputs are the trajectories per user, as a collection of GPS data points.

Fig. 4.3: Comparison of changes in a fixed number of GPS points. The green box shows 12 fast-moving GPS points and the red box shows 12 slow-moving GPS points.

## **4.2.1 Trajectories with a fixed length of GPS data points**

In this approach, we divide a long series of GPS data points into trajectories based on a given fixed length. Here, the fixed length is the number of GPS points to be extracted as a single trajectory. Simplicity in handling and processing the trajectories are the main advantages of this method. However, this method's main drawback is that some subtrajectories cover small geographical areas, while others cover large ones. For example, a number 𝑁 of GPS points for a walking trajectory can be within 1 kilometre, while the same number of GPS points for the trajectory of a fast car can cover around 10 kilometres. To understand this phenomenon, see the illustrations in Figure 4.3. Therefore, when analysing POIs around a trajectory, a large geographical area causes problems in extracting a large amount of additional metadata.

#### **4.2.2 Trajectories with fixed time intervals**

In this method, we use predefined time intervals, such as two hours, one hour, half an hour, a minute, and a second to create trajectories. These time intervals are calculated using timestamps, which are part of the metadata of each GPS point collected by the mobile application. The main advantage of this method is its ability to find trajectories for a given time interval. However, similar to the method of extracting a fixed number of points, the resulting trajectories can have an area so large that extracting metadata from the map servers would be too computationally expensive. This function works as a support function to extract POIs from long trajectories, because extracting POIs around a long trajectory is time and resource intensive. The pseudocode of this function is presented in Algorithm 1.

## **4.2.3 Trajectories based on trips and stop points**

A natural way of thinking about a trajectory is in terms of different modes of transport. This approach splits a long GPS trajectory into smaller chunk-based trips and stop points. In this case, a trip is defined as moving some distance over some time, such as a person driving to work or walking a dog. Stop points are points where a person is still for a longer period within a predefined radius. The approach is based on the work of Cich et al. [2]. The advantage of this method is that we obtain a clean set of trajectories pertaining to either stop points or trips that can be further classified into a mode of transport. A disadvantage of this method is that we must ensure that the trajectories obtained are stable enough to detect stop points properly and to distinguish between different trips. Furthermore, this method produces trajectories of various lengths. For example, the trajectory of a person going to the post box would be much shorter than that of a person walking to work.

# **4.3 Predicting the mode of transport**

Even if the physical distance between two people is close enough for infection, it does not necessarily mean they were in contact. For example, one person could be driving a car, while the other one is running on the sidewalk. Furthermore, two people can be a safe distance apart but sitting on the same bus, raising the likelihood of infection. Therefore, it was important to assign a mode of transport to the GPS trajectories generated by the users. For this purpose, we defined seven different types of transport modes: being still, walking, running, on a bus, in a car, on a train, and on a plane (see Table 4.1). These categories were selected based on the most common forms of transportation in Oslo, Norway.

Since we were, for the most part, interested in determining whether or not two people were in direct contact with each other, we generalized these groups further to only include *still*, *on foot*, and *in a vehicle* The group *still* covers the case in which a person is standing still, or, in other words, has no speed; *on foot* encompasses all instances of a person moving on foot, such as walking, jogging, or running; and *in a vehicle* contains all cases in which a person is in a vehicle, including seated inside a car, bus, tram, train, or airplane. Despite being a less precise estimation of the transport mode than in using the seven categories above, these categories still achieved our target of being able to more accurately differentiate between in-person contacts. For example, if contact between individuals is determined, but one is *on foot* while the other is *in a vehicle*, we can rule out the possibility of infection. As development continued, we planned to gradually increase the level of precision of the predicted modes of transport, but this was not achieved before the project was shut down.

Research on deriving transport modes from GPS data relies mostly on supervised learning methods that use a large training data set of labelled trajectories to learn the nuances between the different modes of transport automatically (eg, [10, 13, 6, 3]). Since we did not have access to an extensive training data set or time to collect one, we had to settle for a simpler approach using heuristics. We decided to use the speed of a given GPS point to predict its transport mode. This means that we assigned a mode of transport for each point in a given trajectory. Initially, we planned to assign one transport mode per GPS trajectory, but we found that giving each point a transport mode would provide greater flexibility further down the pipeline.

There were two advantages to this method. First, speed was calculated on the smartphones, such that we obtained this information for free, without the need for any additional computations. Second, assigning a transport mode for each point gave us more flexibility in comparing contacts at specific periods of time. The lookup table used to determine transport modes is shown in Table 4.1, where we also show the conjectured speed of the more precise modes of transport. These speed values were selected by taking the average speed of the transport mode in question and adding a small upper buffer to allow for some variability. Since the accuracy of the collected GPS points varied, the assigned transport modes underwent cleaning and post-processing. This involved looking at the individual points within a given time frame and assigning all points within that frame to the majority transport mode.

The evaluation was carried out by comparing the predicted transport modes against a set of manually annotated points collected by members of the development team. Overall, we had approximately 35 test cases for evaluation, all from Simula employees who gave explicit permission to use their data for testing purposes. Each entry consisted of a start time, an end time, and a mode of transport for that duration. The results were evaluated against this test data set continuously through a series of unit tests that ran every time the analytics pipeline was started. Furthermore, we performed a qualitative evaluation of the predicted transport modes using interactive maps generated by kepler.gl.1 Based on this visual analysis, we made specific changes

1 See https://kepler.gl/.

to the transport mode prediction algorithm, such as the speed thresholds used for the individual transport modes and fixing bugs that were not caught by the unit tests. Despite being very useful in creating a more robust and stable transport mode prediction approach, we had to be careful when making changes, since we were using a small subset of data that might not have represented the overall population. It is important to note that these interactive maps were only used in the development phase of Smittestopp, and not in production.

Table 4.1: The lookup table used to determine the transport modes for a given GPS point. The upper half of the table shows the more precise modes of transport, while the lower half shows the modes of transport used in the final version of Smittestopp.

# **4.4 Map matching and map visualization**

Map matching involves combining GPS data with metadata from publicly available maps. For the Smittestopp project, we tested Google Maps, Azure Maps, and OpenStreetMap2. Based on the performance we needed and the amount of metadata available for Norway, we decided to use OpenStreetMap. The methods implemented were partially inspired by other work (a good overview can be found in [1]). Nevertheless, we basically started from scratch, to develop methods specifically designed for contact tracing that could provide the information needed and, at the same time, respect the privacy of users. More details on the OpenStreetMap backend we used to query the information are available in the part describing the backend.

Our goal for the map matching was to understand whether a contact had occurred in a closed environment (e.g. a building or a bus), since this could impact the risk level. Contacts are split into three categories: *inside*, which can be inside a given building or a vehicle or public transportation, *outside*, and *uncertain*, when we lack

2 See https://www.openstreetmap.org.

4 Smittestopp analytics: Analysis of position data 71

Fig. 4.4: A comparison of two bounding boxes and the areas they cover. Note the differences between the green and red boxes, which both cover the area corresponding to two GPS points.

relevant information or when the data are inconsistent (e.g. one person is detected as being in a car while the other is walking).

#### **4.4.1 Extract POIs from dilated areas**

Our main goal is to find POIs around the given trajectories that are associated with positive cases or identified as a trajectory to be analysed. Initially, we considered bounding boxes around trajectories as an area around which to extract POIs. However, the bounding boxes cover a large geographical space than we wanted to analyse to find POIs. The maximum number of unnecessary POI extractions arises when two GPS coordinates are located at two ends of a bounding box's diagonal. Figure 4.4 illustrates this phenomenon. Therefore, we were looking for alternatives, such as extracting POIs using dilated areas.

The main purpose of extracting POIs using a dilated area is to minimize the number of POIs returned for a given trajectory. In this method, we replace the bounding box with a narrowed polygon. The polygon's width (the maximum distance to the polygon boundary from a given point) is defined as an input parameter (a given fixed value). A sample trajectory, a corresponding dilated area, and the extracted POIs within the area are illustrated in Figures 4.5a, 4.5b, and 4.5c, respectively.

72 Thambawita et al.

Fig. 4.5: An example of a trajectory and its POI extractions using a dilated area.

## **4.4.2 Obtaining contacted POIs with points**

Identifying POIs around a specific GPS coordinate is essential when determining the contacted POIs of a given trajectory. To extract POIs from each GPS point, we consider a circular area around every GPS point of a trajectory, because we did not have access to indoor positioning systems [5]. Practically, when we extract POIs around a point using the radius of a circle, we observe several POIs per point. However, we know that this point could only be in contact with one POI. Therefore, there should be a reliable method to identify the most appropriate POI with a high chance of having contacted a given point.

In this functionality, we can select two options for the value of the radius of the circle, which will be considered the area for extracting POIs. The first option is a fixed radius passed to the algorithm. In this case, we can carry out a heuristic analysis to find the most suitable radius. The second option is to use the accuracy radius, which is part of every GPS coordinate collected by our mobile application. Considering the accuracy value (radius of the accuracy circle) as the radius to extract POIs is logically more related to our goal than the fixed radius, because, when a mobile phone has a poor GPS signal, the radius of the accuracy circle is bigger to extract POIs around it. On the other hand, a large error (when the GPS signal is poor) can lead to a large radius. Then, the POIs cannot be extracted because of there being too much data. To overcome this problem, we defined a threshold for the maximum radius.

Within a single circle, we can sometimes observe several POIs, as mentioned earlier. However, we have to select one of them. We do so by maintaining a ranking score for every POI extracted for a given trajectory. In this scoring method, we increment a counter (starting from zero) when a POI is detected as a contacted POI for a given GPS point. For example, assume that 𝑅 GPS points intersect with a building 𝐵. Then, the rank of building 𝐵 is 𝑅. Ultimately, each and every POI around a given trajectory is assigned a rank based on the number of intersected GPS points. If we detect a single POI for a given point, we consider that POI as contacted. If we have more than one contacted POI, we use the POI with the highest rank. However, if we have numbers of equal rank, we select the first POI detected as the point contacted. The pseudocode for this algorithm is given in Algorithm 2.

# **Algorithm 2:** Obtain the POIs of contacted points.

```
Data: GPSData, amenities, paddings, maxPadding, columnName,
      OverpassAPI
Result: OutputPerPoint, POIsInfo, POIsCount
GPSOutput ← [ ] ;
POIsInfo ← [ ] ;
POIsCount ← [ ] ;
if padding is not given then
   paddings ← List[Minimum(accuracy, maxPadding) for all GPS records];
end
Output ← CallingToOverPassServer(GPSData, amenities, paddings);
OutputPerPoint ← split Output to length of GPSData;
for POIs in OutputPerPoint do
   if POIs is not Null then
       append POIs to POIsInfo;
   end
end
if POIsInfo is not empty then
   POIsCount ← CountUniquePOIs(POIsInfo);
end
for ContactedPOI in POIInfo do
   ranks ← calculate ranks of ContactedPOI;
   POIMaxRank ← selectMax(ranks);
   append POIMaxRank to POIsInfo;
end
```
## **4.4.3 Relation between POIs and transport modes**

Transport modes and POIs are closely related, since both indicate whether the contact could have happened in a closed environment. We describe this interaction in a few points below.

First, POIs are only queried at instants when the trajectories in contact are associated with transport modes indicating that the contact could indeed have happened. In a nutshell, we will not check whether people considered to be in a car were inside a building. More precisely, we will query POIs for trajectories satisfying the condition that either (i) both are considered to be *on foot* (which covers walking and running) or *still* or (ii) one of the trajectories is considered so and we do not have data for the other (transport mode *N/A*). The result of querying the POIs will lead to their classification as either *outside* or *inside*.

Second, parts of trajectories for which either (i) both are considered inside transport or (ii) one of them is and we lack data for the other will be considered as inside a transport, which means the contact will be classified as *inside*. Table 4.2 summarizes how we first infer the *contact transport modes* from the transport modes of each trajectory. A contact inside transport is considered to occur inside, and looking for POIs will lead to contacts occurring either outside or inside.

Table 4.2: This table describes how the different contact modes (inside, outside, or uncertain) are informed by the transport modes of the trajectories. For example, if two users who meet have *vehicle* as the transport mode in the same location, the contact is defined as happening inside.

We also apply a smoothing function to the trajectories' transport modes, to detect suspicious transport modes, which involve data we assume to be spurious and due to incorrect transport mode attributions. More precisely, we initially compute whether the different points of the trajectories are those for which we should query POIs or ones judged to be *inside transport*. Afterwards, we smooth this prediction by re-attributing the predicted value for points of contact whose prediction differs from those both before and after. More specifically, we look for points of contact 𝑡𝑖 such that contact at 𝑡𝑖 is considered inside a vehicle, but contacts at 𝑡𝑖−2, 𝑡𝑖−1, 𝑡𝑖+1, and 𝑡𝑖+2 (where the length of this interval is a parameter) are considered to be walking/still. Such points, if below a certain duration threshold, are transformed into the opposite prediction, which is, in this case, not *inside transport*.

Once this smoothing has been applied to the contact's transport modes, the points are classified as (i) inside a transport (e.g. contact happening inside a car); (ii) points for which people are walking/still and we would like to know if they met outside or, for example, inside a school or a shop; and (iii) points with inconsistent transport modes, whose contact location/context will be considered *uncertain*.

Lastly, the radius of search of POIs depends on the transport mode detected. The reason we generally use a nonzero radius – that is, a point need not strictly be within a polygon, but only very close to it – is to handle GPS imprecision, which can typically be high inside a building. On the other hand, keeping a high radius can lead to trajectories on the pavement being perceived as happening in nearby shops alongside that pavement. A compromise is to first compute a search radius based on the GPS inaccuracy and to apply a coefficient based on the transport mode detected (e.g. equal to 1.0 if both trajectories are *still*, but reduced to half if both are *on foot*).

## **4.4.4 Querying POIs**

Once the transport modes are analysed, the last step of our method to obtain the context of a contact (see *Algorithm 3*) is to query points of interest for parts of the trajectories. First, we feed chunks3 of these trajectories to the functions mentioned above that query contacted POIs. Second, we apply smoothing to these detected points, very similarly to smoothing we applied to the transport modes. Since we use a nonzero radius to search for POIs, the role of this filtering is to eliminate contact points that actually might not have happened in a closed environment. Such scenarios – isolated trajectory points being attributed to a POI for a short duration – could involve, for example, nearby shops when walking on the pavement.

When querying POIs from OpenStreetMap Overpass, we receive specific information with very precise names4. Therefore, we design a dictionary converting the information detected into simple categories names (e.g. we extract the value *dormitory* and convert it into the general term *residential*). We used the following list of (generalized) POIs: hospitals, nursing homes, schools, kindergartens, universities, bars and restaurants, sports facilities, culture and entertainment facilities, residential, religious buildings, shops, other education facilities, other healthcare facilities, and others.

Information returned to reports include the duration of contact within each of the three categories (*inside*, *outside*, and *uncertain*), as well as the types of inside contact (inside a mode of transport or one of the POIs following the aforementioned list) and their respective durations. Moreover, we returned a filtered version of the POIs, keeping only locations above a certain duration and/or relative duration threshold.

The data obtained from the POIs are then part of the information of a given contact.  These dictionaries are used to display results when executing specific code or are sent as JSON objects to the frontend. When producing the reports, one can then retrieve the particular

3 It became progressively clear that, to handle the data we received, we had to compute the nonzero duration of single timestamps. In other words, we interpreted the duration of the segment [𝑡𝑖 , 𝑡𝑗 ] as roughly (𝑡𝑗+1/2 − 𝑡𝑖−1/2), with 𝑡𝑗+1/2, 𝑡𝑖−1/2 defined using previous and subsequent timestamps. This allows single timestamps to have a nonzero duration. To ensure that we are not capturing excessively long durations (e.g. where the phone stops recording so that 𝑡𝑗+1 𝑡𝑗), we cut up the trajectories into chunks of typically two hours.

4 See https://wiki.openstreetmap.org/wiki/Points\_of\_interest.

locations if contacts between two users occurred, as well as obtain a summarized description of the most important of all the users' contact locations.

## **4.4.5 Accuracy of the identified POIs**

The quality evaluation of the predicted POIs was carried out using data for which we had ground truth generated by members of the Smittestopp development team to test different scenarios and edge cases. Thus, different parts of the code were changed based on these tests (e.g. varying the accuracy with transport modes, asking for one or both individuals to share a specific type of transport mode).

In their definitive form, the POIs seemed accurate and coherent with the ground truth available. However, we have no quantitative figures to more precisely judge their accuracy. Besides, one should bear in mind that several steps filter out potential errors (if they account for a negligible part of the predictions). Such cleaning steps include the generalization of the detected points of entities (a step related to privacy concerns) into more general categories – for example, the algorithm can detect a 'apartment' instead of a 'cabin' and, since both are displayed as being 'residential', the error would be invisible in the reports – as well as the filtering of POIs accounting for a short duration and the relative duration of the contact – for example, if one identifies a 'shop' for a few seconds that was not in the ground truth data, it could be filtered out and again become invisible in the reports.

Update the total duration of contact inside, outside, uncertain. ;

**end end**

# **4.5 Challenges, experiences, and lessons learned**

The treatment of GPS data led to multiple challenges, as well as being timeconsuming and resource intensive. GPS signals often being very imprecise, we had to reconsider early plans to adapt them to typical levels of inaccuracy or issues in the real data gathered. These issues include difficulties in determining transport modes (since successive inaccurate positions can lead to incorrect speed computations) or POIs (forcing us to relax the strict requirement that a point must be within a building's OpenStreetMap polygon to be considered inside it). In addition, we considered leveraging these very difficulties to our advantage, such as attempting to deduce being inside from more inaccurate measurements, which did not perform satisfactorily. Great opportunities are associated with the use of GPS data in combination with external resources such as public maps and metadata, which constitute a powerful tool to infer much information. Many functionalities were eventually left out, not used, or not finished before Smittestopp was shut down, including street map analysis using pathways and distinguishing public transportation use from other personal transportation, among many others. Proper followup studies and more development time would be needed to observe the effects and value of such features for contact tracing.

# **4.6 Ethical considerations**

The use of GPS data raises many questions about data privacy. Since our analysis can trace a person's locations, it allows us to access much personal information. For example, using the collected data, we can determine where a person went to work, when the person left for the gym, and what restaurant the person went to for dinner. Had one kept the raw information from OpenStreetMap, even more sensitive information would have been displayed. We intended to use the minimal amount of informative data, leaving out all that seems unnecessary or ethically questionable. Following that principle, we returned rather general terms (e.g. the residential label instead of an address), protecting more sensitive information (e.g. addresses, names, and the type of apartment a person was visiting). Moreover, one should keep in mind that the personal information mentioned is intrinsic to GPS data, in the sense that we did not add any information sources (e.g. public telephone book entries) that would have allowed for the easy identification of the person, simply using OpenStreetMap, which can be accessed as soon as one acquires GPS data.

To protect privacy, we also exclusively used the data of Simula employees who were part of the Smittestopp application development team and who agreed to being part of the testing. Information from these test subjects and the resulting maps were not made public or shared with anyone besides project management, and then only during the development stage. The data collection and analysis were kept separate. Additionally, later on, we decided to hide sensitive information by not providing the interactive maps created for the development stage in the presentation of the results (since visualizing the movements of users further raised privacy issues), as well as combining relevant information in summary form (e.g. communicating the most common transport modes of a contact, rather than the transport modes for all instances of that contact). No interactive maps were used in the production system, but static maps were implemented within the analysis pipeline.

# **4.7 Summary and conclusions**

We presented and discussed the GPS data analysis pipeline and methods developed for Smittestopp. In addition, we discussed lessons learned and ethical considerations. Overall, we can summarize that GPS data hold a great deal of potential for contact tracing, especially if combined with metadata from public maps and related databases. Nevertheless, this information can be seen as optional and might not be relevant in determining close contacts. This information is also associated with substantial ethical and privacy-related concerns, and one needs to weigh the usefulness and added value against these. For Smittestopp, we implemented the features that we found most useful with the smallest privacy impact, and omitted functionalities such as geomapping/tracking and person identification (which is possible to a certain degree of accuracy with the data at hand, public maps, and the person's registration information).

# **References**

	- [7] A. C. Prelipcean, G. Gidófalvi, and Y. O. Susilo. Transportation mode detection – an in-depth review of applicability and reliability. *Transport Reviews*, 37(4):442–464, 2017.
	- [8] X. Yang, K. Stewart, L. Tang, Z. Xie, and Q. Li. A review of gps trajectories classification based on transportation mode. *Sensors*, 18(11):3741, 2018.
	- [9] Y. Zheng. Trajectory data mining: an overview. *ACM Transactions on Intelligent Systems and Technology (TIST)*, 6(3):1–41, 2015.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 5 Using Bluetooth for contact tracing**

Ahmed Elmokashfi and Amund Kvalbein

**Abstract** Bluetooth data is used as the main method for contact tracing with Smittestopp. When two active devices are within Bluetooth range, they will record the ID of the paired device, along with information about the received signal quality. In this chapter, we describe how this method is implemented in Smittestopp, and how Bluetooth data is processed and analysed, to determine if an encounter between two users should be considered a qualified contact with a risk of contamination. We show that distance estimation based on Bluetooth signals is challenging due to differences between devices, lack of information on transmit power and varying environmental factors. Based on this experience, we propose a simple rule for identifying contacts based on received signal strength combined with information about the operating system type.

# **5.1 Collecting Bluetooth data from iOS and Android devices**

Bluetooth Low Energy (BLE) is a technology for wireless communication in the 2.4 GHz ISM band, and it has been supported by most smartphones since its introduction in 2011 [1]. BLE works over short distances (typically less than 10 metres) and with low capacity (less than 1 Mbps). A BLE device can both advertise its presence by

A. Elmokashfi

A. Kvalbein Center for Resilient Networks and Applications, Simula Metropolitan Center for Digital Engineering, Analysys Mason AS, e-mail<EMAIL_ADDRESS>
Center for Resilient Networks and Applications, Simula Metropolitan Center for Digital Engineering,

e-mail<EMAIL_ADDRESS>
broadcasting a unique identifier (Universally Unique Identifier, or UUID) and scan for the presence of a particular UUID in its proximity.

The basic idea for digital contact tracing is to exploit this ability to record when a device with a contact tracing app installed has been in proximity of another device [11]. We refer to such an event as a contact.

A BLE device can assume four different roles that dictate the behaviour of the device: two roles are connection based, while the other two facilitate communication in only one direction. A device assuming a connection-based role can act as a peripheral or a central device. The former is an advertiser, while the latter is a scanner. A central device scans for a particular UUID, connects to it, and can then request extra information. A peripheral device implements a Generic Attribute Profile (GATT) server. GATT defines the way two BLE devices can communicate back and forth using a generic protocol called the Attribute Protocol. Devices following the non-connectable modes act as either broadcasters (i.e. a beacon) or observers (i.e. a scanner), without interaction with other devices. Smittestopp uses connectionbased roles, and each device acts as both a peripheral and a central. All devices with the app installed broadcast their UUID and periodically scan for the UUIDs of other Smittestopp devices. Along with the UUID, exchanged BLE packets include information about the transmit power *txPower*. Together with the received power, or received signal strength indicator (RSSI), this information can potentially be used to improve distance estimates. See Chapter 2 for more details. The scan cycles for Android and iOS devices vary:

# **5.2 Challenges in distance estimation using Bluetooth**

To detect and classify a contact between two devices, we need an estimate of the distance between them. Smittestopp attempts to estimate this distance based on the measured BLE signal strength at the receiver, denoted the received signal strength (RSS). The RSS is a function of the transmitted power, the gain/loss in the transmitting and receiving antennae, and the signal attenuation (path loss) between the two devices. A simple diagram showing the different components is shown in Figure 5.1.

The radio signal attenuates as the distance between the transmitter and receiver increases. Attenuation can be modelled, and one of the most widely used models is the log distance path loss model [8]:

$$RSS(d) = RSS(d\_0) - 10n\log(\frac{d}{d\_0}),\tag{5.1}$$

where 𝑅𝑆𝑆(𝑑) (measured in decibel-milliwatt, or dBm) is the signal strength at distance 𝑑, 𝑅𝑆𝑆(𝑑0) is the signal strength at the reference distance 𝑑0 = 1 metre, and 𝑛 is an attenuation factor that represents the environment between the two devices. Based on this, the distance can be estimated as follows:

$$d = 10^{\frac{RSS(d\_0) - RSS(d)}{10n}}.\tag{5.2}$$

The BLE standard does not specify the transmit power that should be used by BLE devices. The transmit power level is instead decided by the equipment vendor, within the limits of regulation. The European Standards Organization ETSI allows a maximum transmit power of 10 dBm (20 dBm with adaptive frequency hopping). Some devices allow the transmit power to be adjusted through an application programming interface.

The transmit power is broadcast by the transmitter as part of the beacon advertising packet structure, and is denoted as *txPower*. The advertised *txPower* is meant to indicate 𝑅𝑆𝑆(𝑑0), the received signal power at a distance of 1 metre. For Smittestopp, we use the default transmit power levels for both iOS and Android phones. Android allows the transmit power to be set to *high* or *low*, where the default is low.

There could, however, be a discrepancy between *txPower* and the actual 𝑅𝑆𝑆(𝑑0), due to loss or gain in the transmitter antenna. Similarly, the RSSI recorded at the receiver might not be the actual 𝑅𝑆𝑆(𝑑), due to unclear loss/gain in the receiving antenna. These effects will depend on the antenna and make of the terminal equipment. To account for this, several initiatives have been taken to measure the actual 𝑅𝑆𝑆(𝑑0) values for different smartphone models [4, 6]. The goal of these measurements is to calibrate different terminals so that differences can be accounted for when trying to estimate attenuation (as a proxy for distance) based on RSSI values. The current form of Smittestopp does not use such calibrations.

In addition to the uncertainties related to the *txPower* and RSS values, distance estimation is challenging, due to variations in the orientation of transmitters and the environment. It is known that the orientation of a mobile handset can have a significant impact on the measured RSSI. The presence of a human body between

Fig. 5.1: The received signal power is a function of the transmitted power, the gain/loss in transmitting and receiving antennae, and the path loss.

the transmitter and the receiver can reduce the signal strength. Conversely, reflections from walls, ceilings, or floors in an indoor environment can produce a stronger signal than what would be expected from the log distance path loss model. Given these considerations, we do not attempt to use a formula to estimate the distance between two handsets.

# **5.3 Controlled experiments to aid distance classification**

Epidemiologists determine potentially contagious contacts based on the duration two persons were in proximity to each other and the distance between them. As explained above, it is challenging to accurately determine distance based on BLE RSSI measurements. Instead of calculating an exact distance based on each RSSI measurement, Smittestopp classifies a contact as *very close*, *close*, or *relatively close* based on a set of RSSI measurements from a contact. The classification is discussed in Section 5.4. Here, we describe a series of controlled experiments that were carried out to determine suitable thresholds for the classification.

#### **5.3.1 April 2020 signal strength measurements**

Several controlled experiments were conducted with a limited set of smartphones in April 2020. Overall, we used 26 phones, 18 of which were iOS and the remainder Android phones, with 10 and eight unique types, respectively (see Table 5.1). These experiments can be broadly split into scenarios in which the phones are kept at a distance of 1 metre (*very close*), 2 metres (*close*), and farther apart (*relatively close*). An overview of the scenarios in each group is given in Table 5.2.

Figure **??** shows the distribution of the RSSI values measured in the different experiments. Experiments with the same operating system (OS) on the transmitter side and distance class are grouped together. We do not distinguish between different OSs on the receiver side. Table 5.3 shows the mean, median, and standard deviation for each class of experiments. First, we observe a clear difference between measurements based on the OS of the transmitting device. The measured signal strength is normally 10–20 dB stronger from iOS devices compared to Android devices. As discussed above, the BLE transmit power is not given by the BLE standard, but is, instead, set by the equipment vendor. These measurements indicate that the default transmit power is higher for iOS devices than for Android devices.

Second, we observe clear differences between measurements taken at different distances. This is good news, since it suggests that it is possible to conduct at least a coarse-grained distance estimation based on RSSI values. For iOS, the mean (median) RSSI is 17.8 dB (21 dB) higher in the experiments in the very close category compared to the close category. For Android, the difference in means (medians) is 10.2 dB (12 dB).

#### 5 Using Bluetooth for contact tracing 85

Table 5.1: The phone models that were used in the April 2020 tests.

Table 5.2: Controlled experiments in April 2020

Table 5.3: RSSI values for different distances and operating systems

Third, the measurements show a significant variance in the RSSI values. This is particularly true for the iOS very close measurements. This result indicates that the number of samples needed to reliably classify a contact as very close or close can sometimes be significant.

## **5.3.2 August 2020 extended RSSI experiments**

The method for identifying and classifying contacts described in Section 5.4 was developed based on the limited measurements discussed above. To further refine or verify the estimates, we utilize a data set collected in August 2020. These data were collected to assess the efficacy of Smittestopp in detecting contacts. For this purpose, 31 smartphones were spread over a large table, where they continuously gathered RSSI data for three days. The makes and models of these phones were chosen based on the top phones that downloaded Smittestopp. Table 5.4 presents the makes and models of these phones. Figure 5.2 illustrates the physical setup of this experiment. A total of 12 phones (six iOS and six Android phones) had their screen on during the experiment. Of these, six phones (three iOS and three Android phones) had the Smittestopp app running in the foreground.

Figure 5.3 shows the RSSI values gathered from these smartphones. Each pair of smartphones was classified as very close or close, based on the distance between the two phones. A phone is classified as very close if the distance from the receiver is less than 1 metre, and as close otherwise.

The probability density function (PDF) of RSSI values for different distances and OSs (April 2020)

Table 5.4: The phone models used in the August 2020 tests.

The results in Figure 5.3 are largely consistent with those of the April measurements in Figure **??**. The same distinction between iOS and Android phones is evident, as is the difference between very close and close phones. The RSSI values measured are, however, higher in the August experiment setup. This can be explained by the smaller (average) distance between the smartphones, given the strict (1-metre) criterion for including a pair of phones in the very close category.

Fig. 5.2: The August measurements were conducted with phones of different makes spread over a table.

#### **5.3.3 The effect of the** *txPower* **parameter**

As discussed in Section 5.2, the *txPower* parameter is included in the messages that are broadcast by the BLE devices. This parameter indicates the expected signal strength at a distance of 1 metre from the transmitter. Figures 5.4 and 5.5 show the distribution of RSSI values for different announced *txPower* values for the iOS very close and Android close groups from the August experiments.

We observe that the *txPower* values vary for both the iOS and Android phones. For the iOS phones, we observe three distinct *txPower* values (from different iPhone models), while we see four distinct values for the Android phones. There are small differences in the RSSI values measured between the different *txPower* values, and it is hard to identify any systematic relation between *txPower* and the RSSI. The results from the April measurements are more dispersed, but they do not provide any basis for systematically concluding that different *txPower* values result in different RSSI observations. Based on these observations, it was decided to not include *txPower* in the contact classification.

As noted above, there were several initiatives to measure the RSS from different phone models in controlled experiments, to compensate for any differences in equipment. The decision to not include *txPower* in the distance estimation process means that we cannot utilize these efforts. This means that there is a risk that we are not adequately capturing differences between the phone models in our contact

Fig. 5.3: The probability density function (PDF) of RSSI values for different distances and OSs (August 2020)

classification. On the other hand, the *txPower* of different phone models can also be set programmatically, which is not captured by the calibration models.

# **5.4 Identifying and classifying contacts**

There are two main assumptions behind digital contact tracing. First, proximity events that are observed via BLE approximate the underlying physical contact. Second, the BLE signal strength can be used as a reliable proxy for estimating the actual distance between the devices involved. Next, we describe how Smittestopp identifies and describes contacts, along with verification results.

#### **5.4.1 Contact events**

An encounter between two mobile phones is a time series of discovery events. Each point in this time series is a tuple of the encounter timestamp and connection properties, which include the measured strength of the signal to the other mobile phone, as well as the other mobile phone's transmission power. In a fully distributed system, each app keeps such a time series locally and uses it later, when identifying

Fig. 5.4: RSSI values for the iOS very close group, split by *txPower*

risky contacts.1 In a centralized system, such as Smittestopp's, all the time series are uploaded to a central server, for further matching and processing that combine measurements from different phones.

To identify all contacts between two apps 𝐴 and 𝐵 within a given time interval [𝑇𝑖 , 𝑇𝑗], Smittestopp follows a two-step approach, which we illustrate in Figure 5.6 and describe as follows:

1. The first step combines the discovery event time series from both devices (i.e. 𝐴 discovering 𝐵, and vice versa) into *contacts*. The combined time series comprise 𝑛 discovery events {𝑒1, 𝑒2, 𝑒3, ..., 𝑒𝑛}, where 𝑛 = 5 in our example.

Each event 𝑒𝑖 is a tuple that consists of four values, {𝑡𝑠𝑖 , 𝑃ℎ1, 𝑃ℎ2, 𝑟 𝑠𝑠𝑖}, where 𝑡𝑠𝑖 is the timestamp of the discovery event, 𝑃ℎ1 is the phone performing the measurement, while 𝑃ℎ2 is the measured phone. Finally, 𝑟 𝑠𝑠𝑖 is the measured signal strength indicator. Smittestopp then considers 𝑒1 as the beginning of a contact and starts looping through the combined discovery time series. Two consecutive events 𝑒𝑖 and 𝑒𝑖+1 belong to the same contact if 𝑡𝑠𝑖+1 − 𝑡𝑠𝑖 ≤ 𝜏. Consecutive events spaced by more than 𝜏 belong to different contacts. We set 𝜏 to five minutes, which allows us to identify contacts, given Smittestopp's scanning rate.

Recall from Section 5.1 that iOS devices scan every five minutes, while Android devices can take up to six minutes before discovering a nearby device. A contact

Fig. 5.5: RSSI for the Android close group, split by *txPower*

1 For an updated list of different contact tracing apps, see https://www.technologyreview. com/2020/05/07/1000961/launching-mittr-covid-tracing-tracker/.

consisting of a single discovery event is assumed to have lasted for five minutes. This results in a time series of contacts 𝑇 𝑆𝐴,𝐵. Each element in this time series is a contact that is characterized by the following: 1) a start timestamp, 2) an end timestamp, and 3) an array of RSSI measurements. Each of these measurements is tagged with the OS of the peripheral. The OS will be used later when determining proximity based on the measured RSSI.

2. BLE scans may not always succeed, due either to iOS limitations when the app is in the background, radio interference and propagation anomalies, or the presence of multiple devices in the app's proximity, which cannot be detected in a single scanning cycle (20 seconds). Hence, Smittestopp leverages its centralized nature to compensate for these artefacts. Smittestopp identifies all devices that both apps 𝐴 and 𝐵 have discovered within [𝑇𝑖 , 𝑇𝑗]. Assume that there is a third device 𝐶 that both 𝐴 and 𝐵 discovered during the interval of interest. Smittestopp constructs the combined contact time series for 𝐴, 𝐶 and 𝐵, 𝐶 and then overlays these time

Fig. 5.6: Discovery events from two phones are combined and grouped into contacts.

series over each other to identify all periods where both 𝐴 discovered 𝐶 and 𝐵 discovered 𝐶. This results in an intersection time series, 𝑇 𝑆𝐴,𝐵|𝐶, that shows periods when both devices were simultaneously close to a third device. The dashed red rectangle in Figure 5.6 bounds the intersection time series. We refer to this time series extrapolation as *contact graph completion* in the following. Smittestopp next checks whether 𝑇 𝑆𝐴,𝐵|𝐶 includes any contact period that is not in 𝑇 𝑆𝐴,𝐵 and updates the latter accordingly. Note that this update only shows that 𝐴 and 𝐵 were close to each other, since both were close to 𝐶; it does not, however, include direct RSSI measurements between 𝐴 and 𝐵.

Following the identification of all contact events, Smittestopp maps each event to a single or multiple distance bucket(s) based on the measured RSSI values. The controlled experiments in Section 5.3 shows differences between iOS and Android devices, as well as differences in the measured RSSI values as a function of the distance between phones. Based on these measurements, we define a mapping between RSSI values and the distance categories *very close*, *close*, and *relatively close* as described above. Tables 5.5 and 5.6 present these mappings for the measurements from iOS and Android devices, respectively.

Table 5.5: Mapping RSSI to distance categories when detecting an iOS device.

Table 5.6: Mapping RSSI to distance buckets when detecting an Android device.

The RSSI ranges in both tables are on the conservative side, which reduces the likelihood of false positives and can increase that of false negatives. To determine the proximity of a particular contact, we divide the contact duration into four proximity ranges (i.e. very close, close, relatively close, and within range), depending on the measured RSSI values. For example, a contact that lasts 𝑇𝑐 seconds and involves 𝑀 RSSI measurements that comprise 𝑚𝑣𝑐, 𝑚𝑐, and 𝑚𝑤𝑟 measurements that fall into the very close, close, and within range buckets, respectively, will be described with the following array, where each element approximates the time spent in each distance bucket: [(𝑚𝑣𝑐/𝑀)𝑇𝑐, (𝑚𝑐/𝑀)𝑇𝑐,(𝑚𝑤𝑟 /𝑀)𝑇𝑐]

The contacts that are identified using contact graph completion do not include direct RSSI measurements between the devices of interest. Hence, we leverage the devices' RSSI measurements to a third device to approximate the distance between them. For example, if 𝑎 is very close to 𝑐 (i.e. within 1 metre) and 𝑏 is very close to 𝑐, then 𝑎 and 𝑏 can be at most 2 metres apart, which corresponds to the case in which 𝑐 is at the midway point on a straight line between 𝑎 and 𝑏. Generally speaking, the maximum distance between 𝑎 and 𝑏 is given by 𝑑(𝑎, 𝑏) = 𝑚𝑎𝑥(𝑑(𝑎, 𝑐)) + 𝑚𝑎𝑥(𝑑(𝑏, 𝑐)). We use the maximum distance as a conservative measure to classify contact graph completion contacts.

#### **5.4.2 Validation of Smittestopp contacts**

To assess the efficacy of Smittestopp in identifying contacts, we use the data set from the experiment with 31 phones, which was described in Section 5.3. This test has similarities to real-world scenarios where a large number of individuals are packed in a limited area, for example, a crowded train or a party, although there are clearly environmental factors in those scenarios that we do capture in this experiment. To this end, we count how many other phones that each phone has seen for at least an hour per day. We choose one hour as a conservative threshold at which Smittestopp will flag a high-risk contact. Perfect identification means that each phone will discover 30 other phones. To quantify the impact of iOS limitations on discoverability, we divide the iPhones in the stress test into three groups: iOS-A, iPhones with the app in the foreground; iOS-B, iPhones with the screen on but the app in background; and iOS-C, iPhones with the screen off.

Figure 5.7 shows the number of phones undiscovered by each test phone during the first test day.2 The majority of phones discovered 90% of the nearby phones (i.e. 27 other phones). iPhones discovered all the other iPhones, but failed to discover some Android phones. Overall, some Android phones struggled with both discovering other phones, as well as with being discovered. Notably, all Samsung phones exhibited good performance. The three Android phones that struggled the most at discovery were Sony Xperia 1, Google Pixel 4, and OnePlus 8.

Bearing in mind the fundamental limitations of Bluetooth scanning on iOS, we note that Smittestopp performs better than expected on iPhones. Surprisingly, we also observe little difference between the three testing modes for iPhones. A closer look at the Android devices shows that they occasionally suffer from a corrupt Bluetooth cache, which degrades their ability to both scan and be discovered. We believe that this degraded performance is caused by effects unrelated to the app, such as the underlying Bluetooth stack or the way it is managed by Android.

The high level of discoverability can be attributed to the centralized nature of Smittestopp. Figure 5.8 shows that the number of undiscovered contacts doubles and

2 The other two test days exhibit a similar trend.

Fig. 5.7: The number of undiscovered phones per test phone on the first test day (iOS-A, iPhones with the app on, in the foreground; iOS-B, iPhones with screen on but with the app in the background; and iOS-C, iPhones with the screen off).

in some cases triples or more when we do not combine time series centrally. As expected, iPhones benefit more from the centralized architecture.

To validate Smittestopp contacts in a realistic setting, we ran a semicontrolled test with participants carrying phones and simulating real-world contacts, such as contacts in training centres, shops, cafes, and public transportation. Overall, Smittestopp performs reasonably well. It correctly identifies 80% of high-risk contacts and is robust to overestimating risk. For more details about the semicontrolled tests and their results, see Chapter 6. For more details about the simulated contacts, see Appendices A and B in [7].

The relatively high accuracy of Smittestopp in both controlled and semicontrolled settings indicates that resorting to RSSI buckets without calibration works acceptably well, with a low number of both false positives and false negatives for high-risk encounters.

# **5.5 Related work**

Since its standardization a decade ago, several works have proposed using BLE for estimating distances indoors (e.g. [10, 18, 13, 9]. These methods assume the deployment of fixed beacons in indoor environments such as shopping centres. Users would then leverage the signal they receive from these beacons to determine their

Fig. 5.8: The number of undiscovered phones per test phone on the first test day without *contact graph completion* contacts (iOS-A, iPhones with the app in the foreground; iOS-B, iPhones with the screen on but with the app in the background; iOS-C, iPhones with the screen off).

position. Most previous studies have focused on improving localization accuracy and often report error margins within 2 to 3 metres. Digital contact tracing, however, is different, since it is not built around the presence of fixed beacons, because contacts between people are not limited to indoor environments where such infrastructure can be deployed. Consequently, all involved phones must be both discoverable and be able to discover other devices in their proximity.

The recent interest in using BLE for digital tracing contacts with persons infected with COVID-19 has prompted many to revisit the question of whether BLE can provide an accurate estimate of distance (e.g. [15, 16, 17, 12]). These studies have underscored the difficulty in using BLE RSSI as a reliable estimate of physical distance. Instead, they recommend a set of guidelines (e.g. asking people to put their phones on a table when meeting strangers) or leverage information from other sensors in the phone to determine the context of the contact (i.e. the phone's orientation and placement) to reduce and control for environment-related effects. Notably, the Google/Apple Exposure Notifications (GAEN) framework does not provide a direct mapping between RSSI and distance [5]. Instead, it calibrates phones to control for all device-related effects and then suggests that health authorities determine their own distance thresholds. This task, however, has proved to be harder than expected [3, 14, 7]. Smittestopp opts for using wider ranges to describe contacts, which seems to provide reasonable results.

SwissCovid is one of the contact tracing apps developed based on the GAEN framework. Measurements have been performed to understand the relation between the attenuation reported by SwissCovid and the actual distances between devices [2]. These measurements are similar in nature to those reported here. The goal of the measurements is to find suitable threshold values to determine when identified contacts should lead to an alert. The study presents empirical data on the recall rate (fraction of phones identified within the threshold distance) and precision rate (fraction of identified phones that were actually within the threshold distance). The overall insight from this study is that it is hard to find a threshold that provides both high recall and high precision.

# **5.6 Lessons learned**

In this chapter, we described Smittestopp's approach to identifying contacts using BLE. BLE signal strength is used as a proxy for distance to determine whether a contact between two users is close enough and long enough to warrant notification. In working with BLE contact tracing, we learned, in particular, the importance of the following points:

We believe that all solutions that adopt BLE for contact tracing will need to continuously monitor and improve the mapping between the measured signal strength and proximity. One such improvement could be to use other sensors in the phone to provide extra data to improve BLE localization.

# **References**

[1] Specification of the Bluetooth System, Covered Core Package, Version: 4.0;

5 Using Bluetooth for contact tracing 97

The Bluetooth Special Interest Group: Kirkland, WA, USA, 2010.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 6 Digital tracing, validation, and reporting**

Ahmed Elmokashfi, Simon Funke, Timo Klock, Miroslav Kuchta, Valeriya Naumova, and Julie Uv

**Abstract** Manual contact tracing has been a key component in controlling the outbreak of the COVID-19 pandemic. The identification and isolation of close contacts of confirmed cases have successfully interrupted transmission chains and reduced the disease spread. Even though manual contact tracing has been widely used, its practice has shown that it is slow and cannot be scaled up once the epidemic grows beyond the early phase. In this case, digital contact tracing can play a significant role in controlling the pandemic. In this chapter, based on our experience and lessons learned from the Smittestopp project, we discuss the main prerequisites for the efficient implementation and validation of digital contact tracing in a population. Specifically, we discuss how to translate a close contact defined for manual tracing to proximity events discovered by a phone, that is, how to define a meaningful risk

A. Elmokashfi

e-mail<EMAIL_ADDRESS>
S. Funke

T. Klock

Department of Numerical Analysis and Scientific Computing, Simula Research Laboratory e-mail<EMAIL_ADDRESS>
M. Kuchta

V. Naumova

J. Uv

© The Author(s) 2022 99 A. Elmokashfi et al (eds.) . , *Smittestopp* − *A Case Study on Digital Contact Tracing*, Simula SpringerBriefs on Computing 11, https://doi.org/10.1007/978-3-031-05466-2\_6

Center for Resilient Networks and Applications, Simula Metropolitan Center for Digital Engineering,

Department of Numerical Analysis and Scientific Computing, Simula Research Laboratory e-mail<EMAIL_ADDRESS>
Department of Numerical Analysis and Scientific Computing, Simula Research Laboratory e-mail<EMAIL_ADDRESS>
Department of Machine Intelligence, Simula Metropolitan Center for Digital Engineering, Simula Consulting AS, e-mail<EMAIL_ADDRESS>
Department of Computational Physiology, Simula Research Laboratory e-mail<EMAIL_ADDRESS>
score and validate the digital contact tracing. We discuss challenges related to each step and provide solutions to some of them, even though questions still remain.

# **6.1 Manual versus digital Tracing**

Since the beginning of the COVID-19 outbreak, contact tracing has been a key component of response strategies in many countries. The rapid identification and quarantine of close contacts of confirmed cases have successfully interrupted transmission chains and reduced the spread of the disease. At the same time, manual contact tracing is slow and cannot be scaled up once the epidemic grows beyond the early phase. Some confirmed cases can also have hundreds of close contacts, as has been reported in the news. To identify, find, and inform all of them in a short time requires a lot of human resources and tedious manual work.

Ferretti et al. propose that digital contact tracing can play a significant role in the control of the COVID-19 pandemic [6]. Since then, several countries have pursued digital solutions for contact tracing using mobile phones. The central idea for digital contact tracing is that individuals in a population install an app that recalls proximity events with other similarly equipped users and then notifies past contacts if and when the individual tests positive for COVID-19. Digital contact tracing does not intend to substitute for manual contact tracing; rather, it allows for the faster and more efficient identification/isolation of close contacts. In this chapter, we discuss how one can correctly identify the most relevant contact events with a digital contact tracing tool and under what circumstances digital contact tracing can be beneficial, compared to manual contact tracing.

The overarching issue we aim to resolve here is how to map proximity events between phones and convert them to epidemiologically meaningful levels of infection transmission risk. To address this issue, we collaborated closely with epidemiologists and manual contact tracing teams from the Norwegian National Institute of Public Health (NIPH). Specifically, we studied the following questions:

**Manual contact tracing.** According to NIPH, close contacts are all people who have been in close contact with an individual who tested positive for COVID-19 in the 48 hours before symptom onset and until that individual comes out of isolation. A distinction is made between 'household members and equivalent close contacts' and 'other close contacts'. The person responsible for contact tracing decides in which category the individual belongs after assessing the infection risk. The type of followup required, including the duration of quarantine, differs depending on the type of contact.

'Household members or equivalent close contacts' are those who live in the same household, those who have had a similar close contact as someone in a household (e.g. boyfriend/girlfriend, work colleagues in an open plan office, the same cohort at a childcare centre or school), and those who have cared for a person confirmed to have COVID-19 without using the recommended protective equipment. Other close contacts are defined as follows

**Smittestopp as a digital contact tracing tool.** The Smittestopp app was launched on 16 April 2020 with two main objectives in mind:

Smittestopp uses both GPS positioning and Bluetooth (BT) proximity to identify close contacts of confirmed COVID-19 cases. Data are stored for a maximum of 30 days.

For the purpose of contact tracing, Smittestopp has been linked with the Norwegian Surveillance System for Communicable Diseases (MSIS). Since COVID-19 is a notifiable condition in Norway, all laboratory-confirmed cases are registered in the MSIS database, which is required under the regulations on the notification system for communicable diseases. Cases are registered in the MSIS database using the infected individual's national identity number, a unique identifier that is assigned to each citizen or legal resident for life. This record can then be linked to a Smittestopp user's mobile number, which is available through the central Contact and Reservation Register. Only people who have downloaded the app and accepted the terms of use will have MSIS case information linked to mobile contact information. If a Smittestopp user tests positive for COVID-19, other Smittestopp users can be alerted if they were in close contact with that individual in the past seven days before the test.

In Smittestopp, BT data are primarily used to determine proximity between phones, whereas GPS data allow for the identification of locations and the more accurate identification of contact duration. The adapted digital definition of a contact is any person in contact with a case with cumulative BT proximity for more than 15 minutes or at least one instance of BT proximity (i.e. that corresponds to a duration of up to five minutes) and GPS proximity for at least 30 minutes. This definition allows us to identify potential close contacts who were in proximity for less than 15 minutes continuously but, for instance, multiple times over the past days, such as when taking the same bus. At the same time, these types of contacts are completely unnoticed or ignored in the current definition of manual tracing.

After identifying close contacts, the app associates each contact with a risk score/category that helps separate out contacts likely to have resulted in an infection. This scoring is necessary for reducing false alarms, which can potentially lead to requesting healthy individuals to quarantine, or vice versa. The risk score, which has been adapted from the literature and discussions with UK collaborators, is calculated as

$$\int\_0^T \frac{1}{\text{distance}^2} dt,$$

where 𝑇 denotes the accumulated contact time [6, 8]. The inverse distance squared is used to model the spread of droplets generated by coughing [4]. The formula also indicates that the risk is high within 1 metre, where such proximity is expected to be related to physical contact between individuals. The time component helps in weighting the risk; that is, the longer the contact time, the higher the risk.

Another important aspect of risk scoring is the time difference between the contact event and symptom onset. This measure is not captured directly in the risk score, but, rather, implicitly when choosing persons to alert. Recall that Smittestopp only alerts app users who were in close proximity to an infected user in the seven days leading to the test day. The number of days (seven) is treated as a parameter and can be adjusted based on new knowledge related to the disease spread.

The risk scores are calculated separately for BT and GPS contacts. Once these risk scores are calculated, a risk category (low, medium, or high) is assigned to each contact. If BT and GPS contacts result in different risk categories, the highest level of risk is chosen as the ultimate risk category.

Table 6.1: Correspondence between risk categories and duration of contact at a distance of 2 metres for BT data and a distance of 4 metres for GPS data.

**Challenges related to digital contact tracing.** From the early phase of the Smittestopp development, we used different approaches to calibrate and validate Smittestopp as a contact tracing tool. These include pre-launch technical validation, comparison of manual and digital tracing in municipalities, and testing in controlled real-life and lab scenarios (see Section 6.4).

During these efforts, it became clear that the definition of digital close contact and risk scores had to be thoroughly tested, adjusted, and validated, due to several factors. This was also pointed out in [6, 10]. First, digital tracing is generally a completely new technology, developed within an extremely short period. Therefore, it still continues to lack technical and epidemiological validation and proper interpretation of the obtained information. Specifically, as pointed out in several studies, the use of neither BT nor GPS signals for digital contact tracing can be expected to deliver optimal results in terms of specificity and sensitivity. For example, as also discussed in previous chapters, the accuracy of a GPS signal is quite low (at least 5 metres), which, by default, does not allow for close contact identification. Even though the BT technology allows us to identify phones in close proximity, the strength of the BT signal changes drastically from one phone to another, as well as based on the phone's location, such as held in a hand or in a pocket. Therefore, it is almost impossible (and not recommended) to translate BT signal strength into the distance definition that is used as input for risk score calculation.

Second, real-life validation of digital contact tracing is particularly challenging, unless a large number of users in a population installs the app (see Chapter 7). In addition, once the contacts of an infected person are identified, how can we ensure that our risk score allows their ranking so that we can notify those who are or will become infected (to notify and quarantine true positives), avoid failing to notify those who are or will become sick (to avoid missing false negatives), and avoid notifying those who are not and will not become sick (to avoid quarantining false positives)? No system will be perfect, and it is important to find the optimal trade-off between these outcomes in terms of the best possible control of the epidemic while still ensuring trust in the technology.

In this chapter, we aim to answer some of the questions, discuss related challenges, as well as share the lessons learned. The chapter is organised as follows. In Section 6.2, we discuss what type of information can be provided by a digital contact tracing tool for its validation and to justify its usefulness for epidemiologists and manual contact tracing teams. Section 6.3 discusses how this information can be obtained from the digital tracing app. In Section 6.4, we discuss the testing and validation routines used for the Smittestopp app, together with the relevant results. We conclude the chapter with a discussion in Section 6.5.

# **6.2 The type of information necessary to validate a digital tracing tool and prove its usefulness for epidemiologists/researchers**

The information generated by the Smittestopp tracing tool is used in three scenarios: first, for the internal validation of the tracing algorithms; second, to support epidemiologists in the contact tracing of infected individuals; and third, to provide aggregated contact and movement statistics at the population level to help decision makers understand the risk of future outbreaks. During the development of Smittestopp, many discussions took place between epidemiologists, researchers, and developers to identify the type of information a tracing tool should provide to tackle these objectives. This sections summarizes the main conclusions for the first two objectives. For the last objective, we refer the reader to Chapter 7.

The key information required to aid in contact tracing is the list of persons who have been in contact with an infected individual. For each person, the system must provide the details, such as the phone number, times, distances, and duration, of the contact with the infected individual. In addition, it is common to present a risk category that summarizes the overall risk of infection transmission in a simple traffic light system (low/medium/high). The risk category allows for the rapid separation between high-risk contacts, which might need immediate action, and medium-risk contacts, which should be looked at in more detail. At times, there can be a high number of contacts, making it necessary to appropriately filter out events we do not consider to be contacts, such as contact involving short durations and/or large distances. In these cases, a risk category provides a natural value for filtering out nonsignificant events. In addition to this key information, the contact's location data can serve as a helpful tool. For instance, knowing if the contact happened inside (within a closed environment) or outside and further being able to determine the type of location – for example, a shop, a public transportation vehicle, or a gym – can help epidemiologists better judge the true risk level of the affected parties. Finally, we found that most of the data can be summarized on a daily basis to obtain a trade-off between sufficient information and compact presentation of the data.

The purpose of internal validation is to evaluate the performance and accuracy of the tracing app, as well as to identify weaknesses. Once a weakness has been identified, it can be addressed and the performance of the tracing increased (e.g. through parameter tweaking or adapted algorithms). To enable the internal validation of the tracing algorithms, the platform must therefore provide sufficient information about contacts, such that they can be compared to reference data. This information can be at a more detailed level than necessary for epidemiologists. For instance, all contact events could be shown, instead of daily aggregated data. The data collection for the internal validation was carried out through pre-launch testing as described in Section 6.4. From this pre-launch testing, we were able to check if the algorithm could correctly identify when the contact happened, the duration of contact, and the location and activity and their durations. The location and activity and their durations were investigated using points of interest and transport modes.

# **6.3 Obtaining the information: Design principles and the implementation of digital contact tracing**

The workflow of the Smittestopp contact tracing pipeline mimics that of manual contact tracing. This means that input to the pipeline involves a time window of interest and a specific individual identifiable via the individual's UUID, and the output is a report summarizing the contact details with other individuals in the population. An important security aspect is that working with the pipeline does not require direct access to the central data storage, because the required data are automatically queried as part of the contact tracing pipeline. In addition, the analysis

Fig. 6.1: The input to the Smittestopp contact tracing pipeline is a potentially infected individual (identified by a Universally Unique Identifier, or UUID) and a time window of interest. The pipeline returns a report summarizing all BT and/or GPS contacts with other individuals in the population. This process thus mimics manual contact tracing as performed by health authorities. The central data storage can only be accessed from within the automated contact tracing pipeline through a set of predefined queries, thus preventing access to the data outside of contact tracing requests.

pipeline code has only limited access to the GPS and BT data, through predefined database queries. The basic workflow is detailed in Figure 6.1.

In this section, we focus on describing the contact tracing pipeline, that is, the component in the middle of Figure 6.1. The first part details implementation aspects that are shared for processing and analysing both BT and GPS data. However, since the data sources naturally differ and different types of pre-processing are required, the second and third parts describe additional details for GPS and BT data, respectively. The final part then concerns the output of the pipeline, that is, the contact reports.

#### **6.3.1 Shared components between GPS and BT data**

Whether we work with BT or GPS data, the main data structure behind the contact tracing pipeline is a contact graph whose nodes represent individuals and the edges between two nodes indicate contacts between the corresponding individuals. Hypothetically, it is possible to constantly maintain an updated version of such a graph over the entire population and for a given time window, but such a strategy is not scalable to reasonable population sizes (larger than a few thousand) and is therefore not pursued. Instead, we compute, on demand, the subgraph of first-order neighbours linked to a potentially infected individual and generate the contact report from the corresponding subgraph. Guided by the number of quarantine days in Norway after potential infection with the coronavirus, the edges in the graph are deleted after 10 days without a contact between two respective individuals. Whenever we refer to the contact graph from now on, we mean the subgraph consisting of the first-order neighbours linked to the input individual.

We note that, at the cost of higher computational demand, the approach can naturally be extended to trace higher-order contacts of a potentially infected individual

Fig. 6.2: The data structure behind the Smittestopp contact tracing pipeline, which is fed into the summary report generating code. A contact graph is created for each infected individual (with the input UUID) and other users in the central data storage. The edges of the graph contain contact list objects that store all cumulative and detailed information about contacts between two individuals in the time window of interest.

by computing a larger subgraph of higher-order neighbours. To facilitate quick and efficient contact tracing, however, the entire process of on-demand report generation should be facilitated to complete in less than an hour, using limited computational resources. This is because digital contact tracing is most important in times of high infection loads, when hundreds or thousands of pipeline requests can be submitted each day. Furthermore, multiple requests can naturally be run in parallel, so that the parallelization of a single request would require large amounts of overall computational resources.

The core of the codebase consists of three classes that represent contact graphs, contacts, and so-called contact lists (see Figure 6.2). The nodes in the contact graph represent individuals, and the edges of the graph contain instantiations of the contact list class. The contact list object is a list of isolated contacts between the same two individuals that occurred over the entire time window. The representation of contacts using isolated contact events and accumulated contact lists is convenient for report generation, because we can attribute detailed information about each isolated contact event (duration, intensity, location, and more) to instantiations of the contact class, whereas contact list objects can be used to compute cumulative information about all contacts between two individuals in the time window of interest. We note, however, that the noisy nature of both GPS and BT data often fragments an isolated contact between individuals into several contact events, for example, due to loss of BT connection or GPS information, even though all segments belong to the same consecutive contact event. We therefore use merging and interpolation procedures to post-process contact events before deciding whether computed contact events constitute two separate entries in a contact list or should be combined into a single entry by interpolating events. Since the processes of interpolation and merging differ between BT and GPS data, we postpone further details to Sections 6.3.2 and 6.3.3, respectively.

Generating the populated data structure in Figure 6.2 requires the computation of isolated contact events based on information in the central data storage. Due to the different nature of stored BT and GPS data, however, we face vastly different challenges in contact computations based on the data type. We therefore postpone the details of this issue to the next two sections.

Finally, contact summary report generation using a populated contact graph is straightforward, because we can loop over edges to list contacts between two individuals with as much information as we desire. Furthermore, it is only at this point that we filter out certain contacts or individuals based on requirements that are specified by epidemiologists. For instance, we can check whether the cumulative contact list contains contacts with a distance of less than 2 metres over at least 15 minutes and thus report only those contacts satisfying the given specifications.

#### **6.3.2 BT data processing**

Querying the central data storage of BT data with a patient UUID and a time window results in a table of events, where each event is specified by the time coordinates (beginning and end) and identifiers of the two devices in contact. In addition, based on the physical proximity, 𝑑, of the devices, each event carries information about the duration of very close (𝑑 ≤ 2m), close (2m < 𝑑 ≤ 5m), and relatively close (5m < 𝑑 ≤ 15m) contacts, which are relevant for determining the risk category (see Table 6.2).

From the point of view of Section 6.3.1, a BT contact graph is straightforward to instantiate, since the nodes and edges are readily available from the query result. However, computing the elements of the contact list require pre-processing, which takes into account the nature of BT event reporting, for example, fragmentation.

Figure 6.3 shows examples of the three scenarios commonly encountered in the BT records: (i) a new BT event occurs entirely within the lifetime of a different event, (ii) two events occur in close1 succession, and (iii) the events overlap. In such cases, it is not desirable to report the individual BT events as separate contacts (i.e. as different items in the contact list), since this can lead to incorrect (overestimated) risk scores. Instead, items (i) to (iii) are *merged* into a new event to be reported as a contact. The closeness attributes of the new contact, in items (i) and (ii), are computed conservatively, that is, by taking the maximum values of the parent attributes. In the case of overlap, the duration 𝑞𝐶 of the child event is computed as

$$q\_C = q\_A \frac{\Delta\_A - \Delta}{\Delta\_A} + q\_B \frac{\Delta\_B - \Delta}{\Delta\_B} + \max\left(\frac{q\_A}{\Delta\_A}, \frac{q\_B}{\Delta\_B}\right) \Delta\_A$$

1 The temporal distance of BT events to be considered close is a parameter of the analysis pipeline (see 𝛿𝑡 in Figure 6.3).

where 𝑞𝑖 , Δ𝑖 , 𝑖 = 𝐴, 𝐵, are, respectively, the attribute values and durations of the parent events, and Δ is the size of the overlap. We remark that the merge rules (i) to (iii) are applied to the list of BT events until no more merging criteria are met (see Figure 6.3 for illustration).

If the GPS data are available, the final step of BT pre-processing is the query of GPS coordinates for each of the contacts in the contact list. The BT events can thus be anchored in space, which is useful, for example, for visualization.

Fig. 6.3: Merging of BT events. Event 0 (lasting from 𝑡0 to 𝑇0, with duration Δ0 = 𝑇0 − 𝑡0) contains event 1 and is close to event 2 (𝑡2 − 𝑇0 ≤ 𝛿𝑡). Event 2 overlaps with event 3 for a time Δ = 𝑇2 − 𝑡3. Applying the merge rules to events 0, 1, 2, and 3 results in the final BT contact [𝑡𝑐, 𝑇𝐶].

#### **6.3.3 GPS data processing**

GPS data serve two main purposes when performing digital contract tracing: 1) extracting metadata, such as trajectory maps, to provide a context for a contact, and 2) identifying people who have been in contact with a confirmed case, by computing all GPS trajectories that intersect, for example, for at least 30 minutes with the GPS trajectory of the case. For both these tasks, the raw GPS data are too noisy and require pre-processing, such as removing outliers and, potentially, interpolation.

The algorithm for computing all trajectory intersections must be carefully designed to be computationally feasible. In particular, querying the location data of all other users to check for possible contacts can be costly, due to the size of the data, namely, billions of GPS data points collected within a day. We note that the related queries can be greatly accelerated if the underlying database uses spatial indexing, implemented, for example, as B-trees [2] or R-trees [7]. In particular, collisions can be quickly computed using a hierarchy of bounding boxes (see Figure 6.5 for illustration). While the SQL server used by the Smittestopp backend supports spatial indexing, this solution was not pursued for two reasons: first, the native implementation requires two-dimensional spatial data, and, in our case, the spatiotemporal coordinates are three dimensional. Second, in the centralized database, the depth of the search tree to obtain leaf-node boxes of small volume is considerable. At the same time, a shallow structure means that, at the finest level, ∼10 square kilometres are searched for contacts.

In the absence of database spatial indexing, the contacts are instead computed in the following hierarchical way. First, on a coarse level, potential contacts are identified through database queries that can be executed quickly on the data storage side. Second, on a fine level, we confir each potential contact by comparing pairs of GPS trajectories. Our intersection algorithm consists of the following steps:

	- a. Overlay the trajectory of the case with a minimal set of bounding boxes. The bounding boxes are constructed so that they all have roughly the same volume. Special cases are treated, for instance, if a person travels too fast, as in an airplane.
	- b. Query the database for all GPS events within that bounding box. This query is fast because database indices are used for all query parameters, that is, the latitude, longitude, and timestamp.

The algorithm is visualized in Figure 6.4.

	- a. Linear interpolation of the trajectories on the union of their timestamps;
	- b. Splitting the trajectories into consecutive segments with no large gaps in either time or space;
	- c. Comparing the trajectories on each segment to determine whether a contact has occurred, that is, if the distance is below the predefined threshold.

Figure 6.6 shows an example of the output of this algorithm.

We note that Step 3 of the intersection algorithm described is rather nontrivial, due to the imperfect nature of GPS data and frequent losses of GPS signals (for a recent study of accuracy in urban areas, see, e.g. [12]). First, interpolating GPS data onto the union of the timestamps of both trajectories must not be performed over large gaps in either the spatial or time domain, because this quickly becomes an extrapolation of data, rather than an interpolation. In the Smittestopp contact tracing pipeline, we therefore introduce two parameters specifying the maximum allowed time interpolation (with a default of one hour) and spatial interpolation (with a default of 1 kilometre). Second, even though the GPS data recorded by mobile phones are processed and assisted by data from cellular base stations (assisted GPS [5]), the data still contain extreme outliers that should not be used as valid location points. Fortunately, because of the internal processing of GPS data, mobile phones also return an accuracy measurement with each data point, so that we can exclude extreme outliers by omitting data whose accuracy exceeds a predefined threshold (instances with a default of 50 metres). To facilitate both of these processing tasks, it

Fig. 6.4: Coarse-scale algorithm for finding all GPS trajectories that intersect with the trajectory of a patient. The patient's trajectory, represented by the black line with a red cross indicating the position every X minutes, is covered by a set of latitude– longitude–time bounding boxes of constant volume. In this case, three bounding boxes are used, and we require lat1 × lon1 × (𝑡2 − 𝑡1) ≈ lat2 × lon2 × (𝑡3 − 𝑡2) ≈ lat3 × lon3 × (𝑡4 − 𝑡3). One SQL query is then executed for each bounding box, querying the GPS events within it. These queries require no geospatial indexing in the database and are fast if the latitude–longitude–timestamp database columns are indexed.

is convenient to implement a class representing GPS trajectories, so that processing can logically be applied to instantiations of the trajectory class.

Finally, we stress that the processing of GPS data is a challenging task and represents an entire research area on its own. Due to the short development time span of the Smittestopp app, we were not able to rigorously test different processing strategies, such as map matching techniques [3, 11], filter-based approaches [9], and others (for a review, see, e.g. [15]). Rather, our goal was to develop a simple but robust solution that excludes false-positive GPS contacts within a limited development time frame.

#### **6.3.4 Contact tracing reports**

Due to the different requirements of the analysis output (see Section 6.2), the analysis pipeline can produce two report styles:

Both report styles give separate information on contacts detected by GPS and BT. By default, the report uses only contact events that match the Norwegian Institute of Public Health (NIPH) requirements, that is, with risk category 'medium', 'high', 'gps\_only', or 'bt\_below\_15\_min', as defined in Table 6.2. For debugging and internal testing, this filter can be deactivated to generate reports that show all contact

Fig. 6.5: On the left is a visualization of a geospatial database using R-trees as the tree data structure (image source: Wikipedia). The panel on the right illustrates geospatial indexing using depth 3 B-trees. Hierarchical structures allow for efficient distance queries. For example, point 𝑃, with index (4, 2, 3), is not close to 𝑄, since its index is (4, 𝑖, · · ·), where, crucially, 𝑖 ≠ 2. Neither R-trees nor B-trees were used by Smittestopp, since experiments showed insufficient performance for computing trajectory intersections on large data sets. A key difference between R-/B-trees and the method described in Figure 6.4 is that the bounding boxes in R-/B-trees are computed on the database side, while the method described in Figure 6.4 computes the bounding boxes dynamically or optimally for each patient's trajectory.

events. The reports can be saved as text, in JSON format, or as HTML webpages, with static or interactive maps and plots.

Table 6.2: Risk category definitions. In addition, to be included in an NIPH report, the contact event needs to contain either 1) BT contacts with a cumulative duration of over two minutes or 2) GPS contacts with an accuracy below 10 metres and a cumulative duration of at least 30 minutes.

Fig. 6.6: The left panel shows the GPS trajectories of two phones during a walk. The right panel shows the identified contact points in red.

Concerning the additional risk categories *gps\_only* and *bt\_below\_15\_min* in Table 6.2, we note that, during the pre-launch testing, too few contacts were reported as *high* or *medium* risk. We suspected that one (or both) of the boundaries in the filter was too strict. Therefore two new categories (i.e. *gps\_only* and *bt\_below\_15\_min*) were introduced.

The day-by-day style report provides information on the cumulative duration, distance, and location of contacts through *points of interest*. Points of interest are determined by transport modes and amenities near the contact points and can be divided into three categories: inside (e.g. in a building or a vehicle), outside (e.g. when walking), and uncertain (when the transport modes are inconsistent). If GPS data are available for a given contact, a static map of contact trajectories is also displayed. To improve privacy, the map shows no more than necessary for contact tracing. An example of the information shown in a day-by-day style report is provided in Figure 6.7-6.12.

The detailed style reports contain information on each individual contact event. In addition to the information provided in the aggregated reports, the detailed style reports show the transport modes of the users involved in the contact and the duration of the contact spent inside and/or outside. In addition to helping determine the location, transport modes can be used to validate an actual contact by checking if two modes are consistent. The three transport modes are *still*, *on foot*, and *vehicle*. The case of a car driving past a pedestrian would not be considered a contact, because the transport modes would be *on foot* and *vehicle*. Detailed reports are only used for internal testing and validation and were not sent to NIPH.

## Fig. 6.7: Header of an example report.

## Fig. 6.8: Example of a detailed daily summary.

Fig. 6.10: Example of a static map generated for daily summary. The green and blue points represent user trajectories, and the red points indicate contact between users.

Fig. 6.11: Graph of the duration for different distances.

Fig. 6.12: Graph of when contact events occurred and their distances.

# **6.4 Smittestopp testing and validation**

Since digital contact tracing is an entirely novel technology, we performed testing and validation in several phases, which allowed us to identify its strengths and weaknesses. Specifically, we performed the following three testing/validation phases:

In addition, we closely followed other teams worldwide in terms of their validation efforts, so that we could modify our studies according to new findings.

Below we provide a detailed description of each of the studies, including the scenarios and results. It is worth mentioning that some countries working on digital tracing solutions also performed extensive testing and validation studies. Specifically, we analysed the results of the German [13] and Swiss [1] studies, which tested Google/Apple Exposure Notifications in lab and real-life scenarios.

## **6.4.1 Pre-launch testing**

Before the launch of Smittestopp on 16 April 2020, we validated the contact tracing solution in several phases, using data from approximately 300 app testers. The main objectives of this phase were to estimate beacon proximity/distance based on the BT signal strength, evaluate phone discoverability via BT and evaluate the tracing algorithms for different types of activities (e.g. walking, driving, and indoor and outdoor activities), and understand whether GPS could be used for contact tracing alone or only in combination with BT. The results of this validation show that the tracing algorithm is quite accurate in identifying contacts if the data are available, but that the contact duration reported in the app differs from the ground truth. Usually the identified duration is slightly shorter than in reality. Additionally, the accuracy of GPS was found to be quite low in indoor locations. However, GPS seemed to provide accurate results for outdoor contacts. Moreover, this phase allowed us to understand and work on challenges related to digital tracing, as well as to specify which features could be provided to NIPH in real-life validation, as discussed above.

#### **6.4.2 Real-life validation in testing municipalities**

To validate the app as a contact tracing tool, from 27 April to 31 May, in collaboration with NIPH, we compared the results from manual and digital contact tracing in three municipalities. During the five-week test period, the uptake of the app in these municipalities was around 14%. Moreover, a rather low number of new cases, only 118, were reported during the five-week period. Of all the cases, only 31 were Smittestopp users. In total, 60 contacts were identified by Smittestopp, of which 24 (40%) were confirmed to be close contacts. Of these, 18 were also found through manual contact tracing (75%), whereas six contacts were found only through Smittestopp (25%). We also looked closely into 20 of the unconfirmed cases, identified by the app as close contacts. It appears that nine of them took place more than 48 hours before the onset of symptoms and were thus not considered true close contacts in manual tracing. The app does not consider symptom onset as one of the variables and takes into account all contacts within the past seven days, and the manual contract tracing team can then decide which contacts to notify. Another eight identified contacts had too little contact with the case (false positives). For the remaining three cases, it is difficult to verify the correctness of the digital contact tracing, since, in two cases, the phone was used by another person than the name under which it was registered and, in one case, the individual was asymptomatic.

In summary, the results of the validation demonstrate that, although Smittestopp was able to identify both contacts already identified through manual contact tracing and additional contacts not already known to the contact tracers, the risk score, adapted from the United Kingdom, required a modification to represent true contacts, since the original version was not adjusted for digital contact tracing. The results also confirm that the added value of a contact tracing app is to identify random contacts, that is, contacts not personally known to the case. Given the low numbers of cases and app users, the data collected through the municipalities was too limited to draw any further conclusions regarding the app's effectiveness in identifying contacts. Therefore, we performed additional controlled testing under real-life and lab conditions to better understand the strengths and weaknesses of digital contact tracing.

#### **6.4.3 Controlled testing under real-life and lab conditions**

In August 2020, a modified and improved version of the app was tested in two types of experiments: a stress test lab experiment and in real-life scenarios. The improvement involved enhancing the stability of the Android version of the app. The goal of the stress test was to assess the ability of the solution to discover phones in proximity when many phones are located in the same place. For more details about the test setup and phones used, see Chapter 5. The testing in real-life scenarios aimed to assess the ability of the solution to discover contacts that were either true positives or false positives in scenarios such as restaurants, shopping malls, and training centres. The detailed descriptions of the tests and their comparison with the Google/Apple solution is available in the Simula-published report on the comparison of different solutions for digital contact tracing (in Norwegian) [14]. In this section, we present only the results from real-life testing. Chapter 5 contains a detailed description of the stress test setup and results.

In the **real-life scenarios**, we tested the app's ability to discover other phones in proximity and to estimate the risk of infection if the contact was identified. In these experiments, six participants were asked to perform standard social interactions while using the testing phones in a common manner. The participants were split into three groups; in each group, one participant had an Android phone and another participant had an iOS phone. More specifically, we used the following phones: second-generation iPhone SE (two), iPhone 11, iPhone 11 Pro Max, Huawei P30 Pro, Samsung S20 5G, Sony Xperia 1, Samsung A71, and Samsung S10. The testing lasted around four hours, during which time the participants carried out different social interaction activities, such as visiting a bar, a restaurant, a training centre, or a shopping mall. Three additional phones were located in the testing areas: one with a waitress, one with a bar attendant, and one with a receptionist. The details of the protocol and scenarios are available in the report.2

2 See https://www.simula.no/news/en-ny-runde-med-digital-smittesporing.

The participants within each group were asked to remain at one metre of each other. Each participant logged their travel details as well as information on where the phone was located. We used this information, together with the detailed protocol, to analyse the results.

Based on the protocol and the participants' logs, 66 contacts could have been identified by the technology, among which 26 should have been considered very close contacts. For our technology, we define a contact as phones being in proximity to each other (within 2 metres) for at least 10 minutes. The confusion matrix is shown in Table 6.3. Based on the results, the app has a recall of 84.6%, a precision of 73.3%, and an accuracy of 81.8%.

Table 6.3: The left panel shows the confusion matrix for the discoverability of contacts: of 66 potential contacts, only 26 are close contacts and 40 are not a contact according to the NIPH definition. The right panel shows the confusion matrix for the risk identification of the contacts: of 26 real contacts, 20 are high risk and six are low risk.

In addition to discoverability, we estimated the ability of the technology to correctly assign the risk category of each contact. For simplicity and in light of the experiment design, we considered only two categories: low risk (all contacts within 2 metres for less than 25 minutes) and high risk (all contacts within 2 metres for more than 25 minutes). We again used the test protocol and the participants' logs to assign a risk category for each contact. Of 26 real contacts, 20 are expected to be high-risk contacts. The results are presented in Table 6.3.

# **6.5 Lessons Learned and conclusion**

In this chapter, we discuss digital tracing technologies for the identification and isolation of potentially close contacts of an infected individual. We show that the technology is feasible, but the main prerequisite for its validation and success is reasonable uptake in a population and close collaboration with epidemiologists. Issues related to defining an epidemiologically meaningful ranking of contacts remain open. We believe that a large validation trial with real-life scenarios is necessary to find the optimal risk score function. A big challenge in the validation of the digital tracing technology is that access to the collected data is very limited. In the case of Smittestopp, the technology was developed using a test data set but applied to real data, which are of completely different size, with much greater variation, leading to challenges related to computational efficiency. How to validate a digital tracing tool efficiently while complying with privacy and security regulations is not yet fully understood.

Our work shows that both GPS and BT data are important for obtaining a better understanding of how digital contact tracing works and illustrates their usefulness to epidemiologists. BT data allow proximity events to be identified, whereas GPS data provides contextualization for the contacts found. We believe that once the digital tracing technology is validated, GPS data can be excluded and the technology can be based only on BT data.

# **References**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 7 Data aggregation and anonymization for mathematical modeling and epidemiological studies**

Are Magnus Bruaset, Glenn Terje Lines and Joakim Sundnes

**Abstract** An important secondary purpose of the Smittestopp development was to provide aggregated data sets describing mobility and social interactions in Norway's population. The data were to be used to monitor the effect of government regulations and recommendations, provide input to advanced computational models to predict the pandemic's spread, and provide input to fundamental epidemiology research. In this chapter we describe the challenges and technical solutions of Smittestopp's data aggregation, as well as preliminary results from the time period when the app was active. We first give a detailed overview of the requirements, specifying the types of data to be collected and the level of spatial and temporal aggregation. We then proceed to describe the concepts for anonymization via 𝑘-anonymity and 𝜀-differential privacy (𝜀-DP ), and the technical solutions for collecting and aggregating data from the database. In particular, we present details of how GPS- and Bluetooth events were mapped to geographical regions and points of interest, and the solutions employed for efficient data retrieval and processing. The preliminary results demonstrate how the recorded GPS- and Bluetooth events match with expected temporal and spatial variations in mobility and social interactions, and indicate the usefulness of the aggregated data as a tool for pandemic monitoring and research. One of the main criticisms of Smittestopp concerns the centralized storage of individuals' movements, even if such data were used and presented only at an aggregated and anonymized level. In this chapter, we also outline a completely different approach, where the GPS data do not leave the user's phone but are, instead, pre-processed to a much

A. M. Bruaset

J. Sundnes

Department of High performance Computing , Simula Research Laboratory, e-mail<EMAIL_ADDRESS>
G. T. Lines Department of Computational Physiology, Simula Research Laboratory e-mail<EMAIL_ADDRESS>
Department of Computational Physiology, Simula Research Laboratory e-mail<EMAIL_ADDRESS>
higher level of privacy before being dispatched to a server-side data aggregation algorithm. This approach, which would make the app significantly less intrusive, is made possible by recent advances in determining close contacts from Bluetooth data, either by a revised Smittestopp algorithm or by means of the Google/Apple Exposure Notification framework.

# **7.1 Introduction**

The aim of this chapter is to explain the reasoning and the strategies behind the aggregation of Smittestopp's data in space and time, to provide high-level information about population dynamics and the spread of disease. For instance, this information could shed light on understanding how, when and where close contacts occur, and could be used to understand how imposed interventions, such as advice on social distancing and changes to public transportation patterns, are met by the public. The techniques described were under implementation and subject to preliminary tests when Smittestopp's development was put on hold. The implementation was therefore not completed or fully deployed in Smittestopp's production system. Based on the gathered experiences regarding scalability, we also present ideas for a distributed aggregation scheme. If implemented, this scheme would also provide improved protection of app users' privacy.

# **7.2 Data requirements and privacy**

As described earlier, the aggregated data sets from Smittestopp were meant to serve several purposes. First, the aggregated data from the app would provide continuous information on movements and interactions in the population during the pandemic, and would be used to monitor how various restrictions and government interventions impact social interactions and, in turn, the spread of the disease. Second, it would provide potentially valuable input to the predictive epidemiology models that inform political decisions and healthcare planning [7]. Data from the app would provide such information on a daily basis, unlike the three- to four-week delay between a change in social interactions and a visible change in COVID-19 hospital cases. This unique and detailed data would also be a resource for long-term epidemiology research, to improve prediction and insight in preparation for future pandemics. Finally, the aggregated data would be used to provide statistics and information to the public, to increase knowledge and awareness in the general population. To serve these different purposes, a requirement list was prepared by the Norwegian Institute of Public Health (NIPH), which specified the following four aggregated data sets with varying levels of detail.

**Data set 1: Individual-based data on the movement patterns and behaviour of app users.** The first data set was to be collected for anonymized individuals, with tables summarizing key numbers for each individual app user. The temporal resolution would be one day, while the spatial aggregation would be at the municipality level. The municipality of Oslo is treated as a special case, with aggregation for each district (*bydel*). A more detailed description of the geographical units used for aggregation is provided in Section 7.3, below. For each municipality and each day, a table is produced, with one row for each app user, and the following columns: travel on foot (total in minutes); travel by vehicle (total in minutes); minutes spent indoors, outdoors, and in particular locations, including grocery shops, kindergartens, schools, offices, hospitals, parks, and residences; and, finally, the total travel distance.

All individual data items would be extracted from the GPS data of the individual app users. Anonymity and privacy would be preserved by anonymizing all app users and ensuring that every table contains at least 𝑘 rows, as described in more detail below. For units with fewer than 𝑘 app users, the aggregation would be moved to the next level of spatial resolution, that is, from the municipality to the county level. With a typical 𝑘 value of 20, it is unlikely that this additional aggregation is needed, since all municipalities are expected to have far more than 20 app users.

**Data set 2: Location-based data set highlighting the exposure of individual locations to the population.** The main purpose of the second data set is to inform about potential disease transmission and guide government regulations and recommendations. Locations of interest are extracted from OpenStreetMap (OSM), and include hospitals, schools, shops, and bus/train stops, etc., and are stored in local files containing a unique ID, name, municipality, type of location, position, and geometry. The geographical data and algorithms to collect them are described in more detail below. The resulting local database of points of interest (POIs) is combined with the GPS data from Smittestopp to count the number of visitors to each location and the time they spend there. As for the first data set, privacy is guarded by lumping any location with fewer than 𝑘 visits together with nearby locations of the same type. The anonymity-preserving aggregation step is likely to be more relevant for this data set, than for Data set 1, since many locations can have fewer than 20 visitors per day.

**Data set 3: Bluetooth contacts quantifying the level of interaction in the population.** The Bluetooth contact data from Smittestopp is a unique data set for quantifying contacts that could potentially transmit disease. Based on Bluetooth pairings between phones with the Smittestopp app, we count all critical contacts, that is, contacts with an estimated duration of more than 15 minutes and a distance of less than 2 metres. The number of contacts is aggregated at the municipality and district levels, with a temporal resolution of one to several hours. To normalize the data to the number of app users, we also count the number of app users belonging to each geographical unit on a given day:

𝑃𝑀1, 𝑃𝑀2, . . . 𝑃𝑀355+15,

where 𝑃𝑀𝑖 is the number of app users on a given day in municipality 𝑖, for 𝑖 ≤ 355, or in the corresponding district in Oslo when 𝑖 = 356, . . . , 370. Similar numbers 𝑃𝐶1, 𝑃𝐶2, . . . 𝑃𝐶11 are recorded at the county level.

**Data set 4: summary statistics on the number of contacts and movement patterns.** The final data set is intended to provide summary statistics on contacts and movement patterns to the public. The data are aggregated from the three other data sets into statistical indicators suitable for public use.

#### **7.2.1 Privacy-preserving techniques**