CARIN Digital Insurance Card, published by HL7 International / Payer/Provider Information Exchange Work Group. This guide is not an authorized publication; it is the continuous build for version 1.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/carin-digital-insurance-card/ and changes regularly. See the Directory of published versions

Use Case

Terms and Concepts

Term	Definition
Subscriber	An individual or entity that selects benefits offered by an entity, such as an employer, government, or insurance company
Dependent	An individual, other than the subscriber, who has insurance coverage under the benefits selected by a subscriber
Member	Any individual covered by the benefits offered by an entity, such as an employer or insurance company. In the US, some government programs refer to Members as Beneficiaries.
Patient	An individual who has received, is receiving or intends to receive health care services. (Health care services as defined by federal and state regulations.)
Personal Representative	Per the HIPAA privacy regulations at 45 CFR 164.502(g), a personal-representative is someone authorized under state or other applicable law to act on behalf of the individual in making health care related decisions (such as a parent, guardian, or person with a medical power of attorney)
Payer	Public or private party which offers and/or administers health insurance plan(s) or coverage and/or pays claims directly or indirectly. Examples include: Insurance Company Health Maintenance Organization Medicare Third-party Administrator Repricer

Use Case - Consumer Access to their Insurance Card Data

Background

This implementation guide is designed to standardize the way that health insurance companies provide the data elements found on the physical insurance card in a FHIR-based API exchange. The primary use case is to support insurance members (or their personal representatives) who wish to retrieve their current proof of insurance coverage digitally via a consumer-facing application. This will provide an alternative to using the physical insurance card as proof of insurance.

Scenario

When an individual visits a healthcare provider, they may be asked to provide proof of insurance prior to receiving care. Instead of relying on their physical insurance card, the individual may pull out their phone and open a digital application to display their insurance card information. This will assist in cases of a lost or forgotten physical insurance card. The provider can capture the necessary information for proof of insurance based on the information displayed in the consumer-facing application.

Consumer-Directed Exchange

Consumer-directed exchange occurs when a consumer or an authorized caregiver invokes their HIPAA Individual Right of Access (45 CFR 164.524) and requests their digital health information from a HIPAA covered entity (CE) via an application or other third-party data steward. 

Technical Workflow

Precondition: Consumer App registers with a payer endpoint and receives a client ID and client secret

Actors:

• Consumer (aka Subscriber, Member, Dependent, Patient, or Personal Representative)
• Consumer App (aka digital third-party application selected by and primarily for the Consumer with a consumer-facing user interface)
• Health Plan API (aka Payer, Covered Entity)
• Health Plan’s Identity and Access Authorization server

Flow:

1. Consumer App presents a list of potential Payers / Health Plans that can be accessed by the Consumer.
2. Consumer selects the Payer / Health Plan to initiate the login and consent flow.
3. Consumer App redirects to the Health Plan’s Identity and Access Authorization server. Please note: The Health Plan may leverage a Third Party authentication service or technology for user login.
4. Consumer enters the credentials and consents to data sharing.
5. Health Plan's Identity and Access Authorization server validates the credentials, generates and returns to the Consumer App an OIDC token with authorized Consumer identities encoded.
6. Consumer App successfully links the user to the Payer / Health Plan and notifies the Consumer.
7. Consumer App requests the Coverage resource and associated resources as desired (i.e. Organization and/or Patient) along with the token and PatientID from step #5.
8. Health Plan’s Authorization server validates the access token.
9. Health Plan's FHIR API responds to the Consumer App with a bundle of the requested FHIR resources.
10. Consumer App receives the FHIR data and presents the information to the consumer.

Use Case - Consumer Access and Exchange

The Digital Insurance Card can also be made available to the member in a verifiable, tamper-proof package that the subscriber can store, manage, and share with healthcare providers as they see fit. In this model, the payer provides the member with a QR code or URL representing their digital insurance card, likely using the same modalities used to share digital cards today (e.g. payer mobile application, website, email). The member is able to present the QR code to be scanned during in-person visits or provide the QR code or URL to mobile or web forms during online registration or check-in flows. The provider then uses the QR code or URL to retrieve the Digital Insurance Card and verify its authenticity.

[SMART Health Cards](https://spec.smarthealth.cards/) are a FHIR-based verifiable credential technical framework that has been made available to hundreds of millions of people around the world for proof of vaccination and infectious disease laboratory testing results.

[SMART Health Links](https://docs.smarthealthit.org/smart-health-links/design) are a derivation of SMART Health Cards that enable larger and dynamic data payloads as well as other methods of interaction.

Flow:

1. Payer shares the insurance card with a member (e.g., as a QR code and text-based link, via the payer website, mobile application, secure messaging, etc.).
2. Member downloads/retrieves the QR code and/or link.
3. Member stores the QR code and link as they see fit, with options ranging from printing on paper to storing in health apps or wallets capable of interpreting SMART Health Links.
4. Member presents the SMART Health Link to healthcare provider.

In-person:

1. Member presents the QR code on their device or paper.
2. Check-in staff or kiosk scan the QR code.

Online:

1. Member provides the insurance card to the online check-in app or web flow by pasting the link into a field, uploading a image of the QR, or in the future via API-based methods tailored to wallet and health apps.
2. Healthcare provider processes the SMART Health Link and retrieves the insurance card information from the Payor (or designated data hosting service), verifying cryptographic signatures if desired.
3. Healthcare provider, EHR vendor, or other platform vendor incorporates insurance information into existing workflows.