Context

We need the ability to deploy an Apple/Google Bluetooth API Prototype over a relatively short time horizon (1-3 weeks) in order to demonstrate competence and relevance. In order to accomplish this task we want to leverage as few as possible UI/UX modifications to the existing app.

Materials:

Mobile App Repository Strategy

Given we want to have an app that supports BTE functionality and an app that supports GPS activity, how should we engineer our code that keeps it maintainable,

Same repo:
- Less Overhead
- Approach: Multi-package, single repo approach until the lines are clearly separated. Then we investigate actual splits. [Default Option at This Time]
New Repo
- Pros:
  - Less overhead.
  - Does not fuck CI/CD
- Cons:
  - Needs to transfer UX gains from old repo (i.e. feature flagging)
  - Lots of maintenance overhead.

Action Items:

~~Safe Paths Core Devs Meeting to Discuss,~~ Decided to investigate Same repo, multiple apps.
Jira Ticket Here.

Covid19+ Test Authentication Service:

We need to deploy for HAs a testing authentication service, and supporting webapp.
1. The Webapp backend would be to allow an HA to configure parameters that determine behavior
This should have unique keys for each Covid19 test and also maintain the status of that test, to be confirmed during the Covid19+ BTE flow.
Ideally out of Scope for MVP, but need to confirm.
1. Given our GAEN Pilot / MVP will be tied closely to an HA partner, we need to take their feedback on how best to implement marking keys as “infected”. This could be through a test authentication service or heuristics of self-reporting based on their feedback.

KeyServer Deployment:

As we are intending to deploy the same application in different nations and states, the Health Authority Selection Screen should tie the user to a given Heath Authority Server. We can explore more sophisticated location-based server logic in later deployments (potentially).

We need to think about KeyServer selection being specified to a specific URL which is specific to the Nation/State/Territory whose app store account we are deploying with or being specified via the healthcare_authorities.yaml file with one URL per Nation/State/Territory pointing to a keys server for all HA’s in that jurisdiction
We anticipate this data will be read quite a bit, and we want the keys to be easily cacheable by CDNs, et et.
We anticipate that this server will become obsolete when this BLE functionality is moved to the OS.
We need to enable the user to be able to select a nation/state.
We want to enable easy deployment within at least one cloud platform.
We want to determine who will manage and host the server.
Krishna’s draft here: https://docs.google.com/document/d/1kWBhCr_IMzGsoq1dVyCVFmI0xycCMUheMxX1h7hXahk/edit?usp=sharing

UI/UX:

We want it to be as close to GPS flow as possible. A few differences may be:

Static content at exposure notification explaining the bluetooth proximity logic in layman's terms
May not include HA selection if a keys server URL is embedded in the app specific to that Nation/State/territory
The concept of being “marked positive” in the GAEN app is different from the GPS app in that there is no CT involved.
- There is no sharing of location history or CT specific interaction flows
- There is a concept of uploading / sharing keys to a keys server within the jurisdiction

Rough Task Plan

If not clear, we have 6 big tasks at hand (tracking in Jira in this epic: https://pathcheck.atlassian.net/browse/SAF-182):

https://pathcheck.atlassian.net/browse/SAF-186
https://pathcheck.atlassian.net/browse/SAF-192
https://pathcheck.atlassian.net/browse/SAF-187
https://pathcheck.atlassian.net/browse/SAF-188
https://pathcheck.atlassian.net/browse/SAF-189
1. Similar tohttps://github.com/vitorpamplona/react-native-ble-advertiser
https://pathcheck.atlassian.net/browse/SAF-190
https://pathcheck.atlassian.net/browse/SAF-191 Options:
- Converting our super simple enterprise server: https://github.com/vitorpamplona/ble-tracker-server
- Building a new one with emphasis on static files for performance.
- Using some work other people have started: https://github.com/dstotijn/ct-diag-server
Meet with early GAEN Pilot partner to establish customization requirements
1. Approach related to “marking positive” via test auth vs self-reporting heuristics
2. Customization of exposure notification logic and “what to do next” URL’s

References

New GAEN Technical Documentation

Exposure Notification FAQ - May 2020 - v1.1
Bluetooth Specification - April 2020 - v1.2
Cryptography Specification - April 2020 - v1.2

Apple Developer Resources: ExposureNotification Framework API
Apple Developer Resources: Sample Code: Building an App to Notify Users of COVID-19 Exposure
- NOTE: You configure the project with a provisioning profile that includes the Exposure Notification entitlement. See Exposure Notification API Entitlement Addendum.
- Ping Sam Zimmerman xianabout the provisioning profile when needed.

Straw-man v1 High Level Design

Google’s exposure notification server requirements - awesome reference

A few notes from SamZ on this (note sure where/how to do this, not a confluence whiz):

You can make it volunteered location, or require ZIP.
We want to connect Covid19+ service to the keys. (I.e. I think we want to abstract, as GAEN do, testing and symptoms into “Indicators”, which can allow for keys to be sent). Allowing HAs to say who should be treated as positive seems not particularly large in scope and very helpful.
I might stick with GAEN concepts when possible (exposed/affected).
Where does the exposure definition live or how is it defined by HAs?
How do we handle affected person state post exposure? (when do they become non-symptomatic do we mark them as asymptomatic? Just waiting 14 days seems wrong to me).
1. SZ to check low-level what sort of things to do post-covid19+. Preference for immediate non-positive.
Why do we need/want the HA registry? If HA tied to App in v1, bit redundant no?
If we’re already supporting secure transmission in SP/SPL, can we make the exposure notification interaction richer much more cheaply (esp given same codebase)? (i.e. it’s not just a page, it’s a communication platform)?
1. SZ: Probs a bit too early to make them converge.
Seems very easy to also support counts of infected users in area from phone, if we want it.
1. SZ: Want if we have it. Applicable to GPS.

GAEN v1 Assumptions

Assumes combined Self-Reporting capabilities via self-assessment questionnaire and the GAEN based mobile app
Backend consists of Self-Reporting, Keys Server (G/A spec) and customization / configuration capabilities for the HA
- May be less flexible for initial pilot
Enables marking someone COVID positive based on heuristics of symptom reporting / self-assessment or strict test authorization code from the Health Authority (HA)
- This assumption may not be correct after changing our strategy back to one that’s customizable by the HA.
- HA during on-boarding will need to define: How someone is marked positive.
Enables uploading keys to the key server in the context of being “marked positive”
Enables notification for those who’ve come into contact with the infected carrier
Notification messaging will be boiler plate and appropriate i.e. NOT “You’ve been exposed”.
- Provide the ability for the HA to define the notification messages, parameters and URL
Assumes a single Keys server endpoint for the specific app at the nation/state/territory level.
App is released using the app store account of the Government / HA and is co-branded so as to discourage download outside of that HA jurisdiction
Requires HA on-boarding for any part of the experience to function

A small syntax note, we should differentiate “self-assessment” from “self-reporting” for clarity - with “self-assessment” as the questionnaire and “self-reporting” as a mechanism to share data.

Hosting Requirements

Working with the Healthcare authority to host the Keys, Self-reporting and Test authorization servers on their IT resources.

Current State of Play

Development

Vitor is getting the demo app working, as a baseline

UX / Screens

Ask

We need a screen to trigger when the person has been exposed.
And try to understand what we want to suggest after that
It could be as simple as "You have been exposed, click here to schedule your Covid test" to type of thing.

Design Considerations

Additional note: HCAs should be informed that all responses are defined by them and can be customized (ex. determining what symptoms are severe enough to filter user to seek emergency services).