Home/Services/Total solution to contact tracing app development
How we build, test and deploy for governments around the world
Total solution to contact tracing app development2020-08-31T09:42:26+01:00
A rapid solution to help combat the impact of Covid-19
Total Solution for Governments
Since The World Health Organisation declared the Covid-19 outbreak to be a Public Health Emergency of International Concern on 30th of January 2020, and subsequently recognised it as a pandemic on 11 March 2020, the search for tools to lessen its impact, save lives and return to the normalcy of everyday life has been a key focus of governments across the globe. Finding the right solution and being able to rapidly deliver are crucial for success.
Rapid Application Development
Over an initial period of four weeks, NearForm are able to apply their experience in accelerated software development to design and produce a multiplatform application that can support user symptom monitoring and contact tracing with other users over Bluetooth, using the Apple/Google exposure APIs.
There are two approaches to take when building a contact tracing application, broadly known as ‘centralised’ and ‘decentralised’. There are pros and cons to both approaches, and NearForm have experience with both. We recommend the decentralised approach, which leverages the Exposure Notification APIs from Apple and Google.
The main distinction is whether you identify and collect users’ interaction graphs (the devices they have had contact with) on a centralised server or do all matching and identification on the users’ mobile devices. The recently released Apple/Google APIs (Exposure Notification APIs) for contact tracing are based on a decentralised approach, and therefore this approach is heavily favoured in terms of privacy and ease of distribution.
Choosing to use the Google and Apple exposure APIs means you are taking a decentralised approach to Covid-19 tracking and need to consider the following usage policies:
The App must be made by or for the use of an official government public health authority and can only be used for the purpose of responding to Covid-19.
The App needs to ask consent of a user to actually employ the API before it can be used.
The App requires a user’s consent to share a positive test result before broadcasting any such info to the public health authority operating the app.
The App should only gather the minimum amount of info necessary for the purposes of exposure notification, and should use that only for the sake of a Covid-19 response. Using these apps for any kind of advertising or other non-Covid purpose is explicitly forbidden.
The App can’t access or seek permission to access a device’s Location Services, which provides specific geolocation data. Google and Apple note that apps already available from public health authorities that make use of location data will continue to be offered, but that no apps that make use of that info will also have access to the new Exposure Notification API.
The Exposure APIs make use of private internal APIs and functionality on Android and iOS phones that are not available to developers by default. This is to protect user privacy. Within the device’s OS, the Exposure APIs use Bluetooth to detect contact with other phones.
It is possible for developers to write their own Bluetooth code that will provide similar functionality, but there are technical limitations if the Exposure APIs are not used, especially on iOS where the application needs to be running in the foreground in order to function correctly.
Limitations include increased drain on battery, managing and calibrating distance detection, key lifecycle management, etc.
Decentralised approach: Privacy
The decentralised approach is designed for optimal user privacy. There are several good guides explaining how this works and the best practises involved.
The core tenet of the decentralised approach is that detection and identification happens at a device level and users’ anonymity is protected at all times.
This approach allows users to be notified when they have a had a close contact event with a person who has tested positive for Covid-19, but the identity of the person that tested positive is never revealed.
Where users are traveling across countries or states, it is possible to use the decentralised approach to facilitate the exchange of Keys associated with Covid-diagnosed users, between each country or state’s own key register.
This allows users’ contact tracing applications to gain a better awareness of contacts across different regions who have subsequently become identified as Covid-positive.
Google/Apple Exposure Notification APIs will not be made available.
Technical methods will need to be developed and implemented for determining contact between phones.
Contact events are broadcast to a secure server and stored centrally.
The server determines when phones are considered to have been in close contact.
The server sends notifications to users when a close contact has occurred.
The central server can determine the contact graph between app users.
Centralised approach: Considerations
A centralised approach is considered significantly weaker from a privacy perspective compared to decentralised. The primary reason for this is that the server data can be used to identify each individual user’s interaction graph.
Most countries started with a centralised approach, but an increasing number are switching to the decentralised approach. This is being driven by both privacy concerns and access to Google/Apple APIs.
Choosing to not implement the Exposure Notification APIs as a consequence of a centralised approach will also present limitations when publishing to the necessary app store.
What can the app do?
Keeps a secure, anonymous record of other users who have been within a predetermined contact zone (distance from user) for a period of time deemed to be a recordable period
Enables users who have tested positive for Covid-19 to choose to share the app’s contact data with health authorities
Provides updates on regional and national stats to users*
Enables daily self monitoring of symptoms, with supporting information*
Allows users to share the app with others, so that they too can become users*
* Optional features that can be added to the base solution
How is it done?
Complete discovery/design workshop
Assemble necessary teams (NearForm + Client)
Using NearForm’s accelerated approach to software development, get the foundations in place in the first few days
Deliver first demo during week 2
Continue to refine designs and targeted outcomes
Carry out development testing
On day 28, application on iOS and Android is ready to ship to customer testing team