corona-warn-app / cwa-wishlist

Central repository to collect community feature requests and improvements. The CWA development ends on May 31, 2023. You still can warn other users until April 30, 2023. More information:
https://coronawarn.app/en/faq/#ramp_down
Apache License 2.0
105 stars 14 forks source link

Discussion about the app's efficiency | Diskussion über die Effizienz der App #150

Closed Tho-Mat closed 2 years ago

Tho-Mat commented 4 years ago

Zahlen:

  1. ca. 20% der Bevölkerung haben sich die App heruntergeladen. (16 Mil/80 Mil)
  2. ca. 3-5% der Infizierten übermitteln dies aktuell mit der App. (281/6012)
  3. ca. 20% der angefragten TANs werden nicht genutzt. (800/1050)
  4. an ca. 2-3 Tage der maximalen Anzahl von 13 Tagen war die Risiko Ermittlung bei den Infizierten nicht aktiv. (ca. 20%)

Nimmt man alles zusammen ergibt sich, dass von 30.000 Infizierten statt 390.000 Schlüssel nur ca. 11.000 übermittelt wurden.

Damit liegt die aktuelle Nutzung der App bei ca. 2,8%.

Ich finde das sehr traurig und frage mich wo die Ursachen liegen und wie man dies ändern kann.

image


P.S. Da es nichts mit dem Code der CWA App zu tun hat, habe ich hier in Deutsch geschrieben.


Internal Tracking ID: EXPOSUREAPP-4916

ndegendogo commented 3 years ago

So I think meaningful numbers to track "app performance" and acceptance could be:

alanrick commented 3 years ago

I'm specifically sceptical about the Lauterbach/Söder claim that only 60% of CWA users testing positive agree to their results being fed into the app (QRcode/TAN). I suspect that the missing 40% of positives from CWA users not being propagated are due to either (a) the 10C/OEGD field 9 not being filled in correctly by doctors or (b) to a lesser extent, labs not being connected.

If my assumption is correct, a code change in the CWA to remove the final approval from the user won't change the situation significantly. I.e. The process is broken, not the app. Consequently app improvements should concentrate on features that encourage more downloads/usage.

At the very least it would be useful to know what percentage of scanned qr-code results aren't being returned to the CWA user through the app.

alanrick commented 3 years ago

Recently spoke to a doctor who'd tested themself and scanned the code into the CWA but forgot to tell the assistant to tick the box on the OEGD form. This check-box is unnecessary bureaucracy that truly messes up the process for handling positive results and reduces the efficiency of the app without any benefit whatsoever.

MikeMcC399 commented 3 years ago

@alanrick

I'm not sure that everyone would agree with you that the checkbox is unnecessary, but read the text and judge for yourself! OEGD form 10C

I do sympathize with doctors and their assistants though who I am sure spend a lot of their time in general on bureaucracy and handling the health system.

alanrick commented 3 years ago

I had indeed, @MikeMcC399 . That text could be displayed and consented to in the CWA by the patient when the patient scans the QRcode. For a start that's more trustworthy than someone else ticking the box later. When the lab inserts the result into a server it would be deleted immediately without storing if the test-ID is not reconciled with the patient's consent.

daimpi commented 3 years ago

WiWo has a new article (German) on a recent Civey survey regarding CWA. One of the main reason why ppl don't install the app: they're not convinced that it has an effect.

Article also talks about some suggested enhancements wrt more info on encounters (cf. #178, #100, https://github.com/corona-warn-app/cwa-wishlist/issues/205) and some gamification aspects. Interesting read 🙂.

alanrick commented 3 years ago

I listened to this weekend's SAP/Telekom CWA podcast and the press spokesperson for Telekom confirmed that:

  1. they recognize there is an issue with low (60%) positive reporting, and
  2. although less than 10% of the test-labs are not connected to the CWA server,
  3. their call-center is currently overloaded with TAN enquiries.

In addition, the spokesperson confirms Telekom's misunderstanding about 10C/OEGD form. The spokesperson believes it is the patient that ticks the all-important "yes-I-really-want-my-results-to-go-to-the-app" checkbox whereas in many doctor surgeries this is done at a later time, often by backoffice health staff who have had no communication with the patient and must err in the direction of GDPR caution. I.e the checkbox is not ticked. The results don't go back to the patient in the CWA app.

This implies that the process is indeed broken. My interpretation: Many CWA users are willing to feed their positive results into the app but are having to resort to the overloaded TAN/Hotline workaround because the result is not being fed by the lab back into the app server, despite 90% of the labs being connected.

@MikeMcC399 I'm not trying to put the spotlight on you, but you did take the time to respond (I'm grateful) and you did suggest that you are in contact with people believing the 10C/OEGD form must offer this checkbox. Did my answer to your question make sense and might those at RKI be swayed into agreeing that the checkbox is redundant and could be bypassed (without changing the form) if the underlying software was improved to include a reconciliation mechanism?

