Test result if healthy

[mitra42]

If the Tester delivers a result of STATUS_HEALTHY @jmday says

if test neg on day x then eliminate any notifications or local symptoms prior to x-1

I think this has to happen client-side, but need to think through potential for spoofing.

• [ ] Make sure to update spec when fix this

[mitra42]

If Terry the Tester thinks Alice is infected he sends /result which causes Alice to receive response to poll result:

{ contact_id: [ id: Alice EphId generated from (Provider,TestID,PIN), status: 0, message: "Call Tracey" ] } 

Causing Alice to go to status 1 = INFECTED

• For Healthy she (currently) receives status:3 unknown and goes to status:4 HEALTHY
• There is no "replaces" code on these.
• This is actually unique as she wouldn't normally receive Status:3 UNKNOWN as that isn't circulated,
• Its not spoofable as noone else but Alice & Terry (the Tester) knows or can generate this EphId
• Alice.pending_test will be recording the EphId so she also knows its special.

Alice should update her status doing a /update status=4 HEALTHY which Bob gets and can drop the notification Alice was PUI

• [ ] Check this is actually being sent out
• [ ] Check that Bob doesnt set own status=5 (off chart)

[jmday]

For discussion: I sense there is may be value to sharing UNKNOWN statuses. Also, I'd like to question the assumption that having a "test-pending" equates to PUI/At-Risk. Note: There are many people being tested that are not at-risk and this may grow as tests become more available/common.

[mitra42]

@jmday regarding what you saud ....

if test neg on day x then eliminate any notifications or local symptoms prior to x-1

A couple of issues here,

• for IDs, we don't know the time of notifications, only the time it arrived at the server and the duration. So if Alice contacts Bob on 1 Jan; and is infected on 14th and tells server immediately, we don't receive in the protocol any info that can distinguish if that contact with Bob happened on 1 Jan or 14th, so we can't pass that on to Bob
• If Bob then gets alerted, gets tested on 15th, and is negative, then if we assumed that contact was on 14th then we wouldn't eliminate it.

Lets say that we decide to add a timestamp to contacts - probably course (at the day level) - then this means the following scenario breaks. ....

• Alice meets Bob on 14th, finds infected later that day and {/status/send Bob 14th, 15 mins}
• Bob status goes to PUI and he does the right thing and gets tested on same day (not unreasonable).
• Bob's client doesnt eliminate this contact since its not x-1, meaning Bob stays at PUI

Note - so far, all this is client side, the server isn't doing anything with the data except passing it on.

Thoughts ....

[jmday]

I sense there may be a conflation between what I've suggested we do with scoring vs. what we should do with status exposures (what you guys are calling "alerts" on the server, which is not quite the same since clients are really in charge of sending out in-app notifications/alerts). The server really can't "alert" (verb) as it doesn't know who to send things to.

When there is a negative test, can we allow the server to eliminate the whole string of exposures (visits & contacts) including the day before and of the test (and beyond)? If the client sees symptoms again (potentially, even before results are available), it will need to initiate a new string of exposures that it can include everything from 1 day before the test into.

Perhaps we should have a deeper discussion around this, but I'm headed to bed soon tonight.

[mitra42]

Its an "alert" when it gets to Bob's client (Bob's client may choose when to "alert" Bob)

We can't have the server eliminate things, for two reasons a) we don't know what the clients have already seen (or what has sync-ed to other servers) so we can only update something> b) the server can't update these alerts since it doesn't have a key c) the server can't find the alerts since they are not in any way tied to the test result (the only place they can be tied together is at Bob - and that is intentional for privacy).

We could have a rule (in the client) about which to eliminate. That rule could be based on when Bob or server sees them (which will be sometime after Alice sent them) or we could add a date field (and its resolution affects privacy)> Or we could have a rule that ignores the timing - e.g. erasing all local status prior to the test result being received, which risks some infection between being tested and getting results being ignored. Or we could have a rule eliminating all status prior to taking the test (which just risks infections events that haven't yet progressed in Bob long enough to make Bob infections). Or .... we could combined this, for example when Bob gets tested, we flag anything that Bob received up to xx-hours prior to taking the test, and then eliminate when the test result comes in.

As you say needs longer discussion, and there may be combinations I've missed.

[jmday]

Ah, "alert" as noun. Okay. I'll keep translating in my head, but marketing has been using "alert" as verb for some comms (FYI).

Apologies: When I said "eliminate" I was keying off your verbiage above... I really just meant "update as healthy" (after negative test as I sense you meant too). :) I realize entries are important for eventual consistency and won't be "deleted" off the server until they time-out for permanent removal.

Correct me if wrong, but... Can't the server can use replacement tokens from the seed (generated from ProvID, TestID, PIN... shared by Bob and Tester... used to generate update tokens in post-test /update by bob... sent in /result by tester), to "update as healthy" the entire sequence of "alerts" Bob has generated?

If this is the case and IF Bob has reported symptoms later than 1day prior to testing, his client would need to send out any alerts for at-risk/pui under a NEW series of "alerts"... this would allow for another test to take those alerts into account as well.

Let's discuss when you're up, though.

[mitra42]

Not quite - we can update the alerts Bob posted about other people - e.g. Bob posts an alert about seeing Carol, Bob gets tested, the shared key between Bob&Tester means Tester can update the alert that Carol received.

BUT We can't update/eliminate the alert from Alice to Bob as the Replacement token for that can only come from Alice.

We can ignore it on Bob's client. (Bob knows they got a test result, and that a negative test result overrides any prior alerts).

We still have the date issues and need to add that to the protocol if we want Bob to consider anything other than the order that their client received alerts. AND we still have the issue of overlapping alerts to deal with, which is tricky as the user is going to notice this.

[jmday]

Ah, yes. This was the "scoring data" vs. "exposure/alert data". I'm on board that Bob will not be able to invalidate the alert that Alice initiated for him. He will still get all his alerts for visits/contacts but the client will need to filter out all items before time of his negative test datetime - 1d. He CAN know the time of proximity contact from Alice as the local device can store time his own EphIDs were used. Prefer we not store (even locally) the time that other EphIDs were seen and it's important that we not have the times be part of the protocol for contact data sent with /send or /update.

[mitra42]

Conclusion from call - eliminate any entries for EphIds used more than a day earlier.