Issued by: Centers for Medicare & Medicaid Services (CMS)

Issue Date: June 01, 2012

Overview

The Beneficiary Claims Data API (BCDA) enables Accountable Care Organizations (ACOs) participating in the Shared Savings Program to retrieve Medicare Part A, Part B, and Part D claims data for their prospectively assigned or assignable beneficiaries. In the production environment, the API provides data parallel to Claim and Claim Line Feed (CCLF) files*, currently provided monthly to Shared Savings Program ACOs by CMS. This includes Medicare claims data for instances in which beneficiaries receive care outside of the ACO, allowing a full picture of patient care.

Representatives of Shared Savings Program ACOs are now invited to express their interest in joining the production environment by completing the BCDA Production Onboarding Request Form. While you wait to onboard in the production environment, we invite developers, analysts, and administrators at Shared Savings Program ACOs to try out the BCDA Sandbox experience.

• What’s the difference between the sandbox and production environments? BCDA’s production environment provides actual patient claims data on an ACO’s prospectively assigned or assignable beneficiaries, while the sandbox uses the same API structure but contains no beneficiary PII or PHI.

• Why should my ACO try the sandbox first? ACOs who have gotten used to working in the sandbox have found it easier to make the switch to the production environment. Since beneficiary claims data must be treated in accordance with HIPAA regulations, the sandbox environment provides a lower-stress environment for retrieving data from the API before touching actual patient data.

• What if my ACO participates in a CMS Innovation Center model? BCDA’s initial goal is to provide bulk beneficiary claims data that meets the needs of Shared Savings Program ACOs. In the months ahead, BCDA’s research team will begin learning about the data needs of Innovation Center Model ACOs, in order to begin accommodating those ACOs in the API in the future. While the sandbox environment focuses on the needs of Shared Savings Program ACOs, all ACOs and their vendor partners are invited to explore the sandbox and give their feedback.

Note: Some data fields have not yet been mapped from CCLFs to BCDA; The Beneficiary FHIR Data Server (BFD) API team is working hard to map all of the CCLF fields in the near future.

Getting Started

Moving from the CCLF file structure to BCDA’s FHIR-based API is a fairly big change. BCDA provides documentation and user guides to help Shared Savings Program ACOs at any stage of technical understanding learn how to interact with the API and the data.

• If BCDA is going to be your first API: start with the guide to Getting Started in Sandbox.
• If you’ve worked with APIs before: start with the Advanced Sandbox User Guide.
• To learn more about the new data structure BCDA will deliver: review the Guide to Working with BCDA Data.
• To join the queue for an invitation to the production environment: fill out the BCDA Production Onboarding Request Form. We will onboard a few ACOs at a time in the order in which requests are received.

Frequently Asked Questions

• Why is CMS making this change?
  • By using a standards-based API, BCDA furthers CMS’ ongoing commitment to MyHealthEData, a government-wide initiative that emphasizes adopting an API-first approach to modernize how CMS exchanges data with stakeholders across the healthcare system.
  • CMS intends for BCDA to meet four main goals for SSP ACOs:
    • Improve ease of access to bulk beneficiary claims data data
    • Decrease the time for CMS to implement any required or requested updates to support the ACO program
    • Reduce burden on ACOs for changes to the data or data format
    • Enhance efficiency by enabling system-to-system communication and reducing the need for manual intervention to retrieve and manipulate the data
• Are the CCLFs going away?
  • No, CCLF files are not going away. CMS wants to make sure Shared Savings Program ACOs have time to work with both formats together to understand similarities and differences, become familiar with the API, and receive data in the most user friendly format.
• Why should my ACO use BCDA?
  • CMS believes that SSP ACOs and their vendor partners will be better able and more easily leverage and use the data provided, since it will be in a more user-friendly format and can be more easily targeted to narrow in on specific data elements.
    • SSP ACOs can retrieve bulk claims data on a weekly, rather than monthly, basis, at a time of their choosing.
    • BCDA allows system-to-system communication and data transfer, reducing the manual intervention currently required to retrieve CCLF files.
  • BCDA is built in accordance with feedback from SSP ACOs and their vendor partners. When you use BCDA in sandbox or production, you are invited to share feedback with CMS and ensure we are creating an API that meets your organization’s needs.
