Difference between revisions of "WHO Vaccination Certificate"

Revision as of 21:55, 25 March 2021

Full Title

Smart digital replacement for the Yellow Card or vaccine passports with Digital Travel Credentials.

Context

• smart vaccination certificate release candidate 1

Release 1

Objections

I am Brad, CDO at Quartech, a consulting firm. We have a team at BC Government delivering Digital Trust Services and the Verifiable Organizations Network. My focus has been in health care and currently leading some work for a citizen’s health gateway where they access health records online using a Level-3 digital ID. We are embarking on issuing VCs for citizens - self-service using the Health gateway but architected as reusable components in the open source. I recently read the Interim Guidance for Developing a Smart Vaccination Certificate, published by the World Health Organization. It left me somewhat stunned to be frank. That said, the proposed data set is useful, the rest is, well I don’t know, not aligned with what I think we should be doing.. W3C VCs and the potential for aggregated privacy respecting claims.

Richard Bookman = I’m interested to hear more about why/how you were stunned. Have you posted an analysis anywhere? Share thoughts here through Slack #CCI maybe?

Brad Head

The scope of the reference solution pulling in HL7 FHIR and IHE and the ‘centralized’ nature of the PKI registry, and the privileged v. non privileged verifiers as a construct adds tremendous complexity. Some of the key data sets are not useful or possible for our jurisdiction - signature of administrating practitioner for example. Rather, the model of trusted Issuer as a digital signed perspective is more useful. Privacy of the practitioner is also a consideration. The need to know basis, as in What is a verifier going to do with the knowledge of which public health practitioner performed the jab? That’s PI leaking unnecessarily, just not the subject’s PI. In BC, our model is the trusted issuer is BC government, not at lab or private clinic. The architecture also speaks to supplying the SVC issuance during the administration of the vaccine, but our model is this is an after the fact step.. the citizen retrieves their VC in an out of band ad hoc interaction when they need it. We rely on the integrity of our provincial immunization records for that subject. The IHE flows and overall presumption of the need for IHE integration maturity is also a concern. While that may be a prerequisite, it is not the scope of issuing SVCs. The basic model is to generate a VC from the trusted data set. Nothing more. Whether FHIR JSON modelling is needed for that is highly arguable. Secondly, many jurisdictions do not support ICD 11. So, I’d prefer the codified mapping be the responsibility of the verifier. This contains scope of the issuer to focus on what they have, in Canada that’s a DIN code for the vaccine, for example. Canada DINS are a matter of public record, available via APIs if the verifier is unclear. But the emphasis should be on trusting the issuer by the verifier and take the claims at face value. This is why the model of having private sector issuer VCs isn’t tenable in my view as that exposes novel trust relationships that frankly are rather presumptive. The scope of work for VCs for vaccine should laser focus on what and how the information is trusted and shared and verified. We don’t need to discuss flows related to IHE nor do we need to talk about HL7 FHIR. The PKI registry centralized but cloned in a closed network is not tenable. Ledger technology solves this in a transparent and observable manner — anyone can decide to be a verifier with no loss of capability. Lastly the WHO architecture completely and deliberately ignores the applicability of W3C VCs and the underlying ledger tech and ignores its benefits. They deliberately constrained themselves to ‘proven’ technology. BC is going to follow W3C standards for VCs and not ‘invent’ its own. Whether we use HL7 FHIR to model is unlikely given we want a balance of meta-data to data in the VC to create the opportunity to fit it into a QR if needed.

References