Cwa-wishlist: Late warning about increased risk

[weso0013]

A friend of mine was Corona positive and reported - conscientiously as he is - the whole thing via the Corona-Warn-App (on a Samsung S10 with Android 10) and after the hotline had given him a TAN, the test was also shown as positive.
His wife (Corona negative) was told 2.5 days later about an increased risk via the app (although she checked several times).
I would have expected her to get a warning within 24 hours after he reported positive.

What is the reason for this late warning? And can this be improved?

---

Internal Tracking ID: EXPOSUREAPP-1883

[tkowark]

Hi @weso0013 ,

thanks for reporting this issue. And first of all: all the best to your friend!

Could you please help us to clarify the timeline a bit? From your message, I assume the following process:

• Your friend reported their positive result via entering a TAN at time X
• At X + 2.5days, your friend's wife was informed via the app?

Is that correct so far?
Would you happen to know at which time of day your friend reported their result?
Also, could your friend's wife take a screenshot of the exposure log checks in the system setting?

That information might help to explain the delay and - more importantly - think about mitigations. The 24h delay is already being discussed in https://github.com/corona-warn-app/cwa-backlog/issues/2 and might be reduced if the API rate limiting will be relaxed in future ENF versions.

[weso0013]

Hi Thomas,

thanks for checking this issue.

