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 CovidTracer app was on August 17 – 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 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?
There are a number of possible technical explanations, including that the settings for Bluetooth Tracing (its current setting to record a contact of 15 minutes or more within two metres has been outdated by the more infectious Delta).
But based on information so far, it also seems that a very human factor is also in play: Overwhelmed contact tracers simply haven’t been walking people through the process of uploading Bluetooth Tracing data from their phone to the Ministry of Health servers.
It is frustrating to see the data potentially isn’t being used to support contact tracing.
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 Google/AppleExposure 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 Bluetooth Tracing enabled (within a couple of metres, for several minutes), 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 Bluetooth Tracing 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).
Prior to the current lockdown, there were approximately 1.5 million devices participating in the automated Bluetooth Tracing each day, corresponding to about 35-40% per cent of the adult population (manual posting scanning was around the 500,000 mark per day; it is now round 750,000 per day – with the total including multiple poster scans by one user).
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 listedExposure Notification check in the system settings was on August 17 or 18.
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 Bluetooth Tracing 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 Google/Apple Exposure Notification 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.
Demographics and digital exclusion
Another possible explanation for the lack of Bluetooth notifications is based on the actual people involved in the current outbreak.
At the time of writing, Ministry of Health statistics showed that 60 per cent of the active cases were under the age of 30, and 70 per centof the active cases were Pacific Peoples.
These two demographic groups are known to be less likely to be participating in Bluetooth Tracing.
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 per cent 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 lazy 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 Bluetooth Tracing for us to expect that at least one case (beyond Case A) would have had keys available to upload.
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 Bluetooth Tracing.
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 Bluetooth approach, because you can be in the same venue without necessarily being close enough to trigger the Bluetooth 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 Bluetooth thresholds currently in place, meaning that fleeting encounters outside of venues are unlikely to be captured by Bluettooth 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 Bluetooth keys is not seen as 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 Bluetooth 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 August 29 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 Bluetooth Tracing.
Bloomfield 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 Bluetooth Tracing on, and why people should use it.
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.
Dr Andrew Chen is a research fellow with Koi Tū – the University of Auckland’s Centre for Informed Futures
Source: Read Full Article