In-App Approval to Receive the Corona Test Result in the CWA App

alanrick commented 3 years ago

Current Implementation

Before taking a test, the patient can use the CWA to scan the test’s qr-code in order to receive the test results directly in the App. However, in order for the lab-technician to enter the result of the test in the CWA infrastructure so that it can be retrieved by the patient’s CWA app the technician must verify that the patient has given permission to add the results to the CWA infrastructure..

Currently, the lab technician verifies the permission by inspecting the OEGD/10C form that accompanies the test, either electronically or as a paper document. This form contains a check-box that confirms that the patient has been properly educated and agrees to their test-result being fed into the CWA infrastructure.

This field is completed by the doctor’s surgery, not the patient. And because the CWA is not the primary focus of the OEGD/10C form (billing and permission to perform the test), this flag may be overlooked.

There is anecdotal evidence (and here and a lab's comments elsewhere ) that the checkbox is overlooked, so the patient receives the result with a delay because they are not relayed back through the CWA infrastructure, but relayed instead through a telephone call or a letter in the post.

Suggested Enhancement

Avoid the OEGD/10C "paper-trail" by transporting the patient’s permission from the CWA app on their mobile phone, to the Test Validation Server directly, where it can be queried by the lab technician (either in batch or through a user-interface). The API that performs this query would not need to know the patient’s personal (e.g. name) or medical details. The API simply queries the test ID and whether that patient has given permission to receive test results in the App. When no such permission exists (either the record does not exist, or the permission is negative), the test results are not fed into the Test Validation Server.

As well as enabling this additional approval-message in the server infrastructure, the UI to the CWA mobile App would also need to be coded. And it must be ensured that the permission data arrives in the Test Validation Server before the test-result.

I believe the approval data element containing the permission only needs to contain the test ID (or a hashed version?), but it would help if this also included a datestamp, for garbage collection of permissions or expiration of approval.

This new approval channel is offered in addition to the first channel. I.e. if OEGD/10C is not checked (paper or otherwise), then query the existence of the permission in the Test Validation Server. If that doesn't exist either, then do not upload the result.

As in the original process, there is no provision for retracting permission for the lab to upload the result to the Test Validation Server. If approval is given by either channel, the lab uploads the test results (and the user still has the option to refuse broadcasting the result to other app users if they haven't given this permission already in the App).

This additional messaging simply increases the fault-tolerance of the result-return process, which is unique to the CWA and a considerable improvement over other Corona apps.

Expected Benefits

Reducing the number of cases where a user fails to receive the test-results in the CWA due to the OEGD/10C form being filled out without full diligence (which increases the efficiency of the app)
Faster broadcasting of the results to other CWA contacts if the additional enhancement above is also implemented.

Security

Due diligence for security. E.g. Avoiding the approval being modified while in the CWA infrastructure. Avoiding spoofing approvals.

Well - but this is a limitation. If I understand your proposal correctly, the consent is given by the user in the moment when she scans the QR code? What do you suggest to happen, if she scans her code late? Later than the lab result is ready to be fed into cwa server? Will there be a second attempt? Or will too late mean too late forever?

There are other process flows without the paperwork of the OEGD form. Many test centers have their own, fully digitized process.

Example: last week I took a PCR test at my local test center, with the following steps and timing:

about lunchtime, I self-registered via a website for the test. The registration form includes checkboxes that I want the QR code for cwa and that I consent to transmitting the result to the cwa server.
there was no long waiting line, so my sample was taken shortly after that
at the end of the working day they shipped the samples to the lab
it is part of the lab process to generate the QR code and send it to me via email
I received the QR code late in the evening. Unfortunately I had no printer and no second device at hand, but cwa wants to scan the code so I had to postpone the scanning
in the night the lab result was ready and uploaded to the server
only next morning I found time to organize a second device so I could now scan the QR code, and received my result immediately

alanrick commented 3 years ago

Many thanks @ndegendogo for the detailed flow. In your case, the API will not be invoked because the permission has already been received through the sequence you describe. The process I describe is in addition to the current process, not instead of it.

I.e. if OEGD/10C not checked (paper or otherwise), then query the existence of the permission in the Test Validation Server. If that doesn't exist either, then do not upload the result.

This additional messaging simply increases the fault-tolerance of the result-return process, which is unique to the CWA and a considerable improvement over other Corona apps.

ndegendogo commented 3 years ago

The process I describe is in addition to the current process, not instead of it.

Yes, this makes more sense now (maybe you could highlight this in your original description to avoid any misunderstanding?)

ndegendogo commented 3 years ago

... I am not an expert for data privacy (Datenschutz), but it has to be clarified if your proposal does not add any ambiguities that could be resolved differently to your intention.

Current process: consent is given by marking the checkbox on the IEGD form. One single path, no ambiguities. Everybody understands that there is no way to revoke such a consent after it is given.

New process (according to your proposal): Now there are two pathes to grant consent. What happens if they disagree? Of course you want either path be sufficient for granting consent. But maybe somebody very concerned about data privacy could suggest, that either path be sufficient to withdraw consent?

alanrick commented 3 years ago

The process I describe is in addition to the current process, not instead of it.

Yes, this makes more sense now (maybe you could highlight this in your original description to avoid any misunderstanding?)

Done. In addition, I made made it clear that this offers an alternative channel for approvals, improving reliability. As in the current (2.03) implementation the App does not offer the chance to retract approval once it has been given. I haven't seen a wishlist item requesting retraction capability so I believe that is a fair assumption.

Ein-Tim commented 3 years ago

As in the current (2.03) implementation the App does not offer the chance to retract approval once it has been given.

What do you mean? If you gave consent to warn others should the test result return positive, it's indeed possible to revoke the consent.

alanrick commented 3 years ago

You're right. But I meant retract permission for the lab to upload the test-result to the server. I'll clarify in the description. The permission to broadcast the result is a separate decision.

corona-warn-app / cwa-wishlist