Government Confusion

At the height of lockdown way back in April, we were promised a contact tracing smartphone app that would help us fight against coronavirus and emerge from lockdown safely. Now 5 months (and a growing second wave) later, we’re at last being delivered an app. During the interim, we’ve heard on the news about some flip-flopping between a ‘centralised’ and ‘decentralised’ system, one of which might be better for privacy, and one for epidemiological insights. There was total silence on when it might be publicly available; while the (implied unsafe) emergence steadily continued, nonetheless. Finally, the day that this will be published in print, the app will see its first light. So, what gives? Is the long-awaited app going to actually save any lives, or is it too late for that?

Manual Contact Tracing

We already have models of contact tracing systems used for diseases such as HIV, TB and some STIs. This involves identifying an index case (someone with the disease), and interviewing them to learn about their recent movements and people they may have come into contact with. For example with STIs, this involves recent sexual partners. For a respiratory disease like COVID-19, this involves people who have been exposed to places the index case has spent prolonged time in, such as those at home, in restaurants and shops, and on public transport. Once identified, the contacts may be diagnosed, given prophylaxis, or asked to self-isolate, depending on what is appropriate for the disease. COVID-19’s extremely high rate of pre-/asymptomatic transmission makes efficient contact tracing vital.

The Need for Instant Contact Tracing

A paper published by the Oxford Big Data Institute in March showed that for a disease like COVID-19 with high pre-/asymptomatic transmission, a manual contact tracing system is too slow to shrink an epidemic without lockdown measures.

Since NHS England launched its Test & Trace (T&T) service on 28th May (already a costly delay: almost ¾ of the total infections to date had already occurred by then), less than 40% of test results were received in under 24h. In order for this to be sufficient, almost ¾ of the contacts would need to be successfully quarantined within 24h of the index case’s symptoms. The published data does not show how long it took to refer cases to T&T, but barely half of “non-complex” contacts were asked to self-isolate within 24h of this referral.

Many of these delays in reaching index cases: referring them to T&T, identifying close contacts, and asking them to self-isolate, are totally avoidable with the use of a smartphone app, where contact tracing can be done instantly upon receiving a positive test result.  

Not to mention, an automated app also allows the tracing of those who cannot be traced with traditional interviewing (on public transport etc). What’s more, it has the potential to do this with even more privacy than the traditional interviewing method.

How smartphone app performs instant contact tracing

The basic premise of a contact tracing app is outlined in the same Oxford Big Data paper from March, and I have used their diagram in Fig 1 to illustrate:

o   An app downloaded to several individuals’ phones monitors their proximity to each other using Bluetooth Low Energy (BLE), a technology available on about 90% of mobile phones in the UK.

o   A unique, pseudo-randomly (as far as any non-mathematicians are concerned, that’s the same as random) generated key is generated by person A’s device at regular intervals (say, every 15 minutes), and broadcast to nearby devices with the same app installed, who receive nothing but the ‘gibberish’ key, and the duration for which they were in close proximity with the device broadcasting it.

o   Person A later develops symptoms, and orders a home test through the app. Later that day they test positive and notify their app. This instantly sends a signal to other devices, and those devices which were in close proximity with the infected individual for a significant length of time will notify their users with a high or medium risk score, with instructions on what to do next. This occurs by one of two methods: either a 'centralised’ or ‘decentralised’ system.

o   In both systems, all of the unique keys that Person A has been broadcasting for the last few days will be flagged, and the BLE signal strength (a proxy for proximity) and the duration of this signal are used to calculate a risk score for other app users.

o   In a centralised system, this risk score is calculated on a central server, meaning that other potentially identifiable data such as location is capable of being stored and decrypted.

o   Whereas in a decentralised system, this all happens locally at the device level; each device regularly checks to see if they have come into contact with the flagged keys. The “key” point here is: nobody has any way of identifying who has met whom (not even the local device), and all the central server has access to are the ‘gibberish’ keys. There is, by design, nothing identifiable about them.

Where the Government’s Smartphone App Strategy Went Wrong

On 27th April the UK government rejected a collaborative, decentralised, solution by Apple and Google (heavily influenced by an international open source protocol, DP3T), in favour of a native centralised model. Within a week, a beta version of this app was running and ready to be tested in the Isle of Wight (IoW). Over a month later, they announced a U-Turn deciding to instead test a new app incorporating the Apple/Google framework, only just beginning testing in IoW and Newham on about 28th August. Finally, on the 11th September, a full-scale app was announced, launching in England and Wales on 24th September.

The original IoW app saw some success, reducing the reproduction rate R from about 1 to 0.25 in mid-May (despite users being unable to input a positive test result). This rose again to 0.75 in June though, which could have been because only 4% of iOS users were actually detectable by the app. This is because iOS does not allow 3rd party apps to use its BLE in the background without the support of Apple’s framework.

In addition, there are concerns raised by an international community of developers about “mission creep” of centralised apps. By storing some location data centrally, the government claims that epidemiological insights can be gained into viral hotspots. As the DP3T White Paper notes, though, now is not the time to conflate the aim of a safe return to ‘normal’ life with these insights, which cannot be well obtained from a technology which uses Bluetooth signal strength as a proxy for viral transmission anyway. Storing more data than is needed allows the possibility of government surveillance, which undoubtedly hampers trust and probably contributed to low uptake in countries like Singapore and Norway.

After much digging, it appears that after aiming on the 18th June to ‘bring together work’ done by Apple/Google, the government finally confirmed that the new app will in fact be using this decentralised framework, with “data remaining only on your phone”.

During the several months of app testing, the government remained concerned that the Bluetooth technology in the Apple/Google API does not allow for quite as accurate proximity tracing as the version developed in May (a distance of 4m might produce a stronger signal than 3m, for example), and for this reason they continued to trial whether this can be improved.

My question is: are not a few extra false positive contacts who have to self-isolate a tiny price to pay in comparison to the thousands of lives that could have been saved with a working app since early May; and as is now apparent, the prevention of a viral resurgence? Or the ability of the public to see their loved ones safely without worrying about making each other unwell? Or the recovery of the economy with all sectors able to carry out close-to-normal functions?

The height of the pandemic is not the time to be continuing trials or pursuing a centralised model, which is also unsuitable for a time when international travel has resumed; cross-border identity keys will be incompatible with a native app.

The government’s delay in delivering this app, an invaluable tool within easy reach since April, demonstrates a negligence of good sense. Their obtuseness in informing the public about their decision making only serves to further erode trust and make people less likely to use the app even now that it has finally surfaced nationally.

Yes, there are certainly political concerns with allowing a corporate monopoly (or, duopoly of Apple/Google in this case) to rule which apps get to be part of a public health effort; but right now, the government’s number one concern is ensuring the safety of the public and the safe recovery of the economy – corporate policy can wait.

In the past few weeks we have seen the viral incidence rise to levels similar to early April – the first-hand effects of our unsafe emergence from lockdown. With the government threatening another national lockdown, slathering on the rhetoric in blaming the public’s poor compliance with (somewhat ambiguous) rules for social contact, we hear no responsibility taken for a totally inadequate test and trace system. It is just one of many setbacks that has contributed to the UK suffering the most deaths from COVID-19 of any country in Europe.

For more information on the NHS Test and Trace system, including testing statistics, and app details, follow these links:

https://coronavirus.data.gov.uk/

https://www.covid19.nhs.uk/ (App details)

https://www.gov.uk/government/collections/nhs-test-and-trace-statistics-england-weekly-reports