FHIR Chat · Digital Insurance Card · smart/health-cards

Stream: smart/health-cards

Topic: Digital Insurance Card

Grahame Grieve (Sep 23 2021 at 21:06):

@Mark Roberts @Adam Culbertson Creating this topic to discuss the use of the SHC card framework for Digital Insurance cards.

Grahame Grieve (Sep 23 2021 at 21:06):

First, do you have a spec or an example at this time?

Adam Culbertson (Sep 24 2021 at 12:40):

thanks @Grahame Grieve we do have a sample JSON object.

Grahame Grieve (Sep 24 2021 at 12:45):

want to share it here?

Adam Culbertson (Sep 24 2021 at 12:48):

Grahame Grieve said:

want to share it here?

Yes let me see if @Mark Roberts can post here. My work computer doesn't like to post things outside of our firewall.

Mark Roberts (Sep 24 2021 at 13:27):

I am trying to post it here. If this doesn't work, all of our content is posted here: https://confluence.hl7.org/display/CAR/Resources

DRAFT-JSONs-for-Digital-Insurance-Card-IG.json

Grahame Grieve (Sep 24 2021 at 13:37):

18kb... massive. A key aspect of the SHC framework that makes it very robust is that the data is extremely parsimonious. Your example is not; it seems extremely unlikely to me that all the information you're representing is on an existing card.

Adam Culbertson (Sep 24 2021 at 13:52):

@Grahame Grieve good point. If we want to leverage SMART Health Cards this piece would have to be widdled down to the essential data.

Mark Roberts (Sep 24 2021 at 13:53):

We captured a pretty comprehensive list of data elements that are commonly found on commercial insurance cards in the document below. We started to look at Medicare and Medicaid cards, but need more work on those sections. @Adam Culbertson correct me if I am wrong, but I think the JSON includes all the commercial data elements in the document below.

CARIN-IG-for-Digital-Insurance-Card-Data-Elements-9.9.211.xlsx

Adam Culbertson (Sep 24 2021 at 14:18):

@Mark Roberts yes this is indeed this list of elements. But I think perhaps what @Grahame Grieve is getting at is perhaps of that list there may be a few we would want to prioritize for including into a SMART health card that would be exchanged with a partner. Perhaps the SMART health card framework is out of scope here. But I think something we need to think about the breath of data we have and thing about what is essential for our use case.

Grahame Grieve (Sep 24 2021 at 14:47):

the first question that leaped out to me is the multiple person question. Does the digital insurance card need to capture all the persons on the logical card in the one digital card?

Adam Culbertson (Sep 24 2021 at 14:53):

@Grahame Grieve great question and one we wrestled with as a group. Some plans do list multiple persons on the same card and that is why we ultimately choose to support them. But again coming back to SMART health cards. If we want to support there is probably a compelling reason to break it at to one person per card.

Grahame Grieve (Sep 24 2021 at 14:54):

perhaps, yes. But if you want QR codes, and you aren't going to do it the SHC way because you have too much data, what option is left?

Adam Culbertson (Sep 24 2021 at 14:58):

@Grahame Grieve Yes, I agree. I think that is a question the group needs to wrestle with. Hence we either need to abandon the idea of using SMART Health cards, narrow down the JSON object, or find some middle of the road solution.

Grahame Grieve (Sep 24 2021 at 14:59):

sounds like it, but does that imply you also need to abandon the idea of using QR codes? And what would a middle of the road solution look like?

Adam Culbertson (Sep 24 2021 at 15:01):

@Grahame Grieve what's the time difference between US eastern time and you?

Grahame Grieve (Sep 24 2021 at 15:02):

10 hours right now. It's 1 am and I have a long night ahead of me

Amy Ballard (Sep 24 2021 at 22:30):

The QR codes we are talking about supporting in this IG are not SMART Health Card QR codes. Many insurance cards have QR codes on them. Ex. https://hmsa.com/Media/Default/images/member-id-card-ppo-compmed.jpg We are planning on allowing providers to include an image of these QR codes as an Attachment in an Extension

Amy Ballard (Sep 24 2021 at 22:57):

In a future version of the IG, we could support issuing a type of SMART Health Card, at which time we'd need to have profiles constraining the allowed data for the card. The user could potentially retrieve the full set of Coverage data mapped for this IG and also request a SMART Health Card be issued. The same way a user can currently retrieve all their immunizations from their provider and also request a SMART Health Card with their COVID vaccines.

Josh Mandel (Sep 24 2021 at 23:54):

