Negative User - Hotspots - Search for Match to Positive Locations

[brittneybrown]

Background

The engineers had a planning meeting and proposed this general shape of work for the sake of time/shipping this first iteration on a Proof of Concept:

• Negative phone sends query with the user's anonymized locations to look for matches server-side.
• If there are matching positive location results, those are sent back to the negative phone in order to display the matches.
• The server does not store the negative user's locations; it only uses them in-the-moment to perform the query and return any matching positive location results based on radius and timeframe.

Implementation Notes

• Per the desire to give the user full agency over their locations, we will only be determining locations from the user's current location list.
• Locations means physical location where the user as well as date/time at each location

Goals of this Issue

• Provide a mechanism by which a person with negative-status to discover they may have come in contact with a person that tested positive
• Ensure that the negative-status user's locations are only used for a location match query and are not stored on the server nor able to be used in a way to identify the user

Scenario: Check for Possible Contact

Given I am a negative-status user in the app

• [ ] When I open the application
• [ ] Then I have a mechanism by which I can compare my locally stored location history with reported hotspots
• [ ] And I can determine if I may have come in contact with a person that tested positive

[iamjoshfrank]

Removing the following:

Then I receive back a percentage which represents the number of times my Locations corresponds with a Positive

Our goal is to show overlaps of times+locations, not to show a percentage. Why? Times+locations that match give the user more actionable insight into where and when they may have come into contact with a COVID-positive person.

Replacing with something about displaying a list of possibly-matched locations.

Further, the following can be clarified:

When I choose to share my Locations

Because we're not really "sharing" the negative user's locations, we're using that negative user's locations to construct a search query.

Ideally, this would happen:

• in the background; or
• less ideally, when the negative user navigates to the view for matches;
• or less ideally, but suitable for this iteration, when the negative user navigates to the view for matches and taps an option along the lines of: "Check my locations to see if I've been in a hotspot."

[iamjoshfrank]

Grabbing this back to make those edits.

[iamjoshfrank]

Removing the resources from the scenario for now; can spin them out into a new Issue. Gotta keep this as simple and straight forward as possible.

• More information links:

• CDC: Prevent Getting Sick https://www.cdc.gov/coronavirus/2019-ncov/prevent-getting-sick/index.html

• CDC: If You Are Sick https://www.cdc.gov/coronavirus/2019-ncov/if-you-are-sick/index.html

• [ ] And then I am presented with

  • [ ] A link to the CDC: Prevent Getting Sick page
  • [ ] A link to the CDC: If You Are Sick page

[iamjoshfrank]

@jwietelmann - I think you're most closely working on the query that would get attached to this Issue. Tapping you as well as @CurtisVonRubenhoff and @zhengfu23 who have been working on API stuff.

In #42, we're going to provide users the ability to provide 3 pieces of information alongside their change to positive-status:

1. Date Symptoms Began
2. Date of COVID-19 Test
3. Date of Positive COVID-19 Test Result

I'm confirming with the resources I have available that the date range we should pay attention to re: building queries (or maybe this is better put on #46 "Share Locations to Server"?) is Date Symptoms Began - 14 days.

I wasn't sure where to land this comment so I'm starting here before I lose it / forget.

[jwietelmann]

To make lines of responsibility clear: I am NOT presently working on reporting at all. I am working onthe endpoint that presumed negatives will use to find locations where presumed positives have been.

On Thu, May 28, 2020 at 7:39 PM Josh Frank notifications@github.com wrote:

@jwietelmann https://github.com/jwietelmann - I think you're most closely working on the query that would get attached to this Issue. Tapping you as well as @CurtisVonRubenhoff https://github.com/CurtisVonRubenhoff and @zhengfu23 https://github.com/zhengfu23 who have been working on API stuff.

In #42 https://github.com/revelry-foundation/nightingale/issues/42, we're going to provide users the ability to provide 3 pieces of information alongside their change to positive-status:

1. Date Symptoms Began
2. Date of COVID-19 Test
3. Date of Positive COVID-19 Test Result

I'm confirming with the resources I have available that the date range we should pay attention to re: building queries (or maybe this is better put on #46 https://github.com/revelry-foundation/nightingale/issues/46 "Share Locations to Server"?) is Date Symptoms Began - 14 days.

I wasn't sure where to land this comment so I'm starting here before I lose it / forget.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/revelry-foundation/nightingale/issues/44#issuecomment-635673271, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEGP2KC3Q53TIJUEFDWYELRT3Y4TANCNFSM4NNLEUVA .

[iamjoshfrank]

