TL:DR, You can build a digital system to catch the highest risk contacts that can’t be traced by the contact tracers by putting up cheap beacons in pubs and restaurants and releasing apps that use officially supported iOS and Android bluetooth frameworks.
*We briefly considered building a system along the lines described below and funding it by selling beacons directly to business owners, but we don’t have the resources or connections to do the sales and marketing, and I’m about to launch a telepresence robot, so I’m writing this in case anyone else wants to build this, or if folks at NHSX fancy trying it out as a strand of the work they are doing.
The pub problem
On Saturday pubs and restaurants in England will reopen. The government will not have released an official contact tracing app, so the contacts of anyone testing positive for the virus, who had recently visited a pub or restaurant, will need to be manually traced. In order to make this possible government guidance for businesses reopening states:
“You should assist this service by keeping a temporary record of your customers and visitors for 21 days, in a way that is manageable for your business, and assist NHS Test and Trace with requests for that data if needed.”
Compliance with this guidance is going to be difficult for both business owners and patrons, meaning that it is likely that many contacts that take place in these contexts will not be able to be traced by the contact tracers.
The app trap
Much has been written about the abandonment of the contact tracing app that was trialled on the Isle of Wight and the switching of the governments focus over to the decentralised Bluetooth proximity contact notification infrastractureure created by Apple and Google.
Not being involved in the project, so looking from the outside with little information, it is hard to know for sure what happened but here is an attempt to summarise.
Essentially, the infrastructure provided by Apple and Google explicitly prevents governments being able to collect (centralise) any of the contact data themselves. All the information that allows a person’s contacts to be deduced is stored on their phone and all the government can do is trigger a notification that percolates out to the contacts of anyone who either tests positive, or self-reports symptoms (which of those is the trigger is up to the government).
As the infrastructure is provided everywhere, you can see why Apple and Google were reticent to give governments a new way to collect contact information on their citizens. However you can also recognise why the UK government would see access to that information as extremely helpful in fighting the pandemic. In these circumstances it is easy to understand why NHSX would have proceeded with the Isle of Wight app in the hope that they would either find a work around to get it to work, or get Apple to make some concessions and help them release an app that does some things with Bluetooth that regular app developers aren’t allowed to do.
The work around didn’t work, Apple didn’t cooperate so the Apple + Google infrastructure is the only option now, right?
I don’t think so.
To understand why let’s step back and look at why we need a contact tracing app.
Think about transmission
There is little about this crisis we know for sure. Proper ‘medical grade’ evidence is very difficult to collect in the circumstances, so most decisions are based on conjecture from observation. Here’s some of that:
It seems that transmission of the virus is relatively uncommon outdoors. We’re now three weeks form the major outdoor anti-racism protests (where the 2m rule was often broken) and we haven’t seen an uptick in cases or hospital admissions in any of the cities where large protests happened.
It also seems that indoor transmission is very common. We don’t really know what kind of distancing was in place in Weston General Hospital or Leicester food and garment factories (if any) but it doesn’t seem to have prevented the spread of the virus. The super spreader events in churches at the start of the epidemic suggests that in the right circumstances the virus can spread over much greater distances than 2m indoors.
In these circumstances, commentators suggesting that the inability of a system using Bluetooth proximity to tell reliably if you were 1, 2 or 3 m away from another contact, seem rather to be missing the point.
There’s a much more important lesson here though.
If we are not worried about tracing someone you walked past in the street, sat near in a park, on a beach or at a bus stop (because you were outside) or at home or work (because the contact tracers should catch them) but are worried about someone you were in the same pub, restaurant, tube carriage or bus as (no matter how close you were)…
…then Apple and Google already give all developers the technology to do this and set no limitations on how it is used beyond establishing user consent!
In the first half of the last decade Apple and Google were keen to be able to connect app experiences to specific indoor locations (probably primarily for retail and entertainment) so both companies created frameworks for determining indoor location using networks of little pieces of electronic hardware called ‘beacons’. Their systems (iBeacon and Eddystone respectively) ended up being fairly interoperable so you can use the same network of beacons to work with apps on both platforms.
These beacons are why when an Android app wants to connect to a bluetooth device (like our Smartibot) Android makes the user grant the app location access (even though all the Smartibot app knows is that you’re near a Smartibot).
Despite all the software frameworks and bits of hardware beacons (and the rich digitally augmented retail and entertainment experiences they were supposed to enable) never really took off in a big way.
Beacons and the pub problem
Being in proximity of a beacon can trigger an installed app to activate (even if it’s in the background or the phone is asleep in your pocket) and then, once the app is running, it is up to the developer what it does.
An app (with the appropriate consents from its user) could upload the user’s phone number and the ID of the beacon they are close to every five minutes or so, for as long as they were near the beacon, to a central server. Doing this would allow the server to keep track of everyone who is in the same section of a pub at a particular time. This would be digitally replicating the information the pub is already supposed to collect (according to the guidance) with much better reliability, less scope for abuse by staff, and higher resolution.
Here’s an illustration of how such a system could work:
Because these data would only be centrally collected when the individuals are in public places they have volunteered to go to (and have a stake in keeping open), it is possible that a centralised system working on this basis would provoke fewer privacy concerns. Installation of the app could be totally voluntary businesses could ask and patrons to show they have the app installed to exempt them needing to leave their phone numbers. Alternatively business owners could choose to make use of the app a condition of entry and then wouldn’t have to worry about collecting and storing phone numbers themselves.
If the app proved to work well and became widely installed it would then make sense to install beacons in other public indoor spaces like public transport.
Will it work?
The beacons themselves are manufactured by numerous different companies, are available at relatively low prices (between £5 and £20 each) and can run for several months on a small battery. Each one can cover a small room or a specific area of a larger premises. They vary in size from a small stack of coins to a matchbox and can easily be mounted almost anywhere.
We’ve used beacon technology in Sight Line, Responsive Street Furniture and the ant-sheep rustling system we developed on the Big Life Fix. Lots of other people have done interesting things with it and most people seem to have been able to release their apps without issue.
Obviously, even though a system can be built that will work with the core frameworks Apple and Google give to developers to use, they could still block the release of such an app, but that seems unlikely as they would be deliberately choosing to depart from their usual way of operating (the opposite of the situation it seems the government tried to put Apple in with the Isle of Wight app).
The way iOS and Android manage apps that are running in the background is a bit murky (maybe one of the reasons NHSX thought it was worth seeing what they could get to work) and it seems that both Apple and Google have imposed stricter limits on how long apps can be activated by beacons when running in the background, in the time since they introduced iBeacon and Eddystone. We experience these issues with Sight Line in that we are unable to predict how long after the app has last been open it will continue to get woken up, in order to ping the server and return the description of the road works. We recommend users launch the app when they start a journey, and then again after an hour if the journey is longer than that, and we haven’t seen any missed beacons when testing with those assumptions.
As long as users are showing the app open when they enter a pub or restaurant, then we can be confident that the server will get at least two or three pings from their phone with the beacon ID (as a worse case scenario) and more likely around 10 to 12 (a record of the first hour or so inside), but they will probably stop whilst some people are still in a pub or restaurant. It is also likely that time after entering at which they stop will be different for different phones.
Even in the worst case scenario (only getting data for the first 10 to 20 minutes when someone is in a location) the system would perform as well or better than the best case scenario of the pub being responsible for recording visitors phone numbers.
Additionally by looking at the patterns of records showing up on the server and comparing these to assumed, or even better observed behaviour of a sample of pub goers, the parameters for what the system views as an overlap can be tweaked, which ought to help compensate for incomplete proximity records. (Basically the system should be able to infer from arrival times whether two people who had been exposed to the same beacon were likely to have overlapped even if it hadn’t received overlapping records).
To allow businesses to check that patrons have a fully working app it could be designed so that when opened it only displays the confirmation screen when bluetooth is switched on, it has permissions to access bluetooth location, it has an mobile phone number associated with it that has been authenticated over SMS, the phone has an internet connection and data permission.
This still might not work, but it’s very easy to build and the beacons are very cheap and easy to get hold of so I think it’s definitely worth someone trying it.