Apple and Google recently announced EN Express (ENX), a way for Public Health Authorities (PHAs) to launch a lightweight Exposure Notification capability to battle COVID-19. ENX allows PHAs to fill out a configuration file and submit that to Apple and Google instead of building their own custom apps. The companies then use a PHA’s configuration file to provide exposure notifications on a person’s phone either through the operating system (iOS) or an app generated on behalf of the PHA (Android).
ENX provides PHAs with another option in order to get privacy-preserving Exposure Notification tools out quickly. For now, ENX is only available in the US; five states and the District of Columbia have announced their intention to use the ENX tools, and California started a set of university pilots on September 21. Meanwhile, as of this writing, ten US states and territories have rolled out custom apps (for a full list of states and countries that have shipped exposure notification apps, please see the LFPH Landscape).
ENX and widely available open source codebases have both made Exposure Notification easier than ever to implement. In the United States, national deployments of the reference key and verification servers are available through APHL and work with either solution, solving the challenges of interoperability and managing a multi-part backend system.
No matter which option a PHA chooses, there’s a large amount of baseline work that needs to happen. Read on to get some help thinking through this decision.
Key differences between custom apps and ENX
These are some of the critical categories that a PHA should take into consideration when deciding which solution to choose:
| ENX | Custom app | |
| How users opt-into Exposure Notifications | iOS: ENX is built into the operating system. Users in states and territories that have opted in will receive a push notification to opt in and then the app will run automatically. Android: ENX is deployed through an app auto-generated on behalf of the PHA. Users will receive a push notification to opt into ENX and install the app in three taps. | Users need to go to the app store to download the app on both iOS and Android. On Android, PHAs will have the option to send push notifications to users encouraging them to install the app |
| Speed to market | The larger barriers to getting an ENX solution to market quickly will be around getting public awareness campaigns set up, legal reviews, and deciding on an appropriate risk model. Once these are complete, ENX can be deployed in days. | If using a well-developed codebase, the main decisions and barriers around speed to market will be slightly longer than with ENX, but a custom app can still be deployed within 30 days provided marketing, legal review, and risk modeling can be completed quickly. If building a proprietary app from scratch, the timeline will take months. |
| Development costs | PHAs will need to fill out a configuration file. This is a text-based file that will set all the parameters for Exposure Notifications. It should be able to be completed with internal staff or minimal help from an outside vendor. | PHAs can build an app from scratch, off of one of the open source libraries available, or based on the Android and iOS reference applications to speed development. They have the option to work with their own internal technical team or an outside vendor. |
| Ongoing maintenance | Apple and Google maintain and update the core functionality. PHAs will still be responsible for updating and optimizing their risk score settings and maintaining the configuration file more broadly. | With an open source app, much of the maintenance to keep up-to-date with API changes is shared across all jurisdictions that have chosen to implement a custom app off that codebase. Maintenance is still required by each PHA to keep the custom app updated, including updating their risk model. |
| Custom features | Features of the solution will be largely limited to the core Exposure Notification functionality, and will provide exposure notification updates and a single message linking to a PHA website indicating where to access other support tools or optionally requesting for additional user information (e.g. phone number, zip code). | Apps can provide any number of features above and beyond the core Exposure Notification functionality, such as daily statistics (e.g.case counts at the county level), daily symptom checkers, requests for additional user information directly in the app (e.g. phone number, zip code) and other support tools (e.g. links to resources for people needing to access testing). |
| Risk scoring model | PHAs can select parameters to a general risk scoring model that incorporates weights for report type, infectiousness based on date of symptom onset, close-near-medium-far based attenuation measurements, and constraints on duration. | PHAs can use raw ExposureWindows to produce very complex risk scoring models, especially if they have specialized domain expertise in attenuation based distance measurement, outlier detection, or require unusual exposure constraints. |
| Connecting the app to other PHA systems | ENX can be integrated with PHA systems in a few ways: linking to a PHA-built website where the PHA can request additional user information (e.g. phone numbers, zip code) and integrating through a verification server API (or a custom verification server). | Apps have full flexibility to connect into a case management or test verification system to optimize interoperability with other PHA systems. |
| Customer support | Given the focused purpose of ENX, lightweight customer support will be required. Many customer support questions can be deflected via a robust FAQ website. Apple and Google will not be providing customer support. | A well-done implementation will not require a significantly different amount of customer support from ENX. More features will likely mean higher demand on the customer support side to manage those features. |
| User analytics | The simplicity of ENX means that a limited amount of analytics will be available to the PHA. | While there are some challenges to providing analytics while preserving privacy, a custom app does allow a PHA to collect a wide variety of analytics. |
How to choose
It’s critical that the PHA have a long discussion about their goals and priorities with the technology team that will be responsible for the Exposure Notification solution. Both solutions are excellent options and the right choice will be different for every jurisdiction.
One option that a number of states, such as Virginia, are choosing is to have both custom apps on iOS and Android, while also deploying ENX on iOS. Since ENX on iOS is built into the operating system, it does not conflict with a custom iOS app and both can run in the same jurisdiction. This means that on iOS, users can choose whether to opt-into Exposure Notifications through the operating system or by downloading a custom iOS app. That is one strategy to maximize adoption within your community, while providing many users the additional benefits of a custom app. If you choose to do this it is critical to think very carefully about messaging and rollout in order to avoid confusion since there will be two paths that citizens can utilize on iOS.
Doing both is not an option on Android. Because deploying ENX on Android will result in the auto-generation of an app on behalf of the PHA, there can only be an ENX app or a custom app active at one time on Android. The template used to generate Android ENX apps will automatically be open source.
Finally, keep in mind that a two-phased strategy could be implemented – PHAs may begin with ENX and then over time build out a custom app. With the right user trust and awareness campaign it would then be possible to encourage “upgrades” to have everyone download a custom app at a later point in time.
No matter what, robust messaging and PR before, during, and after the launch of Exposure Notifications remain the most critical part of deployment. Any strategy without a user trust and awareness campaign is unlikely to drive substantial adoption. Bringing political leaders, public health leaders, technologists, marketers, and other key stakeholders together from the beginning of the process is necessary for success.
Every PHA will have to make the decision for themselves on which option is best. To discuss your options with other jurisdictions or get a consultation from a Linux Foundation Public Health staff member, please join our Slack community and/or reach out to Jenny Wanger, Head of the LFPH’s Implementer’s Forum.