FHIR Chat · Health Cards · smart

Stream: smart

Topic: Health Cards

Josh Mandel (Oct 14 2020 at 21:30):

(Placeholder for discussion about https://healthwallet.cards/)

Bill Claxton (wmclaxton) (Oct 15 2020 at 04:37):

New here and new to FHIR. I have some questions about how to implement a health certificate for COVID-19 PCR test results as a Verifiable Credential.

By way of background, my company NextID is working on the Safe Travel project in Singapore (https://safetravel.ica.gov.sg/pdt-digital-certification). We are adding a feature to our NextCert issuance application to support HealthCerts which use FHIR syntax, much like the Health Cards example (https://healthwallet.cards/credential-modeling). These certs will record the result of a COVID-19 PCR test based on a nasalpharyngeal swab. The presentation layer will display the result as 'positive/negative/inconclusive/invalid'.

The sample certificate given in the specification (not to be confused with a JSON schema) has capability for recording the clinical lab result as a text string such as 'negative'. But we feel that the certificate should be more informative and include also the Ct (cycle time), igG and igM (2 types of antibody) in the certificate data, whether or not is shown in the presentation layer. Here is a snippet from the observation block of the sample cert as shown in the specification document:

{
"resourceType": "Observation",
"identifier": [{
"value": "123456789",
"type": "ACSN"
}],
"code": {
"coding": [{
"system": "http://loinc.org",
"code": "94531-1",
"display": "Reverse transcription polymerase chain reaction (rRT-PCR) test"
}]
},
"valueCodeableConcept": {
"coding": [{
"system": "http://snomed.info/sct",
"code": "260385009",
"display": "Negative"
}]
}

I'm not sure if the only value we need to make dynamic is the valueCodeableConcept display. It seems from what I've read that the code number also changes if the result is other than negative. Aside from this point, my primary question is, how would we add the fields to capture Ct, igG and igM and what is the data type to be captured (eg- are they text, integer values or scientific notation)?

Lloyd McKenzie (Oct 15 2020 at 04:50):

Seeing as this is focused more on how to express the Observation, not SMART, I'd suggest asking on #implementers or perhaps #Orders and Observation WG

Grahame Grieve (Oct 15 2020 at 04:51):

and a direct answer to the question is, component observations. I don't think LOINC has published codes for those things? @Swapna Abhyankar

Bill Claxton (wmclaxton) (Oct 15 2020 at 05:01):

@Lloyd McKenzie , @Josh Mandel suggested I post here but happy to have it moved to the correct forum if that helps. Apologies, I'm new here.

Lloyd McKenzie (Oct 15 2020 at 05:04):

No apologies needed. This forum is a big place. The recommendation was more about where you might find more people with the right expertise paying attention. Unfortunately, we can't move posts. You'd have to re-ask the question elsewhere. Normally asking the same question in multiple places is frowned upon, but it's fine if someone suggests you post elsewhere (and best practice is to include a link on the old discussion to the new discussion so those late to the party can see where things moved to.

Josh Mandel (Oct 15 2020 at 13:51):

sorry, about the confusion on where to post. This is getting into details about modeling specific lab results, but briefly: I would think about capturing these kinds of attributes of a test as components of an observation, via Observation.component.

Josh Mandel (Oct 15 2020 at 13:54):

I would be happy to work with you on writing out some examples that we could make public, if you like. Oftentimes the process of doing this translation reveals areas of ambiguity or mapping details that we will need to work through.

Isaac Vetter (Dec 10 2020 at 16:58):

Is it a mistake that the $HealthWallet.issueVC example requests in this section don't contain a presentationContext?

Josh Mandel (Dec 10 2020 at 18:37):

Right now, "presentation context" is a way of shaping what details the issuer should include in a Health Card; it's not necessarily a field baked in to the VC itself.

Josh Mandel (Dec 10 2020 at 18:38):

We've been thinking about removing "presentation context" as a concept from the spec altogether, to focus on one "primary" use case initially -- a use case that includes a pretty rich set of details in the issued card.

Josh Mandel (Dec 10 2020 at 18:42):

(After discussion with the team from Pew re: patient matching, etc, we tried to write a "simple" set of recommendations -- not requirements! -- at https://healthwallet.cards/credential-modeling/#modeling-a-health-card under "FHIR identity resources". Feedback would be quite welcome.)

Daniel Levenson (Jan 29 2021 at 17:49):

@Josh Mandel @James Kizer and I were chatting about https://github.com/smart-on-fhir/health-cards/pull/50 and https://github.com/smart-on-fhir/health-cards/pull/49 -- how much of the size of the VC bundle is driven by long-form ION DIDs? If Health Card VCs just used short-form DIDs (seems possible considering that ION is now live) - would that save us enough space?

Josh Mandel (Jan 29 2021 at 17:51):

Indeed -- if you look into the details on #50 you'll see that this suggests short-form DIDs (but does not suggest/expect DLT-based resolution, to be clear -- we are not going to introduce a hard dependency on sisdetree nodes in v1 of Health Cards).

Josh Mandel (Jan 29 2021 at 17:52):

In this QR scheme, we can resolve DIDs by linked domains (.well-known/did-configuration) and/or trust framework-hosted registries; the suffix data is always verifiable, since the short-form DID is calculated by hashing this data.

Daniel Levenson (Jan 29 2021 at 18:17):

Got it – yeah, re: "we are not going to introduce a hard dependency on sidetree nodes in v1 of Health Cards)." what's the thinking there? Just that the ION nodes are perhaps too immature at this point or that the infra requirements are too much to get started? Some other thoughts/concerns (which may or may not be warranted, just thinking out loud):

• Is supporting a QR-able flavor of a VC (distinct from a general Health Card) too much complexity for issuers? I imagine this would be another VC type with it's own schema, so perhaps not, but it's still definitely "more stuff to support" for issuers.
• It feels a bit against the grain of sidetree-based DID methods to have a, effectively, a closed network, of DID resolution. At least, that's my gut impression -- would love to learn more about what you thinking there.
• To play out how .well-known/did-configuration.json plays a role here, is the following correct. QR VC includes short-form DID and DID origin -> verifier/holder resolves origin's well-known/did-configuration.json domain linkage VC -> check that short-form DID in VC matches long-form DID in domain linkage VC -> if check passes, resolve long-form DID in domain linkage VC to DID Document (local res; not DLT) -> verify signature of VC using signing key in DID Document.
  • This assumes that the DID @ .well-known/did-configuration.json is long-form, but perhaps that's a fair assumption

Daniel Levenson (Jan 29 2021 at 18:19):

also, meta point -- lmk if GH is the preferred way to have this conversation! Happy to do whatever

Josh Mandel (Jan 29 2021 at 20:03):

what's the thinking there?

It's just early; it raises questions for instance about whether DIDs need to be public (for issuers, they are; for users, that's another story, and by simply avoiding ledger-backed DIDs for now, we avoid those questions).

• Yes doing something (anything!) specific for QRs is more work for issuers -- but it's a core part of the problem we're committed to solving, given the importance of supporting users without a smartphone. There are trade-offs, but we want to develop the best system we can.

• Yes, the flow your dsecribed with .well-known/did-configuration.json is what I had in mind. We'd indeed need to specify that long-form ION DIDs appeared in those configuration docs, but that's an eaay thing.

Happy to discuss here or GH at your preference.

Daniel Levenson (Jan 29 2021 at 21:16):

It's just early; it raises questions for instance about whether DIDs need to be public (for issuers, they are; for users, that's another story, and by simply avoiding ledger-backed DIDs for now, we avoid those questions).

gotcha - yeah, totally makes sense.

Yes doing something (anything!) specific for QRs is more work for issuers -- but it's a core part of the problem we're committed to solving, given the importance of supporting users without a smartphone. There are trade-offs, but we want to develop the best system we can.

For sure :) – I haven't dug too deeply yet, but I would hope that there's some specification for "concatenating many QR codes together", so that a data-rich VC could be encoded via 2/3 QR codes without any modification to the VC payload - of course that would be only be useful if QR scanners/libs implement said spec. If of interest and not done already, I would be happy to do some research there.

Josh Mandel (Jan 30 2021 at 00:38):

Thanks -- I haven't done any research in this regard, and would love to know what's out there. (E.g. in scanning multiple codes, presumably you'd need to ensure you weren't order-dependent, so each chunk would need to embed its own index an the total set size.)

Gino Canessa (Feb 01 2021 at 20:11):

I'm working on a PoC to play with some of these questions - there are a lot of theoretical approaches that have been tossed around already, and I'm curious to see how they work in practice. Once there's something "working", I'll post to GH.

On scanning multiple QR codes, there is a specification for it; my exploration so far has found exactly one library that implements it. I haven't spent too much time looking, but I'm not too confident in it either.

Santosh Jami (Feb 03 2021 at 04:34):

I am building a mobile wallet application that can store the Vaccine information of members enrolled.
Is there a listing of the Labs that are capable to support the "Issuer" role? Where can I find this information?

I see the healthcare wallet demo is here: https://github.com/microsoft-healthcare-madison/health-wallet-demo
Is there github sources for the Verifier app and Lab ("issuer") app for reference?

I posted it here previously: https://chat.fhir.org/#narrow/stream/179170-smart/topic/Labs.20that.20support.20SMART.20on.20FHIR.20for.20sharing.20Vaccination.20info

Rob Resendez (Feb 09 2021 at 23:09):

Trying to take in the documentation here, and related specs.. and make sure I've connected all of the dots correctly. Say I'm taking on the perspective of an issuer. The user has given a VC I've issued to a holder. Some time later, the holder presents the VC I issued to a verifier...

I wasn't totally clear on interactions between the verifier and the issuer; or, perhaps the verifier only deals w/ the holder. I do think that the verifier does have some interaction w/ the issuer... in healthwallet.cards docs, this bit stuck out to me:

Verifiers will discover public keys associated with an issuer via .well-known DID URLs

The sequence diagram, "Complete the Presentation", has a note joining the the holder and the verifier "Verify VC" and subsequent operations on the verifier participant "extract issuers did and resolve".. then another operation titled just "...".

Switching gears quite a bit, I was reading about "Status" and "Revocation" (https://www.w3.org/TR/vc-data-model/#status). I'm interested in bolstering my mental model on this subject as it relates to healthcards. Say, for example, an immunization resource is "entered-in-error". How will the VC's status be updated w/ the holder?

I'll probably need to read through all of the specs involved (DID, VC) a few more times before everything really "clicks"..

Josh Mandel (Feb 09 2021 at 23:44):

Re: DIDs and encryption I should point out that https://github.com/smart-on-fhir/health-cards/pull/64 is in flight and will likely change the story here.

Josh Mandel (Feb 09 2021 at 23:48):

Re: updates, we're not currently planning to support updates to a Health Card; they're designed to cover (more or less) immutable clinical facts. This isn't perfect, but neither is vaccine protection; if I give you a card with information that turns out to be incorrect... you can still show that card to people. Some notes:

• The holder can always go request new cards from the issuer, so if there's a change to the data that the holder desires, they can obtain and use a new health card. But if the holder wants to keep sharing the old one, that's a threat we don't try to mitigate.
• If an issuer's keys are compromised, the issuer may decide to revoke them in a way that may invalidate health cards (e.g., from a particular date range) -- so at the time of validation when a verifier goes to determine "is this signature valid," they may decide "no, the associated key isn't trustworthy". This isn't quite what you're asking about, but has some similar properties.

Alberto Peirats (Feb 22 2021 at 19:57):

Is the https://smarthealth.cards#health-card credentialType still used? It's not listed on the Vocabulary section, but there's still a dangling reference to it in one of the sample responses. It's also still used by the demo app at c19.cards.

Alan Viars (Feb 22 2021 at 20:12):

I may try and implement this on OAuth2.org or verifymyidentity.com server when I get some free cycles. I may attempt to work on this during the connect-a-thon, but hopefully before.

Josh Mandel (Feb 22 2021 at 20:27):

The expectation for COVID-19 immunizations is currently to include:

    "https://smarthealth.cards#health-card",
    "https://smarthealth.cards#immunization",
    "https://smarthealth.cards#covid19"

in the .vc.type array. Our examples should include this; will add it to the vocab page right now.

Alberto Peirats (Feb 22 2021 at 20:31):

Thanks, Josh. So it's only used on the response, right? Is it ever required for the request, or is the #covid19 type enough?

Josh Mandel (Feb 22 2021 at 20:32):

I've updated https://smarthealth.cards/vocabulary/ to include this value, and to clean up no-longer-relevant content.

Josh Mandel (Feb 22 2021 at 20:33):

Is it ever required for the request,

When you say "the request", you mean in the case where a client is obtaining Health Cards by calling the FHIR $HealthWallet.issueVc operation?

Alberto Peirats (Feb 22 2021 at 20:34):

The Vocab now has #covid19 listed twice

Josh Mandel (Feb 22 2021 at 20:34):

(D'oh, fixing.)

Josh Mandel (Feb 22 2021 at 20:35):

When calling issueVc, you can provide just a single type if you want -- e.g., "https://smarthealth.cards#health-card" for all health cards, or "https://smarthealth.cards#covid19" if you just want any covid-related stuff, or "https://smarthealth.cards#immunization" if you want any immunization records.

Alberto Peirats (Feb 22 2021 at 20:36):

Josh Mandel said:

Is it ever required for the request,

When you say "the request", you mean in the case where a client is obtaining Health Cards by calling the FHIR $HealthWallet.issueVc operation?

Yes. If the request only specifies #covid19, the response's vc.type should include all of #health-card, #covid19, and #immunization, or should it only include the types that were requested?

Josh Mandel (Feb 23 2021 at 17:47):

If the request includes type X, then all responses should include type X (in addition to the other types needed to describe them). So if you ask for #covid19 you should get a pile of cards that each include #covid19 and #health-card at minimum (some might include #immunization, too).

Alan Viars (Feb 24 2021 at 16:34):

I saw this article which may be of interest, "As more governments mull vaccine passports, critics raise discrimination fears: "https://www.france24.com/en/europe/20210223-as-more-governments-mull-vaccine-passports-critics-raise-discrimination-fears

Alberto Peirats (Feb 26 2021 at 22:46):

Are JWKs expected to be backed by a valid CA-signed certificate, or is it enough to simply generate private/public keys without issuing signed certificates?

Josh Mandel (Feb 26 2021 at 23:10):

The core Health Cards spec only describes bare keys in a jwks.json file. (We're interested in developing guidance for linking out to certs as well, as part of trust framework options -- but that's something we'd layer on top; discovery bare keys should always work.)

Alberto Peirats (Feb 26 2021 at 23:18):

Gotcha. Our CA doesn't seem to be fond of signing certs with 256-bit keys, so I'm just looking at my options.

Josh Mandel (Feb 27 2021 at 00:09):

Just to check: you mean your CA won't sign certificats that contain 256-bit keys (rather than: your CA can't use a 256-bit key to sign a cert)?

Alberto Peirats (Mar 01 2021 at 14:58):

I believe we're limited to just RSA-2048 certs.

David Pyke (Mar 01 2021 at 15:12):

Get a new CA

Yunwei Wang (Mar 05 2021 at 19:53):

I am reading the health card IG and would like to clarify how the .well-known endpoint is constructed:

Issuers SHALL publish keys as JSON Web Key Sets (see RFC7517), available at <<iss value from Signed JWT>> + .well-known/jwks.json.

The URL at <<iss value from Signed JWT>> SHALL NOT include a trailing /. For example, https://smarthealth.cards/examples/issuer is a valid iss value (https://smarthealth.cards/examples/issuer/ is not).

So the well-known endpoint (using the example quoted here) is https://smarthealth.cards/examples/issuer.well-known/jwks.json. This is different from what SMART App Launch uses (http://hl7.org/fhir/smart-app-launch/conformance/index.html#using-well-known) @Josh Mandel

Josh Mandel (Mar 05 2021 at 20:07):

I think you're politely pointing out that our spec has a bug/typo @Yunwei Wang :) Fixed in https://github.com/smart-on-fhir/health-cards/commit/51859cdaa58c2ca00cdbaf60fba3d461203f8f17

Yunwei Wang (Mar 05 2021 at 20:11):

Another confusion (not typo) for the first time reader is "what is VC". The first instance this word is "Issuers sign Health Card VCs with a signing key (private key)" But there is not indication what the acronym means. I assume it mean "Virtual Card" but sure if that is the actual meaning.

Yunwei Wang (Mar 05 2021 at 20:16):

Oh I got it. It is "Verifiable Credentials" https://www.w3.org/TR/vc-data-model/#use-cases-and-requirements

Yunwei Wang (Mar 05 2021 at 20:17):

Still it would be less confusion by indicate the full name in the first instance of acronym like: "Issuers sign Health Card VCs (Verifiable Credentials) with a signing key (private key)

Josh Mandel (Mar 05 2021 at 20:37):

Thanks! If you're willing to submit a PR that'd be excellent.

Josh Mandel (Mar 05 2021 at 20:38):

(otherwise I'll get to this when I'm back at my desk .)

Yunwei Wang (Mar 05 2021 at 21:00):

OK. I will do that later. (Maybe sometime this week end)
If I have more such thing, should I put them here, github issues, or JIRA?

Josh Mandel (Mar 05 2021 at 21:52):

Here and/or GitHub is great.

Josh Mandel (Mar 05 2021 at 21:52):

At your preference.

Yunwei Wang (Mar 08 2021 at 19:43):

I don't quite understand how this works

Any JWS longer than 1195 characters is split into "chunks" of length 1191 or smaller; each chunk is then encoded as a separate QR code to ensure ease of scanning.

Does this mean that after scanning the initial QR code, the second one pops up automatically? I have never seen this before. Is there any reference to the requirement (about the subsequent codes) and real world implementations?

Josh Mandel (Mar 11 2021 at 16:06):

It's probably easy to think about paper to start: this would mean a piece of paper with two QRs on it. (Or digitally, could be 2 QRs displayed on the screen, or a "next" button -- probably not something automated.)

Josh Mandel (Mar 11 2021 at 16:07):

To be clear, we look at multi-QR Health Cards as an exceptional case / escape hatch; generally health cards are expected to fit in a single QR, and if we find this isn't the case, we may want to re-work the way we encode data to be more efficient.

Josh Mandel (Mar 11 2021 at 16:07):

(No matter what approach we take, we'll want some kind of escape hatch though.)

John Moehrke (Mar 15 2021 at 17:20):

FYI: John Halamka promoting the Vaccine Credentials concept http://geekdoctor.blogspot.com/2021/03/vaccine-credentials-done-right.html

John Moehrke (Mar 25 2021 at 11:33):

WHO set some principles for a Vaccine Certificate
https://www.who.int/news-room/articles-detail/call-for-public-comments-interim-guidance-for-developing-a-smart-vaccination-certificate-release-candidate-1

John Moehrke (Mar 25 2021 at 11:33):

will the HL7 Vaccine Credential follow these guidelines?

Josh Mandel (Mar 25 2021 at 13:16):

A couple of us from the Health Cars / VCI crew participated in the WHO process gathering input. A few notes:

• The WHO scope it is broad compared with the scope for SMART Health Cards. It includes continuity of care use cases in addition to proof of vaccination, and because of this, it assumes there will be a centralized national database that each public health authority makes available for queries from authorized users or outside jurisdictions. In Health Cards, we are entirely focused on giving individuals a copy of their own data in a verifiable format, with a workflow that allows paper-based or electronic presentation.

• The "RC1" doc from the WHO does not yet include recommendations from the ethics workstream; I'm looking forward to seeing these land in a subsequent revision.

Stephen Whitney (Mar 25 2021 at 15:44):

What is the current specification for adding Location (Immunization.location) resource to the vaccination credential? Should it be included?

Josh Mandel (Mar 25 2021 at 16:09):

We don't include a Location resource in our recommended data profiles, but rather "performer" -- https://smarthealth.cards/examples/example-00-b-jws-payload-expanded.json shows an example

              "performer": [
                {
                  "actor": {
                    "display": "ABC General Hospital"
                  }
                }
              ]

Josh Mandel (Mar 25 2021 at 16:09):

http://build.fhir.org/ig/dvci/vaccine-credential-ig/branches/main/StructureDefinition-vaccine-credential-immunization-dm-definitions.html#Immunization.performer.actor is the formal definition for this

Josh Mandel (Mar 25 2021 at 16:10):

And if you're interested in some of the thinking behind this: aim is to support the relevant fields from CDC paper cards, but acknowledging there's not generally going to be detailed/consistent structured data for this. (#15 if you want to see the full discussion.)

Michael Turman (Apr 09 2021 at 21:35):

Hi all,

As an FYI - we have added an SMART Health Cards track to the CARIN Connectathon next week. Our objective is to bring together implementers in various roles to test out reference implementations of the framework.

More info here: https://confluence.hl7.org/display/CAR/Track+Page+for+the+SMART+Health+Card

Abbie Watson (Apr 10 2021 at 03:05):

So, I've been piecing a Vaccine Wallet/Passport together also, but I've been taking a slightly different approach, since we're using Apple Health Records. We get the Immunization records raw, which I can generate a QR code with. So, for instance, if you take out your phone, and scan the following code, you should get a FHIR Immunization record for Candace Salinas.

Symptomatic-VaccineWallet-QrCode-CandaceSalinas.png

I'll update this over the weekend, put it into a Bundle, hash the whole thing, and put the output of _that_ on in the QR code.

Michael Turman (Apr 10 2021 at 18:49):

Thanks for sharing, Abigail.

Hope to continue the conversation into next week's Connectathon!

Eric Haas (Apr 13 2021 at 17:19):

@Josh Mandel Is there only one HL7 project health card project that is bound to immunization passports or is there a stand alone Health Cards project?

Josh Mandel (Apr 13 2021 at 17:56):

Today there are two key implementation guides in development:

1. SMART Health Cards: Framework IG
2. SMART Heath Cards : Vaccination and Testing IG

(2) is already on its way through the HL7 process (as you noted above), and we're preparing a PSS for (1)

(@Reece Adamson @Max Masnick @Neelima Karipineni FYI.)

Richard Braman (FLY.HEALTH) (Apr 17 2021 at 20:56):

Something small I noticed in the draft spec:

JWKS URL looks like:
/.well-known/jwks.json

Most outh servers publish JWK like:
${baseUrl}/<?version>/keys
the version is optional

If nothing else, I would get arid of the .json

Josh Mandel (Apr 17 2021 at 22:16):

Can you clarify what you mean about "most OAuth servers"? And are you saying they're following some kind of standard? (I should note that at this stage we would make breaking changes to the specification only if there is a pressing reason to make a change -- e.g., if we discover something that makes the spec implementable.)

Josh Mandel (Apr 17 2021 at 22:51):

FWIW, AWS, Auth0, Akamai, and others do follow this .well-known/jwks.json pattern; it's as close to a convention as anything else I could identity.

Richard Braman (FLY.HEALTH) (Apr 17 2021 at 23:52):

I was referring to Okta and AzureB2C. From the looks of it, it is not standardized at all. See https://tools.ietf.org/html/rfc8414#section-2
Their example uses neither .well-known or keys. But the example does show jwks.json, which I had never seen before you mentioned it. It does seem widely used. But so is /keys The spec says jwks_uri should be advertised to /.well-known/oauth-authorization-server. Are we trying to standardize its uri for SHC?

Richard Braman (FLY.HEALTH) (Apr 17 2021 at 23:58):

@Abigail Watson when I scan the QR code above using my iphone's camera, it opens safari and tries to search the web for the patient's data. Doesn't seem to secure... Am I missing something?

Josh Mandel (Apr 18 2021 at 00:58):

SMART Health Cards imposes a hard requirement on this, relative to the issuer URL, yes.

Josh Mandel (Apr 18 2021 at 00:59):

You need a fully specified discovery algorithm for this to work.

Abbie Watson (Apr 18 2021 at 01:06):

Hi Richard,
Once the data gets to the patient, it's their choice to share the data freely and publicly if they wish. The security aspects are primarily required when dealing with somebody else's data. The auto-opening in Safari is maybe not desired, but the intent was to demonstrate that FHIR resources can be shared via QR codes. Also, there may be interest in sharing FHIR resources insecurely as a Receipt function.

Also, I added the security components in during the connectathon and in another stream. You're continuing a conversation from early in the implementation and connectathon.

Josh Mandel (Apr 18 2021 at 02:15):

#smart/health-cards has the discussion on this

Last updated: Apr 12 2022 at 19:14 UTC