Version 2 of the Beneficiary Claims Data API (BCDA V2) is now available as of Summer 2021. If you are interested in learning more about how BCDA is changing in this new version of BCDA endpoints, please navigate to the BCDA Version 2 (V2) Data section for more information.

Claims Data Availability

Since the Beneficiary Claims Data API (BCDA) shares fully adjudicated Medicare claims data (Part A, B, and D), claims data availability relies on how quickly a claim has been submitted, processed, and approved. Per Section 6404 of the Affordable Care Act, the maximum period for submission of all Medicare Fee-for-Service claims has been reduced to no more than 12 months (1 calendar year) after the date services were furnished. CMS typically receives claims 3-4 weeks after care has been provided. Once received by CMS, it is possible for claims to undergo more than one round of processing to make adjustments, edits, and cancellations. Data will only be available via the API once a claim has been approved. For more details on claims submission and approval timeframes, please review this white paper which outlines the lifecycle of a Medicare claim, as well as timeframes for submission and approval (pages 11, 12, and 22 have details on month-over-month statistics).

Once a claim has been submitted, processed, and approved, BCDA receives the data on a weekly cadence, while Claim and Claim Line Feed (CCLF) files receive them monthly. New data is loaded from the CCW every weekend. In the event of a delay, there will be an announcement in the BCDA Google Group with updates on when the data will be refreshed.

How to Use BCDA Data

CMS provides model entities – Accountable Care Organizations (ACO), Direct Contracting Entities (DCE), Kidney Contracting Entities (KCE), and Kidney Choice First (KCF) Entities – with beneficiary identifiable claims data for assigned beneficiaries and other beneficiaries who receive primary care services from a model entity.

For adjudicated claims, BCDA serves data according to the bulk FHIR specification using three FHIR resources: ExplanationOfBenefit (EOB), Patient, and Coverage. This means that your claims data will be delivered through three FHIR resource types rather than 12 CCLF files.

The ExplanationOfBenefit (EOB) resource type provides similar information to what is provided in CCLF files 1-7. The EOB files contain lines within an episode of care, including where and when the service was performed, the diagnosis codes, the provider who performed the service, and the cost of care.
The Patient resource type provides similar information to what is provided in CCLF files 8 and 9. This is where you get your information about who your beneficiaries are, their demographic information, and updates to their patient identifiers.
The Coverage resource type provides information about beneficiaries’ insurance coverage, including information about dual coverage.

For partially adjudicated claims two FHIR resources are available to REACH ACOs: Claim and ClaimResponse.

The Claim resource type provides information about professional and institutional claims providers submit for payment, including the services that beneficiaries receive.
The ClaimResponse resource type provides information about a claim’s adjudication status and results process.

Confidentiality and Medical Data Sharing

In accordance with applicable law, including HIPAA and the regulations in 42 CFR Part 2, a beneficiary’s substance use disorder records are confidential. For example, claims data related to alcohol and drug abuse treatment are not shared.

In addition, BCDA will not share any data of beneficiaries who have opted out of data sharing.

BCDA Version 2 (V2) Data

Version 2 of the Beneficiary Claims Data API (BCDA V2) is available as of Summer 2021. To support industry alignment, BCDA V2 conforms to the FHIR R4 specification and follows the CARIN Implementation Guide. For adjudicated claims, below is a high level summary of data differences to expect between BCDA V1 (which supports FHIR version STU3) and BCDA V2 (which supports FHIR R4), focusing on the three primary resources provided in the API: ExplanationOfBenefit (EOB), Patient, and Coverage. In general, the differences for each resources can be grouped into two categories:

Differences due to changes in the FHIR specification between STU3 and R4.
Differences due to following a different implementation guide. For more information on specific API-related changes in BCDA V2, please visit the Getting Started Page.

Specification-Based Changes

ExplanationOfBenefit

The following table summarizes changes to the EOB resource due to changes between versions 3 (STU3) and 4 (R4) of the FHIR specification.

For details, see the FHIR Explanation of Benefit resource page, and select the R3 Diff tab under section 13.10.4 Resource Content

Change Type	Description	Examples
Consolidated/Removed Elements	Some elements were consolidated and/or removed. For instance, in STU3 there were two elements (Eob.Organization and Eob.Provider) that could represent the party responsible for the claim. In R4, this has been consolidated into one element (Eob.provider)	Eob.provider Eob.hospitalization
Added Constraints	Fifteen fields were changed from optional to mandatory. Changing the optionality in this context generally has no impact on users consuming this data. A few other minor constraints were added or modified (such as valueset bindings and reference targets)	Eob.use Eob.patient Eob.referral Eob.outcome
New Elements	Approximately 35 new elements were added to the EOB Resource. About 65% of these new elements are child elements of the .addItem property which is not supplied by BCDA. Of the remaining 35%, very few, if any, of these elements are populated by BCDA.	Eob.priority Eob.preAuthRef Eob.diagnosis.onAdmission Eob.formCode
Renamed Elements	A handful of elements were renamed. For users converting from V1 (STU3) to V2 (R4), it is likely that existing parsing/handling logic must be adjusted.	Eob.information → Eob.SupportingInfo Eob.careTeamLinkId → Eob.careTeamSequence Eob.diagnosisLinkId → Eob.diagnosisSequence Eob.service → Eob.productOrService

Patient

