| Table of Contents | ||
|---|---|---|
|
Squad
Dev: Vitor Pamplona Tim Stirrat @tylerRoach Krishna Durai @prithvi Kyle Towle
Product: Christian Crumlish
UX: Ali Raizin
Content: Patty Michaud (Deactivated)
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,
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.
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.
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-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
Approach related to “marking positive” via test auth vs self-reporting heuristics
Customization of exposure notification logic and “what to do next” URL’s
References
| Info |
|---|
New GAEN Technical Documentation
|
Straw-man v1 High Level Design
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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).
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)?
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.
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
| Note |
|---|
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).
Screens in progress
*NOTE: All ‘Brief Health Screen’ and ‘'Next Steps’ questions and responses are defined by individual HCA
Exposure Notification Permission primer
Exposure Opt-In
Exposure Notification
Tapping notification takes user to ‘Exposure History’ screen
Exposure History
(new exposure notification state)
NOTE: Time references are placeholders, need to be updated with specific levels based on HA configuration.
Next Steps
(new exposure notification state)
NOTE: Placeholder text above.
User is sent to HA website link or into self-assessment
If user believes the update was a mistake, they can dismiss and report an error
If user taps the back arrow without dismissing or next steps
NOTE: Adding option to get emergency access on main screen.
Once user has either selected “dismiss” or “next steps,” app resets to normal mode (no more exposure notification mode).
User can return to Exposure History screen after dismissing to find information again.
Home screen
Exposure History Screen
(no date selected)
Exposure History Screen
(date selected)
Next Steps
Report an error
