Why not using app-triggered information in case of positive test result?

[rennertimo]

Hi,

thnx for providing an idea to tackle the issues the current app versions are not able to handle properly.

I was wondering why you make the information process more complex. From my point of view it could be much easier.
Of course, I am assuming that the approach is relying on already existing Corona Warn apps based on the GAEN, and not as a dedicated additional app.

Assuming that a guest (and not the host) of an event is tested positive, in your approach the workflow is the following:

• the guest contacts health authorities (ha)
• the ha interview the guest, asking of his contacts / events in the last 14 days
• the ha uses the information to contact the hosts of events
• the ha enables the user to upload the data of the event
• the uploaded data is made public

I see several topics which could cause issues in this case:
a) the host of an event still forms a single point of failure (he's not available, the device is not available, ...)
b) the process requires the health authorities to act - in the current situation this is a high potential bottleneck
c) positive tested persons might not remember all events where they have been

As an alternative for reporting a positive test to all participants of an event, why not relying on the already existing method directly via the app? This means, when a user is using the existing app and receives a positive test result, why not directly notifying all users?
What would change:

• the notification speed is remarkably higher, as manual processes are eliminated (which does not mean they are not required)
• load on health authorities decreases more (your approach already does)

Open points:
Q: Is there a higher risk of misuse?
A: When using the same way of notification as in the German CWA, I would not see a higher risk compared to the already proposed way

Q: How to handle notifications compared to BT-LE indicated ones?
A: Probably the notifications should include the info how it was detected (via BT-LE, via QR-Code, via both) so the user can better judge the risk.
But this question also exists on your approach.

Best regards,
Timo

[Thomas-Hendrik]

Hi Timo,
thanx for describing the automatic app triggered information of positive test to all participants of an event!
It is exactly the way I thought about it, because in fact the bottleneck are the ha (regarding complete tracking and fast acting).
Furthermore, this feature may be used for all kinds of controlled spaces and will push the usage of the CWA!

I just would like to modify or add one Feature: Better than letting the hosts of events transfer data to the ha (what is all but secure or private), the app shall send depersonalised, anonymous information on where and when infected people have been the last 14 days. With this data, the ha could in real time visualize an follow infection clusters and there development.
Through this, they may analyse, where the real hot spots are and seize the most effective and adaptive measures.
This also would help to communicate those measures and make people supporting them.
Again, only depersonalised statistic data should be transmitted, that may not be traced back to a specific person.
Does anybody know, what kind of Software the Gesundheitsämter (ha) use for analysing data? More than Excel?
The German Government offers quite a huge fund for the digital modernization of the Gesundheitsämter...
May I help raising support from the governmental or associations (e.g. the German association for hotels and restaurants, DEHOGA e.V.)?

Finally I have serveral suggestion for the name of this Feature: CoVTrckr, CovidTrckr, CoronaTracker...

[agreulich]

Fair point, and I mentioned something like this already in an earlier comment (#27 (comment)), however the main issue is closed meanwhile and my comment might have been overseen. The problem with your idea is that - after a visitor visited an event and scanned the QR code - the information about this event is ENCRYPTED on her device, so there is no way this information could be passed to ha in case this visitor is later tested positive; not even the ha could decrypt that entry, this REQUIRES the - at this point still secret - tracing QR code of the event organizer. Only after the event organizer published the tracing QR code (CrowdNotifier notification), the visitor can decrypt the entry and notice that event was a potential cluster. This approach ensures that no entity who gains access to the data stored in a person's smartphone can find out what events she visited (unless a notification about it was already issued), and is a very strong feature in terms of privacy.

However, a workaround would exist in combining CrowdNotifier and SwissCovid in another way; it requires development of a 3rd, rather simple app for the event organizer though, I'd call it "SwssCovid-for-eventorganizers": it would be just like SwissCovid, but not emit any BT beacons itself; it would however record beacons of actual SwissCovid apps around it, very much like a BT scanner; the 1.5m / 15 minute rule would be ignored, so this app would record every single EphID it can see, no matter how weak and for how short a time it was seen. And it should be possible to distribute it on several smartphones for one event. The event organizer would distribute these "sensors" at several points in his event. Now, if a visitor uses both CrowdNotifier and SwissCovid (maybe combined in one app), her SwissCovid beacons would most probably registered in one of the event sensors. If this visitor later on tests positive and uploads her CovidCode, the "SwissCovid-for-eventorganizers" app of the events she visited will all be notified, just like any ordinary SwissCovid user - here not about a "potential infectious contact", but rather a "potential superspreader on this event". Now, it would be in the responsibility of the event organizer to contact the ha and upload the event tracing QR code for the second notification wave about the event. This avoids the "patient can't remember" and "patient interview" bottleneck. The event app could also count received warnings for one event and so enrich it by an additional "potential superspreading event" warning in the sense of backward tracing (this however requires SwissCovid warnings that not only cover potential infectious phase of a patient, but also potential infection phase - before incubation - of the patient). It might need some cooperation by Google/Android to make such a 3rd app possible, but of course such an app could also run on dedicated hardware (but I guess that would not scale very well).

[rennertimo]

I think I understand why your approach is different from my idea.
If I understand the idea of the CrowdNotifier correctly, you're planning to provide this as a dedicated app. Then this all makes sense from my point of view.

I was having the idea of integrating the entire story into an existing official Corona App. So it would be nothing more than replacing the BT-LE beacons by QR codes for events where we know that the BT-LE approach is not sufficient.
Then storing of the GUIDs extracted of the QR codes would be handled in the app, in parallel to the GAEN. The upload of GUIDs will follow the same mechanism, requiring a positive test result.

There are a few points where I can imaging options or other solutions:

• including this into GAEN would help securing the data and getting a common risk calculation, but also does not help breaking the requirement of having phones that are supported. for this case a standalone app only covering this use case is required
• the handling of notification in case of a positive test in the group sharing a GUID should indicate that it is different from the GAEN. Ideally, a notification covered by both approaches should indicate a higher risk than before
• as the GUIDs can easily be shared/spread via the internet potential misuse must be regarded and mitigated