CARIN Digital Insurance Card
2.0.0 - STU 2.0

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

## Narrative Conformance

Page standards status: Informative

### Conformance Statement Index

This page provides an index of all conformance statements in this Implementation Guide. Each conformance statement is identified with a unique reference number in the format §c4dic-nnn.

Id | Expectation | Rule
--- | --- | ---
| SHALL SHOULD SHALL NOT |
§1 | SHALL | c4dic-035 Client applications and Payers SHALL support the standalone launch sequence (launch/Patient) of the SMART App Launch framework for user authorization and client authentication.
§2 | SHALL | c4dic-036 Payers SHALL publish their authorization and token endpoints for discovery in accordance with the SMART App Launch framework.
§3 | SHALL | c4dic-036 Payers SHALL publish their authorization and token endpoints for discovery in accordance with the SMART App Launch framework. §2
§4 | SHOULD | c4dic-031 There are instances where an individual was previously, but is no longer a member of a health plan (coverage is expired), the health plan SHOULD respond to requests for C4DIC Coverage resources using the latest version of each applicable Coverage resource, even if the individual is no longer a member of the Health Plan.
§5 | SHALL | 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.
§6 | SHALL | SHALL follow the SMART Health Cards specification to create a SMART Health Card containing the FHIR bundle.
§7 | SHALL | SHALL create the SMART Health Card as a JWS string, as defined by https://spec.smarthealth.cards/#health-cards-are-encoded-as-compact-serialization-json-web-signatures-jws.
§8 | SHOULD | SHOULD implement revocation as defined by https://spec.smarthealth.cards/#revocation.
§9 | SHALL | SHALL follow the SMART Health Links specification to create a SMART Health Link referencing the SMART Health Card.
§10 | SHALL | 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 https://spec.smarthealth.cards#via-file-download.
§11 | SHALL NOT | SHALL NOT require the user to set a passcode, and SHALL NOT enforce a passcode by default.
§12 | SHALL | SHALL share the Digital Insurance Card with the member as other personal information would be shared.
§13 | SHALL | SHALL provide the member the SMART Health Link in text URI format as well as QR format, as described here .https://docs.smarthealthit.org/smart-health-links/spec#sharing-user-transmits-a-shlink.
§14 | SHALL | SHALL in close proximity to the link and QR code, specify to the member
§15 | SHALL | SHALL display the included data elements for the card.
§16 | SHALL | 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.
§17 | SHALL | SHALL display the expiration date, `exp` (if present) for the card.
§18 | SHALL | SHALL inform the user if the card has been revoked, as specified by https://spec.smarthealth.cards/#revocation.
§19 | SHALL | SHALL update the display of data from the SMART Health Link
§20 | SHALL | SHALL provide the member with the ability to share the SMART Health Link as they see fit.
§21 | SHALL | SHALL provide the member the SMART Health Link in text URI format as well as QR code, as described here https://docs.smarthealthit.org/smart-health-links/spec#sharing-user-transmits-a-shlink.
§22 | SHALL | SHALL in close proximity to the link and QR code, caution the member about sharing the link with parties they trust.
§23 | SHALL | 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:
§24 | SHALL | 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.
§25 | SHALL | 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.
§26 | SHALL | c4dic-004 Consumer App actors SHALL be capable of displaying the data elements for human use.
§27 | SHALL NOT | 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.
§28 | SHALL | 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.
§29 | SHALL | 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.
§30 | SHALL | 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
§31 | SHALL | c4dic-010 Any Health Plan API actor in this IG SHALL:
§32 | SHALL | c4dic-011 Any Consumer App actor in this IG SHALL:
§33 | SHALL | 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.
§34 | SHALL | c4dic-013 SHALL follow the SMART Health Cards specification to create a SMART Health Card containing the FHIR bundle.
§35 | SHALL | 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.
§36 | SHOULD | c4dic-015 SHOULD implement revocation as defined by http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/cards-specification.html#revocation.
§37 | SHALL | c4dic-016 SHALL follow the SMART Health Links specification to create a SMART Health Link referencing the SMART Health Card.
§38 | SHALL | 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.
§39 | SHALL NOT | c4dic-018 SHALL NOT require the user to set a passcode, and SHALL NOT enforce a passcode by default.
§40 | SHALL | c4dic-019 SHALL share the Digital Insurance Card with the member as other personal information would be shared.
§41 | SHALL | 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.
§42 | SHALL | c4dic-021 SHALL in close proximity to the link and QR code, specify to the member:
§43 | SHALL | c4dic-022 SHALL display the included data elements for the card.
§44 | SHALL | 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.
§45 | SHALL | c4dic-024 SHALL display the expiration date, `exp` (if present) for the card.
§46 | SHALL | 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.
§47 | SHALL | c4dic-026 SHALL update the display of data from the SMART Health Link.
§48 | SHALL | c4dic-027 SHALL provide the member with the ability to share the SMART Health Link as they see fit.
§49 | SHALL | 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.
§50 | SHALL | c4dic-029 SHALL in close proximity to the link and QR code, caution the member about sharing the link with parties they trust.
§51 | SHOULD | 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.
§52 | SHOULD | c4dic-032 In instances where a Health Plan API actor is the Payer for multiple types of coverage for a member, the payer SHOULD represent each type of Coverage as a distinct Coverage resource.
§53 | SHOULD | c4dic-033 A government agency offers separate plans (or “Parts”) that each cover distinct types of services, such as inpatient, outpatient, and prescription fills. The Health Plan API Actor SHOULD represent these using three different Coverage resources, with different values in Coverage.type.
§54 | SHOULD | c4dic-034 A private insurance plan offers both medical and dental insurance using the same group ID and member number. The insurance plan SHOULD represent medical and dental insurance using separate Coverage resources, with different values in Coverage.type.