This page is part of the CARIN Blue Button Implementation Guide (v2.1.0-snapshot1: STU 2) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 2.0.0. For a full list of available versions, see the Directory of published versions
Page standards status: Informative |
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.
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 |
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>