MikeMcC399 commented 3 years ago

@alanrick Let me play this back to you and say I'm grateful for your link to the Telekom / SAP podcasts which I was not actively following!

I agree that Nicole Schmidt, Pressesprecherin #Telekom suggested that patients should remember to agree to their data being shared in Corona Warn App Podcast #9 at around 07:40 (the general discussion starts at 05:40). The form isn't filled out by patients though! I found the process description on https://www.kbv.de/media/sp/KBV-Vorgaben_RVO_Pflichten_Leistungserbringer.pdf from Kassenärztliche Bundesvereinigung, so if this is going wrong then the Kassenärztliche Bundesvereinigung should be following up and ensuring that those who are filling out the forms are doing it as intended.

There is another issue I found at https://github.com/corona-warn-app/cwa-app-android/pull/1514 about incorrectly coded QR forms. I don't know how many of these are in circulation though and therefore how big a problem this could be.

I'm afraid I have to disappoint you if you think that I have any special contacts or influence here. I'm just an active community member!

alanrick commented 3 years ago

@MikeMcC399

The form isn't filled out by patients though! I found the process description ...

Exactly! And reading the process description it's clear its primary focus is the steps necessary for the surgery to receive payment, not the quality of the information in the form.

So I remain of the opinion that it is a broken process, that could theoretically be diligently followed, but in practice won't. Removing or ignoring the check-box and instead adding an automatic reconciliation mechanism (standard procedure in accounting since the '90's) would repair the process.

I'm not disappointed in your community engagement, just grateful for your input both to the forum and also to the app itself.

ndegendogo commented 3 years ago

although less than 10% of the test-labs are not connected to the CWA server

... and maybe this number is by far too optimistic ...

https://www.tagesschau.de/inland/corona-warn-app-labore-101.html

coder66 commented 3 years ago

Warum nicht die Nutzer für die Übermittlung der Testergebnisse belohnen? Nach Eintragung eines positiven Ergebnises könnte ein Amazon, hello fresh, edeka, rewe, lieferando Gutschein generiert werden. So könnte die Charantäne sogar noch angenehmer ausgehalten werden. Sozusagen eine Win-Win Situation für alle Seiten.

Genau, am besten mit Payback, Deutschlandcard Punkte 🤣🤣🤣😂😂😂🙈🙈🙈🙈🙈🙈

ndegendogo commented 3 years ago

@coder66 🤪🤪oder einen Gratis-Test fürs nächste Mal Motto: pay two - take three 😷😷😷😷😷

Blackjacx commented 3 years ago

Hey, I read through the issues in the wishlist and actually there are many items that target an increase in app usage: gamification, geofencing zones to prevent tracking in certain areas, etc.

I think time will show results after these features are implemented :-)

daimpi commented 3 years ago

Results for wave 4 of the survey mentioned above have been released: https://ai_society.mpib.dev/tracking-app/wave4.html

Twitter thread: https://twitter.com/AnaSKozyreva/status/1327213257422155779

One question is particularly about the reasons for why people decide not to share their diagnosis keys (DKs) in CWA after testing positive:

Privacy concerns and feelings of shame (e.g., because one fears that they were not careful enough) proved to be two leading potential reasons

(link)

alanrick commented 3 years ago

17 app current or not-yet-but-intend-to-eventually CWA users were tested positively. Of those, 14 did upload their results. It is not clear if the missing 3 don’t yet use the app or deliberately didn’t upload the result but that doesn’t tally with the missing ~40%.

The number of replies to this survey question is minuscule and statistically of very little relevance so conclusions can’t be drawn. But my money is still on the unnecessary 10C/OEGD checkbox as being the most significant contribution to the poor CWA performance discussed in this thread.

askozyreva commented 3 years ago

@alanrick here is absolutely right. That is why we do not report reasons for not uploading test results from these 3 respondents - such a small N can't be reliable. The results that @daimpi quoted is from a different question (which was posed to the whole sample, N=1188), namely: "In your opinion, what could be the reasons why people decide not to share their positive COVID-19 test result via the Corona-Warn-App?" (before asking we displayed relevant statistics from the RKI website). So, as we report, these are not the experience-based reasons for not uploading positive test results, but potential reasons that other people think might apply. Hope it clarifies it.

pitsch commented 3 years ago

