Stream: smart/health-cards
Topic: Connectathon 27 Cerner Issuer Testing
Reece Adamson (May 18 2021 at 16:28):
Just tested out the Cerner Issuer $health-cards-issue operation and it worked like a charm! :party_ball:
Only thing our tests noticed is that there is no ./well-known/smart-configuration file.
Screen-Shot-2021-05-18-at-12.27.53-PM.png
Reece Adamson (May 18 2021 at 16:29):
@Josh Mandel I don't see an explicit SHOULD or SHALL for supporting /.well-known/smart-configuration and indicating support for the health-cards capability (link to section of the spec). Is this something that should be an optional test or that we should clarify the language for?
Josh Mandel (May 18 2021 at 16:32):
A SMART on FHIR Server advertises support for issuing VCs according to this specification by adding the health-cards capability to its /.well-known/smart-configuration JSON file
This should be updated to say:
A SMART on FHIR Server SHALL advertise support for issuing VCs according to this specification by adding the health-cards capability to its /.well-known/smart-configuration JSON file
I'll create a PR.
Zameer Sura (May 18 2021 at 16:32):
We do not publish /.well-known/smart-configuration on our Open/Insecure endpoint as it is not backed by SMART authorization. It should pass if you try using the patient access endpoint.
Josh Mandel (May 18 2021 at 16:34):
Added https://github.com/smart-on-fhir/health-cards/pull/145
Isaac Vetter (May 18 2021 at 16:36):
would this only be in the case of the $issue operation?
Josh Mandel (May 18 2021 at 16:36):
Yes -- it's a requirement for FHIR servers supporting issuance.
Josh Mandel (May 18 2021 at 16:37):
Added further clarification to PR#145.
Reece Adamson (May 18 2021 at 16:56):
Tested against the secured endpoint where the SMART configuration test passes :congratulations:
Screen-Shot-2021-05-18-at-12.55.11-PM.png
James Kizer (May 18 2021 at 17:03):
@Reece Adamson what tool is that?
Stephen MacVicar (May 18 2021 at 17:06):
It's an alpha release of a new version of inferno: https://inferno-dev.healthit.gov/
Reece Adamson (May 18 2021 at 17:06):
@Zameer Sura it does give a warning that the JWKS response does not include the Access-Control-Allow-Origin header expected by the spec (https://smarthealth.cards/#determining-keys-associated-with-an-issuer).
This is required, but for the tests we have it tuned to a warning so that it doesn't halt the following tests.
Zameer Sura (May 18 2021 at 18:14):
Reece Adamson said:
Zameer Sura it does give a warning that the JWKS response does not include the
Access-Control-Allow-Originheader expected by the spec (https://smarthealth.cards/#determining-keys-associated-with-an-issuer).This is required, but for the tests we have it tuned to a warning so that it doesn't halt the following tests.
Our endpoints do support CORS but it seems like the inferno test is making the calls without an Origin header set, basically in no-cors mode which is why our server is not responding with the required CORS headers.
See: Here, which shows the CORS headers being returned if you look under your browser developer tools.
Reece Adamson (May 18 2021 at 18:26):
Good catch @Zameer Sura - we'll debug that now
Zameer Sura (May 18 2021 at 18:28):
Reece, aside from the CORS warning i also see the inferno tool giving a warning about the payload length
Payload may not be properly minified. Received a payload with length 1448, but was able to generate a payload with length 1167
This seems to be performing the check against the decompressed payload instead of the JWS token. Lengths of the responses, decompressed payload = 1448, jws token = 889
Reece Adamson (May 18 2021 at 18:29):
The payload length checks have some known issues we're looking at so you can ignore that warning.
Stephen MacVicar (May 18 2021 at 18:48):
That test is intended to specifically check against the decompressed payload. We take the payload, minify it ourselves and compare the lengths. It's tricky to say for sure that a difference in length is an actual problem, so it's just a warning and the wording says "may". Due to an issue that we are unlikely to resolve before the connectathon, the length we're checking against is ~40 characters shorter than it should be. A difference of 300 characters seems like it indicates a problem with one of our implementations.
Vijayendra Prabhakar (May 19 2021 at 10:34):
@Zameer Sura One query for the cerner issuer, is authentication through SmartOnFHIR required to access the API through Patient Access? We have enabled authentication through Bearer token from our Holder App.
Reece Adamson (May 19 2021 at 11:16):
@Vijayendra Prabhakar I was able to test with the Cerner open endpoint.
For convenience here is the open endpoint: https://fhir-open.stagingcerner.com/beta/ec2458f2-1e24-41c8-b71b-0e701af7583d/Patient/{id}/$health-cards-issue
Zameer Sura (May 19 2021 at 12:53):
@Vijayendra Prabhakar, yes in a production system you got to access the Patient Access API through the SMART On FHIR OAuth2 authentication. The documentation that Reece linked describes how you can register your application to connect with this endpoint.
Please let me know if you require assistance with this.
Additionally we provide the open endpoint to test in our public sandbox/connectathon domain that does not require authentication.
Last updated: Apr 12 2022 at 19:14 UTC