The QR in this example is super tiny -- what does it convey / how is it used?

Amy Ballard (Sep 25 2021 at 01:03):

For this example, it appears to be the Subscriber ID, not sure how it's intended to be used. We have discussed that insurance cards have images, which could be logos, bar codes and QR codes. We'd like to define a way for insurers to optionally include these in the Coverage resource. We have not yet worked out the details of how we might convey the meaning/intended use for each image. QR codes are likely be used differently by different insurers. The "images" discussions are yet to come.

Grahame Grieve (Sep 25 2021 at 01:06):

that'll be a simple avoidance of keyboard entry errors - scan the barcode into the UI entry with a simple USB scanner

Adam Culbertson (Sep 28 2021 at 02:07):

@Grahame Grieve yes agreed and then you sovle 90% of my patient matching problem. :

Josh Mandel (Sep 28 2021 at 02:15):

Mistyping insurance numbers can't really be be 90% of the problem with patient matching, can it?

Adam Culbertson (Sep 28 2021 at 14:55):

@Josh MandelNo the data on the insurance card won't solve 90% of the problem. But to Grahme'ss comment "simple avoidance of simple keyboard entry errors" such as mistyping names, addresses, and DOB would solve a significant portion of it.

Ryan Howells (Jan 13 2022 at 17:52):

We are SUPER early in this discussion. In fact, we really haven't had any meaningful conversations about this because health plans have not indicated this is a priority for them right now. The goal has been to publish STU1 and simply make room for images as @Amy Ballard mentioned. As background, there are significant differences between what data elements health plan membership cards include across lines of business, employer groups, and states. Early indications are that it would be a heavy (maybe too difficult) lift to provide uniform SHC guidance as to what the ~1200 characters should include for each of the possible combinations but again, we need to discuss in more detail. @Grahame Grieve Is there a specific demand out there regarding why you are asking that we may be failing to take into account? Happy to reprioritize this discussion if that's the case. @Cille Kissel Watkins @Pat Taylor @Gail Kocher may also want to weigh in from the payer community.

Cille Kissel Watkins (Jan 13 2022 at 18:13):

Hi all - I second Amy's comments wholeheartedly. For STU1 of the IG, we focused on enabling essential elements found on the physical insurance cards to be passed, including a few image types. QR codes are used by a small number of plans to communicate MemberID or SubscriberIDs; barcodes are far more common communicating MemberIDs, names of beneficiaries, and plan details. Would be happy to point you all to some sample insurance cards from US insurers if there is confusion or concern about the data elements we are exposing in the initial IG.

For future versions of the IG (assuming there is interest from the community to take this forward), we are very interested in understanding how the insurance card data could be passed as a verifiable SMART health card. We had some initial dialogue with Josh about this a few months ago but would need to have more formal dialogue as a community. Once we get past this ballot reconciliation, we would welcome participation in our regularly scheduled Thursday meetings to discuss how we could make this a reality for STU2. If that timing is not convenient, we could organize another time to connect to augment our regularly schedule touch bases.

Josh Mandel (Jan 13 2022 at 19:29):

Clearly none of this should be affecting current term ballots. But it would be great to build some prototypes that explore what it would mean to support smart health links, as a background process.

If you want to schedule a conversation or better yet a working session to hack on some demonstrations here, I would be very happy to participate:-

Grahame Grieve (Jan 13 2022 at 20:07):

@Ryan Howells

@Grahame Grieve Is there a specific demand out there regarding why you are asking that we may be failing to take into account?

I have no particular stake in the ground regarding functionality. Just that the project when presented to FMG indicated an intention to use SHCs, but the way the project was progressing indicated incompatible technical thinking with SHC constraints. So I'm exploring that.

• strip the data down to what can be in an SHC
• use the QR code to refer to data elsewhere
• have a QR code that's only a limited portion of the data that is transferred at point of clerical processing
• don't use QR codes

I'm not invested in any of those, just trying to make sure that the project's work and it's stated goals align

Vitor Pamplona (Jan 13 2022 at 20:38):

I will be very interested in working with the group to fit a large payload into a single QR. I actually think the previous proposals are not really that large and can be made to fit into a QR with some encoding magic.

Grahame Grieve (Jan 13 2022 at 20:39):

well, the proposal I looked at was 18k and wasn't going to fit any time

Vitor Pamplona (Jan 13 2022 at 20:40):

In raw, yes it will never fit

Grahame Grieve (Jan 13 2022 at 20:43):

right. so my point was that either you aren't using SHCs, or you are working towards meeting the technical constraints, or you are working with the SHC group to find a 3rd course

