Stage 3 – Future Development


There are many additional features that we’d like to add to Dot2Dot. The following is a list we’ve put together, in no particular order. If you have other ideas to make the system more powerful, please let us know.

Note – building out Dot2Dot will require funding beyond our current resources – please click here to see how you can help.

Additional Features

Team Management

Different disease outbreaks will have different levels of human resource attached. The coronavirus outbreak in Wuhan, for example, had 1800 teams of 5 people assigned to it.

The design of Dot2Dot now allows tasks to be assigned to different people. A more fully featured system will take this feature much further, allowing teams to be created and managed, and tasks organised between teams. Teams may need a geographical element to manage outbreaks in different areas – some cases in Birmingham, some in Manchester, for instance.

Vulnerable Location Management

It’s important to know which locations contain people that are vulnerable to a particular disease. We will therefore explore the creation of a national database of vulnerable locations. Some of the data is likely to be readily available, such as lists of schools, and we will correlate our data with the existing Google Places database and see how we can map the two.

User Self Service

We allow the system to send an email or SMS to a contact, which includes a link. This prompts the user to complete a self-service questionnaire.

Many users will be mobile only, so this must be fully tested with all mobiles. Some users will be unwilling or indeed not have a Google account – so we will add a manual login option. As some users may be low-tech, we must make this very easy to use, whilst still being secure. This will mean that the user interface is simplified to the version used by professionals.

A photo of the contact would also be desirable, so when visiting locations, we can ask if the interviewees remember seeing the person under investigation.

App Self Service

At present, we plan to design the whole system as a web application. But whilst a web app offers many advantages, there are situations where a mobile app may have more valuable benefits – particularly in supporting older mobile devices or using offline use. There is also general sentiment that apps are how things are done. If we find a good reason to add an app, this would be a significant scope increase.

Google Location Timeline

The system should allow users who have a Google account to give us permission to access their location timeline.

This is tricky because Google does not have an official interface for doing this. We would also like the user to login with their google account and therefore obtain secure permission to collect data. This requires that Google check the system and approve it at some point.

Open Banking API

The UK has a law which requires all banks to provide an interface (API) to bank data. I believe we can use this API to download bank statements on an individual and we can then use the bank statement to identify location visit history. South Korea is doing this now. This is a very powerful way to identify location history.

Cell Phone Data Import

The mobile system records the location of every phone and – in theory – this data can be extracted by the phone company. In an ideal future scenario, the phone companies could make this data available – with permission – on a per user basis.

Flexible Import / Data Cleanup

There are multiple stages in the location tracing process. If a contact tells us that he was at the GP surgery, we go to the surgery and ask who else was there at 10am. They give us some extract from the GP system which gives a list of people and details. We should then be able to import that list into the system as a set of candidate contacts.

We then need to try to find those candidate contacts. The data from the location may be incomplete or incoherent. It may have mobile or email, or neither. At this point we should be able to bulk-validate the phone numbers or emails. The team can then contact these new candidate contacts. They can do that manually, call or send an email shot/SMS, or even letter mailshot.


The system will effectively hold medical data on people, which will need GDPR security.

Multi Language Support

Even for the UK, we need to build full localisation support into the system so the self-service pages can appear in Hindi or any other language.

To do this we use an online translation service –

We should also plan to localise the main pages in the system, so that it can be used in other countries. But UK Grants may not want to pay for this.

Note: localisation can be done openly – we publish a link to the Transifex site and any person in the world can improve it.

Multi Country Support

The behaviour of the system will need to change to some extent in different countries. The formats of mobile phone numbers may be different.

A big issue is that we build web systems using modern development tools, but these only support modern browsers. In low-income countries, we may need to create a different version of the UI that supports older tech.


First, we should note that there is a huge difference between a local TB case in Coventry and the Asian state efforts on Corona. In Asia, authorities are gathering GPS information on all citizens. This is a completely different scale of operation from our design – it needs a vast database and thousands of servers. It’s also a completely different approach – you’re adding millions of people to the database who you don’t know and then seeing who came close to contacts.

In this case, we need to look at how the system might cope with a contact tracing team of maybe 100 or 1000 people. In general, scalability to 1000 users isn’t that tough – we can do this with larger servers mostly. It’s when you get to 10k users that you need to start doing a lot more engineering work to make sure it scales properly.

Country Wide Self Service

Another model of use is the full country-wide self-service model. Imagine UK Govt issues tests to everyone. Then everyone tested could voluntarily add their Google tracking data to the system, and other random strangers could then ask the system “did I bump into anyone infected”.