• Why are Shared Savings Program ACOs getting access to this data?
  • As indicated in the regulation §425.704, “subject to providing the beneficiary with the opportunity to decline data sharing as described in this §425.708, and subject to having a valid DUA in place, CMS, upon the ACO’s request for the data for purposes of evaluating the performance of its ACO participants or its ACO providers/suppliers, conducting quality assessment and improvement activities, and conducting population-based activities relating to improved health, will provide the ACO with beneficiary identifiable claims data for preliminarily prospectively and prospectively assigned beneficiaries and other beneficiaries who receive primary care services from an ACO participant that submits claims for primary care services used to determine the ACO’s assigned population under subpart E of this part during the performance year.”
• What claims does BCDA exclude?
  • BCDA excludes all claims with substance abuse codes (as required by the Confidentiality of Alcohol and Drug Abuse Patient Records Regulations, 42 CFR Part 2). Additionally, if beneficiaries have modified their preferences regarding claims data sharing via 1-800-MEDICARE, those preferences will extend to this program as well.
• Sounds great! Where do I start?
  • If your Shared Savings Program ACO is ready to start working with BCDA, the first step is to let us know you’re interested. BCDA will onboard ACOs to the production environment in the order in which they sign up.
  • While you wait, join the BCDA Google Group to learn how other ACOs are working with the API, try out the sandbox environment, and get familiar with how to translate between CCLF and BCDA data fields.
• I’m a vendor who works with Shared Savings Program ACOs. How can I work with BCDA?
  • Vendors who work with Shared Savings Program ACOs to assist in managing their data should work with their ACO partners to interface with BCDA.
• There are so many new acronyms on this page. What do they mean?
  • API: An API (Application Programming Interface) is a set of features and rules that exist inside a software program that allows other software programs to interact with it. For example, you can build an app that uses the Twitter API to get information or data from a user’s Twitter account. APIs are used in a wide variety of ways, but for our purposes, you can think of an API as a pipeline that can allow your ACO’s computer systems to receive data directly from CMS’ databases.
  • FHIR: FHIR (Fast Healthcare Interoperability Resources) is a specification for exchanging healthcare data electronically, allowing any system to access and consume this data to solve clinical and administrative problems around healthcare-related data. BCDA is built on the Beneficiary FHIR Data Server (BFD) API, which has structured its data using the FHIR standard. BCDA will use three resource types from the FHIR specification: explanation of benefits, patient, and coverage. Learn more about FHIR in the guide to working with BCDA data.
  • NDJSON: New Line Delimited JSON is the file format used by the bulk FHIR specification. An NDJSON file provides a single record on each line, which makes it easy for various tools to look at and process one record at a time before moving on to the next one. Our About the Data page provides more information on working with the NDJSON files you’ll receive through BCDA.

FHIR APIs at CMS

BCDA is one member of a suite of FHIR APIs provided by CMS, which work together to provide claims data that enables higher-quality patient care.

Claims Data to Part D Sponsors API (AB2D):

• Provides FHIR-formatted bulk claims data to stand-alone Prescription Drug Sponsors for their enrollees.

Blue Button 2.0:

• Provides FHIR-formatted data for one individual Medicare beneficiary at a time, to registered applications with beneficiary authorization.

Beneficiary Claims Data API (BCDA):

• Uses the bulk FHIR specification to provide data files to an ACO for all of the beneficiaries a given Shared Savings Program ACO is eligible to receive.
• BCDA does not require individual beneficiary authorization to send this information, though beneficiaries can opt out of having their data shared with the ACO by calling 1-800-Medicare.

Data at the Point of Care (DPC) pilot:

• Provides FHIR-formatted bulk data files to fee-for-service providers for their active patients as needed for treatment purposes under HIPAA.
• Data at the Point of Care does not require individual beneficiary authorization but does allow patients to opt out of data sharing.

HHS is committed to making its websites and documents accessible to the widest possible audience, including individuals with disabilities. We are in the process of retroactively making some documents accessible. If you need assistance accessing an accessible version of this document, please reach out to the guidance@hhs.gov.

DISCLAIMER: The contents of this database lack the force and effect of law, except as authorized by law (including Medicare Advantage Rate Announcements and Advance Notices) or as specifically incorporated into a contract. The Department may not cite, use, or rely on any guidance that is not posted on the guidance repository, except to establish historical facts.