if the sensitivity of a corona test is above 90%, the corona warning app will give a sensitivity of 30%. for the users, this correlation is anything but transparent in the risk assessment. (despite an extensive FAQ) it would make sense if the data were made available to the public independently and promptly, especially in relation to current incidence values. above all, the user agreement should not allow the "voluntary" data not to be transmitted despite a positive test result, so that the app can continue to be used. statistically speaking, this app is at best a digital placebo, relying on it is highly dangerous to health with the rate of false negatives and should be warned to entirely rely on for legal reasons alone.

there is an error in the system analysis, which is rather built in for ideological-libertarian reasons, that bypasses any interface to "health authorities", although the client is the federal government itself. the federal and municipal organized network of about 400 health authorities have no interface to the app infrastructure, despite the obligation to register a positive test, (there is no validation process based on the root of trust at the local health authority). this task is transferred to the overburdened medical practices with an error-prone QR code system and a test.lab infrastructure, which is also developed to route around the DEMIS backend system, and has not been integrated in any publicly visible API, despite the recommendation of the RKI and the legal situation. The system analysis of the data flows, whose design error was taken over by DB3T, is disregarded in the public debate about data protection and decentralization, while the data sovereignty of the individual health authorities is tacitly replaced by a centralized backend.

as a practical suggestion to not make the CWA a Pyrrhic victory for the 'community' of digital civil society activists, it would be important to identify the problem and then find ways how to fork or update the app. a simple graph which measures the app performance in relation to incidence numbers and tests of the general population.

(translation with the help of deepl)


wenn die spezifizität eines corona tests bei ueber 90% liegt, so liegt er bei der corona warn app also bei 2-4%. fuer die nutzerinnen ist dieser zusammenhang bei der risikobewertung alles andere als transparent. (trotz umfangreichem FAQ) es waere sinnvoll wenn diese daten unabhaengig und zeitnah oeffentlich verfuegbar gemacht werden gerade auch im verhaeltnis zu aktuellen inzidenzwerten. vor allem sollte die nutzervereinbarung es nicht erlauben dass trotz positivem testergebnis das "freiwillig" nicht uebermittelt wurde, die app weiterhin genutzt werden kann. statistisch gesehen ist diese app im allerbesten fall ein digitales placebo, sich darauf zu verlassen ist bei der rate an falsch negativen hochgradig gesundheitsgefaehrdend und sollte allein aus juristischen gruenden mit einer warnung versehen werden.

zugrunde liegt ein fehler in der systemanalyse der eher aus ideologisch-libertären gruenden eingebaut ist, das umgehen jeglicher schnittstellen zu "health authorities", obwohl der auftraggeber der bund selbst ist. die foederal und kommunal organisierten ca. 400 gesundheitsaemter haben trotz meldepflicht keinerlei schnittstelle zur app infrastruktur. (es gibt keinen Validierungsprozess, der auf dem 'root of trust' bei der lokalen Gesundheitsbehörde beruht) diese wird trotz der empfehlung des RKI und der gesetzeslage auf die ueberlasteten arztpraxen uebertragen mit einem fehlertraechtigen QR code system und einer test.lab infrastruktur die ebenfalls am DEMIS backend system vorbei entwickelt wird, und bisher auf keinerlei oeffenlich einsehbare weise API-technisch integriert wurde. die systemanalyse der datenfluesse, deren webfehler von DB3T uebernommen wurde wird in der oeffentlichen schein-debatte um datenschutz und dezentralisierung missachtet, waehrend die datenhoheit der einzelnen gesundheitsaemter stillschweigend durch ein zentralisiertes backend ersetzt wird.

als praktischer Vorschlag, die Coronawarnapp nicht zu einem Pyrrhussieg für die "Gemeinschaft" der Aktivisten der digitalen Zivilgesellschaft zu machen, wäre es wichtig, das Problem zu identifizieren und dann Wege zu finden, wie man die App forken oder aktualisieren kann: eine einfache Grafik, die die Leistung der App im Verhältnis zu Inzidenzzahlen und Tests der allgemeinen Bevölkerung misst.

sources: https://github.com/micb25/dka/blob/master/plots_de/plot_rki_cwa_cases.png https://twitter.com/rki_de/status/1283731663722340353

alanrick commented 3 years ago

@MikeMcC399 There's a new Spiegel Podcast out today that sings the praises of the independents and startups involved in the app development 👍👏👏👏

Anyone know why the efficiency appears to be decreasing constantly and steadily over the last 3 weeks? It's only gone down by ~20% but the lack of knowledge or interest in the trend is worrying. plot_rki_cwa_cases_7d20201125

cfritzsche commented 3 years ago

Maybe it is simply that the share of young people infected is dropping relative to the old people?

mrs1959 commented 3 years ago

