search

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
106 stars 14 forks source link

"Certificate Grouping" based on NON-standardized names ("nam/fn" and "nam/gn") instead of standardized names #823

Open jkrwdf opened 2 years ago

jkrwdf commented 2 years ago

Current Implementation

The grouping of multiple certificates for the same subject (e.g. multiple vaccination certificates, but also vaccination and test certificate for 2G+) is currently based on

Especially when rapid-tests (RAT) are involved, the data of "nam/fnt" and "nam/gnt" are manually input in some user-interface by the test-station personnel.

Since I regularly perform RATs at my employer site, I get any combination of nonsense content here, starting from single letters to incorrectly transliterated content (e.g. JORG instead of JOERG).

As a result, the "2G+" grouping does not work then, and to make it even more confusing for the end-user, the name displayed in the CWA certificate tab looks right (in my case it stems from the RAT quick test profile QR code and is always correct) so the user finds two cards with exactly the same name.

Suggested Enhancement

CWA (and CovPass as well) shall use the normal name components ("nam/fn" and "nam/gn") together with the "dob" for grouping of certificates.

The usage of the standardized versions is IMHO the wrong choice here.

Their main use-case is border control to visually compare what is shown in the ID document with what is shown in the validation application. For certificate grouping, they have no apparent advantage.

Expected Benefits

Higher probability that certificate grouping works as expected, especially independence from manual input errors in the fields "nam/fnt" and "nam/gnt" which are "alien" for most personnel in the test stations.

The recently introduced "fuzziness improvements" are possible for them as well as currently in the standardized versions, therefore there is no regression expected.

Internal Tracking ID: EXPOSUREAPP-12910

larswmh commented 2 years ago

Thanks for your enhancement request @jkrwdf. We have created an internal ticket for it and will raise this topic internally. Internal Tracking ID: EXPOSUREAPP-12910

Corona-Warn-App Open Source Team

jkrwdf commented 2 years ago

In the meantime I found a counter-argument against my own suggestion, and this has to do with my employer.

While two of my vaccinations happened at regular vaccination locations (doctor, centre) and took over my registration data 1:1, my third vaccination took place at the site of my employer, and the registration data were taken over from our internal employee management system, in which all names are stored in transliterated format.

That is: While certificates 1 and 2 are issued for "Günter" with standardized name GUENTER, the number 3 is issued to "Guenter" with standardized name GUENTER.

With the current implementation of certificate grouping, all find together, with my suggestion, they would no longer.

I leave it to the discretion of the CWA product owners to keep this issue upright or close it.

The core idea could be saved by introducing a local standardization which mitigates "ü vs. ue" in the non-standardized data, but I agree that this might be too much indirection.

larswmh commented 2 years ago

Thanks for presenting a counter-argument for your own enhancement suggestion @jkrwdf. Unfortunately, we did not receive an update on it yet, but I have forwarded your new comment.

Corona-Warn-App Open Source Team