Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 62 Next »

Squad

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.

Project Plan:

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:

  1. Safe Paths Core Devs Meeting to Discuss, Decided to investigate Same repo, multiple apps.

  2. Jira Ticket Here.

Covid19+ Test Authentication Service:

  1. 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

  2. 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.

  3. 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 BT 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.

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):

  1. https://pathcheck.atlassian.net/browse/SAF-186

  2. https://pathcheck.atlassian.net/browse/SAF-192

  3. https://pathcheck.atlassian.net/browse/SAF-187

  4. https://pathcheck.atlassian.net/browse/SAF-188

  5. https://pathcheck.atlassian.net/browse/SAF-189

    1. Similar tohttps://github.com/vitorpamplona/react-native-ble-advertiser

  6. https://pathcheck.atlassian.net/browse/SAF-190

  7. https://pathcheck.atlassian.net/browse/SAF-191 Options:

  8. 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

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):

  1. You can make it volunteered location, or require ZIP.

  2. 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.

  3. I might stick with GAEN concepts when possible (exposed/affected).

  4. Where does the exposure definition live or how is it defined by HAs?

  5. 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.

  6. Why do we need/want the HA registry? If HA tied to App in v1, bit redundant no?

  7. 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.

  8. 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).

Screens in progress

https://www.figma.com/file/79OwaKqHvSeriExpYzAvVN/PATHS-Exploration-April-and-May-2020?node-id=1652%3A496

*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.

View recommendations:

User is sent to HA website link or into self-assessment

Report an error:

If user believes the update was a mistake, they can dismiss and report an error

Exposure screen

(User can de-select date)

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

Google Apple Demo App screens

From May 4 2020 TechCrunch article:

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.