bcgov / dts-vc-issuer-service

Digital Trust Verifiable Credential Issuer Service
Apache License 2.0
0 stars 11 forks source link

Format of vaccination credential -- draft proposal #21

Closed swcurran closed 10 months ago

swcurran commented 3 years ago

I suggest for this proof of concept vaccination credential we start with this JSON-LD version of the WHO SVC format https://w3c-ccg.github.io/vaccination-vocab/#example

We'll need to do some transformations to make this work for the Indy AnonCreds deployment we are using today:

  1. For the claims with the same name (e.g. "type"), we add the JSON path to the claim name e.g. "credentialSubject_type", "vaccine_type", etc. No sure what the best delimiter should be between the path and item name.
  2. Decide what VC metadata should be included? For example, issuer is inherent in Indy so not needed, anything else above "CredentialSubject" needs to be included or not.
  3. What would BC/Canada NOT want in the credential. For example, I notice that there is nothing about who administered the vaccination, which is good.

@bradhead Sarah Pugh (don't know github ID).

SarahRPugh commented 3 years ago

Commenting so you have my github ID @swcurran. For the purposes of demoing we should show more but demonstrate or talk to less as a possibility - but still probs don't need administeringCentre, healthProfessional, or batchNumber...

swcurran commented 3 years ago

Thanks @SarahRPugh -- I missed the "HealthProfessional". Doh. Ridiculous. I'm good on leaving the other two out as well on the first cut. @AnaisHebert @itchison are one of you creating the Schema for the credential to be issued? Recall that @bradhead is providing whatever data he thinks is needed, but you can completely ignore what he gives you and set up the schema as you want :-) .

AnaisHebert commented 3 years ago

Yeah ill be creating the schema for the credential. Hows this:

{
    "name": "Vaccination Certificate",
    "description": "Vaccination Certificate",
    "issuanceDate": "2019-12-03T12:19:52Z",
    "expirationDate": "2029-12-03T12:19:52Z",
    "credential_type": "VaccinationEvent",
    "countryOfVaccination": "NZ",
    "recipient_type": "VaccineRecipient",
    "recipient_givenName": "JOHN",
    "recipient_familyName": "SMITH",
    "recipient_birthDate": "1958-07-17",
    "vaccine_type": "Vaccine",
    "vaccine_disease": "COVID-19",
    "vaccine_medicinalProductName": "COVID-19 Vaccine Moderna",
    "vaccine_marketingAuthorizationHolder": "Moderna Biotech",
    "vaccine_dateOfVaccination": "2021-03-03"
}

Updated to remove Covid 19 from name/description Update to remove gender Removed atcCode Added vaccine_dateOfVaccination

swcurran commented 3 years ago

Don't like the name/description -- should be just Vaccination Certificate as this is not limited to COVID-19.

The rest I like. I'm a bit torn on the need for the JSON path in all the names vs. just those that conflict, but don't think I'm the right one to weigh in on that. :-)

Thanks!

SarahRPugh commented 3 years ago

At the risk of being a huge PITA I think we need to question the inclusion of recipient_gender. It's not relevant to anything - DOB is sufficient to confirm identity. And it's potentially problematic because this schema uses strings for gender, which supports non-binary people as required in BC, but if this credential was used in other jurisdictions a non-binary entry might be worse than having it not there. Thoughts?

bradhead commented 3 years ago

At the risk of being a huge PITA I think we need to question the inclusion of recipient_gender. It's not relevant to anything - DOB is sufficient to confirm identity. And it's potentially problematic because this schema uses strings for gender, which supports non-binary people as required in BC, but if this credential was used in other jurisdictions a non-binary entry might be worse than having it not there. Thoughts?

Agreed! So much so, that I didn't include gender in the Patient data set. Despite WHO and others 'wanting' it.. It's not useful as personally identifiable information and it is not clinical gender, so we have not included it in the PI.

swcurran commented 3 years ago

Totally agree with removing gender from the cred.

bradhead commented 3 years ago

Yeah ill be creating the schema for the credential. Hows this:

{
    "name": "Vaccination Certificate",
    "description": "Vaccination Certificate",
    "issuanceDate": "2019-12-03T12:19:52Z",
    "expirationDate": "2029-12-03T12:19:52Z",
    "credential_type": "VaccinationEvent",
    "countryOfVaccination": "NZ",
    "recipient_type": "VaccineRecipient",
    "recipient_givenName": "JOHN",
    "recipient_familyName": "SMITH",
    "recipient_birthDate": "1958-07-17",
    "vaccine_type": "Vaccine",
    "vaccine_disease": "COVID-19",
    "vaccine_atcCode": "J07BX03",
    "vaccine_medicinalProductName": "COVID-19 Vaccine Moderna",
    "vaccine_marketingAuthorizationHolder": "Moderna Biotech"
}

Updated to remove Covid 19 from name/description Update to remove gender

To comment on this the ATC Code, which is the WHO's stnadard for vaccinations is not supported by CanImmunize and other vaccination sources in Canada. That is not to say we cannot map to them, but the Canadian Standard is DIN which is a code system designation by the URI defined by HL7, which I have put into the payload and for which I have based the example data set. IN MY OPINION, it would be better for the W3C to offer n-tuple that defines the codification, with: identifier value, identifer code system and identifier description, with at least the ident value and code system. Can Immunize for example supports other code systems for the vaccine, such as SnomedCT extensions.