Optimize and extend the Corona infection calculation algorithm

[di-sc]

Current Implementation

The current implementation is based on https://github.com/corona-warn-app/cwa-documentation/blob/master/cwa-risk-assessment.md and from my understanding if there is a contact of A - B and A is infected, makes a test and puts the result into the CWA, than B is notified about this infection the next time he/she requests the infection data from the server.

Suggested Enhancement

The problem with the implemenation above is that in most cases the notification of B would be too late to stop the virus from spreading. With an infection time of 5-6 days B may have more contacts to C, C', C'', ... and also C may have contacts to D, D', D'', ... before A detects that he/shie is infected, makes a test, and puts the data into the CWA. The CWA is always running behind the virus. To have an advantage above the virus the CWA should be changed in a way that it also informs C and may be D (both with lower probability) about the infection of A (and perhaps B). The CWA could suggest C and D to make a test, which is of little effort because test centers are now everywhere available.

Implementation details

Only what I was thinking about was that this enhancement could be implemented by calculating a probaility value for every contact in the case one of the parties gets infected. Having this probability and while initiating a server request these probabilities could be used to calculate the own probability and if it is above a specified level make a suggestion to the user to make a test. Simple ;-)

Expected Benefits

If it works as expected it should be possible to get control over the virus completly, because we are always near by the virus infections and not running days behind. There is one drawback that the installed base of the CWA is not high enough to follow all path of the virus but anyway I would take that risk.

Prospect

For later optimization I suggest to add also other calculations of the user into the CWA, e.g. having many contacts increases the risk also without infections, living in areas with high rates of infections, etc.

[MikeMcC399]

@di-sc

There is a detailed discussion in "Epic 4: Missing User Story to optionally notify secondary contacts" #24.

It was also raised in #221.

Edit:
#24 was renamed from "Epic 4: Missing User Story to optionally notify secondary contacts" to "Optionally notify secondary contacts"

[di-sc]

Hi @MikeMcC399

thank you for your answer.

Sorry, but when searching the list of issues I didn't find these both topics.

Anyway I would like to keep this issue because it puts another light on this topic. The CWA is a great tool and the developers did a fantastic job to create this application but the feeling of the people (and also the politicians) is the CWA does not help to get rid of the pandemic. It helps to inform people about contacts that have been infected as the Gesundheitsamt does but not more.
But the CWA can do more. The complete path of contacts is available (for all people that have installed the CWA) so it would be possible to make a complete contract tracing and all people in the path can be informed and asked to make a test for the complete time of the infectious time of up to 14 days (not only the second contact).
This would allow us to come to the virus as near as possible and follow it. Currently we are always days behind and in-between the virus can spread everywhere.
I think that this is the main feature that should be implemented to fight the pandemic or any pandemic!

I read #24 but did not understand everything but I agree with @cfritzsche that it should not be too complex to implement this feature. You can use the same mechanism for it as you do for normal positive test notifications. If currently only Ids of infected persons are stored on the server the server DB has to be extended to store also the IDs (and their probabilty) of contact persons of infected persons and contact persons of contact persons of infected persons, etc. . These other persons can be notified in the same way and should make a Corona Test.

[Jo-Achim]

@di-sc, @MikeMcC399,

The problem with the implemenation above is that in most cases the notification of B would be too late to stop the virus from spreading. ...

In this context, I would like to refer to a study that underlines the need for quick information about potentially infected people and the health system.
Please refer: corona-warn-app/cwa-documentation#466 (comment).

Joachim.

[Ein-Tim]

Disclaimer:
I'm neither a community manager nor a developer.

Definitely a great proposal @di-sc, but could you please further evaluate why this issue can't/shouldn't be merged with #24?

[di-sc]

@Ein-Tim

could you please further evaluate why this issue can't/shouldn't be merged with #24?

I am new to this repository, so I don't know what the best place is to put this issue to. If it helps that this issue will be realized then it's okay to merge it to #24 but the last entry of #24 is from October 2020. That is before the second Corona wave in Germany! I have doubts that this item got and will get the attention that it deserves.

[Ein-Tim]

@di-sc

No problem, we normally try to not get issues about the same topic multithreaded, since it's harder to keep track what has already been said and what not, etc.
#221, which requested the same as #24, was also closed back then.

