CARIN Digital Insurance Card
2.0.0-ballot - STU 2 Ballot

CARIN Digital Insurance Card - Downloaded Version 2.0.0-ballot See the Directory of published versions

## General Guidance

Page standards status: Informative

### Actors

The following actors are part of the CARIN IG for Digital Insurance Card:

- CARIN IG for Digital Insurance Requestor or Consumer App: An application that initiates a data access request to retrieve patient data. This can be thought of as the client in a client-server interaction.
- CARIN IG for Digital Insurance Responder or Health Plan API: A product that responds to the data access request providing patient data. This can be thought of as the server in a client-server interaction.

### Conformance Verbs

§The conformance verbs - SHALL, SHOULD, MAY - used in this guide are defined in FHIR Conformance Rules. §

### Must Support

For profiles defined in other IGs, the meaning of Must Support is established in the defining IG. Note that the Must Support requirements for this IG are modeled after the US Core implementation guide. The requirements for Health Plan API actors are modeled on those for US Core Responders, and the requirements for Consumer App actors is modeled on those for US Core Requestors. c4dic-001 When querying and reading CARIN IG for Digital Insurance Card Profiles, Must Support on any profile data element SHALL be interpreted as follows: §23

- c4dic-002 Health Plan API actors SHALL be capable of populating all data elements as part of the query results as specified by the CARIN for Digital Insurance Card CapabilityStatement. §24
- c4dic-003 Consumer App actors SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail. §25
- c4dic-004 Consumer App actors SHALL be capable of displaying the data elements for human use. §26
- c4dic-005 In situations where information on a particular data element is not present and the reason for absence is unknown, Health Plan API actors SHALL NOT include the data elements in the resource instance returned as part of the query results. §27
- c4dic-006 In situations where information on a particular data element is missing and the Health Plan API actor knows the precise reason for the absence of data, Health Plan API actors SHALL send the reason for the missing information using either the nullFlavors or dataAbsentReason extensions. §28
- c4dic-007 When querying Health Plan APIs, Consumer App actors SHALL interpret missing data elements within resource instances as data not present in the Health Plan API actor's system. §29§30 c4dic-007 When querying Health Plan APIs, Consumer App actors SHALL interpret missing data elements within resource instances as data not present in the Health Plan API actor's system. §29§30

NOTE: Readers are advised to understand FHIR Terminology requirements, FHIR RESTful API based on the HTTP protocol, along with FHIR Data Types, FHIR Search and FHIR Resource formats before implementing CARIN IG for Digital Insurance Card requirements.

### Missing Data

If the source system does not have data for a Must Support data element with minimum cardinality = 0, the data element is omitted from the resource. If the source system does not have data for a required data element (in other words, where the minimum cardinality is > 0), follow guidance defined in the core FHIR specification and summarized in the US Core.

### Conformance to US Core Profiles

c4dic-010 Any Health Plan API actor in this IG SHALL: §31

- Be able to populate all profile data elements that have a minimum cardinality >= 1 and/or flagged as Must Support as defined by that profiles StructureDefinition.
- Conform to the US Core Server Capability Statement expectations for that profile’s type.

c4dic-011 Any Consumer App actor in this IG SHALL: §32

- Be able to process and retain all profile data elements that have a minimum cardinality >= 1 and/or flagged as Must Support as defined by that profiles StructureDefinition.
- Conform to the US Core Client Capability Statement expectations for that profiles type.

#### US Core Version Support

This IG supports two versions of US Core:

- US Core 6.1.0 (USCDI v3) - the primary dependency. The profiles in this IG are derived from US Core 6.1.0.
- US Core 7.0.0 (USCDI v4)

This IG profiles only three resources: Coverage, Patient and Organization. US Core 6.1.0 and US Core 7.0.0 place identical conformance constraints on all three - the cardinalities, Must Support flags, terminology bindings, types and invariants of US Core Coverage, US Core Patient and US Core Organization are unchanged between the two releases. The only difference is an annotation extension recording which elements are USCDI requirements, which carries no conformance obligation.

A server whose Coverage, Patient and Organization resources conform to either US Core release can therefore satisfy this IG. The C4DIC profiles are derived from US Core 6.1.0, and that derivation is equally valid for an implementer working to US Core 7.0.0.

