CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®)
2.0.0 - STU 2 US

This page is part of the CARIN Blue Button Implementation Guide (v2.0.0: STU 2) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

General Guidance

Considerations for Improving Interoperability

Many of the codes used in this guide are proprietary with licensing requirements. While it is recommended that consumer apps acquire the necessary licenses to show descriptions for these codes, not all app developers may be in a position to do so. Because of this, payers MAY choose to provide a concept text [CodeableConcept].text or the coding display `[CodeableConcept].coding.display. It is the responsibility of the payer to make sure that the descriptions provided are correct.

If the ‘display’ element is populated, the string used in display SHALL be one of the display strings defined for that code by the code system (code systems may define multiple display strings for a single code). If the code description available is not known to be an exact match of a display string defined by the code system, the [CodeableConcept].text should be used in place of the [CodeableConcept].coding.display.

Payers MAY choose to also provide resource level text to enable consumers apps to render resources in a manner that the payer would like to have the data presented. The [Resource].text is a Narrative datatype that has a div element that is an xhtml datatype. This element MAY be used to provide an easily renderable version of the resource that is meant for human viewing. This capability may be of particular interest to payers for ExplanationOfBenefit resources and can be used to enable the rendering of the Explanation of Benefit data in a fashion similar to their mailed or portal accessible Explanation of Benefit documents.

Explanation of Benefit information can be complex. Many of the data elements in this guide go beyond what is commonly included in printed Explanation of Benefit documents today. Payers may also provide additional data elements beyond what is in this guide. As part of their API documentation, Payers SHOULD include descriptions of the data elements they provide, particularly for data elements not covered in this guide, and may consider providing a display mapping like can be found in the Example Printed Explanation Of Benefit Mapping section of this implementation guide.

Printed Example Explanation Of Benefit Mapping

Explanation Of Benefits documents that are either mailed in a physical form or downloaded through a member portal vary widely from payer to payer. There is no such thing as a standardized Explanation Of Benefits document format. There are some common elements across many of these documents, such as how much was charged by a provider and how much is covered by the insurance, but the manner in which this data is presented is determined by the individual payer.

The information found in payer Explanation Of Benefits documents represent only a subset of the data that may be available through the use of the profiles defined in this implementation guide. Printed Explanation of Benefits documents usually present a member friendly overview of services, charges, cost sharing, and benefits and do not usually contain the claim details or other more detailed codified and discrete data made available through this implementation guide’s profiles.

Below is an example generic Explanation Of Benefits document that represents some of the information one might find from payers. This example is not exhaustive, but does present some common information found on these documents. As shown in this example document, payers may include more than one claim on a single explanation of benefit document. The ExplanationOfBenefit profiles in this guide address a single claim. In this example there would be two ExplanationOfBenefit resources, one for each claim, that both relate to this one “printed” document. Below is an example mapping from these informational elements to CPCDS data elements and specific resource data element paths. This mapping can be used by app developers as guidance to understanding how information found on EOB documents relate to the profiles in this guide. This mapping can also be used by payers as guidance for how they could further develop their API documentation to enable client apps connecting to their API.

CPCDS Element IDCPCDS Element DescriptionResource/Profile Paths
175Claim Payer NameExplanationOfBenefit.insurer.reference-> Organization.name
179Adjudication DateExplanationOfBenefit.created
130Patient NameExplanationOfBenefit.patient.reference->Patient.name
1Member IdExplanationOfBenefit.patient.reference->Patient.identifier:memberid
132Subscriber IdExplanationOfBenefit.insurance.coverage.reference->Coverage.subscriberId
135Group NameExplanationOfBenefit.insurance.coverage.reference->Coverage.class:group.name
134Group IdExplanationOfBenefit.insurance.coverage.reference->Coverage.class:group.value
155Plan NameExplanationOfBenefit.insurance.coverage.reference->Coverage.class:plan.name
154Plan IdExplanationOfBenefit.insurance.coverage.reference->Coverage.class:plan.value
177Statement From DateExplanationOfBenefit.billablePeriod.start
178Statement Through DateExplanationOfBenefit.billablePeriod.end
35Payer Claim Unique IdentifierExplanationOfBenefit.identifier[type.coding.code = ‘uc’].value
167Claim Billing Provider NameExplanationOfBenefit.provider.reference->Organization.name
  or
Practitioner.name
101Claim Billing Provider Networking Status (If claim is not adjudicated in alignment with network status, an process note is typically provided)ExplanationOfBenefit.adjudication
  :adjudicationamounttype[category.coding.code=billingnetworkcontractingstatus]
  .reason
94Claim Billing Provider NPIExplanationOfBenefit.provider.reference->Organization.identifier[NPI]
  or
Practitioner.identifier[NPI]
121Claim PayeeExplanationOfBenefit.payee.party.reference->Organization.name
  or
Practitioner.name
  or
Patient.name
36Line NumberExplanationOfBenefit.item.sequence
90Service (From Date) (Outpatient & Pharmacy)ExplanationOfBenefit.item.ServicedDate
  or
ExplanationOfBenefit.item.ServicedPeriod.start
118Service From Date (Professional & Oral EOB)ExplanationOfBenefit.item.ServicedDate
  or
ExplanationOfBenefit.item.ServicedPeriod.start
86Revenue Center Code (IG requires codes only, a display/text may not be provided)ExplanationOfBenefit.item.revenue
20aLine Submitted AmountExplanationOfBenefit.item.adjudication:adjudicationamounttype
  [category.coding.code=’submitted’].amount
20bLine Eligible AmountExplanationOfBenefit.item.adjudication:adjudicationamounttype
  [category.coding.code=’eligible’].amount
20cLine Discount AmountExplanationOfBenefit.item.adjudication:adjudicationamounttype
  [category.coding.code=’discount’].amount
20dLine Copay Amount or Line Co-insurance AmountExplanationOfBenefit.item.adjudication:adjudicationamounttype
  [category.coding.code=’copay’].amount
  or
ExplanationOfBenefit.item.adjudication:adjudicationamounttype
  [category.coding.code=’coinsurance’].amount
20eLine Patient DeductibleExplanationOfBenefit.item.adjudication:adjudicationamounttype
  [category.coding.code=’deductible’].amount
20fSum of
  - Line Amount Paid to Provider
  - Line Member Reimbursement
ExplanationOfBenefit.item.adjudication:adjudicationamounttype
  [category.coding.code=’paidtoprovider’].amount
  +
ExplanationOfBenefit.item.adjudication:adjudicationamounttype
  [category.coding.code=’paidtopatient’].amount
20gLine Member LiabilityExplanationOfBenefit.item.adjudication:adjudicationamounttype
  [category.coding.code=’memberliability’].amount
148aClaim Submitted AmountExplanationOfBenefit.adjudication:adjudicationamounttype
  [category.coding.code=’submitted’].amount
148bClaim Eligible AmountExplanationOfBenefit.adjudication:adjudicationamounttype
  [category.coding.code=’eligible’].amount
148cClaim Discount AmountExplanationOfBenefit.adjudication:adjudicationamounttype
  [category.coding.code=’discount’].amount
148dCopay Amount or Co-insurance Liability AmountExplanationOfBenefit.adjudication:adjudicationamounttype
  [category.coding.code=’copay’].amount
  or
ExplanationOfBenefit.adjudication:adjudicationamounttype
  [category.coding.code=’coinsurance’].amount
148eMember Paid DeductibleExplanationOfBenefit.adjudication:adjudicationamounttype
  [category.coding.code=’deductible’].amount
148fSum of
  - Claim Amount Paid to Provider
  - Member Reimbursement
ExplanationOfBenefit.adjudication:adjudicationamounttype
  [category.coding.code=’paidtoprovider’].amount
  +
ExplanationOfBenefit.adjudication:adjudicationamounttype
  [category.coding.code=’paidtopatient’].amount
148gMember LiabilityExplanationOfBenefit.adjudication:adjudicationamounttype
  [category.coding.code=’memberliability’].amount
92Line Payment Denial Code (In EOB Documents, this is a payer defined code. These codes are not included in the IG. Instead, this IG uses CARC and RARC codes. Payers may include their own codes and descriptions in process note – 181)ExplanationOfBenefit.item.adjudication:denialreason.reason
40Procedure Code (IG requires codes only, display/text may not be provided)ExplanationOfBenefit.item.productOrService
181Payment Member ExplanationExplanationOfBenefit.processNote.text[number = ExplanationOfBenefit.item.noteNumber]
*Remark codes are payer specific and not defined by this IG. These remarks are generally included in the process note, which can be linked by the noteNumberExplanationOfBenefit.item.noteNumber

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)