I am a software engineer and a part of the team in Mobi Lab that works on the Estonian COVID-19 contact notification application HOIA. I am also involved in the process of supporting and improving the application post-launch. This article is about the human element of the system, and how what you plan is often not the same as what your users assume, expect, or want.
The Estonian HOIA application and contact notification system was created as part of a combined effort by a consortium of volunteering companies, and delivered to Estonia free of charge.
There were about 30 experts working on the project, most of them from different companies and with very different backgrounds.
The Estonian Ministry of Social Affairs directed the overall effort together with the Welfare Information Systems’ Centre (TEHIK) and the Estonian Health Board specialists. The consortium united 12 companies that are experts in design, software development, and security:
Contact tracing is a time-proven tactic used to limit the spread of infectious diseases, and dates back to the 16th century. The purpose of contact tracing is to find all the close contacts of an infected person as fast as possible to notify and isolate them from the general population. The faster this can be done, the less chance there is that these contacts themselves spread the disease to other people. A close contact in terms of COVID-19 is defined as being within 2 meters for 15 minutes or longer.
Every day the Estonian Health Board gets notified about people who have tested positively for COVID-19. The Health Board officials call all these patients, advise them about the next steps and enquire about their last contacts and movements. This is done to find out any close contacts they may have had to call those and notify them about the risk of infection.
While this process works very well it has a few downsides. Not all people can recall everyone they met and interacted. Often people only remember those cases which were somehow significant for them. And tend to not remember contacts in public spaces or with people whom they do not know personally. For example taxi drivers, other passengers on a bus, people sitting next to them in a cinema hall, etc.
This is where the digital contact notification shines. HOIA application will work the same way regardless if the two people know each other or not. If the application has recorded a close contact with someone who is now marked as sick then an anonymous notification is shown. Allowing them to make sure that even if the infected person does not remember the contact, the notification is delivered nevertheless.
While France and a few other countries felt doing everything by themselves was the only way to go, Estonia didn’t want to abide by NIH and reinvent the wheel. The HOIA application was not built from scratch.
Rather it was based on an already proven contact notification solution called “Decentralized Privacy-Preserving Proximity Tracing” (DP-3T, https://github.com/DP-3T/), built by the Swiss EPFL Swiss EPFL university.
DP-3T, in turn, utilized Google and Apple provided Exposure Notification (GAEN) framework, which took care of the underlying platform support and the complexity of dealing with different devices.
All the technical aspects and minutiae of the solution are fully described at https://koodivaramu.eesti.ee/tehik/hoia, together with all of the source code.
As varied and experienced as our team was there were still some aspects of the project which puzzled us. While there were interesting design and technical challenges, with thorough planning and analysis we overcame them. But the human element of the solution is something that still surprises us, even now.
We predicted that one of the hardest parts of the whole project would be to deliver a system which is at the same time secure, privacy-preserving, transparent, and easy to use. And we turned out to be correct.
To explain the application to the users and to answer all the questions they may have, we created the https://hoia.me website, and added simple graphics and FAQ about how the application works. This worked for many, but not for everybody.
It turns out that we started from an incorrect position. We assumed that understanding the nature of contact notifications would not be a problem. The process has existed for hundreds of years. It is nothing new.
The only goal of the application is to notify the contacts that may be infected, but are missed by the conventional process. It is important to do it as fast as possible so they can be aware of the risk and isolate as fast as possible when they start feeling the symptoms. This only works if the application is used by healthy people and not only installed after a person is already sick.
There was another subset of users we were worried about. They understood the use case of the HOIA application well. They were also theoretically ready to use it. But still ended up not using it. They didn’t understand how the application behaves after it is installed. And this created anxiety and fear. How the notifications would be delivered? How many of them would there be? Maybe it would notify me every day? Maybe every hour? When and how do I know if I can trust the application? How to use it “the right way”? Can I still remove it after I decide that I do not want to use it?
In order to alleviate these concerns, we are improving the HOIA website with some practical screenshots and videos about how the application works, how the contact notifications are delivered, how to successfully mark oneself infected, and how to reset the application if desired. We expect this to allow the users to have a dry run of using the application and then to build up to using the actual application.
Our goal was to create a simple and easy UX for the app to hide all the complicated processes required to ensure security and privacy. Thanks to the thorough security analysis by Cybernetica and excellent design by Iglu we feel we have gotten very close. But we still have some ways to improve.
One problem we are encountering comes from the Estonian infection confirmation process, which consists of two steps. One step is familiar to most Estonians, the other is unfamiliar and can be confusing.
The first step is to log in to the Estonian Patient's portal (Patsiendiportaal) to give permission for the HOIA system to verify the user’s diagnosis. As a lot of people are already familiar with the portal then this creates no issues for most of our users.
The second step, however, is more problematic. After the COVID-19 diagnosis has been confirmed and the backend has agreed to allow the user to mark themselves infected, the user also needs to allow the application to upload the anonymous device keys from their device to the backend. This step is important for sending out the notifications. To authorize this, Google and Apple’s GAEN API shows the user a permissions dialog and asks them to press a button called “Share”.
This dialog contains a different style of messaging from the rest of the application and is unfamiliar to most of the users. Worse yet, on iOS it is always in English. A subset of users do not connect the purpose of the dialog with the overall process (Sharing is something you do on Facebook, right?). And they will not press “Share”. And will not send out any notifications to their close contacts.
Our fix here is twofold. We are in talks with Google and Apple to make the content of the dialog easier to understand for users. We also added an additional screen to the application which explains the 2nd step of the process and the nature of the upcoming dialogue. With these changes, we hope to make the unfamiliar more familiar and not lose any users in the process.
For iOS, this is mostly an easy task. Apple controls all aspects of their devices. And is very good at not leaving users behind on software updates. Platform and GAEN SDK issues are a few and far between.
With Android, it is a different story. As there are a lot of different manufacturers and devices with different software versions and configurations, we feared trouble. And trouble did come, just not from the expected place.
As Google used the Google Play Services library to deploy the GAEN API and keep it up to date on all the devices then the API was available and operational on all of the compatible devices.
But then issues started to emerge with some users not being able to run the GAEN API (and thus the HOIA application) in the background.
It turned out that there are a few problematic phone manufacturers who do not follow Google’s official guidelines on battery optimization. They add their own optimization, which is enabled by default and hidden from the user. This optimization often disables all background tasks as soon as the device screen is closed. Trying to make the battery last as long as possible. But ends up disabling GAEN, underlying Bluetooth signalling, and background server synchronisation. Making the HOIA app effectively useless.
To solve this issue we have been working on two aspects. We updated the Hoia FAQ page so that users can be more aware of this behaviour. And we created simple guidelines for support on how to diagnose and advise people who have such devices. Great help on this effort is the site https://dontkillmyapp.com/. It both details the behaviour of the problematic manufacturers and gives easy-to-follow guidelines to users on how to disable these hidden battery saver features.
As with almost any project that is created to solve a particular problem - getting it out of the door was only the first step. Supporting and improving it over time is what matters in the end. I feel that while we have much to learn and to solve, we are nevertheless at a good spot, and ready to accept the challenges. The important thing to keep in mind is that technical solutions are not the end goal. The users are. So we must turn our focus from technical problems into solving issues of UX,UI, and user perception.
Harri Kirik
Software engineer
harri.kirik@lab.mobi