1/ The NHSX Bluetooth works - it doesn't require the phone to be always on.
(incorrect assumptions by DP-3T critics claiming it does) and isn't blocked by Apple/Google - it won't kill your battery any more than using a BLE peripheral (e.g. airpods:) it is a bit of a hack. and may place limits on detecting some contacts.
2/ The "contact" proxy is pretty much based on what we did in fluphone a decade back so also fairly solid indication of proximity, but may need adaptation (as will all BLE based contact tracing apps whether centralised or decentralised). updates to the parameters in the algorithm can be computed in centralised approach somewhat more easily than decentralised (where you don't have the false -ve/+ve rate info).
3/ The rationale for centralising the data is several fold, which are nigh on impossible with decentralised apps:
a) You can update the algorithm in 2 based on measuring false positive/negative rates (there are other factors in deciding a contact is real too) - you can incorporate factors about the contactees in computing risk of infection, given the measured parameters of the encounter.
b) The narrative script people use for self-reporting can be updated based on ROC that that achieves
c) You can detect hotspots in infection near real time (e.g. superspreader events).
d) Epidemiologists potentially get to run models on pseudonymised social contact graph < this is where you might baulk but they aren't publishing the data - it will stay put, and models be updated from that - if hackers gain access to this data (how?), then there's a risk some people's graph could be partially re-identified. there's no geo-loc data in the phone or uploaded data so probably rather limited threat - if data is deleted (as claimed) in 30 days, then that threat is also time limited...
b) The narrative script people use for self-reporting can be updated based on ROC that that achieves
c) You can detect hotspots in infection near real time (e.g. superspreader events).
d) Epidemiologists potentially get to run models on pseudonymised social contact graph < this is where you might baulk but they aren't publishing the data - it will stay put, and models be updated from that - if hackers gain access to this data (how?), then there's a risk some people's graph could be partially re-identified. there's no geo-loc data in the phone or uploaded data so probably rather limited threat - if data is deleted (as claimed) in 30 days, then that threat is also time limited...
4/ There's a human-on-the-loop in the self-diagnosis phase (drawn from pool of people that deal with manual contact tracing) (and obviously also in actual test if that's triggering a notification) they can decide there's no problem, which can revoke the notification to contacts (rather hard to do in decentralised apps). This limits cascades from false positives.
5/ Contacts of contacts (etc) can also in principle be notified (useful in small, fast local outbreaks/clusters - a real problem in this virus) - again, difficult to do in decentralised model meaningfully
I'd welcome hearing how the decentralised app folks will tackle some of these useful
challenges.
In common to all app based contact tracing is the acceleration over manual tracing, which has a marked impact on reducing the R0 of the pandemic. Contrary to claims that you need 60% of the population to be running the app, actually any number of people will help reduce contact times so reduce R0 - so it starts to be useful at low levels of deployment (as already pointed out, the epidemiologists find it useful at low levels already too since it lets them see SEIR parameters and spot any changes).
There's a lot of misinformation out there (nothing new about that:)
Ref white paper on NHSX app design.
Ref Limits on reduction of R0
Ref white paper on NHSX app design.
Ref Limits on reduction of R0
No comments:
Post a Comment