What’s wrong with Bluetooth Tracing?

by Dr Andrew Chen
Overlay of images superimposed onto an aerial view of a city at night

This article was first published on Mashed Calculus and Differential Potatoes on 29 August 2021 and has also been republished on NZ Herald and The Spinoff.

Dr Andrew Chen

We know that contact tracing is a critical part of our ability to contain any outbreak of an infectious disease. Bluetooth Tracing, offered through the NZ COVID Tracer app, is part of that process in New Zealand. Or at least, it should be. Technical folks over the last week have noticed that the most recent Bluetooth data made available to the NZ COVID Tracer app was on 17 August – the day we found out about Case A with the delta variant and the country went into lockdown. No Bluetooth keys have been uploaded to the central server since then, despite there being 512 positive cases at the time of writing. This therefore means that there have been very, very few Bluetooth-based exposure alerts sent to users. So why is there no Bluetooth Tracing data when there have been many Locations of Interest and related alerts sent out for QR code-based locations?

The Basics of Bluetooth Tracing
Before we go too far, let’s recap on what Bluetooth Tracing (BT) is supposed to do. NZ’s Bluetooth system is built on the Apple/Google Exposure Notification Framework (often referred to as GAEN or ENF). Once it’s enabled on your phone, you go about your life as usual. As you wander around, your phone broadcasts an ID number (also known as a “key”). When your phone is physically close to another phone with BT enabled (within a couple of metres), the two phones exchange keys, and record them in a diary/log. If one of the two phone owners tests positive for COVID-19, they are then asked by public health officials to (voluntarily) upload the keys on their device to a central Ministry of Health (MOH) server. Phones with BT enabled are checking that server on a regular basis and, if there are new keys, will download them and check them against their log. If there is a match, then the user is notified about the match, and prompted to isolate and get a test. Importantly, MOH does not know the identity of people who have matched, so this system relies on people doing the right thing when notified. This is pretty similar to the QR code/venue-based system that runs in parallel, with the key difference that contact tracers can still send out an exposure notification if the case wasn’t using the app, by looking up the location in the system and finding the corresponding Global Location Number (GLN).

That’s it in a nutshell – there are other technical elements like rotating keys to help protect privacy and filtering to deal with noisy signals, but they are less relevant for the current problem. Prior to the current lockdown, there were approximately 1.5 million devices participating in BT each day, corresponding to about 35-40% of the adult population. But MOH told Newshub that “fewer than ten” Bluetooth-based alerts had been sent out. And a number of people have verified on their device that the last listed (GAEN-based) Exposure Notification check in the system settings was on the 17th or 18th of August. Given the rate of uptake across the population, it seems implausible that across 500+ cases there would have been no Bluetooth keys to upload to the MOH server, as that would imply that none of the 500+ individuals had BT turned on.

Close Contact Thresholds
One of the possible explanations that has been mooted is around the thresholds used for determining that one Bluetooth device has been close enough for long enough to another Bluetooth device to be considered a close contact with a reasonable risk of virus transmission. When the devices exchange keys, they also note how strong the signal is (as a proxy for distance) and the length of time they see the signal for. The GAEN protocol essentially multiplies these together to create a score, and there is a threshold that says if the score is above that value, then the two devices should be considered close contacts. While this is not an exact measure (especially due to the high variability of the signal strength), it can roughly translate to a close contact definition like “within 2m for 15 minutes”.

The thresholds can be inspected by checking the open-sourced code used in the NZ COVID Tracer app. The code probably doesn’t mean much to most people, but essentially the NZ thresholds are currently based on the Linux Foundation Public Health (LFPH) thresholds, mostly because Ireland uses the LFPH thresholds now, and our Bluetooth implementation is based on their code. However, a close contact definition of “2m for 15 minutes” seems incongruous with the data on how the delta variant of COVID-19 spreads. The increased transmissibility, and the documented cases of people getting infected simply by walking past an infectious person, indicate that the thresholds need to be much lower than they were in the past. This is the same reason why MOH has broadened its contact definitions to capture more people, basically treating anyone who was in a venue at the same time as an active case to be a close contact.

This has two implications on the current outbreak and the lack of Bluetooth keys being reported. Firstly, if the thresholds were too high, then the Bluetooth system could miss a lot of contacts that should be considered contacts. Secondly, if the public health officials know this, then they might have less confidence in the Bluetooth system.

However, the first justification does not actually explain what we are observing with the Bluetooth keys. This is because the central server should contain the keys of infected persons, which does not depend on any matching operation or any thresholds. The matching is done on the device once it has pulled the relevant keys from the server. So even if the thresholds are too high, we would still expect to see cases uploading their keys to the central server and to see devices performing the checks. To my understanding, MOH are investigating lowering the thresholds, but they need to do this carefully as lowering it too much could lead to many false positive matches (people being told they’re close contacts when they’re not). The second justification may have more merit, and we’ll come back to why it matters later.

Case Demographics and Digital Exclusion
Another possible explanation for the lack of BT notifications is based on the actual people involved in the current outbreak. At the time of writing, Ministry of Health statistics showed that 60% of the active cases were under the age of 30, and 70% of the active cases were Pacific Peoples. These two demographic groups are known to be less likely to be participating in BT. The reasons for this are less clear, and before I offer some of the justifications that have been discussed amongst experts, I’d note that the data to support these is incomplete at best.

