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

General Guidance

Page standards status: Informative

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 ID	CPCDS Element Description	Resource/Profile Paths
175	Claim Payer Name	ExplanationOfBenefit.insurer.reference-> Organization.name
179	Adjudication Date	ExplanationOfBenefit.created
130	Patient Name	ExplanationOfBenefit.patient.reference->Patient.name
1	Member Id	ExplanationOfBenefit.patient.reference->Patient.identifier:memberid
132	Subscriber Id	ExplanationOfBenefit.insurance.coverage.reference->Coverage.subscriberId
135	Group Name	ExplanationOfBenefit.insurance.coverage.reference->Coverage.class:group.name
134	Group Id	ExplanationOfBenefit.insurance.coverage.reference->Coverage.class:group.value
155	Plan Name	ExplanationOfBenefit.insurance.coverage.reference->Coverage.class:plan.name
154	Plan Id	ExplanationOfBenefit.insurance.coverage.reference->Coverage.class:plan.value
177	Statement From Date	ExplanationOfBenefit.billablePeriod.start
178	Statement Through Date	ExplanationOfBenefit.billablePeriod.end
35	Payer Claim Unique Identifier	ExplanationOfBenefit.identifier[type.coding.code = ‘uc’].value
167	Claim Billing Provider Name	ExplanationOfBenefit.provider.reference->Organization.name   or Practitioner.name
101	Claim 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
94	Claim Billing Provider NPI	ExplanationOfBenefit.provider.reference->Organization.identifier[NPI]   or Practitioner.identifier[NPI]
121	Claim Payee	ExplanationOfBenefit.payee.party.reference->Organization.name   or Practitioner.name   or Patient.name
36	Line Number	ExplanationOfBenefit.item.sequence
90	Service (From Date) (Outpatient & Pharmacy)	ExplanationOfBenefit.item.ServicedDate   or ExplanationOfBenefit.item.ServicedPeriod.start
118	Service From Date (Professional & Oral EOB)	ExplanationOfBenefit.item.ServicedDate   or ExplanationOfBenefit.item.ServicedPeriod.start
86	Revenue Center Code (IG requires codes only, a display/text may not be provided)	ExplanationOfBenefit.item.revenue
20a	Line Submitted Amount	ExplanationOfBenefit.item.adjudication:adjudicationamounttype   [category.coding.code=’submitted’].amount
20b	Line Eligible Amount	ExplanationOfBenefit.item.adjudication:adjudicationamounttype   [category.coding.code=’eligible’].amount
20c	Line Discount Amount	ExplanationOfBenefit.item.adjudication:adjudicationamounttype   [category.coding.code=’discount’].amount
20d	Line Copay Amount or Line Co-insurance Amount	ExplanationOfBenefit.item.adjudication:adjudicationamounttype   [category.coding.code=’copay’].amount   or ExplanationOfBenefit.item.adjudication:adjudicationamounttype   [category.coding.code=’coinsurance’].amount
20e	Line Patient Deductible	ExplanationOfBenefit.item.adjudication:adjudicationamounttype   [category.coding.code=’deductible’].amount
20f	Sum 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
20g	Line Member Liability	ExplanationOfBenefit.item.adjudication:adjudicationamounttype   [category.coding.code=’memberliability’].amount
148a	Claim Submitted Amount	ExplanationOfBenefit.adjudication:adjudicationamounttype   [category.coding.code=’submitted’].amount
148b	Claim Eligible Amount	ExplanationOfBenefit.adjudication:adjudicationamounttype   [category.coding.code=’eligible’].amount
148c	Claim Discount Amount	ExplanationOfBenefit.adjudication:adjudicationamounttype   [category.coding.code=’discount’].amount
148d	Copay Amount or Co-insurance Liability Amount	ExplanationOfBenefit.adjudication:adjudicationamounttype   [category.coding.code=’copay’].amount   or ExplanationOfBenefit.adjudication:adjudicationamounttype   [category.coding.code=’coinsurance’].amount
148e	Member Paid Deductible	ExplanationOfBenefit.adjudication:adjudicationamounttype   [category.coding.code=’deductible’].amount
148f	Sum of   - Claim Amount Paid to Provider   - Member Reimbursement	ExplanationOfBenefit.adjudication:adjudicationamounttype   [category.coding.code=’paidtoprovider’].amount   + ExplanationOfBenefit.adjudication:adjudicationamounttype   [category.coding.code=’paidtopatient’].amount
148g	Member Liability	ExplanationOfBenefit.adjudication:adjudicationamounttype   [category.coding.code=’memberliability’].amount
92	Line 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
40	Procedure Code (IG requires codes only, display/text may not be provided)	ExplanationOfBenefit.item.productOrService
181	Payment Member Explanation	ExplanationOfBenefit.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 noteNumber	ExplanationOfBenefit.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.1 version of the US Core Profiles IG includes requirements from a previous ONC rule including U.S. Core Data for Interoperability(USCDI) v1 and the more recent 6.1.0 version of the US Core Profiles IG includes requirements from a more recent ONC rule including USCDI v3</a>