which SK's to report + was_warned_by_app flag

[peterboncz]

In contrast to descriptions of manual contact-tracing, which distinguish between tracing forward and backward (source tracing), all use cases for app-based contact tracing I have seen are on forward contact tracing, i.e.:

Case A. If you receive a warning through the app, you know the time you got infected (assuming you test positive). According to literature, you can be infectious from day 3 of infection. So we would need to to report the SKs you issued from your infected date +3 days and beyond (if any, because if the warning comes real quick, you have not yet been infectious). That is clear.

But what if you get tested positive without having received a warning?

[ This will of course happen (i) if you got infected by a non-user of the app, but we cannot warn anyone there. But it can happen also if (ii) your infector is an app-user, but got infected by a non-user: the Ferretti et al Science paper estimates the amount of a/pre-symptomatic transmission as 37%. This means that these people would infect others without feeling ill, and would get warned by the people they had infected. It also (iii) happens if an infected app-user ignored a warning. When the contacts get ill, they will not have received a warning. The infector who ignored the warning, then hence later gets more warnings, from the people [s]he infected. Finally, testing positive without warning happens also (iv) if the app failed to detect the contact between two users properly (BLE handshake failure, or false negative in the risk-score threshold). All in all, this will likely happen in a significant fraction of positive app-users: 40% for (i) if adoption is 60%. Plus 60% of 37% for (ii). Add 60% of 63% of 20% if 1/5 ignores a warning. In case of 15% false negatives add 60% of 63% of 80% of 15%. Under these numbers, 75% of positive app-users will not get a warning by forward-tracing. It will undercut the feeling of usefulness of the app for its users, unless we stress the utility of backward tracing also. Note: do not feel necessarily defeated by a low detection rate: if contact-tracing apps can bring an R=1.4 to R=0.9 they still are useful as they can enable a partial lifting of lockdown. ]

In case of testing positive without warning , we could also attempt to do backwards contact-tracing (source tracing).

Case B. There is an incubation time of on average 5 days. So if you had symptoms and tested positive (typically, you got the test because you were ill), you would need to post the SK's from 2 days before your first symptoms on, to do forward contact tracing. But you have to extend this to 5 days before your first symptoms to also do backwards contact tracing (it is said incubation time can be up to 10 days, so it could even be argued to be a few days more). So without warning, you should be posting more SK's (at least if we want to attempt backwards tracing).

Case C. If you do not have symptoms but still got tested positive (e.g. in a routine or dragnet test), you were infected less than 5 days ago, you would only need to post the SKs from yesterday to do forward contact tracing, but would have to post SKs at least from 4 days ago and beyond to include backwards contact tracing (and similarly this could be argued to be a few days more).

My assumption is (anyway) that SK's would get posted on the backend with date (or put in some data-structure segmented per date). We could further annotate the reported SK's with the boolean attribute whether the infected person was warned or not by the app (forward- or backward-tracing). This is useful first of all when communicating a warning in the app because if it is backwards tracing (typically after quite a time lag) the person probably will have developed some light symptoms, and the app could remind of that as an extra motivation to get a test ("did you feel a bit ill a week ago? You could have had it and passed it on!"). Second, in case of a test after a backwards warning, the health authorities should also throw in a ELISA blood test. Because you may already be cured, but we can still detect immune response. Third, the risk score should go up when multiple warnings amass (forward, and backwards).

Anyway, depending on the situation (case A, B or C), different SK's need to be posted with either backwards- and forwards-annotation. The app could support the reporting of the proper SK's if not in case A (did receive a warning) by asking: "what was the day of the first symptoms?" (to compute this for case B -- if the answer is: "I have no symptoms", it is case C).

(moved the previous discussion on possible opt-in stats to collect at the backend to #225)

[lbarman]

Hi @peterboncz, thanks for the input ! From the little I know about it, I think that the user, when getting the authorization code from the health authorities, would have the opportunity to discuss with a doctor to

• identify the infectious period depending all circumstances,
• possibly redact some private time-periods,
• then upload the SK's corresponding to the remaining infectious time-period.

If I understand correctly, this encompasses the use-cases you mention, or did I miss something ?

Also, about the boolean flag of whether the user has been warned through the app, I don't think this is something we considered yet... one downside is that it would indicate to the backend partial graph information. I'll flag this as a possible extension

Thanks!

[peterboncz]

Thanks. Good point on the redacting time periods with some help (and I would add: do more redacting by a-posteriori whitelisting of the home WiFi connectivity -- I would make a case for logging actual WiFi network name with each contact to make that possible).

The boolean flag is very partial info -- because the backend does not know who did the warning. Only becomes problematic if there are a handful of positive cases per day (countermeasure security-folks style: let some apps with low probability log a few hundred bogus SKs every day, then you will never get to that situation).

Back to your question: yes, to a large degree, what you write covers those cases, if the country choses to do human-in-the-loop contact tracing using well-trained doctors.

It still would mean the app needs functionality to mark time-periods in the reporting screens. Arriving at these time-periods would require help from a doctor, because I realize the story above is a bit dizzying. Too much for the average user to do correctly. You might also need to do some doctor-training; because not all doctors are experts in contact-tracing, and/or in coaching users to do the right thing with the app. An alternative might be a call-center with contact-tracing trained people. But they would have to walk the user through doing this while on the phone -- not handy.

However, countries might also opt to separate more strictly the use of the app and interaction with the healthcare services (just the TAN code to enable reporting). In that case (and in any case), finding the right SKs could be helped by an "SK wizard" in the app, as I suggest above (it checks whether you were warned, and if not, asks for the date of first symptom). This SK-wizard approach would work well if the health authorities do human-in-the-loop contact tracing using a call center, with the app as support. The main task of the call centre agent would be to provide the TAN code, ask sanity questions and determine if the app was used sufficiently to achieve contact tracing coverage (otherwise manual tracing is needed), and help a bit to reduce false positives in the SKs. BTW: it would be very good if the app could somehow give the user some feedback that confirms it was on and functioning (picking up contacts) in the past week to inform such a conversation.