Vitor Pamplona (Jan 13 2022 at 20:44):

SHCs support multiple QRs. One could definitely do that.

Vitor Pamplona (Jan 13 2022 at 20:45):

But there are better compression mechanisms out there. It would be a different spec, but you can expect to put a 60KB sparse json file into a 4Kb QR

Vitor Pamplona (Jan 13 2022 at 21:06):

Like I said, it's not really that big. Here's the JSON from @Mark Roberts signed following SHC: Mark-Roberts-JSON-as-an-SHC.png

Vitor Pamplona (Jan 13 2022 at 21:07):

Without any additional compression.

Josh Mandel (Jan 13 2022 at 22:40):

These 4kb QRs aren't easy to scan, especially when printed on paper or scanned from a consumer grade camera (subject is not perfectly flat, not evenly lit). We chose V22 as a pragmatic upper bound in SHC.

Josh Mandel (Jan 13 2022 at 22:41):

In any case, it's worth exploring density of inline data as well as approaches that link to external data.

Grahame Grieve (Jan 13 2022 at 22:59):

the Australian ICAO QR codes are more dense than SHCs (they have all the X509 stuff in there) and I have had problems scanning them all over the place

Vitor Pamplona (Jan 13 2022 at 23:16):

So, what's the limit for you? 1Kb?

Vitor Pamplona (Jan 13 2022 at 23:19):

We could use the EU's DCC standard to put all that data under 1KB QRs if we wanted to

Josh Mandel (Jan 13 2022 at 23:27):

I think the limit is best expressed in terms of QR symbol version rather than bytes -- V22, for example.

Vitor Pamplona (Jan 13 2022 at 23:43):

So, is V22 the limit for SHCs?

Josh Mandel (Jan 14 2022 at 02:33):

Yes, see https://spec.smarthealth.cards/#chunking for details

Vitor Pamplona (Jan 14 2022 at 12:56):

Hum.. which mode is the V22 for? Based on Example 2, it looks like that limitation requires folks to use QR's ECC L, which is not great. Otherwise that same QR goes into v25 for M, v30 for Q and v34 for H.

Vitor Pamplona (Jan 14 2022 at 13:04):

I would strongly suggest upping it to v25-28 and requiring to M. The L mode is probably the reason why @Grahame Grieve is having a hard time with ICAO cards (which can only use L), since the vast majority of reading inconsistencies out there come from "damaged" QR.

Josh Mandel (Jan 14 2022 at 15:14):

Keep in mind that v22 is an upper limit; implementers can increase error correction when they have smaller data sets, otherwise we break the data across multiple QRs (and again, these can be populated with less data if more air correction is desired). We chose an upper bound based on some testing, and we certainly have not discovered evidence that we have a lot of headroom here to increase the cap.

Vitor Pamplona (Jan 14 2022 at 15:23):

Sure, but what I am saying is that, in practice, a print of v22 on L is worse than v25 on M just because of the way people manage their QR papers (folding, scratching, oils, water damage, etc). Using only the version as a guide on the spec misses the point.

Vitor Pamplona (Jan 14 2022 at 15:26):

And if people are only using screens (like their phones instead of a printed card), the display reflections alone, especially in lower-end phones which are less bright and more reflective, makes any L QR hard to read.

Vitor Pamplona (Jan 14 2022 at 15:33):

In other words, in practice, the QR density is less impactful than the QR correction capabilities.

Josh Mandel (Jan 14 2022 at 15:44):

Are you familiar with some best practice guidance or data driven recommendation in this space? We struggled to find these, and relied on feedback from participants during spec development to set limits.

Vitor Pamplona (Jan 14 2022 at 15:50):

We did a study for the Good Health Pass blueprint last year. There are some very good considerations at the GS1 2D Barcode Verification Process Implementation Guideline: https://www.gs1.org/docs/barcodes/2D_Barcode_Verification_Process_Implementation_Guideline.pdf

Vitor Pamplona (Jan 14 2022 at 15:51):

But my comments here are based on the use of our universal verifier, with around 75K stored pictures of COVID QRs from the app in one of our client's databases.

Vitor Pamplona (Jan 14 2022 at 19:57):

Ok, I played a bit with this Insurance Card payload. Here's a SHC QR (v22 on L) with most of the information from the original JSON.

Changes were:

