Safe Places (SPL) is an augmentation tool for Digital Contact Tracing (DCT). SPL is meant to work in concert with the Safe Paths Mobile App. The practice of DCT involves more tools and processes than just what SPL provides capabilities for.

Typical Digital Contact Tracing (DCT) Interview

Contextual Assumptions about DCT

...

CT’s are expected to redact / remove sensitive location history (such as personal residence) from the patients SPL file and gain consent prior to storing the location history in a database where the data can be aggregated and published as “points of concern” for the community to receive exposure notifications based on.

Deployment of Safe Places at an HA

Overview

Safe Places is an open source white-label web application. The business logic and UI/UX of the web app is functional to spec, but a production deployment of the web application on the infrastructure of the HA requires development work to actualize.

There are 3 primary reasons for why the application doesn’t work at an HA after simply downloading it from our open source repo’s:

1. The Safe Places web application requires a database backend to function correctly. There is a wide variety of database technologies in use across the landscape of HA’s. We’ve not assumed or optimized for any specific database technology. We’ve left that open to be “finished” by a development team looking to install Safe Places

2. An identity management platform is also required to ensure that only authenticated personnel have access to the Safe Places web application. There are a variety of ways an HA may be implementing identity management. We assume it exists, but leave the actual implement to be “finished” by a development team looking to install Safe Places.

3. We publish a file of public concern points (GPS lat,long,time of infected carriers) to be publicly accessible for all mobile app clients. How that file is published or moved from the server it was published from to an endpoint which is publicly accessible may vary from HA to HA. We’ve also left this open to be finished.

It’s very unlikely that a non-development team will be able to download our source code and make it production functional unless they implement our example backend exactly as it’s written.

Server Requirements

There are no specific requirements for the server the code is installed on. There are a variety of ways to make a deployment successful. The two largest workload stress points are as follows:

1. The server which is hosting the file to be downloaded by mobile apps will experience load in proportion to the active case load and the number of active mobile app users in the jurisdiction of the HA.

2. The server which is hosting the ingest endpoint will experience load in proportion to the number of active cases.

3. The server which hosts the Safe Places software will experience load in proportion to the number of active cases and the number of contact tracers working those cases in parallel.

High Level Deployment Diagram

In the below diagram, there are a few components described here:

• Secure sharing endpoint - Publicly accessible URL defined in the Safe Places setup process by the HA, written to safe_paths.json file via Safe Places publisher functionality

• Published points of concern - Publicly accessible URL defined prior to the Safe Places setup process by the HA, written to healthcare_authorities.yaml file by Path Check.

  • Should be hosted behind a load balancer or via a CDN

• Safe Places web tool - Software downloaded from the Path Check Frontend repo on github.

• Safe places Backend - Example software downloaded from the Path Check Backend repo on github. Requires a dev team to modify for the HA specific IT environment.

• Safe Places DB - Database platform chosen by HA

• Identity Management Platform - Authentication solution chosen by HA