My daughter (21) recovered from the virus 2 week ago. When the health institute called her, noone was asking about informing others via the app, noone was even asking whether she installed the app. She didnt receive a QR code as her doctor (Hausarzt) only called her by phone that her test was positive. I told her to call the hotline for getting a TAN - she was not aware of this hotline - but thats how she feeded the app.

Guess? How many would follow this complex, process path?

How much easier would it be if we enrich the process (not the technology!) by the doctors, the health care institutes (Gesundheitsamt) etc, if they would only ask about adding the result to the app and informing others that way? And for sure the process is voluntarily still.

MikeMcC399 commented 3 years ago

@cfritzsche

Maybe it is simply that the share of young people infected is dropping relative to the old people?

I'm not sure it's that clear. See Figure 2 on page 4 of: https://www.rki.de/DE/Content/InfAZ/N/Neuartiges_Coronavirus/Situationsberichte/Nov_2020/2020-11-24-en.pdf?__blob=publicationFile

alanrick commented 3 years ago

You mean "Demographic distribution of cases" in the Tuesday reports? And you're assuming older people don't use the app? But I'd assume the non-app users are the over-90 category (and even those I know personally in that category do use a Corona app ) so IMHO plausible, but I'm not convinced.

What's going to be interesting is to see if there's a kink upwards in a few days when the new reminder function kicks in. I'd wager a 6-pack 🍺 there won't - simply cos I'm a sucker for betting on predictions and predict the other factors (isolation-fatigue, OEGD/10C checkbox, lab-connections) are more significant😎

cfritzsche commented 3 years ago

Ok you are right. Relative increase is highest in 90+ but the young people also still increase.

Maybe it's also negative reporting around gaps in the app. I wish officials and physicians would be more positive about it and include it in their normal Workflows.

pitsch commented 3 years ago

The Number of potentially shareable positive results is directly dependent on the number of reported cumulative cases (today 1,006,394) of the population. (83,122,889) in relation to the number of the installed apps (23.2 Mio) Assuming a random selection*) of app users from the population, we should expect a ratio of about 3,582 which would lead to 280.889 sharable positive results.

The number given by RKI is 152.200 verified positive tests, which leaves quite a gap of 128.689 unreported positive test results. the percentage of shared results (83.314) would then be rather 29.66% of shared and 70,34% of non shared results.

Since the limited effiancy of QR codes and Teletans as well as various other factors, the number of shared diagnostic keys is just an internal measurement and does not represent what should be achievable representing positive PCR tests reported to health authorities and RKI, it is just what the system under whatever circumstances was able to output.

https://www.rki.de/DE/Content/InfAZ/N/Neuartiges_Coronavirus/WarnApp/Archiv_Kennzahlen/Kennzahlen_27112020.pdf?__blob=publicationFile

*) age distribution of infections is rather "in favor" of app users. age groups known to have less app usage are less infected. https://experience.arcgis.com/experience/478220a4c454480e823b17327b2bf1d4 https://en.wikipedia.org/wiki/File:Germany_population_pyramid_2019-12-31.png

while intensity of smart phone usage does not directly translate into the acceptance of this particular app in certain age groups, probably google play store knows more... https://www.statista.com/statistics/1133174/smartphone-users-by-age-germany/

pitsch commented 3 years ago

DEMIS centralizes the reporting data with ACL rules, which could contain data protection problems. CWA gets lousy with TeleTans and QR codes in order to route around the health authority following an air gap strategy. for the lack of efficiancy, doctors and health personal are not to be blamed, neither PR campaigns or the quality of lengthy FAQs. what is needed is a redesign of the backend dataflows, a compromise where the reported infection data stays with the municipal GAs (containerized SORMAS) and only anonymized extracts of it go to DEMIS for scientific use, as well as using cryptographic hashs to not reveal personal data to the app infrastrucutre side but only use it to verify diagnostic keys. single elements in the backend could be repurposed, like the verification server. the encapsulation of the health department is a counterproductive design decision, as well as making it optional to not produce false positives by default. besides the call centers store mobile phone numbers, are not authorized and trained as well as health authorities, and probably have to record phone calls. lab test data goes via a sidechannel directly to app users without getting synched with the recommendations of the doctor and the decisions of the health authorities and in general work is beeing done double and triple times because of the distrust in already stored personal health data of the positive tests based on the infektionsschutzgsetz. a better strategy would be to keep data sovereignity at the communal level and build an infrastructure which relies on due diligence in terms of providing performance data, chains of trust, a scarcity principle and positive network effects based on real world use value.