Got it, @jwietelmann .

I've opened #46 to handle the sharing of locations, which as I think about it more clearly, would likely be a combo of mobile + backend/API - so more clearly in @CurtisVonRubenhoff and @zhengfu23 's court on the API side and someone else on the mobile side.

Update: added the CDC guidance on the contact elicitation period in this comment on #42.

[zhengfu23]

Gonna try to pick this one up

[iamjoshfrank]

Pushing this forward to Implement and marking it in progress per @zhengfu23 's comment above.

Probably should self-score it, James, if you can.

Also, since it's been 4 hours and we're approaching pencils down, drop a Comment update and/or call for help getting unblocked.

[iamjoshfrank]

From Planning Poker in Slack:

Estimates for revelry-foundation/nightingale/44: curtis=5 and josh=8

---

josh (8): I think the API part is in place or in progress. There is no sketch or wireframe attached, so design ought to be involved in the solution. Tests to make sure we're not exposing privacy.

iamjoshfrank 3:29 PM I was borderline 5 on this one, with most of the squishiness being around the API / server part. Seeing Joel's comment above moves me back down to 5.

James Fu 3:29 PM I’d like to agree with a 5

jwietelmann 3:30 PM api is 100% done tests exist code prevents any potentially-identifying data from making its way into the db (addressing all your estimate comments)

[iamjoshfrank]

@zhengfu23 - since this is a carry-over goal from last week and integral to complete our loop, please call out blockers and/or seek a pairing partner ASAP today. Thanks!

[NOrzechowski]

@Samkeer1 I'm still getting set up, but I feel like this would be a good place for me to get up to speed via some pairing with you. LMK when you're available!

[iamjoshfrank]

FYI from @jwietelmann [at end of All-Hands](fastlane increment_build_number): here's an example of a match between mobile and the server response:

https://nightingale-server.nightingale.revelry.org/api/v1/find_proximate_positives?lat=90&lng=90&when=2020-05-28T17:21:29Z

[Samkeer1]

@iamjoshfrank I have a list of locations in which a user was in close proximity to covid-positive reporting users, just working on a bit of styling before pushing up code. I know it's not part of this ticket, but are hotspots something that we should also be listing out as well? I noticed hotspot listing on a wireframe and not seeing any sort of ticket for that.

[iamjoshfrank]

I'm not sure what you mean:

• [ ] Then I have a mechanism by which I can compare my locally stored location history with reported hotspots
• [ ] And I can determine if I may have come in contact with a person that tested positive

(emphasis added)

I think a solution such as the one sketched out by @HauwaAguillard in #59 is one way to achieve the goals of this Issue (though it needs some refinement)

Doesn't the payload of the API response provide:

1. The location used to perform the query (the user's location); and
2. The matching hotspot location?

And so, when trying to show the user their "matches," we should try to show them the pair: their location and the matching location.

[iamjoshfrank]

To clarify further:

are hotspots something that we should also be listing out as well?

We're not dumping out a list of ALL REPORTED HOTSPOTS BY EVERY USER FROM ALL TIMES into the app.

The "hotspots" feature is solely about showing matching locations.

[HauwaAguillard]

Moving these wires over here in ref to work done on #59. Also paired with @Samkeer1 to complete design implementation here.

Updated wires:

[Samkeer1]

Current pictures:

[iamjoshfrank]

Quick response: 👍

Note: we'll need more accurate explanatory copy on the first view (b/c currently it looks like you're using copy related to a positive-status user's option to upload their locations to the server).

[iamjoshfrank]

Bad assumptions re: what the server spits back as a result from the search request.

Joel is grabbing folks to clear it up.

[Samkeer1]

Discussed the presentation of hotspot information with @HauwaAguillard, @jwietelmann and @NOrzechowski, and we agreed that the simplest way to tie off the core loop is to show text along the lines of 'x' amount of people tested positive, within the 'matching' constraints.

@HauwaAguillard is working on mocking this up currently, while Neil and I work on displaying this data.

This will allow us to iterate and further flesh out data that we're comfortable with displaying to user, as well as to iterate in terms of continuing to define what a hotspot is.

Potentially, in further iterations it was mentioned that we could display more granular data to users. For example, 'the user was x distance away from you, for y amount of time'. etc.

[HauwaAguillard]

@Samkeer1 @NOrzechowski I'm sure yall already seen these but updating this ticket for our future selves 😄

@iamjoshfrank comments

👍 on this approach.

updated wires:

[NOrzechowski]

Thanks @HauwaAguillard, looks great. Let's pair in the AM.