Support

BCDA supports organizations (entities) participating in the following CMS alternative payment models:

• ACCESS (Advancing Chronic Care with Effective, Scalable Solutions)
• ACO REACH (Accountable Care Organization Realizing Equity, Access, and Community Health)
• GUIDE (Guiding an Improved Dementia Experience)
• IOTA (Increasing Organ Transplant Access)
• KCC (Kidney Care Choices)
• SSP (Shared Savings Program)

Terminated and discontinued organizations lose access to the API, including runouts data, the same day their participation in the model ends.

CCLF files are automatically available monthly using 12 flat files, and can be downloaded weekly upon request.

BCDA updates adjudicated claims weekly and partially adjudicated claims 4x/week using 3 NDJSON files (Coverage, Patient, ExplanationOfBenefit).

Additionally, BCDA is an API that uses the Bulk Fast Healthcare Interoperability Resources (FHIR) format, as required by CMS. Learn more about the differences.

BCDA v3 introduces a number of improvements, including:

• More frequent and timely updates
• Easier claims tracking
• Enhanced filtering capabilities
• Simplified, reliable data mapping capabilities
• Improved conformance with select FHIR Implementation Guides
• Simplified linking between partially and fully adjudicated claims
• Uses consistent claim identifiers across all phases of adjudication

We’ve also corrected issues some users encountered with v1 and v2 such as:

• Mismatched data between BCDA resources and CCLF files
• Missing data for newly attributed enrollees
• Issues for enrollees assigned more than one BENE_ID

You can learn more about v3 improvements and problems solved at Introducing BCDA v3.

Completely cover or label Personally Identifiable Information (PII) and Protected Health Information (PHI) as “REDACTED” in emails, screenshots, and documents. Ensure any masks are 100% opaque and in a format that supports layers.

Examples of PII and PHI:

• Medicare Beneficiary Identifier (MBI)
• Taxpayer Identification Number (TIN)
• National Provider Identifier (NPI)
• Social Security Number (SSN)
• API keys or access credentials (e.g., client ID and secret)
• authorization or bearer tokens

PII and PHI are often found in API requests or response payloads referenced in:

• the text of your Google Group posts or emails
• files attached to your Google Group posts or emails (e.g., XMLs, JSONs)
• screenshots attached to your Google Group posts or emails

Example of a redacted response:

{
    "taxpayerIdentificationNumber": "REDACTED",
    "nationalProviderIdentifier": "REDACTED"
}

Use caution with 3rd party web-based clients. By sharing your credentials, you may be allowing them to make REST calls on your behalf. This is a serious data privacy and security risk. We recommend using secure REST client tools.

It typically takes 2-4 days after submission for BCDA to receive partially adjudicated claims data and up to 7 days for adjudicated claims data. Even after adjudication, claims may go through additional processing. BCDA will continue to provide the latest updates available for each claim.

According to Section 6404 of the Affordable Care Act, Original Medicare claims must be submitted within 12 months (1 calendar year) of the date of service.

BCDA v3 sources data from CMS's Integrated Data Repository (IDR).

For earlier versions of BCDA, adjudicated claims data is loaded from the Chronic Conditions Data Warehouse (CCW). Partially adjudicated claims data is loaded from the Fiscal Intermediary Standard System (FISS) and Multi-Carrier System (MCS).

The following table shows how frequently Medicare claims data is refreshed and potentially available to eligible organizations.

¹ Data is loaded on the Monday after it's loaded into the source system, 0-7 days from processing or "adjudication."

To stay up to date with the latest claims data for your enrollees, we recommend exporting data from National Claims History once per week, and daily for all other sources. Use the _since parameter when running jobs to avoid downloading duplicate data.

BCDA requires that all production requests come from a registered IP address. Make sure the IP addresses you're using to request data have been added to the Allow List in your model-specific system. Visit Production Access for more details.

A status code of 429 indicates “Too Many Requests.” Wait until the period of time specified in the header has passed before making more requests.

This makes sure your client can adapt without manual intervention, even if the rate-limiting parameters change. Learn more about the 429 status code.