The boring side of tech, transparency and contact tracing

28 April 2020

The tech-twitter conversation about contact tracing apps has focused on privacy and decentralisation. Regardless of the form it takes in the UK — and it looks like for now it will be a centralised system, (hopefully with some very strong legal constraints) — there are eight things* that the NHS should do to make sure the process enables a healthy and open public debate.

  1. Publish a list of all the names of the different bits of technology (app, admin system, design system, etc) used to deliver the service along with the current version number and the date and time it was updated. This should be kept up to date each time a new version is deployed.

  2. In line with the Government Service Standard, wherever possible, the source code and database schema for each of these should be published in the open. Given the NHS will be likely using modern development practices and deploying updates regularly, publishing as a one-off will not be sufficient. Source code should be published as soon practically possible after each release. Commercial ownership of bespoke or customised code developed for the service should be not a valid reason for not publishing.

  3. Any data sharing agreements used to deliver the service should be published in one place on either GOV.UK or NHS.UK.

  4. Elements with a user interface (e.g. public-facing apps and admin systems) should display the current version number. The NHS App already does this). For each version, the NHS maintain an archive of the user interface changes. This is important because mall design choices can have big impacts on how people access and understand services. If the tinkering with the branding/advertising campaign is anything to go by, the temptation to tweak will be strong (and there may also be legitimate uses of A/B testing). As such, it is important that a record is maintained of how people are experiencing the service.

  5. The design should clearly explain when notifications have been triggered automatically, vs when it has been done by a person. It doesn’t need any wizzy design; words should do it. (Maybe something could be fast-tracked through the GOV.UK/NHS design system?)

  6. Given this will be a real-time system, it should regularly publish data about how the service is being used. This should include the number of users, but also information that will help the public understand if it is advantaging or disadvantaging particular groups. (This is a knotty problem and runs counter to some of the debate around privacy — sometimes you need to collect more data to know if you’ve built something discriminatory).

  7. Relevant civil society organisations should have access to the categories and absolute numbers of issues that users are reporting.

  8. There should be a clear, well-designed process for users and those involved in delivering the service to understand their rights and raise or escalate concerns about how data is being used. This should be part of the design of the service, not an add-on.

* This is not an exhaustive list. I’m hoping people will have their own.