https://www.rki.de/DE/Content/Infekt/IfSG/DEMIS/DEMIS_node.html http://materials.dagstuhl.de/files/16/16353/16353.OlgaStreibel.Slides.pdf https://edoc.rki.de/bitstream/handle/176904/2007/20teFClzrKjE.pdf?sequence=1&isAllowed=y https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md

cfritzsche commented 3 years ago

That's all under the assumption that users would tolerate a communal centralization of data. Which is clearly a gamble. https://www.google.de/amp/s/amp.n-tv.de/panorama/Deutschland-bei-Corona-App-tief-gespalten-article22118613.html

And it doesn't need any software changes to make sure users get their QR code when tested and anyone interacting with positively tested individuals asks them to upload their results.

pitsch commented 3 years ago

the current architecture will split the app infrastructure for the verification of positive tests from DEMIS and actually leads to high error rates. the priority should be GDPR compliance and data scarcity. no question about that. but it doesnt need an architecture where positive tests dont come through, which is costly (call center etc.), and highly inefficiant because it starts with the wrong premises, that what is already happening in a lawful way, has to be ignored and cannot be trusted: the registration of positive test results at the local, communcal health authority. all it needs is a verification process which is seamless and fully GDPR compliant. there are known cryptographic and well documented mechanisms for such use cases, similar to OAUTH or OpenID.

there is nothing wrong with the BLE meshwork architecture of the "exposure notification" framework, only in terms of trustfulness that it is not open source and cloud servers are run by apple/google in an intransparent way.

it comes down to trust, if you do not trust the health infrastructure, you're likely in the camp of corona deniers anyway, and therefore evade the law, avoiding registration of infections, as well as vaccinations. the corona warn app actually trusts google/apple more than the state institutions, which basically pay for it.

what is needed is a functional and audited "identity firewall" between the app infrastructure and the registration infrastructure, but diagnostic certificates should be verified against the existing lawfully registered cases, instead of building a inefficiant "air gap" infrastructure leading to an extremely high rate of false negatives (and extra work for labs, doctors and users) which defeats the purpose of the risk assessment if you properly analyse the data.

there is little public critical attention for the DEMIS backend, which most probably will be still officially released during this pandemic, some of its design principles could be already implemented by coronawarnapp instead of errecting a competing workflow and infrastructure which is not fully legitimized merely by data protection since there are alternatives with similar results in terms of trustfulness and privacy.

the communal "federation" of registered positive tests at your local health authority is defined by law already, if you go to a doctor for a test, he is obliged and payed to do the registration process for you (while labs should only get anonymized samples to begin with) the simple idea is that no positive test goes unregistered for the reason of epidemic overview. https://www.rki.de/DE/Content/Infekt/IfSG/ifsg_node.html

QR codes and Teletans are only needed for the verification if there would be no trustful and privacy preserving API access to verify a result against the already registered test data. if the coronawarnapp would speed up registration (repurpose lab servers) the RKI would be able to report earlier and with less artifacts. there are only two possible roadmaps, merge with DEMIS development and rapidly implement some rudimentary elements of it, or establish a counter infrastructure leading to more feature creep, more FAQs, increased workload for health personel and users with a resulting error rate of false negatives which defeats the purpose of reliable risk assessment.

ndegendogo commented 3 years ago

And it doesn't need any software changes to make sure users get their QR code when tested

@cfritzsche Not everybody has a QR code. I got none. I live in Bavaria, we have local test centers with self-registration for the test (at least that was the procedure last month, not sure if this has changed meanwhile). Got my result via email within 14 hours. Fast and easy. Only not integrated with the cwa infrastructure.

heinezen commented 3 years ago

Hello everyone,

I've changed the title of this issue so that it is easier to find via the search. There is also an english version of the title now. I don't know if we should keep the percentage value in the title, so I removed it for now. Let us know what you think aboout the change.

Regards, CH


Corona-Warn-App Open Source Team

MikeMcC399 commented 3 years ago

@heinezen

Let us know what you think aboout the change.

Good idea to change the title to make it more generalized. Perhaps you could correct the spelling of Dicussion => Discussion?

alanrick commented 3 years ago

10 days have passed since 1.7 was released. The RKI had declared the goal of improving the positive reporting with a reminder feature. This improvement should be visible almost immediately since it only depends on how quickly users update the app and we can assume a significant number updating in the first 2 days.

The RKI shows a reporting ratio deterioration since then of 1% (from 55% to 54% ). However, Michael's dashboard does indeed show that the downward trend has been blunted, even though is nowhere near an improvement over what the value was a few weeks ago..

It is high time the roadmap was made transparent so that efficiency improvement is significant, or at the very least previous roadmap decisions can be understood and confidence isn't lost. 2020-12-06_12-40-24 2020-12-06_12-39-05