0. All Plan members were turned into Patients inside the Bundle. This allows for the use of references in the other objects
1. The organization's contact information should not be on the QR. This is mutable data and the QR should simply have a URL to download the most up-to-date contact information for each one of the purposes listed here.
2. The logo and color information should not be in the QR.
3. Instructions in English (due to internationalization issues) and Display names for the codes (which is alredy available from the coding system) were removed.
4. All extensions should be turned into regular fields.
5. This is using Brotli compression instead of ZLib, which produces 25% smaller QRs, and will require updating the SHC spec to support another compression algorithm.

The final payload looks like this:

{
  "type": [ "https://smarthealth.cards#insurance-card" ],
  "credentialSubject": {
    "fhirVersion": "4.0.1",
    "fhirBundle": {
      "resourceType": "Bundle",
      "entry": [
        { "resourceType": "Patient", "name": [ { "family": "Doe", "given": ["John"] } ], "id": "102345672-01"},
        { "resourceType": "Patient", "name": [ { "family": "Doe", "given": ["Jane"] } ], "id": "102345672-02"},
        { "resourceType": "Patient", "name": [ { "family": "Doe", "given": ["Jimmy"]} ], "id": "102345672-03"},
        { "resourceType": "Patient", "name": [ { "family": "Doe", "given": ["Ginny"]} ], "id": "102345672-04"},
        {
          "resourceType": "Coverage",
          "id": "8a01955891bc1c1262d689b616fb6e9e32d268e7a65632ce62ac347263112345",
          "identifier": [ { "value": "102345672-02", "assigner": { "reference": "Organization/2222222222" } } ],
          "type": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "HIP" } ] },
          "subscriber": { "reference": "Patient/102345672-01" },
          "beneficiary": { "reference": "Patient/102345672-02" },
          "relationship": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship", "code": "spouse" } ] },
          "period": { "start": "2021-01-01" },
          "payor": [ { "reference": "Organization/2222222222" } ],
          "class": [
            { "type": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/coverage-class", "code": "group"   }]},"value": "993355",   "name": "Stars Inc"},
            { "type": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/coverage-class", "code": "plan"    }]},"value": "11461128", "name": "Acme Gold Plus"},
            { "type": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/coverage-class", "code": "division"}]},"value": "11"},
            { "type": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/coverage-class", "code": "network" }]},"value": "561490",   "name": "Acme Gold Plus South"},
            { "type": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/coverage-class", "code": "rxbin"   }]},"value": "100045"},
            { "type": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/coverage-class", "code": "rxpcn"   }]},"value": "1234000"}
          ],
          "costToBeneficiary": [
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/ValueSet/coverage-copay-type", "code": "gpvisit"    }]},"valueString": "N/A" },
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/ValueSet/coverage-copay-type", "code": "spvisit"    }]},"valueString": "N/A" },
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/ValueSet/coverage-copay-type", "code": "emergency"  }]},"valueString": "N/A"},
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/ValueSet/coverage-copay-type", "code": "urgentcare" }]},"valueString": "N/A" },
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/ValueSet/coverage-copay-type", "code": "rx"         }]},"valueString": "DED THEN $10/$40/$70/25%"},
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/valueset-coverage-copay-type", "code": "FamOutDed"  }]},"valueMoney": {"value": "10000.00", "currency": "USD"}},
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/valueset-coverage-copay-type", "code": "FamInDed"   }]},"valueMoney": {"value":  "8000.00", "currency": "USD"}},
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/valueset-coverage-copay-type", "code": "FamRxOutDed"}]},"valueMoney": {"value":  "2000.00", "currency": "USD"}},
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/valueset-coverage-copay-type", "code": "FamRxInDed" }]},"valueMoney": {"value":  "1500.00", "currency": "USD"}},
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/valueset-coverage-copay-type", "code": "FamOutMax"  }]},"valueMoney": {"value": "12000.00", "currency": "USD"}},
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/valueset-coverage-copay-type", "code": "FamInMax"   }]},"valueMoney": {"value": "10000.00", "currency": "USD"}},
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/valueset-coverage-copay-type", "code": "FamRxOutMax"}]},"valueMoney": {"value":  "3000.00", "currency": "USD"}},
            { "type": { "coding": [ { "system": "https://hl7.org/fhir/valueset-coverage-copay-type", "code": "FamRxInMax" }]},"valueMoney": {"value":  "2000.00", "currency": "USD"}}
          ]
        },
        {
          "resourceType": "Organization",
          "id": "2222222222",
          "identifier": [{"system": "http://hl7.org/fhir/us/carin-bb/CodeSystem-C4BBIdentifierType.html","code": "payerid","value": "45002" }],
          "name": "Acme Insurance Co",
          "contact": "http://acmeinsurance.com/contactInfo"
        }
      ]
    }
  }
}

Screen-Shot-2022-01-14-at-2.43.37-PM.png

Vitor Pamplona (Jan 14 2022 at 20:05):

If the group is willing to transfer non FHIR-based payloads in the QR, then the QR size can be further cut in half for the same payload. As you can see, most of the QR is being occupied by overhead of FHIR. The content itself is quite minimal

Josh Mandel (Jan 14 2022 at 20:11):

Neat! I really do appreciate the very concrete suggestions and example here. I should say though: keep in mind that the changes you're describing would be significant breaking changes to the SHC spec; FHIR can't turn extensions into regular fields; FHIR also expects Bundle.entry.fullUrl. And at the end of the day even with these kinds of tweaks we still hit a capacity wall. Yes, overhead of FHIR is significant here; but other approaches require interop compromises or limit the ability to extend the data payloads or introduce new operational compelxity.

Vitor Pamplona (Jan 14 2022 at 20:12):

Agree. For the new fields, they would need to get those extensions into the usual FHIR process to turn them into fields. I think it is worth doing. They should have been there already.

Josh Mandel (Jan 14 2022 at 20:15):

Agree, but for context the "usual FHIR process" will take O(years)

Vitor Pamplona (Jan 14 2022 at 20:16):

In terms of the non-Fhir Payload, if a given Profile is "enforced" by the spec (similar to how Immunizations on SHC have a specific /constrict profile), then the extensibility is already compromised. An intermediary StructureMap could serve as a leaner version of the same payload without leaving the "FHIR Realm".

Vitor Pamplona (Jan 14 2022 at 20:16):

Basically, doing what the EU does. From FHIR to the EU DCC and then Back to FHIR when the verifier loads it.

Vitor Pamplona (Jan 14 2022 at 20:19):

Brotli compression is something you can add to the SHC spec very quickly.

if (header.zip == 'DEF') {
   // zlib compression/decompression
} else  if (header.zip == 'BR') {
  // Brotli
}

Josh Mandel (Jan 14 2022 at 20:20):

Adding it to the spec is easy, but adding it to every implementation not so much. (We did comparison testing early on with example payloads and chose zlib as a compromise between wide/easy support and perf.)

Josh Mandel (Jan 14 2022 at 20:22):

Agreed we may want more flexibily here, but the backwards compatibility story is tricky. Probably would need to introduce a new SHC version, and how does that play out for consumers who just seee a QR?

Vitor Pamplona (Jan 14 2022 at 20:25):

Verifiers are super used to the idea of certain QRs not working or even straight up crashing the app. Every issuer has a little customization that we need to adapt the code to. So, I wouldn't be that worried about it.

Vitor Pamplona (Jan 14 2022 at 20:31):

Another way to remove the FHIR Overhead is by using templates. Both CBOR-LD and JSONXT can kill those large field names and system values automatically. If the SHC creates a standardized "Profile" for each card type, the template would just be a coded version of that Profile. It would enforce that certain fields are and are not used and because it knows all possible valid combinations, it can encode most of these common strings into fixed integers, significantly reducing the payload size.

Josh Mandel (Jan 14 2022 at 22:24):

Encoding JSON property name strings into fixed integers was helpful but had a surprisingly small effect on payload size when we tested this (<10% on realistic examples if I recall)

Josh Mandel (Jan 14 2022 at 22:25):

Profiling everything up front is super powerful but you lose flexibility; at that point, you can throw away FHIR models in the payload altogether (like EU DCC)

Vitor Pamplona (Jan 14 2022 at 22:55):

payload size when we tested this (<10% on realistic examples if I recall)

It depends on how many times field names and values duplicate. Zlib takes care of duplications really well. So, the benefit is bigger when you have extensions, for instance, because each url is different. So, for cases with multiple immunizations of the same manufacturer, the zlib does a good job. CBOR-LD keeps the hierarchy and JSONXT fully removes field names and flattens the JSON out (Basically turning into a CSV file), bringing more gains.

Vitor Pamplona (Jan 14 2022 at 22:58):

But, for JSONXT to work well, the number of filled fields needs to be bigger than the number of nulls, which makes it horrible to encode the FHIR payloads without a specific Profile.

Josh Mandel (Jan 14 2022 at 23:00):

payload size when we tested this (<10% on realistic examples if I recall)

It depends on how many times field names and values duplicate.

Yes, this is why I specified realistic payloads

Last updated: Apr 12 2022 at 19:14 UTC