Changes to the availability of Partially Adjudicated Claims

[Beneficiary Claims Data API (BCDA) Community]

Hi BCDA users,

Effective this evening, BCDA will no longer share partially adjudicated claims which have not been updated in the past 60 days. When making a request to the /Group or /Patient endpoints, ACO REACH participants will only receive Claim and ClaimResponse resources where the Last Updated Date (meta.lastUpdated) field is within 60 days of the date the API request was made.

NDJSON files for completed jobs will no longer contain Claim and ClaimResponse resources where the resource's Last Updated Date (meta.lastUpdated) field is more than 60 days prior to the date the API request was made. However, it is important to note that these claims may still be moving through the adjudication process. If a claim that is omitted from BCDA's results after 60 days receives an update at any time, the Last Updated Date (meta.lastUpdated) will be updated on the Claim and ClaimResponse resources, the 60 day window will reset, and the updated resources will be included in BCDA's results.

Please don't hesitate to reach out if you have any questions or would like to provide feedback on this upcoming change.

Thanks,
The BCDA Team

[Maddy Blakeslee]

Hi all,

Is this specific to only partially adjudicated claims? I deleted my previous post because I believe I misunderstood the second paragraph. I assumed it was also talking about the regular (adjudicated) claim and claimresponse resources.  

For some context we are doing a backfill to account for missing claims caused by a bug in the /since parameter code that will be blocked by this change if it also applies to adjudicated claims. It looks like the announcement about the fix has been deleted but the related issue numbers are: 

• 6386: Missing historical data for newly attributed beneficiaries.
  
• 6156: The runout endpoint is not providing historical claim updates for newly unattributed beneficiaries in the current year

We are trying to capture all missing claims data from these bugs. Because the /since parameter does not have the ability to pull data from a specified date range (start and end point) we had to optimize our ingestion process so that we are not ingesting duplicate claims. For some context our attributed patient population is over 1.3 million patients. As a result of the required development time and the regular end point not being available in January and February of this year this backfill is not complete. 

[Nick Moore (Pearl Health)]

Hi -

We are not observing this 60-day restriction in our jobs which request data from the /Group endpoint with a specified since parameter of about 24 hours from the API request date. In fact, we appear to be getting data that is unbound by the since parameter value altogether.

For example, we have several thousand claim records belonging to thousands of distinct patients with meta.lastUpdated in the year 2022 for a job we submitted yesterday using a since parameter value of '2024-02-24 05:00:07.410371+00:00'.

Happy to provide more detail directly, but I would like to know if there already has been any acknowledgement of this particular issue.

Thank you,

Nick Moore

Pearl Health, Inc

[Nick Moore (Pearl Health)]