Yes, your assumption is correct.
My friend posted it at 4 p.m. using a TAN (after just scanning the QR Code didn't work) and his wife (they are 24/7 together) got the warning 2,5 days later.

Please find attached the all-exposure-checks.json - unfortunately they only reach back until the 14th but the reporting of the positive test was on the 9th.
all-exposure-checks.zip

Thanks and best regards!

[kbobrowski]

@weso0013 from the logs: the app made a match on the 11th of July, with 11 keys - this also reflects a delay you mentioned because if there was no delay it should match it with 13 keys.

It could be that your friend reported his status on the 9th of July but his keys were only made available in the "10th of July" package, which can only be downloaded on the 11th of July. But there are probably couple of other scenarios possible, would be really useful to know on which day exactly your friend reported his status and when exactly (day and time) his wife got notification. I'm a bit confused by 2.5 days later after 4 p.m. at certain day, would it mean that notification arrived in early morning hours?

@tkowark I think the issues discussed in https://github.com/corona-warn-app/cwa-backlog/issues/2 still can result in 48 hours delay (someone reports the result early in the morning, and phone of the contact person makes a sync late in the evening next day), although 24 hours is an average right now. Google is rolling out the update to EN framework which would allow exposure status update every 4 hours without changing epidemiological approach of CWA (so always feeding complete 14 days worth of Diagnosis Keys), would be great to have some update from SAP about the status of the discussions about moving to this API version, related issue: https://github.com/corona-warn-app/cwa-documentation/issues/373

[VeitRichter]

Hey @All,

@weso0013 invited me to join the conversation. I am "that friend". Feel free to get into contact with me directly per phone.
If that's a good approach, dm me.
To your Questions:

She never got a notification at all, but looked into the app every now and than.

[tkowark]

@VeitRichter unfortunately, there is no DM feature available in Github. If you prefer to continue the discussion more privately, we'd really appreciate your answer to corona-warn-app.[email protected] instead of this thread.

When saying that she never got a notification at all, this just refers to no notification popping up, but the app card turned red, right?

From the logs I would also assume the following timeline - please correct me if I'm wrong on anything:

• You reported your result on July 9 at around 4pm
• Your wife's phone did a check (judging by the rather consistent timestamps - a background check) on July 11, 13:21
• Your wife checked her Corona-Warn-App later that evening (?) to see the red card w/o getting a notification beforehand?

If that's accurate, than I think two issue came together:

1. the almost maximum delay between key upload and match as discussed in https://github.com/corona-warn-app/cwa-backlog/issues/2
2. the notification was not triggered, either because of an error in the app or maybe some phone setting preventing notifications (do not disturb mode?)

[kbobrowski]

@tkowark if the keys were uploaded on the 9th of July well before midnight then the match should happen next day at 07:50, but this check resulted in no match. Wonder if it is possible for the server to still shift Diagnosis Keys to the next daily package somehow. Would be great to know the exact timeline of the events here

[tkowark]

Keys were uploaded July 10 in the morning. Hence, server side seems to have worked as expected.

On client side, the app should have shown a red card on July 11 mid-day and send out a notification, if the matched encounters where above the minimum risk threshold.

The card only turned red on July 12 evening. Hence, we'll look into the risk calculation and asses under which circumstances this could have happened.

Another issue that occurred was that the QR-code-based test result retrieval did not work as expected and we have to check what might have happened there.

[kbobrowski]

Interesting, risk calculation in general feels a bit over-optimized and over-confident (e.g. registering contact but still displaying "low risk" with no notification if risk calculation did not cross the threshold). Perhaps it would work ok if we did not have such significant uncertainties in the system already (very short scanning windows + variability of BLE signal strength). What makes it further worse is that mathematics in "Epidemiological Motivation of the Transmission Risk Level" were probably based on a flawed research paper (related issue: https://github.com/corona-warn-app/cwa-documentation/issues/384).

Maybe a solution which could be considered is to introduce third interim state "possibly increased risk" with yellow card and notification whenever at least 1 key has been matched

[tkowark]

Indeed. Thanks for the yellow card proposal! We'll take that to the product management so they can discuss with RKI and the other stakeholders.

[kbobrowski]

@tkowark thanks for passing this yellow card proposal further to the management / RKI :)

[daimpi]

The yellow card proposal sounds great ☺️ 👍
It also relates to the issue regarding green risk encounters which recently moved to backlog: https://github.com/corona-warn-app/cwa-backlog/issues/23 (and https://github.com/corona-warn-app/cwa-wishlist/issues/100)

[jensjensenjens]

Due to lack of data to verify the classification, I think it's important to analyse such case-stories to see, where to improve. So thanks for sharing.

Interesting, risk calculation in general feels a bit over-optimized and over-confident (e.g. registering contact but still displaying "low risk" with no notification if risk calculation did not cross the threshold). Perhaps it would work ok if we did not have such significant uncertainties in the system already (very short scanning windows + variability of BLE signal strength).

I agree with the distance part being hard to measure and, hence, maybe some more relaxed criterion should be used or something more flexible than a binary categorisation. However, since it's a household contact one is likely to have had an exposure every day, so it would be surprising if the particular choice of the epidemiologically motivated transmission risk level had any big influence on the risk classification? Still seems to be important to analyse these cases in more detail.

[daimpi]

I just received report of a similar case.
The situation is the following Person A & B are living in a household together i.e. have continuous contact.

The timeline looked like this:

• 17.10. person A got their positive test result and submitted their DKs in CWA. This submission happened around midnight (CEST), but before 02:00 CEST.
• 18.10. checks performed on B's phone on the 18th at 02:33 didn't yield any matches.
• 19.10. checks performed at 08:26 find matches and yield an increased risk (last contact 3 days ago):
  

Why wasn't Person B already warned on the 18th? Shouldn't DKs uploads before 02:00 CEST (00:00 UTC) still go into the package for the upcoming day?

• Log: PersonB-log.txt

[daimpi]

Does someone know what the latest point in time is for when DKs uploaded on day 1 will still be added to the daily package which becomes available on the following day?
@christian-kirschnick @Tho-Mat @EvgeniiSkrebtcov maybe? 🙂

[cfritzsche]

I guess with 1.7.1 out we can close this issue?

[dsarkar]

HI @weso0013, as @cfritzsche suggests, with the new updating schedule of CWA version 1.7.1 this issue becomes obsolete. Do you agree to close this issue? Thanks for the feedback. Best wishes,
DS

---

Corona-Warn-App Open Source Team

[weso0013]

@dsarkar Yes, for sure!

Thanks!

[dsarkar]

@weso0013, thanks for contributing! Best wishes, DS

---

Corona-Warn-App Open Source Team