Toward a Wider Adoption of Digital Insurance Cards

The insurance card in my wallet—where I always keep it in case of emergency—is getting pretty dog-eared and frayed. So I was intrigued when Mark Scrimshire, chief interoperability officer of OnyxOS, introduced me to developments over the past few years that will make digital insurance cards feasible. This article looks at what it will take to let us all check in to our doctor’s office as easily as we wave our cell phone before a scanner in a retail store.

Start with Standards

A typical digital validation in health care must be recognized by software on the patient’s device as well as sites at multiple institutions: providers, payers, pharmacies, and more. Therefore, standards are a prerequisite to digital insurance cards. Luckily (as the saying goes), there are many to choose from.

HL7, which has been setting standards for health care since 1987, leapt into the modern age of computer standards by adopting the FHIR standard. One of the FHIR standards, conveniently enough, is a digital insurance card. A complementary standard was created by an organization that has been developing standards for health care platforms even before the FHIR standard existed: SMART Health (previously the SMART Platform).

The digital card contains the typical information an insurance card needs to display, along with information that the payer uses to verify that the card is legitimate. Furthermore, the card can contain useful information about the patient’s identity, policy, benefits, and coverage. The patient can control which information is shared with a given provider.

This information is exchanged using JSON, like most web interactions. The standard can generate a QR code that the patient prints on paper or stores on a mobile device.

The payer can then verify the information by scanning the QR code when the patient comes in, or by letting the patient upload the QR code to a web site.

All these technologies exploit everyday, secure, web-based technologies such as SSL/TSL and OpenID Connect (OIDC).

Software Needed

So the nuts and bolts of a digital insurance card are in place. The standards are already being used for vaccination cards such as COVID-19. But what do patients, providers, and payers have to do in order to complete the chain and enable check-in with a click or a swipe?

The SMART Health standard thankfully makes the patient’s job simple. A payer such as Medicare could just put a card on its web site for each patient to download. Once you have a card, uploading a URL or QR code to a web site should take no more effort than typing in your Medicare number. More and more providers are asking patients to pre-register for their appointments, which eliminates the tedium and wasted time that both patients and office staff suffer when patients have to fill out a form at the time of arrival.

Ryan Howells is Principal at Leavitt Partners and Program Manager of the CARIN Alliance, a multi-sector stakeholder alliance focused on consumer-directed exchange. He says that current technologies will allow a patient to use an app of their choice to do the following before they enter the doctor’s office:

• Create a digital identity credential to authenticate themselves
• Aggregate and share their health information with their provider
• Schedule an appointment
• Upload their digital insurance card to their provider’s application

Once the patient enters the provider’s office, they will no longer need to fill out any additional paperwork and can focus on their visit. This workflow will also take a huge burden off the provider staff and save providers millions of dollars a year.

The provider has to do more work to integrate digital cards into its infrastructure. Another nonprofit, the Commons Project Foundation, has created the software to implement the SMART Health care reader. JP Pollak, technical lead on their digital insurance card program, describes the process: “a web app decodes and validates the insurance card, checks the issuer against the registry, then displays the contents and whether they are valid.

Pollak says that any EHR supporting the SMART App Launch Framework can install an application to do the validation. To be federally certified, an EHR has to support that framework. This should be help even small providers implement a digital card scanner.

The payer needs to set up the infrastructure to create individual cards for its members, sign them to ensure that the cards are valid and up to date, and distribute them. This information allows the provider to validate the cards, a topic I’ll take up in the next section.

Verification and Trust

It’s a trivial task to create a fake digital artifact that looks real. A fraudster could even set up a site to back up a digital insurance card and falsely claim to validate it on behalf of Medicare or some other payer. Web developers have created systems for thwarting such fraud, so let’s look at how they would work in health care.

Each digital card includes a URL where the payer can retrieve the keys needed validate the card. For a major payer like Medicare, the provider could use an API (defined by the HL7 insurance card standard) to query Medicare for the most up-to-date insurance information for the individual.

The payer needs to run a server that generates cryptographic keys that sign the cards. When the provider contacts the payer and submits the key from the card, the payer validates the keys.

The provider might also consult an online directory at a URL provided in the member’s card. One such directory includes geographic information on payers, which can help to identify them or do searches. Besides providing trust, the directory can store information such as keys to help the provider avoid another round-trip request to the payer.

Clearly, the critical elements here are who maintains the directory and how carefully they vet payers who want to be included.

A comparison with web server certificates may be useful here. When you contact a server, it sends a certificate that validates that it is meant to serve that URL. The verification cuts out certain “man in the middle” attacks where a rogue server pretends to be something like healthcareittoday.com. However, a server that tricks you into contacting it (perhaps by misspelling “healthcareittoday” as “healthcareitoday”) can provide its own certificate and make the site seem valid. Consulting a directory can prevent misspellings.

But web security also requires preventing a rogue site from registering its own certificate for a legitimate site. Thus the designation of a limited set of trusted servers to be a Certificate Authority (CA). The browser lists all CAs, and the CAs vet other web sites.

The process, being a gargantuan and complex bureaucracy, has breaches and weaknesses. Still, you’re less likely to be tricked by a false certificate than to be denied access to a legitimate cite because the administrator failed to update its certificate or register it correctly.

So a simple registry may be all that payers and providers need for secure validation.

Howells says that the use of digital signatures prevents someone from simply copying a patient’s legitimate card and using it to gain access to treatment. Pollak says that the directory maintained by the Commons Project validates payers thoroughly, using human contacts. The project also runs an application every night to collect, validate, and digitally sign the latest keys from each payer.

Payers will certainly continue to distribute paper cards to patients who want them. But it can save an enormous amount of money if a lot of patients go digital. For patients who are comfortable with the technology, it can make life easier by simplifying check-ins and web activities.

Potential Future Uses

The applications I’ve mentioned in this article are only a start. Whenever information is digitized, we can hope for new and unexpected applications

Future digital cards might provide details such as an advance directive or a list of prescriptions. The advance directive is valuable at an emergency room, and prescriptions at pharmacies and providers.

Scrimshire offers a possible scenario that can save lives: medicine reconciliation. Pharmacies often know more about what a patient is taking than the providers do, because a patient may visit many providers and also use over-the-counter medications; surprisingly often, dangerous combinations of medications result. A medicine reconciliation brings hidden risks to the surface.

In Scrimshire’s suggested scenario, a patient submits their digital card to the pharmacy when filling a new prescription. The pharmacy offers a medicine reconciliation. When the patient assents, the pharmacy checks their records at the payer and uses information such as prescription drug claims to perform the reconciliation. Results are returned to the patient and, optionally, the prescribing physician. The patient has control over the flow of information.

The CARIN Alliance has created a FHIR implementation of CMS Blue Button 2.0 that could be the foundation for digital insurance cards. Version 2.0 is a greatly expanded version of the classic Blue Button created by the Department of Veteran Affairs in 2010. Medicare uses Blue Button 2.0 to provide members (and the computer programs they use) with access to their coverage and claims; hundreds of payers support the standard too.

A great deal of software and infrastructure have gone into digital insurance cards. Besides the convenience and security they already offer, the information they provide in standardized form will likely be useful for innovations we don’t even imagine currently.