The following table summarizes changes to the Patient Resource due to changes between versions 3 (STU3) and 4 (R4) of the FHIR specification. The Patient Resource is normative, with a maturity level of 5. In other words, because this resource has been in a mature state for quite some time, the amount of change to this resource in R4 is minimal.

For details, see the FHIR Patient resource page, and select the R3 Diff tab under section 8.1.2 Resource Content

Change Type	Description	Examples
Consolidated/Removed Elements	Only one element was removed (Patient.animal) which has no effect on BCDA.	Patient.animal
Constraints	A handful of fields are bound to different valuesets. Other minor changes to default value and reference target.	Patient.active Patient.gender Patient.generalPractitioner

Coverage

The following table summarizes changes to the Coverage Resource due to changes between versions 3 (STU3) and 4 (R4) of the FHIR specification.

For details, see the FHIR Coverage resource page, and select the R3 Diff tab under section 13.1.3 Resource Content

Change Type	Description	Examples
New Elements	Six new elements were added to the Coverage Resource. Most of the new elements relate to costToBeneficiary and will not be supplied in BCDA.	Coverage.class.name Coverage.costToBeneficiary Coverage.costToBeneficiary.type
Consolidated/Removed Elements	The Coverage.grouping Element was removed. The equivalent element in R4 is Coverage.class. This element is provided in the API, so any user converting from V1 to V2 will be required to make minor changes to their parsing/handling logic.	Coverage.grouping
Added Constraints	A few changes to make certain elements mandatory. Generally this has little or no impact to any users consuming this data.	Coverage.beneficiary Coverage.payor

Implementation Guide-Based Changes

Version 1 of the API is based on the Blue Button 2.0 Implementation Guide, Version 2 is based on the CARIN CDPDE Implementation Guide. Subsequently, there are minor changes to the mapping and values of certain data elements based on conformance to the CARIN Implementation Guide. For instance, slicing/discriminator rules can be different, and some valuesets will be bound to CARIN or HL7 valusets instead of BlueButton. As an example, Patient.identifier.type in V2 is bound to http://www.hl7.org/fhir/us/carin-bb/ValueSet-C4BBPatientIdentifierType.html. As another example, EOB.Type is bound to http://www.hl7.org/fhir/us/carin-bb/ValueSet-C4BBPayeeType.html and the associated value will be one of the codes in that valueset.

The BCDA Data Dictionary provides additional information on how BCDA data is mapped to its CCLF counterparts, and how to use the discriminators for FHIR resources and extensions.

BCDA Data Dictionary

BCDA provides the CCLF to BCDA Data Dictionary to customers to facilitate their data mapping process.

The Data Dictionary was last updated in March 2024.

Because BCDA delivers data in the FHIR format, data field names will be different from data fields delivered through CCLF files. In this spreadsheet, BCDA has provided a crosswalk between all CCLF data fields and their new locations within BCDA claims files. The BCDA Data Dictionary also provides supplementary context for each of the CCLF/BCDA data fields, including:

Claim Field Names and Descriptions
Data Type
Format

Some data fields will not be mapped from CCLFs to BCDA in the Data Dictionary.

Additional information for unmapped fields can be found in the notes column of the BCDA Data Dictionary.

BCDA Partially Adjudicated Claims

The BCDA Partially Adjudicated Claims data was designed as an expansion of the data already available to Medicare providers from BCDA. Partially adjudicated claims are claims that have entered the Medicare processing system but are not fully paid or processed by CMS. This reduces the time to access Parts A and B Fee-for-Service (FFS) claims from typically up to 14 days for adjudicated claims, to 2-4 days using partially adjudicated claims data. REACH ACOs with BCDA credentials can currently access adjudicated claims data through three (3) bulk Fast Healthcare Interoperability Resource (FHIR®) resource types: Explanation of Benefit, Patient, and Coverage. The BCDA Partially Adjudicated Enhancement exposes the following two (2) additional bulk FHIR® resource types: Claim and ClaimResponse, so that REACH ACOs with BCDA credentials can also access partially adjudicated claims data.

Characteristics of BCDA Partially Adjudicated Claims Data

Adds additional data to a subset of fields that exist in BCDA today. These fields have the potential to be beneficial in supporting care coordination.
Provides Fee-for-Service (FFS) claims from the Medicare Fiscal Intermediary Shared System (FISS, for institutional claims) and Medicare Multi-Carrier System (MCS, for professional claims).
Excludes Part D (drug coverage) and Durable Medical Equipment (DME) claims.
Filters claim data so that REACH ACOs only receive data about their aligned beneficiaries (who have not opted out of data sharing). BCDA also excludes all claims with substance abuse codes (as required by the Confidentiality of Alcohol and Drug Abuse Patient Records Regulations, 42 CFR Part 2).
Must be retrieved through Beneficiary Claims Data API Version 2 (BCDA V2).

Sample BCDA Files

In order to aid in customers' understanding of BCDA file data and structure, for adjudicated claims, BCDA provides sample ExplanationOfBenefit, Patient, and Coverage FHIR Resource files to download. For partially adjudicated claim data, BCDA provides sample Claim and ClaimResponse FHIR® Resource files. These files contain synthetic data, but the structure and contents of the files are similar to the actual files you will be pulling and downloading from the BCDA Production Environment. These files contain data for 100 synthetic beneficiaries. Please visit the Getting Started page for a more in-depth look at the synthetic data options available to you through the BCDA Sandbox Environment.