CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®), published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.1.0-snapshot1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/carin-bb/ and changes regularly. See the Directory of published versions

Conformance Requirements

Page standards status: Informative

Actors

The following actors are part of the CARIN IG for Blue Button®:

• CARIN IG for Blue Button® Requestor: 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 Blue Button® Responder: 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, with the requirements for CARIN Server APIs modeled on those for US Core Responders, and the requirements for CARIN Consumer Apps modeled on those for US Core Requestors.  When querying and reading CARIN IG for Blue Button® Profiles, *Must Support* on any profile data element SHALL be interpreted as follows: 

• Health Plan API actors SHALL be capable of populating all data elements the payer maintains as part of the query results as specified by the CARINBlueButtonHealthPlanAPICapabilityStatement.
• Consumer App actors SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.
• Consumer App actors SHALL be capable of displaying the data elements for human use.
• 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.
• When querying Health Plan API actors, Consumer App actors SHALL interpret missing data elements within resource instances as data not present in the Health Plan API actors system.
• 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 values (such as nullFlavors) from the value set where they exist or use the dataAbsentReason extension.
• Consumer App actors SHALL be able to process resource instances containing data elements asserting missing information.

NOTE: The above definition of *Must Support* is derived from HL7v2 concept Required but may be empty - RE described in HL7v2 V28_CH02B_Conformance.doc.

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 Blue Button® 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

Any actor acting as a Health Plan API actor in this IG SHALL:

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

Any actor acting a FHIR Client in this IG SHALL:

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

Profiling Constraints

The constraints in this guide's profiles have been applied to only address the scope defined in the guide. Data element that are not part of this scope have not been constrained out, and as such, may be included by the Health Plan API. If a Health Plan API includes additional information, there SHALL be no expectation that client applications support the data in any way in order to be conformant with this specification.

CapabilityStatement Server Requirement

Servers claiming conformance to this guide SHALL include a CapabilityStatement that has a CapabilityStatement.instantiates with a URL of http://hl7.org/fhir/us/carin-bb/CapabilityStatement/c4bb or a URL to the appropriate version of the CapabilityStatement.