WHO Vaccination Certificate - Revision history

Tom: /* References */

2021-06-29T19:02:43Z

‎References

Tom: /* References */

2021-06-29T19:01:37Z

‎References

Tom: /* Objections */

2021-06-29T18:51:07Z

‎Objections

Tom: /* Objections */

2021-06-29T18:50:30Z

‎Objections

Tom: /* Context */

2021-03-26T04:55:21Z

‎Context

Tom at 00:05, 21 March 2021

2021-03-21T00:05:53Z

Tom: Created page with "==Full Title== Smart digital replacement for the ==Context== * [https://www.who.int/news-room/articles-detail/call-for-public-comments-interim-guidance-for-developing-a-smart..."

2021-03-21T00:02:50Z

Created page with "==Full Title== Smart digital replacement for the ==Context== * [https://www.who.int/news-room/articles-detail/call-for-public-comments-interim-guidance-for-developing-a-smart..."

New page

==Full Title==
Smart digital replacement for the

==Context==
* [https://www.who.int/news-room/articles-detail/call-for-public-comments-interim-guidance-for-developing-a-smart-vaccination-certificate-release-candidate-1 smart vaccination certificate release candidate 1]

==References==

[[Category: Health]]

@@ Line 14: / Line 14: @@
 ==References==
-* See wiki page on [[A Critique of Immunity Passports and W3C Decentralized Identifiers]]
+* See wiki page on [[Health Credentials]] for a broader view of the topic.
 [[Category: Health]]

← Older revision		Revision as of 19:01, 29 June 2021
Line 14:		Line 14:

	==References==		==References==
		+	* See wiki page on [[A Critique of Immunity Passports and W3C Decentralized Identifiers]]

	[[Category: Health]]		[[Category: Health]]

@@ Line 11: / Line 11: @@
 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.
+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==
 [[Category: Health]]

@@ Line 9: / Line 9: @@
-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?
+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
+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==
 [[Category: Health]]

@@ Line 4: / Line 4: @@
 ==Context==
 * [https://www.who.int/news-room/articles-detail/call-for-public-comments-interim-guidance-for-developing-a-smart-vaccination-certificate-release-candidate-1 smart vaccination certificate release candidate 1]
 ==References==
 [[Category: Health]]

@@ Line 1: / Line 1: @@
 ==Full Title==
-Smart digital replacement for the
+Smart digital replacement for the [https://www.washingtonpost.com/lifestyle/travel/yellow-card-vaccine-passport/2020/12/30/746c0558-40b7-11eb-8db8-395dedaaa036_story.html Yellow Card or vaccine passports] with [[Digital Travel Credentials]].
 ==Context==