Note that this equivalence covers only the three resources profiled here. US Core 7.0.0 differs from 6.1.0 in other areas; see the Cross Version Comparisons section of the US Core IG.

Note: The ONC HTI-1 rule set January 1, 2026 as the date on which US Core 6.1.0 becomes the base standard. Implementers building to USCDI v4 may use US Core 7.0.0.

### U.S. Core Data for Interoperability and 2015 Edition Common Clinical Data Set

The US Core Profiles were originally designed to meet the 2015 Edition certification criterion for Patient Selection 170.315(g)(7), and Application Access - Data Category Request 170.315(g)(8). They were created for each item in the 2015 Edition Common Clinical Data Set (CCDS). The 3.1.0 version of the US Core Profiles IG includes new requirements from the latest proposed ONC U.S. Core Data for Interoperability(USCDI) .

### Conformance to SMART Health Cards and Links

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 Healt hCards 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 are a derivation of SMART Health Cards that enable larger and dynamic data payloads as well as other methods of interaction.

#### Typical 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.

The Digital Insurance Card can be shared by a consumer in flexible ways. See Authorization and Distribution to learn more.

### A Payer, to provide members with SMART Health Digital Insurance Cards:

- c4dic-012 SHALL generate a complete and appropriate FHIR bundle using as described in this specification, including Coverage, Organization, and Patient information, as well as any additional information defined by this IG’s extensions. §33
- c4dic-013 SHALL follow the SMART Health Cards specification to create a SMART Health Card containing the FHIR bundle. §34
  - c4dic-014 SHALL create the SMART Health Card as a JWS string, as defined by http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/cards-specification.html. §35
  - c4dic-015 SHOULD implement revocation as defined by http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/cards-specification.html#revocation. §36
- c4dic-016 SHALL follow the SMART Health Links specification to create a SMART Health Link referencing the SMART Health Card. §37
  - c4dic-017 SHALL include the SMART Health Card as `application/smart-health-card`, a JSON file with a `.verifiableCredential array` containing the SMART Health Card JWS string, as specified by http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/cards-specification.html#via-file-download. §38
  - c4dic-018 SHALL NOT require, after initial download/retrieval, the user to set a passcode on a generated SMART Health Link, and SHALL NOT populate the `P` flag in the generated SMART Health Link Payload by default. §39
- c4dic-019 SHALL share the Digital Insurance Card with the member as other personal information would be shared. §40
- c4dic-020 SHALL provide the member the SMART Health Link in text URI format as well as QR format, as described here http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/cards-specification.html#presenting-health-cards-to-a-verifier. §41
- c4dic-021 SHALL in close proximity to the link and QR code, specify to the member: §42
  - Data referenced in the link.
  - Expiration date.
  - Whether or not the information is updated over time.
  - Caution about sharing the link with parties they trust.

### A Consumer App, in helping members manage and share their Digital Insurance Card:

- Can process the SMART Health Link as described here http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/links-specification.html#smart-health-links-receiving-application-processes-a-smart-health-link.
- c4dic-022 SHALL display the included data elements for the card. §43
  - c4dic-023 If the `flag: L` is present, indicating the contents are for long term use, the application SHALL update the display of the contents or display a message noting that the contents may be stale. §44
- c4dic-024 SHALL display the expiration date, `exp` (if present) for the card. §45
- c4dic-025 SHALL inform the user if the card has been revoked, as specified by http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/cards-specification.html#revocation. §46
- c4dic-026 SHALL update the display of data from the SMART Health Link. §47
- c4dic-027 SHALL provide the member with the ability to share the SMART Health Link as they see fit. §48
  - c4dic-028 SHALL provide the member the SMART Health Link in text URI format as well as QR code, as described here http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/links-specification.html. §49
  - c4dic-029 SHALL in close proximity to the link and QR code, caution the member about sharing the link with parties they trust. §50

### Providers, receiving the Digital Insurance Card:

Can process the SMART Health Link as described here http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/links-specification.html.

### Color Palette Extension

c4dic-030 When rendering foreground and background colors, the implementer SHOULD not use the same foreground and background colors and instead should algorithmically determine a high color contrast. §51