Improve presentation of risk assessment

[markusmarkusz]

Didn't see a comparable issue when reading the overviews. ✅ Please correct me if I missed something similar.

Current Implementation

Whenever a contact tracing alert is displayed through the CWA, it always says "increased risk" regardless of how high the risk might be. In addition, it is difficult to understand exactly when the encounter took place.

Suggested Enhancement

Very simple: Provide more informations. In particular, to make the warnings more understandable, as it can be difficult to understand where they come from.

A few examples:

• Explicit display on the main page that the warning was due to contact tracing.
• In the event of a warning from contact tracking, it would make sense to indicate whether you actually met the person (key exchange took place - yes / no) -> Useful to determine whether distances have been observed if this isn't clearly known. Many organizers take one qr code for an entire building.
• If possible: Show exactly when you had a risk encounter (precise: time and duration of the encounter)

Regarding the 3rd point: Due to the pseudonymization using the random keys, it is of course difficult to clearly assign how long an encounter was. However, it can be checked with a probability bordering on certainty if the timestamps seamlessly pass over. In this case, if it looks too unsafe, a hint would be a possible solution. In my opinion, it's still better than no information at all.

Expected Benefits

iirc, a major criticism of the Luca-App was that the data was too imprecise to really work effectively with it. In restaurants, for example, it was impossible to determine whether the people were sitting close to each other at all. I get warnings more often because my cafeteria is warned about contact tracking. The fact that the building has more than one floor and that it is very large is not taken into account. Clarifying the risk assessment would help to act more sensibly. Once I was unsure about a warning and was then turned down on the 116117 hotline regarding a PCR test, because: "The Corona Warn App warns so often anyway, it doesn't matter." - Such prejudices would eventually be broken down.

In my opinion, the value of the data would increase and you can act more sensibly and thereby increase the usefulness of the app.

Have a nice day and stay healthy. ✌️😷

[Ein-Tim]

@markusmarkusz

Good morning! I've got some comments and questions for you 😅

---

Whenever a contact tracing alert is displayed through the CWA, it always says "increased risk" regardless of how high the risk might be.

With "contact tracing" you mean the Check-In/Event Registration feature of CWA, right? If yes, it's not true that always increased risk is shown, see https://www.coronawarn.app/en/faq/#check_in_qr_warning, which includes the question

"How is the risk determined? When do I receive a low-risk warning (green tile), when do I receive a high-risk warning (red tile)?"

which is answered with:

"The calculation of the risk depends on whether and for how long a user's attendance overlaps with the attendance of a person who later tested positive for COVID-19. If the attendance overlaps by less than 10 minutes, users receive a warning for a low-risk encounter (green tile). If a user's attendance overlaps by 10 minutes or more with that of a person who later tested positive for COVID-19, users will receive a warning about an encounter with increased risk (red tile)."

---

In the event of a warning from contact tracking, it would make sense to indicate whether you actually met the person (key exchange took place - yes / no) -> Useful to determine whether distances have been observed if this isn't clearly known. Many organizers take one qr code for an entire building.

I fear this is technically impossible. AFAIK, If a user who checked in get's infected and warns his contact via CWA, their CWA uploads the Diagnosis Keys (DKs) (from BLE contact tracing) and also uploads the Event-IDs, together with the information when and for how long the user was checked in to an event. However, CWA is not able to connect these DKs and the Event-IDs, so CWA does not know which of the received BLE beacons belong to the person who is infected and you received a Check-In warning from.

---

Have a nice Sunday.

[markusmarkusz]

@Ein-Tim

"The calculation of the risk depends on whether and for how long a user's attendance overlaps with the attendance of a person who later tested positive for COVID-19. If the attendance overlaps by less than 10 minutes, users receive a warning for a low-risk encounter (green tile). If a user's attendance overlaps by 10 minutes or more with that of a person who later tested positive for COVID-19, users will receive a warning about an encounter with increased risk (red tile)."

In my opinion, this is far too imprecise to talk of an increased or a low risk. The high level of inaccuracy lowers the value of the information.