Hi - Hoping we might get an acknowledgement for the issues identified in this thread (both mine and Maddy's).

Thank you for your help!

Nick Moore,

Pearl Health, Inc.

[Beneficiary Claims Data API (BCDA) Community]

Hi Maddy and Nick,

This data retention change is limited to partially adjudicated claims (via Claim and ClaimResponse resources). The availability of adjudicated claims (via Explanation of Benefit resources) and the Patient and Coverage resources is not affected.

Maddy, on issue 6386, we've found a bug in how the _since parameter is implemented in BCDA and are working on a fix. The issue stems from calculating newly attributed enrollees based on the date BCDA first received the CCLF 8 file with a newly aligned enrollee, rather than the date BCDA completed processing that file and updating the list of attributed enrollees for your model entity(ies).

Nick, are you seeing the claims dating back to 2022 for all patients or just those newly attributed in 2024?

Thanks,
The BCDA Team

[Maddy Blakeslee]

I thought you implemented a fix for the bug in issue 6386  . Is it not fully resolved?

[Maddy Blakeslee]

Hi all,

Looking back at my emails it was announced that the fix was released on 10/26/2023. Are you saying that the fix did not address the issue and the larger group was not notified and the announcements that were previously posted here were just deleted?

On Thursday, October 26, 2023 at 12:28:25 PM UTC-4 Beneficiary Claims Data API (BCDA) Community wrote:

Hi BCDA users,

This change has been released.

When using the /Group endpoint with the _since parameter, BCDA will provide historical claims for newly attributed enrollees. Previously, BCDA did not provide historical claims for newly attributed enrollees if the _since parameter was more recent than the latest data from BCDA (indicated by the meta.lastUpdated field).

For more information, you can view our previous announcement or review the changes in this pull request.

Please don't hesitate to reach out to us here or directly via email at bc...@cms.hhs.gov if you have any questions or feedback related to this change.

Thank you,
The BCDA Team

[Beneficiary Claims Data API (BCDA) Community]

Hi Maddy, 

Sorry for the lack of clarity around the _since parameter. We are working to optimize the function as we gain new information.

Regarding the bugs (issues 6386 and 6156): we did believe that the October fix addressed the issue fully, but the volume of attribution changes at the beginning of the PY exposed an additional discrepancy; Nick's comment in this thread reopened the investigation. We are working on another change to ensure the parameter is implemented optimally per the Bulk FHIR IG and will notify the group once it is complete.

Regarding the 10/26 announcement thread: This thread was automatically deleted without notice, and we were unable to reach a Google Group support team to restore the thread. The main announcement is reposted below, and we can share the additional questions again if needed.

Thank you,
The BCDA Team

[Beneficiary Claims Data API (BCDA) Community]

Reposting the deleted announcement from 13 Oct 2023 :


Hello BCDA users,

To resolve a bug in the implementation of the _since parameter for the /Group endpoint, we are introducing a minor change in our release the week of October 23rd, 2023.

What to expect
To align with our documentation, we are correcting the logic for calculating new beneficiaries when the Group endpoint is called using the _since parameter. 

Current Behavior
When using the /Group endpoint with the _since parameter, BCDA is not providing historical claims for newly attributed enrollees when the _since parameter is more recent than the latest data from BCDA (indicated by the meta.lastUpdated field).

Upcoming and Intended Behavior

When using the /Group endpoint with the _since parameter, BCDA will provide historical claims for newly attributed enrollees.

How to prepare
We expect minimal impact to BCDA users making new requests. However, if you believe the results of a recent job request using the /Group endpoint with the _since parameter has excluded historical claims for a newly attributed enrollee, you may wish to retry that request to retrieve the historical claims once this change is released.

More information
For more information, you can review the upcoming changes in this pull request. We will notify you the week of October 23rd, 2023 when this change has been deployed or if there are any changes to the planned schedule.

Please don't hesitate to reach out to us here or directly via email at bc...@cms.hhs.gov if you have any questions or feedback related to this change.

Thank you,
The BCDA Team

[Andy McLaughlin]

I'm curious if this issue is related to a problem I'm seeing. If not, I can create a new thread on it as a separate discussion.

My data ingestion process fails if I receive an EOB file without having received the corresponding Patient file matched on bene_id, either in the same batch of files as the EOB file or in a previous job. About a month ago, I did a historical backfill using the Group/runout/ endpoint, without using a _since parameter, so that I would receive all of the Patient files for the beneficiaries who were active in the ACO in 2023. Since then, I have run weekly incremental loads, using the previous run's transaction date as the _since parameter, as is recommended in the API docs. I'm getting errors on 1-2% of the bene_ids in EOB files, because I have not previously received the corresponding Patient files. 

Is this related to the issues with the _since parameter? If so, what is the recommended course of action? Wait until a fix is deployed and then do another historical backfill? Do another historical backfill using the Group/all/ endpoint?

Any guidance here is appreciated, thanks!

[Andy McLaughlin]

Any update on the issues with the _since parameter? I've found that by doing repeated historical backfills of Patient files, I can get most of the Patient resources for the bene_ids I'm seeing in ExplanationOfBenefit files, but NOT all of them. To me, this suggests either a major issue in how Patient files are produced or a major issue causing ExplanationOfBenefit files to be produced/sent for beneficiaries that are not part of the ACO.

[Beneficiary Claims Data API (BCDA) Community]

Hi Andy,

We believe the changes in r216 have addressed the issues you've run into when building a list of enrollees attributed to your ACO and their bene_ids from Patient resources. Your prior requests likely completed prematurely and contained -error.ndjson files in place of the missing enrollees' Patient files.

We've reached out directly over email to collect a bit more information and definitively rule out the possibility that the EoBs belonged to enrollees not attributed to your ACO.

Thanks,
The BCDA Team