Stream: smart/health-cards
Topic: Excelsior Pass
Josh Mandel (Dec 09 2021 at 15:41):
Can you clarify the purpose of this stream? Is it possible to consolidate with #smart/health-cards given that Excelsior Pass now supports SMART Health Cards?
Vitor Pamplona (Dec 09 2021 at 15:57):
"Excelsior Pass" is not an SHC. "Excelsior Pass Plus" is SHC. I am not sure which one the author is referring to.
Poonam Kariya (Dec 09 2021 at 16:01):
we are trying to verify our employees excelsior passes through https://github.com/smart-on-fhir/health-cards-dev-tools
but issuer we are not able to verify ... in fact there is no QR numeric showing after scanning the image.. but it shows directly raw data
Poonam Kariya (Dec 09 2021 at 16:02):
How can we verify the excelsior passes through nodejs source code including issuers verification
Vitor Pamplona (Dec 09 2021 at 16:04):
I see. What you have is an Excelsior Pass (which is not a SmartHealth Card). See if you can ask the person to send you a QR from the Excelsior Pass PLUS app.
Vitor Pamplona (Dec 09 2021 at 16:05):
More info: https://epass.ny.gov/home
Poonam Kariya (Dec 09 2021 at 16:12):
So we got QR image from our employee, we scanned it through SHC framework and instead of encrypted values we directly got the raw data like DOB, First Name, Last Name, Issuance Date and Expiration Date but issuer information we are not sure how can we verify it
Poonam Kariya (Dec 09 2021 at 16:13):
we tried t0 scan it Excelsior Pass Plus app directly and it shows only name, DOB and status VAlid or not
Vitor Pamplona (Dec 09 2021 at 16:14):
Correct. The QR you have is just a pass. It doesn't include vaccination information.
Vitor Pamplona (Dec 09 2021 at 16:15):
Your Employee needs to generate an Excelsior Pass PLUS if you want to process with the SmartHealth Cards SDK
Poonam Kariya (Dec 09 2021 at 16:15):
all we need to do is find out nodejs code so we can deploy it on Google Cloud firebase function and automatically as soon as our employees upload their QR images, in backend it verifies the card including issuer and in response we need first name, last name, Dob, first date of dose , 2nd date of dose, vaccine company name like moderna or pfizer etc.
Poonam Kariya (Dec 09 2021 at 16:16):
oh ok.. I understand now. this information is really helpful.. we will try soon and will get back.
cheers
Vitor Pamplona (Dec 09 2021 at 16:16):
I am glad it helped.
Poonam Kariya (Dec 09 2021 at 16:20):
can you pls share the link of the excelsior pass plus mobile app?
Vitor Pamplona (Dec 09 2021 at 16:31):
I don't think the app generates the QR. They need to go here: https://epass.ny.gov/home
Poonam Kariya (Dec 09 2021 at 16:41):
ok. great. thanks to confirm
Poonam Kariya (Dec 09 2021 at 16:56):
So as it is mentioned in the description here is the wallet where user can store the pass and generate it https://play.google.com/store/apps/details?id=gov.ny.its.healthpassport.wallet
Vitor Pamplona (Dec 09 2021 at 17:15):
Does it generate the Plus pass as well? Or just stores it?
Poonam Kariya (Dec 10 2021 at 13:22):
Well. not sure.. we are going to check it soon with card holder so we can observe the process they need to follow to store or generate the excelsior pass plus
Josh Mandel (Dec 11 2021 at 20:45):
I think this steam got started by accident and was supposed to be a topic -- I'll migrate to #smart/health-cards
Notification Bot (Dec 11 2021 at 20:46):
This topic was moved here from #EXCELSIOR PASS > stream events by Josh Mandel
Poonam Kariya (Dec 13 2021 at 11:37):
Hello Vitor,
Great news to share.. we asked end user to generate excelsior plus pass from the suggested web page and it is working fine and giving response of verification status with required details. however the SDK give following messages as response as well:
Any inputs on the following errors/ alerts?
"alerts": [
"fhirBundle.entry[1].resourceImmunization.patient = \"Patient/resource:0\" (Reference) should be short resource-scheme URIs (e.g., {\"patient\": {\"reference\": \"resource:0\"}})",
"fhirBundle.entry[1].resourceImmunization.patient = \"Patient/resource:0\" (Reference) is not defined by an entry.fullUrl [resource:0,resource:1,resource:2]",
"fhirBundle.entry[2].resourceImmunization.patient = \"Patient/resource:0\" (Reference) should be short resource-scheme URIs (e.g., {\"patient\": {\"reference\": \"resource:0\"}})",
"fhirBundle.entry[2].resourceImmunization.patient = \"Patient/resource:0\" (Reference) is not defined by an entry.fullUrl [resource:0,resource:1,resource:2]",
"fhirBundle.entry[1].resourceImmunization.patient = \"Patient/resource:0\" (Reference) should be short resource-scheme URIs (e.g., {\"patient\": {\"reference\": \"resource:0\"}})",
"fhirBundle.entry[1].resourceImmunization.patient = \"Patient/resource:0\" (Reference) is not defined by an entry.fullUrl [resource:0,resource:1,resource:2]",
"fhirBundle.entry[2].resourceImmunization.patient = \"Patient/resource:0\" (Reference) should be short resource-scheme URIs (e.g., {\"patient\": {\"reference\": \"resource:0\"}})",
"fhirBundle.entry[2].resourceImmunization.patient = \"Patient/resource:0\" (Reference) is not defined by an entry.fullUrl [resource:0,resource:1,resource:2]"
]
}
Vitor Pamplona (Dec 13 2021 at 13:27):
hum... strange. Which SDK are you using?
Christian Paquin (Dec 13 2021 at 15:01):
It looks like you are using the dev tools. First, it should be noted that these tools are not meant to verify end-user cards, but rather to help issuers validate their implementation. Second, the error you are seeing is because the card's patient references (in the FHIR bundle) are referencing patient/resource:0
instead of the short-form resource:0
.
Josh Mandel (Dec 13 2021 at 15:20):
(to be clear patient/resource:0
is invalid, in addition to being longer.)
Vitor Pamplona (Dec 13 2021 at 15:24):
@Josh Mandel Maybe together with the reissuance URL, the SHC could require each issuer to provide production-based test QRs on some interface. This would help assert compliance to each issuer's crazy implementation individually.
Vitor Pamplona (Dec 13 2021 at 15:29):
Most issuers and verifiers that I see are assembling these FHIR payloads by hand as opposed to using a FHIR engine to automatically generate/load them from/into FHIR objects. California's open source issuer is classic example: https://github.com/StateOfCalifornia/DigitalCovid19VaccineRecord-API/blob/9792f01862cd788962bed581d9d5185b2d7986cf/Infrastructure/CredentialCreator.cs#L40
Josh Mandel (Dec 13 2021 at 16:34):
Indeed, we are looking at adding this as part of the workflow for joining the VCI directory. It doesn't quite make sense at the specification level, because it's not enforceable there but for a given trust framework it feels like a good fit.
Josh Mandel (Dec 13 2021 at 16:36):
(And indeed, the logic you point to in the California implementation for generating display names on Google Wallet wrappers around SHCs is a good example of this kind of thing -- that logic would quickly fail if applied to arbitrary SHC payloads (e.g., it's never looking at name.text), but of course, it is only being applied in a very limited context to SHC payloads that California's system has created.)
Vitor Pamplona (Dec 13 2021 at 17:25):
But not everyone wants to join the VCI directory :(
Vitor Pamplona (Dec 13 2021 at 17:26):
I do think the spec could help define the API and the test schema just like the spec enforces Canada to publish keys on their servers (they never wanted to do that). It's not perfect, but it defines the basic language that is independent of which trust registry one subscribes to.
Josh Mandel (Dec 13 2021 at 17:28):
We do this -- IG at https://vci.org/ig/vaccination-and-testing (it defines the data schema). It just doesn't impose requirements about publishing examples, which I'm not sure would be workable in the abstract.
Josh Mandel (Dec 13 2021 at 17:30):
Ultimately an "issuer" can fail to follow the spec in many ways (by not hosting keys, by generating invalid payloads, etc), so part of the role of a trust framework is making an assessment of which issuers are "doing it right".
Vitor Pamplona (Dec 13 2021 at 17:32):
I see. I would use the EU's work as a reference. Those datasets are awesome: https://github.com/ehn-dcc-development/dcc-testdata
Grahame Grieve (Dec 13 2021 at 18:27):
that is very nice
Poonam Kariya (Dec 14 2021 at 11:43):
Hello,
The errors mentioned above are the result of the SHC/Health Cards dev tools... see ref links given here.
We are testing on local system following Github source code to verify our employee's vaccination status and getting response like 1st date of does, 2nd date of dose and vaccine company names:
https://demo-portals.smarthealth.cards/VerifierPortal.html
https://github.com/smart-on-fhir/health-cards-dev-tools
Please guide if there is specific source code developed in nodejs,typescript/javascript, that we can use to verify the status of the bulk vaccination cards of our employees. We need to deploy the final source code as a REST Api to google cloud - Firebase function.
Thank you in advance.
Josh Mandel (Dec 14 2021 at 14:12):
As Christian pointed out, the dev tools repository is not intended for use in this kind of validation scenario. Because it's designed to provide helpful feedback for issuers, it will do things like speculatively parse payloads and push through errors to see what else might be wrong, (These are good behaviors for debugging at development time, but unsuitable for real-world verification in a security sensitive environment).
You may want to borrow some ideas or patterns from this tool, without wrapping/running it directly for your use case.
Perhaps others here may be able to recommend additional tools suitable for real-world use? (I think the key would be to keep things very narrow and concrete. Like, a simple script to evaluate whether a SHC is signed correctly by a trusted issuer and return the FHIR Bundle; then another script to evaluate a FHIR Bundle to determine whether the immunization history meets your requirements).
Priyanka Yadav (Dec 23 2021 at 11:08):
@Samarth
Last updated: Apr 12 2022 at 19:14 UTC