Another possible idea that just came into my mind would be that you could include the specification of the category in the risk analysis or possibly offer an option that you can weight the risk. In the retail trade with face masks and capacity limitations, the risk is definitely lower than, for example, in a pub. In this way, the information would definitely be made more helpful and recommendations for action could be concretized. (In the case of a corona case in a club, a PCR test would be much more important than if the case took place in retail.)

---

However, CWA is not able to connect these DKs and the Event-IDs, so CWA does not know which of the received BLE beacons belong to the person who is infected and you received a Check-In warning from.

The idea was not to connect the DKs (from BLE tracing) and the Event-IDs, but to put them in a common context. Afaik both informations contain timestamps.

So my idea would be basically: positive test -> DKs and Event-IDs are uploaded and processed by the clients of the contacts. DK timestamp and Event-ID timestamp have time overlaps -> Point out that the risk could be higher than if you had no contact.

---

The problem I see with the risk assessment is that the information about how high the risk could be is incomprehensible and clearly too imprecise. From this, not really effective recommendations for action can be derived and that is exactly what - in my opinion - leads to the statement I quoted at the beginning: "The Corona Warn App warns so often anyway, it doesn't matter."

A more precise risk assessment would make contact tracking with the CWA much more powerful and helpful, especially at a time when health authorities are no longer able to track contacts.

[Ein-Tim]

Another possible idea that just came into my mind would be that you could include the specification of the category in the risk analysis or possibly offer an option that you can weight the risk. In the retail trade with face masks and capacity limitations, the risk is definitely lower than, for example, in a pub. In this way, the information would definitely be made more helpful and recommendations for action could be concretized. (In the case of a corona case in a club, a PCR test would be much more important than if the case took place in retail.)

This is in general a frequently discussed thing, see

• 254

• 251

• 108

108 & #251 are talking about the special cases of health care workers, #254 was closed with a reference to #251, which is IHMO wrong, as #254 suggested to be able to tell the app whiter face makes were worn or not and #251 wants to get the exact time of an encounter. You could either comment in #254 or open a new issue.

---

So my idea would be basically: positive test -> DKs and Event-IDs are uploaded and processed by the clients of the contacts. DK timestamp and Event-ID timestamp have time overlaps -> Point out that the risk could be higher than if you had no contact.

Ah now, I understand what you mean! But also this is, sorry to say it, impossible, as the app does not get the timestamp of the encounter which was recorded via BLE (the underlying GAEN framework does only provide the day of the encounter to the app & not the time).

[Thomas1664]

Ah now, I understand what you mean! But also this is, sorry to say it, impossible, as the app does not get the timestamp of the encounter which was recorded via BLE (the underlying GAEN framework does only provide the day of the encounter to the app & not the time).

@Ein-Tim Is it at least possible to display how long the exposure took? Another improvement would be to show if several on its own un-risky contacts add up to a risky contact.

[Ein-Tim]

@Thomas1664

Another improvement would be to show if several on its own un-risky contacts add up to a risky contact.

This is shown in the contact journal.

Is it at least possible to display how long the exposure took?

I think this would be possible, but this would always be with an ±5 min. uncertainty.

[Thomas1664]

@Ein-Tim

I think this would be possible, but this would always be with an ±5 min. uncertainty.

I think it would be useful anyway. You could show the user something like "You had x risk contacts for a total duration of 10 - 20 [or 15 ±5] min"

[MikeMcC399]

I suggest background reading of the Solution Architecture document - section Mobile Applications which explains about exposure windows and the limitations of assigning matches. to one or several devices / persons:

"All exposure events are collected by the ENF internally and are split up into "Exposure Windows", which represent all instances where one other specific device (without known identity) has been detected within a 30 minute window. If an encounter lasted for more then 30 minutes, multiple exposure windows are derived. Those cannot be related to each other neither can it be determined in which order (and possible overlap), exposures windows have occurred. This means that if for example five exposure windows are presented to the app by the ENF, it cannot be determined whether those have been five different devices or a single other device with 2.5 hours of contact. Same applies to the timely arrangement, i.e. all windows could have happened in parallel, with partial overlap or after one another."