CARIN Digital Insurance Card
2.0.0 - STU 2.0 United States of America flag

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 2.0.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

Consumer Access to their Insurance Card Data

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.