CARIN Digital Insurance Card
0.1.0 - STU 1 Ballot

This page is part of the CARIN Digital Insurance Card (v0.1.0: STU 1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.0.0. For a full list of available versions, 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
Beneficiary Any individual that selects or is covered by benefits provided by government programs
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: App registers with a payer endpoint and receives a client ID and client secret

Actors:

  • Consumer (aka Subscriber, Beneficiary, 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.
  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 Consumer and authorized patient/beneficiary 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.