But we have multiple issues which request the same (see for example #288, #206, #266).
I would say let's wait what the community managers say.

Reg. the attention part, I agree that there is no visible development reg. this, but I don't think that the problem is that there's no attention, but that this seems to be technically not feasible (correct me if I get something wrong here) with the currently used Exposure Notification Framework, provided by Google/Apple. To implement this, contacts from infected people would also have to upload their keys (=marked as infected).
Now the question would be:
How can we identify the truly positive keys (which were uploaded after a positive test result was entered into the app), which should get a higher priority the the secondary keys (which were uploaded after someone received a red warning).
AFAIK, it is not possible to distinguish between uploaded keys in any form, the risk assessment happens locally on the device.

Some sources:

• https://github.com/corona-warn-app/cwa-documentation/blob/master/cwa-risk-assessment.md#procedure (please note: some parts are outdated)
• https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md (some parts are outdated here too)

[di-sc]

@Ein-Tim
Okay, I understand (or please correct me if I am wrong). It was not clear to me that also handling the keys is done by Google/Apple. I take back my statement that this is "simple".
But it is technically feasible, I would say. All connection data that are needed are available. Only missing is to send a parameter, like a probability together with the diagnostic key, right? And this has to be implemented by Google/Apple.

(But is it really still needed to distinguish the "truly positive keys" from "seconday keys"? In the end all people notified will be sent to the test center to make a test. Only thinking.)

Beside that, I saw that there exists a fork of the CWA on f-droid that doesn't depend on the Google/Apple library. May be joining both projects would be a solution.

That's very disappointing.

I will then close this issue during the next days.

[Ein-Tim]

@di-sc

No, you don't have to close this issue, I think it's a really great proposal!

Also, after having a second thought, it will somehow be possible to distinguish between people you met and places you visited (I'm talking about the event registration feature, which is planned for version 2.0).

So besides that this is closely related to #24, I would leave it open.

Have a nice Friday everyone!

[di-sc]

@Ein-Tim
Sounds good but I don't see if this could help here. If I understand event registration feature correctly it is about detecting clusters, meaning instead of a A - B infection you may have A - B, B', B'', B''' ... . But still if A is infected and notifies the next level only B, B', B'' will be notified. It is the same thing what the CWA already does, it is only much more worse because all B, B', B'' can infect C, C', C'', etc. before A registers his infection. The challenge is to erase the complete branches A-B,B',B''-C,C',C''-D,D',D''-E, etc. to stop the virus from spreading.
Am I missing something?

[Ein-Tim]

@di-sc

Yeah, you're right, sorry.

Maybe someone could first clarify wether this is technically feasible with the current implementation and then we can decide wether to merge with #24 or not.

[di-sc]

... or feasible under the current limitations.
In #24 it has been discussed to save ids into a central database, which is not allowed by the restrictions of "Datenschutz". But may be for notifying secondary contacts it is a bit more weaker because you won't blame anyone to have been in contact with an infected person it is only to notify him/her about a higher risk and suggest to make a test. This may be allowed under the restrictions of "Datenschutz", but I don't know!?
Also tracking Ids with a faked phone or sending notification may be of acceptable risk in the current situation where the next step in the pandemic would be to make always a test before meeting people anyway. In that case we would send people to the test center which we normally wouldn't. No one is blamed.
I would prefer to communicate more positive, which options exist to make this feature technically feasible instead of saying generally that it is not feasible at all.

[cfritzsche]

#24 does not require a central database. It just involves a second kind of risk calculation, based on uploaded keys with a different marking, e.g. UNTESTED_CONTACT, and a way to upload them. The rest of the framework could work as before, apps of warned users would tell them the contact was not tested yet but his contact was.

See more details here: #24 (comment)

[heinezen]

Hey @di-sc,

Thank you for your submission However, as others pointed out, this request is already discussed in #24. We will therefore close your issue as a duplicate (for reasons see the section below).

Also as a general reminder (for everyone) regarding this statement:

I am new to this repository, so I don't know what the best place is to put this issue to. If it helps that this issue will be realized then it's okay to merge it to #24 but the last entry of #24 is from October 2020. That is before the second Corona wave in Germany! I have doubts that this item got and will get the attention that it deserves.

Please keep in mind that we use Github mainly as a bug/issue tracker, not as a newsfeed. Spreading a discussion out over multiple threads makes it much harder for us (i.e. the community team and the devs) to follow, figure out what the users want or see how popular a request really is. If the discussions are very similar, arguments/questions also tend to get repeated a lot which leads to some discussions going in circles. Overall, this might result in the core ideas in some wishlist items getting less attention because the discussion is hard to follow.

So even though the issue thread in here already has a lot of comments, we will close it in favour of #24 because this thread does not add new arguments and #24 already has links to scientific papers which explore implementation ideas. Of course, everyone should be still encouraged to voice their support for the feature request in #24 by writing a comment or giving it a thumbs up/heart emoji.

---

Corona-Warn-App Open Source Team

[heinezen]

Duplicate of #24

[heinezen]

@Ein-Tim

Reg. the attention part, I agree that there is no visible development reg. this, but I don't think that the problem is that there's no attention, but that this seems to be technically not feasible (correct me if I get something wrong here) with the currently used Exposure Notification Framework, provided by Google/Apple. To implement this, contacts from infected people would also have to upload their keys (=marked as infected).

Exposure keys can be extracted regardless of risk status (with consent of the user). The ENF does not even know about the risk status, only the app does.

[Ein-Tim]

@heinezen

Yes, sure. But would it be possible for the app/ENF to distinguish between direct contacts and secondary contacts in any form?
Or rephrased question:
Can TEKs be marked:

POSITIVE_TESTED
and
SECONDARY_CONTACT

so that the app which downloads the keys knows wether this is a key from a confirmed positive tested person or only from a secondary contact?

I hope you know what I mean.

[heinezen]

@Ein-Tim The app could attach any additional metadata to the uploaded keys which could be stored by the server. So in general: Yes, something like this is technically possible.

---

Corona-Warn-App Open Source Team

[Ein-Tim]

Thanks @heinezen 👍