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

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.

IdExpectationConditional?Rule
 SHALL
 SHOULD
 SHALL NOT		 Yes
 No
 Any
§1SHALL 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.
§2SHALL c4dic-036 Payers SHALL publish their authorization and token endpoints for discovery in accordance with the SMART App Launch framework.
§3SHALL c4dic-036 Payers SHALL publish their authorization and token endpoints for discovery in accordance with the SMART App Launch framework. §2
§4SHOULD 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.
§5SHALL 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:
§6SHALL 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.
§7SHALL 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.
§8SHALL c4dic-004 Consumer App actors SHALL be capable of displaying the data elements for human use.
§9SHALL 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.
§10SHALL 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.
§11SHALL 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.
§12SHALL 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. §11
§13SHALL c4dic-010 Any Health Plan API actor in this IG SHALL:
§14SHALL c4dic-011 Any Consumer App actor in this IG SHALL:
§15SHALL 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.
§16SHALL c4dic-013 SHALL follow the SMART Health Cards specification to create a SMART Health Card containing the FHIR bundle.
§17SHALL 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.
§18SHOULD c4dic-015 SHOULD implement revocation as defined by http://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/cards-specification.html#revocation.
§19SHALL c4dic-016 SHALL follow the SMART Health Links specification to create a SMART Health Link referencing the SMART Health Card.
§20SHALL 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.
§21SHALL NOT c4dic-018 SHALL NOT require the user to set a passcode, and SHALL NOT enforce a passcode by default.
§22SHALL c4dic-019 SHALL share the Digital Insurance Card with the member as other personal information would be shared.
§23SHALL 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.
§24SHALL c4dic-021 SHALL in close proximity to the link and QR code, specify to the member:
§25SHALL c4dic-022 SHALL display the included data elements for the card.
§26SHALL 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.
§27SHALL c4dic-024 SHALL display the expiration date, exp (if present) for the card.
§28SHALL 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.
§29SHALL c4dic-026 SHALL update the display of data from the SMART Health Link.
§30SHALL c4dic-027 SHALL provide the member with the ability to share the SMART Health Link as they see fit.
§31SHALL 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.
§32SHALL c4dic-029 SHALL in close proximity to the link and QR code, caution the member about sharing the link with parties they trust.
§33SHOULD 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.
§34SHOULD 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.
§35SHOULD 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.
§36SHOULD 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.