Caveats: The Android Release took a few days to reach the play store, but even for these users the trend should show already. I assumed about 30% of users update within 2 days of a release, helped by automatic updates. Research points this way, and a sanity-check with my friends confirms this.

alanrick commented 3 years ago

This Nature study is about incentivizing the CWA interesting. Many of the reluctant CWA users in the sample of 2000 were frequent venue visitors so I’d be keen to see a similar study to investigate the incentive of #338 (venue checkin) instead of cash.

https://rdcu.be/cehx8

stweil commented 3 years ago

Nach Erfahrungen in meinem persönlichen Umfeld (> 10 Corona-Tests) hat es bisher noch keiner geschafft, sein Testergebnis automatisch eintragen zu lassen.

Die beim Test mitgegebenen QR-Codes sind dafür schon deshalb unbrauchbar, weil sie keine individualisierte URL enthalten, sondern nur auf die Startseite eines Prüflabors verweisen, wo man manuell abfragen muss, ob schon ein Ergebnis vorliegt. Das ist ineffizient und kostet wertvolle Zeit, in der betroffene Dritte nicht gewarnt werden können.

Leider IT-technische Steinzeit.

MikeMcC399 commented 3 years ago

@stweil

Nach Erfahrungen in meinem persönlichen Umfeld (> 10 Corona-Tests) hat es bisher noch keiner geschafft, sein Testergebnis automatisch eintragen zu lassen.

Nach der Beschreibung zu beurteilen, war der ausgegebene QR-Code schlicht und einfach nicht für die Corona-Warn-App bestimmt.

Unter "Connectivity to laboratories / Transfer of QR code / QR code not working" https://github.com/corona-warn-app/cwa-documentation/issues/400 läuft eine Sammlung derartigen Probleme. Die E-Mailadresse corona-warn-app.opensource@sap.com wurde zusätzlich angeboten, um Feedback in konkreten Fällen geben zu können. Siehe auch https://www.coronawarn.app/en/faq/#qr_scan.

stweil commented 3 years ago

Nach der Beschreibung zu beurteilen, war der ausgegebene QR-Code schlicht und einfach nicht für die Corona-Warn-App bestimmt.

So ist es, und genau das finde ich sehr traurig bei einem großen bundesweit agierenden Labor wie Limbach Heidelberg, das darüber hinaus noch den Datenschutz sehr stiefmütterlich behandelt.

dsarkar commented 3 years ago

FYI https://www.nature.com/articles/s41467-020-20817-6.pdf

image

alanrick commented 3 years ago

