API performance and hung jobs

[Maddy Blakeslee]

Hi all,

We've been having very hard time getting data from the API since it was enabled for 2026. Once we are finally able to download the files and we aren't receiving errors it is taking us up to 20 hours to download files for a single ACO. We still have not gotten data for all 68 of our MSSP and ACO REACH ACOs in 2026 to date. We are downloading compressed files. 

I wanted to flag these three jobs in particular. They were created on 2/24 and hung sitting at 0% progress until we killed them today. job ids: 162328, 162329, 162244

While our other jobs have taken significantly longer than normal we did get errors and/or the job failed. 

[Beneficiary Claims Data API (BCDA) Community]

Hi Maddy, 

Thank you for alerting us to this issue! We have been investigating the challenges you reported with requesting and downloading data and have identified a few potential issues.

We've also just shared this in a parallel Aledade thread, but we are updating the way BCDA prioritizes jobs to ensure large export requests are better supported during high traffic times and continuing to investigate other improvements. 

Have you been able to successfully complete these requests? If so, when these jobs succeeded, were you able to download the files without any issue? 

Thank you, 

The BCDA team

[Maddy Blakeslee]

I believe the performance issues are due to the fact that the restrictions on patients' Medicare Claim history were removed from the API. While I welcome the change and in general I think more data is better, this change was significant and the communication was so subtle that multiple people on my team saw the PY 2026 enable announcement and missed it. The impact of the change for us was >7X increase in total file volume as compared to 2025. We received >217k files requiring ~500k GB of storage in 2026. This is up from ~28.5k files and 130 GB. We could not have estimated that growth. In addition, we continued to try to request files for our new and some very large ACOs without utilizing the _since parameter. It took weeks to finally get the jobs that I noted above to finish. We could have used the _since parameter if we were aware of the change. 

When there are foundational changes to the API or any changes please clearly outline and communicate the changes as soon as possible. For us, the amount of data and how it will increase YoY requires thoughtful budgeting and a planning for our infrastructure, performance, scalability and ROI. Maybe more importantly, I think everyone is excited to have access to more data but without a proper announcement you missed an opportunity for people like me to be stoked, let you know and share with our companies exciting enhancements for 2026 :)

Thanks!

[Beneficiary Claims Data API (BCDA) Community]

Hi Maddy, 

Thanks as always for your feedback! Beyond releasing PY 2026 data in line with our performance year transition protocol, we did not make changes to BCDA's claims history restrictions and continue to follow model guidance on claims data lookback periods. We took another look at the completed jobs you shared and reached out via email with a likely explanation as to what might explain the large increase in data you've seen from the start of PY 2025 compared to PY 2026.

For others following along, here is some general information that may help you troubleshoot the cause of larger than expected volumes of data: 

• Making an $export request without using the _since parameter will return historic data for all of your model entity's currently attributed enrollees. Depending on the Alternative Payment Model, your organization will have access to different amounts of historical data:
  • ACOs in the Medicare Shared Savings program will receive all historic claims data for their currently attributed enrollees dating back to 2014
  • REACH ACOs will receive all claims data from the current performance year, and the previous 3 full performance years
  • KCC participants will receive all claims data from the current performance year, and the previous 2 full performance years
• By default, BCDA will return gzip-compressed files. If your client makes a request to the /download endpoint with an Accept-Encoding header and value other than "gzip", BCDA will return uncompressed ndjson files. This will not increase the number of files BCDA returns, only the size of files.

Thanks,

The BCDA team

[Beneficiary Claims Data API (BCDA) Community]

Hi folks, 

We made a mistake in the info we provided about gzip-compression in our previous message.

By default, BCDA will return gzip-compressed files only if the "Accept-Encoding: gzip" header is used in requests to the /data endpoint. We strongly encourage all BCDA clients to use this header to improve download speeds. If the header is not provided, BCDA will return uncompressed files which are much larger and will take longer to download.

Our documentation includes example request headers and sample curl commands for downloading files using the /data endpoint.

Thanks and apologies for any confusion from our earlier message,

The BCDA team