Skip to content
This repository has been archived by the owner on May 16, 2023. It is now read-only.

Subtitle of Vaccination QR code is a little bit misleading #645

Closed
lgmIT opened this issue Jun 23, 2021 · 20 comments
Closed

Subtitle of Vaccination QR code is a little bit misleading #645

lgmIT opened this issue Jun 23, 2021 · 20 comments
Labels
documentation Improvements or additions to documentation Fix 2.6 Fix is planned for 2.6 mirrored-to-jira This item is also tracked internally in JIRA

Comments

@lgmIT
Copy link

lgmIT commented Jun 23, 2021

Hello,

since this behaviour is identical on Android and iOS devices (and also in all UI languages), I found no better place than to put it here. Hope that works for you!

The string vaccination_qrcode_card_subtitle might be misleading to the user: It shows the String certificate.vaccinatedAt (his last vaccination date) and correlates it - as far as I understand - with something different: certificate.expiresAt (the date the HCERT Signature Validity ends).

Some users instantly thought, the "valid to" date shown on the certificate shows how long you count as completely vaccinated according to federal law. I thought so too until I browsed the repositories (e.g. issues #627 and #615).

This might lead to confusion at a vaccination checkpoint, as the user might think, his vaccination status (not his HCERT Signature) is still valid. It might even be a realistic future scenario since I saw some vaccination certificates for a second dose in March 2021 (digitalised a few days ago in a pharmacy) which had a certificate validity end date of someday in June 2022. But their status as completely vaccinated should expire (at least according current German rules) already in March 2022.

If I understood this correctly, you might consider differentiating between two distinct sets of dates to the user:

  • The validity dates of the HCERT certificate (issuedAt and expiresAt)
  • The dates of vaccinations, vaccination protection timespans etc. within these certificates (vaccinatedAt, daysUntilImmunity, ...)

Here one of the example screens, that show the affected string:

Screenshot Second Health Certificate


Internal Tracking ID: EXPOSUREAPP-8092


Related to topic: Check signature of certificates
Internal Tracking ID: EXPOSUREAPP-8010

@dsarkar dsarkar added documentation Improvements or additions to documentation mirrored-to-jira This item is also tracked internally in JIRA labels Jun 24, 2021
@dsarkar
Copy link
Member

dsarkar commented Jun 24, 2021

@lgmIT
Thanks for contributing. I understand that you are suggesting implicitly to create a FAQ entry explaining this issue?


Corona-Warn-App Open Source Team

@MikeMcC399
Copy link
Contributor

@dsarkar

I understand that you are suggesting implicitly to create a FAQ entry explaining this issue?

That sounds like a good idea anyway.

  • What does the "valid to" date mean for a vaccination certificate? (EN)
  • Was bedeutet das Datum "gültig bis" beim Impfzertifikat? (DE)

@lgmIT
Copy link
Author

lgmIT commented Jun 24, 2021

@lgmIT
Thanks for contributing. I understand that you are suggesting implicitly to create a FAQ entry explaining this issue?

Corona-Warn-App Open Source Team

Hi @dsarkar!

I don't know if a FAQ entry is enough, but it is at least a start. But many people will not understand, that this "valid to" date has nothing to do with the vaccination status. I would even suggest to remove it completely in the app. The alternative app (CovPass) and the certificate printout from the pharmacies/vaccination centers also don't show this date anywhere. I think it's because this date is basically irrelevant to the user and he also can't do anything about it (like prolonge it) himself...

PS: You could maybe add a warning in the app if the last/current HCERT Signature Validity runs out soon, but in normal cases the user really don't need to care about the validity of the HCERT Signature.

@dsarkar
Copy link
Member

dsarkar commented Jun 24, 2021

@lgmIT Ok, thanks for the feedback. We will communicate your concerns and suggestions internally.


Corona-Warn-App Open Source Team

@vaubaehn
Copy link

@dsarkar
please also have a look at #627 (comment)
For me this is all connected, might need a general re-evaluation by stakeholders and changes accordingly.

@lgmIT
Copy link
Author

lgmIT commented Jun 24, 2021

@lgmIT Ok, thanks for the feedback. We will communicate your concerns and suggestions internally.

Corona-Warn-App Open Source Team

Thank you, @dsarkar

I know especially around the vaccination part of the app there are a lot of stakeholders (EU, Bundesgesundheitsministerium, CovPass/IBM/UBIRCH/RKI, other EU member countries and their health ministries...) and there might be lot of changes in the future, but please consider hiding the certificate validity date until there are more sophisticated algorithms to show more information to the user along (e.g. vaccination status business rules) and procedures to mitigate expiring signatures (renewing/prolonging an existing certificate) in place. Because the first real certificates will be invalid by June 2022, there is enough time to develop an easier to understand displaying of end dates until then...

@jkrwdf
Copy link

jkrwdf commented Jul 2, 2021

When the dates of vaccination and creation of the certificate differ as in the following example, the need for explaining the meaning of the "Valid to" becomes even more apparent.

image

@GisoSchroederSAP
Copy link

GisoSchroederSAP commented Jul 14, 2021

@ALL,
both dates will be removed from the first screen of the certificate. The vaccination date will still be displayed in the detailed section. The "valid to" date shown was the technical expiration date of the certificate, which is completely independent of the vaccination date and will be set bei the certificate issuer. In Germany, usually, those DCCs have a expiration date of one year after issuing the certificate.

As there is no such thing as "vaccination validity" (there is only a "period of protection" based on the current scientific evidence), the EU DCC does not carry a validity for the vaccination.
To cover this topic the app will be enhanced with the business rules that allow "inside validation" of the certificates. Obviously, our objective is to explain, what rule(s) is/are violated and lead to the invalidation of the certificate.

The "period of protection" becomes a (nationally-defined) business rule:

  • For Germany any complete vaccination defines a "valid period of protection" of one year after the most recent vaccination dose (after 14 pending days for the vaccination to become effective),
  • A recovered person without vaccination receives a recovery certificate, the ruled "valid period of protection" is 180 days.
  • A recovered person with vaccination receives a vaccination certificate, that becomes immediately effective, the defined "valid period of protection" is one year starting at the date of vaccination.

I'm not saying, it becomes easy to understand. And yes, there are other (not yet mentioned) scenarios with a timely mixture of vaccinated and recovered. The all can be explained, but this may become rather more confusing than helpful. We have a huge task of communication.

Hope that helps.

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Jul 14, 2021

The valid to date is already removed in version 2.5.

@GisoSchroederSAP
Copy link

Yes, this is correct and intended. Most of the users don't care about the technical expiration date (as long as it is not passed ;-) So, we decided to remove it from screen and handle the expiration internally. Once implemented, the screen will indicate when the certificate is expired.

@vaubaehn
Copy link

Hi @GisoSchroederSAP ,
I'd like to comment rather here than there, because the issue affects both CWA versions.

The all can be explained, but this may become rather more confusing than helpful. We have a huge task of communication.

You have my (and probably all our) full understanding.

Most of the users don't care about the technical expiration date (as long as it is not passed ;-) So, we decided to remove it from screen and handle the expiration internally. Once implemented, the screen will indicate when the certificate is expired.

If I understood the way forward correctly, after implementing business rules and validation check in 2.6, the certificate details still won't show any expiration date, but only the validation screen will do, when triggering a rule check.
I'm a bit concerned that many user might complain some months into the future, that they were "surprised" by a sudden validation failure of their certificate as nothing else before displayed anything, that the DCC has actually expiration date(s).
And what about users, that do not trigger the business rule validation because they are not travelling, but are "suddenly" rejected from entering a venue, because the gate keeper's verifier app signaled an expired DCC? In that case there was nothing pointing to an expiration date.
Finally (the hardest point to discuss), "several reports" indicate, that verifier apps are rarely used currently, and that even "border control staff" are looking into the wallet apps to check DCCs for face validity. Even I also do not support that approach, if we can't change the application in that case, then expiration dates could become necessary also for the details screen.

Like I wrote before, you have my full understanding that this is a difficult task. But if you like, we could find solutions together here on how to solve it in the best possible UX way. What do you think?

@GisoSchroederSAP
Copy link

GisoSchroederSAP commented Jul 14, 2021

Thanks for sharing your (and probably not only your's) concerns! This is wonderful support for our requests to the different parties regarding your valid points:

  • Nobody will be surprised (I hope), if we implement an early indication for both, that the certificate will expire in a few days/weeks, or that the vaccination protection terminates in a few days/weeks. The details about the when to "indicate in advance" are not finally discussed, but the goal is clear - active information about what comes in the near future and how to behave/what is our recommendation.
  • Not triggering the rule validation: Well, we cannot enforce, but only offer the capability to do so - and communicate the benefit. (In fact, this is one of the advantages in the CWA compared with the paper certificate, right?)
  • "several reports indicate, the check app is rarely used - BIG THANK YOU on that. We mentioned that since weeks, we asked several parties about the general communication, we proposed the BMI to "motivate" at least the forces and authorities to tell the story spread the idea of "proper checking". I'll take this remark directly again to the next discussion... Many thanks for that. We will see if we have success or at least progress. Maybe, it still needs a trigger, an event or other public media to emphasize this topic...

And yes, if you guys have ideas how to enhance the UI and/or ideas to enhance the "information flow" or the "guidance" for the user, I kindly encourage you to provide your ideas, to share mockups in any way, don't stop unless you are satisfied.

Meanwhile, I allow to step back and will be off for a summer break, still having an eye on you ;-)

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Jul 14, 2021

@GisoSchroederSAP Have a nice break and enjoy your vacation! Thanks for all your long and detailed comments! Have a nice time. 🏝

@vaubaehn
Copy link

@GisoSchroederSAP -> some notes for after your summer break 🍹 🌞 🏊
Thanks also to you for your transparancy, that makes it much more easy. So, we're all pulling on the same rope, that's great!
From my pov, I can only add some small details:

we implement an early indication for both, that the certificate will expire in a few days/weeks

Imho 4 weeks could be optimal: long enough to take action, short enough not to forget it because it was already displayed for a while.

In fact, this is one of the advantages in the CWA compared with the paper certificate, right?

Right 😃

several reports indicate, the check app is rarely used

This is based on personal experiences (e.g., famous cafe in a metropolitan city last week), and on user reviews like this:

This was CovPass and the UI was subject of concern, but it describes how verifier apps were used lately (i. e., not used). Although we need to take into account, that experiences made here were likely before July 1st (official start in EU).

Have a nice time off!

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Jul 15, 2021

FYI: @coronawarnapp tweeted:

[Das Gültigkeitsdatum] Wird mit einer der nächsten Versionen wieder angezeigt.

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Jul 16, 2021

Version 2.7 will show the date again, but with a better explanation: corona-warn-app/cwa-app-ios#3180

@jkrwdf
Copy link

jkrwdf commented Jul 16, 2021

I doubt that it is a good idea to confront our main user base already today with the outlook that some kind of "Bemühen" (endeavor) might be necessary in the future (likely starting in 10 months). This will raise questions in the hotline and medical staff.

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Sep 21, 2021

@lgmIT

Do you meanwhile consider this as fixed?

@lgmIT
Copy link
Author

lgmIT commented Sep 21, 2021

@Ein-Tim

Yes, I think my original issue is taken care of and the regular user should be way less confused with the newer versions. Thank you! Should I close this issue or will somebody/some bot do it as part of some process?

@dsarkar
Copy link
Member

dsarkar commented Sep 21, 2021

Hi @lgmIT,

Thank you for contributing and leaving feedback here. We usually encourage authors to close a issue when they agree that they consider an issue fixed or obsolete. We will close this now, thanks again for contributing.

Thanks also to the other contributors of the communtiy: @Ein-Tim @vaubaehn @MikeMcC399 @jkrwdf, ...

Best wishes, DS


Corona-Warn-App Open Source Team

@dsarkar dsarkar closed this as completed Sep 21, 2021
@dsarkar dsarkar added the Fix 2.6 Fix is planned for 2.6 label Sep 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Improvements or additions to documentation Fix 2.6 Fix is planned for 2.6 mirrored-to-jira This item is also tracked internally in JIRA
Projects
None yet
Development

No branches or pull requests

7 participants