Interesting. The Spanish App (RadarCovid) offers no significant capability over the CWA (GoogleApple API, EU Interconnectivity, statistics), so the results could be extrapolated to the CWA. Very rough estimate: RadarCovid last week propagated 5119 positive cases, compared with 65779 detected ~ 7.8%. While the CWA (according to Michael's Dashboard) is in the range10-15% -> perhaps even double the efficiency.

ndegendogo commented 3 years ago

Indeed, very interesting!

What comes into my mind when reading this:

ndegendogo commented 3 years ago

The effectiveness of a contact-tracing app like cwa relies also very much on the role and significance it is given by politics and public health care. I am aware that a red warning of cwa recommends that I self-isolate "if possible", and that I should be tested, and there is even a budget that covers such testing, so I don't have to pay for it.

BUT: when I got a red warning in late October, my company doctor followed the guidelines of RKI, and interviewed me (a) if I was aware of any specific risky situation I had encountered, and (b) if I showed any symptoms. I mentioned public transport, and you never know, although mostly we keep our distance and generally we are wearing masks. She then told me: of course I can get a test if I want. But without any symptoms she cannot report me sick. So it is now up to my employer if they allow me to self-quarantine in such a situation or if they insist that I should come in to work...

MikeMcC399 commented 3 years ago

There is a new survey announced on https://www.coronawarn.app/en/blog/2021-02-23-corona-warn-app-survey/ which is gathering data about users' motivation to use the app and to report infections, including questions about whether being rewarded has any influence on users' behavior.

The survey itself is on https://umfrage.uni-wuppertal.de/index.php/765823 and is in German.

annebeckmann commented 3 years ago

Die Effizienz der CoronaWarnApp (CWA) ist vom Prozess in den Testpraxen und dem dort unterstützenden Formularwesen abhängig und hier gibt es einen zentralen Mega-Bug, der dafür sorgt, dass die Einwilligung zur Datenübermittlung systematisch nicht erfasst wird. Hintergrund der Beobachtung: Wir sind als lokale Helferinitiative Nutzerbeschwerden nachgegangen, die behauptet haben, dass das Scannen des Barcodes zum Testabruf und Warnen der Kontakte nicht funktioniert habe. Unsere Ergebnisse stimmen mit der folgenden Statistik des RKI zur CWA (Stand 23.4.2021) überein: image

Zentrale Erkenntnis der Untersuchung: Der hohe Anteil von 38% NICHT geteilter positiver Testergebnisse hängt mit dem einem falsch aufgebauten Formular in Verbindung mit dem Test-Ablauf VOR den Arztpraxen zusammen: Konkret: Das Problem liegt im Aufbau des zweigeteilten Formulars 10c/OEGD der Kassenärztlichen Vereinigung. Die haben bei der Formularerstellung nicht berücksichtigt, dass der Patient wegen der Ansteckungsgefahr ja die Praxis nicht betreten kann und auf dem Formularteil, den er ausgehändigt bekommt, kann er sein Einverständnis nicht erklären:

image

Die Lösung wäre nicht schwer, wenn sich die Kassenärztliche Vereinigung bereiterklären würde das Formular zu überarbeiten, so dass man unterscheiden könnte, wann eine Einwilligung nicht abgefragt wurde oder wann sie verweigert wurde.

image

Ich vermute, dass es noch bessere Lösungen gibt, wenn sich jemand damit beschäftigen würde, der die internen Prozesse in der KBV und den Laboren besser kenn. Aber das ist der Kassenärztlichen Vereinigung zu aufwändig. Sie weiß von dem Problem und ignoriert es einfach. Die Antwort, die ich von der KBV bekommen habe ist, dass das Problem erkannt und bekannt sei, aber es nicht genug Platz auf dem Formular gäbe, um es zu ändern. (Kein Hörensagen, habe ich persönlich am Telefon als Antwort bekommen.)

Resultat: Jeden Tag können im Schnitt 1946 Nutzer der CoronaWarnApp mit posivem Ergebnis ihre Kontakte nicht warnen, obgleich sie GLAUBEN Ihr Einverständnis zum Übermitteln der Testergebnisse gegeben zu haben. Bei einem aktuellen R-Wert von 1 und einer Sterberate von 2,5% (Quelle RKI, 23.4.2021) bedeutet das jeden Tag weitere 48 Todesfälle, die auf die Weigerung einiger weniger Bürokraten bei der KBV zurückzuführen ist.

Ich habe persönlich schon seit Oktober 2020 den Vorstand Dr Gassen der KBV mehrfach direkt dazu angeschrieben. ohne je eine Antwort zu bekommen. Von einer Dame aus dem Fachreferat habe ich dann erfahren, dass das Problem bekannt, aber das Formularfeld zu klein sei und habe tatsächlich den ernstgemeinten Vorschlag bekommen, wir als kleine lokale Helferinitiative könnten doch bundesweit alle Mitarbeiter in allen impfenden Arztpraxen schulen, so dass die trotz des kontra-intuitiven Formulars nicht vergessen den Patienten um seine Einwilligung zu bitten.

Im Dezember 2020 haben die übrigens das Formular (wegen anderer Belange) geändert, aber die notwendigen Änderungen für die CoronaWarnApp NICHT gemacht.

Also die Verantwortlichen oben in der Hirarchie muss man wohl erst auf vielfachen Mord verklagen, bevor die was machen, aber hat vielleicht einer von Euch kontakt zu den Orga-Abteilungen oder Projektgruppen selber und kann das weiterleiten?

alanrick commented 3 years ago

@annebeckmann (deutsch unten)

I agree, and I was thinking of reopening the discussion in view of the expansion of the App to cover rapid tests as well. Your experience confirms my suspicions.

Basically, the problem is that the lab technician, who is remote, needs the patient’s permission in order to enter the results. Would splitting the OEGD/10C checkbox into 2 fields help? If not another solution is needed, such as transmitting the permission from the App to the Test Result Server.


@annebeckmann Dem stimme ich zu, und ich habe mir überlegt, die Diskussion angesichts der Erweiterung der App auch auf Schnelltests neu zu eröffnen. Ihre Erfahrung bestätigt meinen Verdacht.

Grundsätzlich ist das Problem, dass das entfernte Labor die Erlaubnis des Patienten benötigt, um die Ergebnisse einzugeben. Würde eine Aufteilung der OEGD/10C Checkbox in 2 Felder helfen? Wenn nicht, ist eine andere Lösung erforderlich, wie z. B. das Übertragen der Berechtigung von der App an den Testergebnis-Server.

ndegendogo commented 3 years ago

@annebeckmann kannst du bitte dein Feedback und Verbesserungs-Vorschläge auf corona-warn-app/cwa-documentation#400 posten, und/oder ein email an corona-warn-app.opensource@sap.com schicken? Siehe auch meinen Kommentar hier

ndegendogo commented 3 years ago

Wir sind als lokale Helferinitiative Nutzerbeschwerden nachgegangen, die behauptet haben, dass das Scannen des Barcodes zum Testabruf und Warnen der Kontakte nicht funktioniert habe. Unsere Ergebnisse stimmen mit der folgenden Statistik des RKI zur CWA (Stand 23.4.2021) überein

@annebeckmann Eure Initiative ist super, und euer Ergebnis ist hochinteressant!

Ein-Tim commented 3 years ago

@annebeckmann

Zentrale Erkenntnis der Untersuchung: Der hohe Anteil von 38% NICHT geteilter positiver Testergebnisse hängt mit dem einem falsch aufgebauten Formular in Verbindung mit dem Test-Ablauf VOR den Arztpraxen zusammen: Konkret: Das Problem liegt im Aufbau des zweigeteilten Formulars 10c/OEGD der Kassenärztlichen Vereinigung.

Die 38% der Testergebnisse die nicht geteilt werden sind schon in der App angekommen, das Feld auf dem Formular 10c/OEGD war also angekreuzt. Der Nutzer entscheidet sich aktiv gegen das Teilen, technisch wäre es möglich. Siehe auch @heinezen's Kommentar hier.

annebeckmann commented 3 years ago

@annebeckmann kannst du bitte dein Feedback und Verbesserungs-Vorschläge auf corona-warn-app/cwa-documentation#400 posten, und/oder ein email an corona-warn-app.opensource@sap.com schicken? Siehe auch meinen Kommentar hier

Das mache ich gerne. In welcher Sprache sollte ich das schreiben? Deutsch oder Englisch? Ich sehe beide Sprachen im Thread und hab noch nicht raus, wann Ihr in welcher Sprache schreibt. Meinetwegen muss keiner Deutsch schreiben. Ich bin zwar Deutsche, aber ich spreche auch einigermaßen flüssig Englisch. Oder poste ich es in beiden Sprachen?

Ein-Tim commented 3 years ago

You can write the Mail in German, here on GitHub we try to stay in English. But sometimes issues are opened in German so we also answer in German. The production repositories, like the iOS/Android app & server repository are completely in English so that also non-German speakers can participate, report bugs, etc. (-:

alanrick commented 3 years ago

Not directly related, but worth noting... @Ein-Tim and @MikeMcC399 pointed out in another thread that from Release 1.9 users can approve result-broadcasting before receiving the results. Based on the RKI statistics, I calculated the approval ratio in the week before the 1.9 release (mid December), and the approval ratio for the current week and it has jumped from 52.5 to 64.8%. A significant 10% increase. That was a good feature .🙏

alanrick commented 3 years ago

Here's what I don't understand, even though I have always suspected that the OEGD/10C-handling undermines the efficiency of the app...

According to the RKI statistics, the app was downloaded about 27 millions times. So I estimate about 20 million active users exist, since some downloads are repeats for newly purchased devices and some users have deinstalled (protest/vaccinated....are the most common reasons I've heard). So about 25% of the over-16 German population use the app.

@micb25 dashboard shows that about 17% of all positive results are broadcast. But that would imply that 25% (17/0,648) of all results are received on the app - matching the 25% using the app. (In fact, since nowadays many of the positive tests are from those under 16 years old, who don't use the app, that implies an even higher success rate for the app. In other words, the app is already at statistically higher than maximum efficiency.)

If that's true, an increase can only be achieved by encouraging more propagation (which is why I'm in favor of legal changes to allow CWA venue-checkins), or encouraging those positively tested to broadcast the results. The OEGD/10c efficiency loss is negligible.

Are my assumptions correct, or where have I gone wrong?

PosTestBroadcasting
ndegendogo commented 3 years ago

encouraging those positively tested to broadcast the results

actually I think this is the number to be improved. I cannot believe that the still high fraction of people that don't broadcast their keys all have decided that they don't want. Included here is the sum of all obstacles in the process that makes it hard or even blocks people. So priority should be to continue to analyse and remove obstacles and blockers in this central cwa use case

encouraging more propagation

Although the pure number of cwa installations will increase with more nice and useful features, I am afraid that a person who installed it to use a venue checkin feature will not in all cases automatically share her keys. I think most people who believe in the core idea of cwa (sharing keys and warn others) can install it now, independant of "secondary features".

And I attribute the rise in efficiency since January mainly to the demography of the infected. The very old people (with little usage of smartphones) are meanwhile vaccinated.

But, all this is "pure gut feeling" on my sude. I don't have any hard numbers.