The very young (11% of the cases are under 10) are not likely to have a smartphone. Young people generally appear to be more reluctant to participate in digital contact tracing, allegedly because they perceive the risk and consequence of getting COVID-19 to be low. Pacific Peoples are more likely to be digitally excluded so they may not have a smartphone. People in both groups may be more likely to have an older smartphone that is not compatible with BT, or they may have older batteries and are worried that BT may drain the battery life.

All of the above reasons come with strong caveats, because I don’t want readers to run off and say “aha, the lack of Bluetooth keys is easily explained by [insert unhelpful stereotype here]”. It’s just not that simple, and to make matters worse, I don’t think this is a good explanation because it doesn’t account for the rest of the active cases also not having their Bluetooth keys on the MOH server. There was a high enough proportion of people participating in BT for us to expect that at least one case (beyond Case A) would have had keys available to upload.

Household Transmission
Another mooted explanation is that after the initial rush of cases that were likely infected in the community, the majority of the cases have been within households. After all, if delta is infectious enough to be transmitted in open air after walking past an active case, then it’s pretty likely that living in the same house as an infectious person will lead to infection. Where a contact tracer is talking to a household contact, it seems plausible that they may not ask for the Bluetooth keys to be uploaded, because (a) the chain of transmission has already been established, and (b) if they know that the new case has been isolating at home for a couple of days, the risk of transmission outside of the home is relatively low. Again, this does not explain what’s happening for all 500+ cases, but it is logical that when the contact tracer is trying to move quickly and collect the most useful and relevant information, that they might focus on other information sources.

Capacity Constraints and Processes
This leads us to one of the more compelling explanations – that contact tracers are simply prioritising other tools ahead of BT. Digital contact tracing in New Zealand is not an automated process that runs by itself. It augments the human-led contact tracing process by providing information and processes that sit on top of the manual approach. So, for an active case’s Bluetooth keys to be uploaded to the MOH servers, a contact tracer has to (a) establish that the active case had BT on across the infectious period, (b) decide that sharing those keys would be useful to support contact tracing efforts, and (c) provide the active case with a code to type into their NZ COVID Tracer app to release the keys to the server. Then the active case has to (voluntarily) enter the code.

There are a couple of reasons that, when combined together, may explain why this process might not happen. With the location or venue-based approach (which is based on QR code data, manual entries, and interviews with the case), it is likely that most of the contacts will already be found. The venue-based approach casts a much wider net than the BT approach, because you can be in the same venue without necessarily being close enough to trigger the BT system. Imagine that an active case is wandering around a supermarket – there might be very few people who are within a few metres for more than a few minutes, but there would be a lot more people who were anywhere in the supermarket at the same time as the case.

This argument is further strengthened by the high BT thresholds currently in place, meaning that fleeting encounters outside of venues are unlikely to be captured by BT anyway. With the number of cases currently in the community, contact tracers are at full capacity (even using up all the extra surge capacity) just trying to call contacts and provide them with instructions. So, time-constrained contact tracers may decide that the extra time required to walk a case through the process of uploading BT keys is not worth it. After many discussions and thinking through all the possible explanations, it’s probably not a complicated technical reason that is leading to the absence of BT data being contributed to the contact tracing system. It’s probably a much simpler explanation: the contact tracers aren’t asking for the data.

Transparency and Clarity
Questions about the lack of Bluetooth keys have been put to MOH over the course of the last week, by myself and other members of the public, as well as by a number of journalists who have also asked me for comment. MOH has not provided a clear, defendable answer until the 1pm press conference on 29/08, when in response to a journalist question, Bloomfield pointed to the contact tracers not asking for Bluetooth information at the first case interview due to the number of cases, and also the demographic groups of the cases being less likely to use BT. He also claimed that “we have been using it where people have said they have Bluetooth turned on, and we’ve used that to send out messages,” but we know based on the MOH server that this has actually only happened for Case A. He added “we have given [the contact tracers] a nudge around that.”

I thought a lot about whether to write this article or not, because anything that might cause people to stop using NZ COVID Tracer is counterproductive in the age of delta. But MOH has had long enough to respond to queries and be upfront with the public about why Bluetooth isn’t being used. New Zealanders have been asked time and time again to “turn Bluetooth on”, and I have spent a lot of time trying to explain how it works, how to turn BT on, and why people should use it. It is frustrating to see the data potentially isn’t being used to support contact tracing. If, as I suspect, the explanation is that contact tracers simply aren’t asking for the information, then we need a policy decision as to whether this system is actually useful for contact tracing. If it is useful, then the contact tracing processes need to be amended to ensure that they are asking for BT information. If it is not useful, then we can have a different debate. Either way, this is about making sure we not only have the right tools to help us fight the virus, but that we are using them effectively.

To be clear, people should still use NZ COVID Tracer if they can, especially to scan QR codes and add manual entries. There is still a lot of potential for BT to be useful, but we need to know that it is actually being used.

PS: The BT data on the device deletes itself after 14 days (compared to 60 days for the QR code data), so MOH is limited in its ability to go back and start using it retrospectively. At this point, we’ve already lost the data related to cases during their infectious periods at the beginning of the outbreak (pre-lockdown).

Our themes