Updated BCDA Data Dictionary

[Beneficiary Claims Data API (BCDA) Community]

Hello BCDA Community,

The BCDA team would like to announce the release of an updated version of the BCDA data dictionary, which provides a crosswalk between BCDA data and the Claim and Claim Line Feed (CCLF file). Please visit the BCDA website to download this updated data dictionary and review the updates.

Summary of the data dictionary updates for BCDA V1 (which supports FHIR version STU3) and BCDA V2 (which supports FHIR R4):

• Fixed diagnosis.sequence for BCDA V1 and V2, impacting all diagnosis code rows.
• Removed duplicative url values in EOB.item.extension in both BCDA V1 and V2.
• Fixed mapping from eob.item[N].extension[N] to eob.item[N].revenue.extension[N] in BCDA V2 only.

Additionally, there were updates made by our upstream data partners as of 27 January 2022. These are updates to the data, though they did not constitute a change to the data dictionary itself:

• Released a fix for a minor bug in BCDA V2 that corrected the:
  1. Line Submitted Charge Amount field, mapping to "line_sbmtd_chrg_amt" instead of "line_alowd_chrg_amt"
  2. Patient Discharge Status Code field, mapping to "ptnt_dschrg_stus_cd" instead of "clm_freq_cd"
• Removed duplicative primary payer code, which impacts the Line Primary Payer Code field
• Removed duplicative drug status code, which impacts the Drug Coverage Status Code field

The BCDA team is appreciative of the user feedback that contributed to these updates and future updates. As always, please feel free to post in the BCDA Google Group if you have any new issues or questions.

Thank you for your continued interest and support!

All the best,

The BCDA Team

[Nick Moore]

Hello -

In regards to the two fixes released for bugs in BCDA v2, we've completed some some research on our end as these have created significant issues for our organization. In doing this research we have found some inconsistencies with the information you've provided and wanted to call them out as well as ask for some additional information.

The first issue (which I believe is mislabeled in your post) refers to the line allowed charge amount (line_alowd_chrg_amt). We were able to confirm that we'd been receiving the amount that is actually the line submitted charge amount (line_sbmtd_chrg_amt). Those two values on the claims received via BCDA API are identical. While we agree on the issue, the date you state this was corrected (January 27th) in BFD appears to be incorrect. I see a commit for this specific issue made to the BFD repository on March 29th, see: https://github.com/CMSgov/beneficiary-fhir-data/commit/403653e034c631a9979cfa37704490f3936e8b9e.

The second issue refers to the patient discharge status code (ptnt_dschrg_stus_cd) being incorrectly mapped to the value of the claim frequency code (clm_freq_cd). We're familiar with this issue, in fact I think we discovered it, see: https://groups.google.com/g/bc-api/c/bp4kgsFZrXY/m/RuTanXECCQAJ. However, this too does not appear to have been fixed on January 27th. On April 12th we see this commit in the BFD repo: https://github.com/CMSgov/beneficiary-fhir-data/commit/9d4fe51711fa6f48a0fb50c641fa8c3edf606f4c.

The dates of the fixes are very important to us because we are having to re-pull all claim data from BCDA for dozens of ACOs. We've rolled out ACOs over a period of time, so knowing the correct dates is critical to understand which ACOs are impacted. Similarly, it would be preferable to find out about these changes prior to the fix, or at least shortly after. In this case, we were not informed of the issue until months later.I have two follow-up questions on this as well:

1. What is the actual deployment strategy or schedule for BFD? Just because these fixes were committed on a certain date does not guarantee the BFD service was redeployed with these fixes. Can you provide us with these dates?
2. For these impacted records, why wasn't the last_updated date of the meta field in the FHIR resource updated? According to the specifications, this value should be updated anytime the resource itself (not upstream data, etc) is changed, see: https://build.fhir.org/resource-definitions.html#Resource.meta. This was not the case here and further complicates the issue as we now have to pull entire seven-year claim histories.

Thank you and I really appreciate a quick response as this is a very high priority problem for us now.

[Beneficiary Claims Data API (BCDA) Community]

Hi Nick!

Thank you for the feedback, and we apologize for the inconvenience this is causing Aledade. We value your level of attention and review of the open source repositories, as well as the communication.

Please know that we acknowledge the criticality of dates and information sharing. We are working with our upstream data partner to provide an answer to your two questions and correct our past announcement.

As an ongoing process, we are re-evaluating how we announce updates so that customers, like Aledade, can better plan for them.

We thank you for the continued support.

The BCDA Team

[Nick Moore]

Hello -

I just wanted to check in to see if you were able to get more information on this?

Thank you,

Nick Moore

Aledade, Inc.

[Beneficiary Claims Data API (BCDA) Community]

Hello BCDA Community,

We are correcting the deployment dates of two changes in our original announcement, based on your feedback and our coordination with our upstream data partners:

As of Thursday, 31 March 2022, a fix was released for a minor bug in BCDA V2 that corrected the:

Line Submitted Charge Amount field, mapping to "line_sbmtd_chrg_amt" instead of "line_alowd_chrg_amt"

As of Tuesday, 12 April 2022, a fix was released for a minor bug in BCDA V2 that corrected the: 

Patient Discharge Status Code field, mapping to "ptnt_dschrg_stus_cd" instead of "clm_freq_cd"

The data is updated in all BCDA requests as of the aforementioned release dates. In order to receive these updates, BCDA customers are encouraged not to use the _since parameter for the next request to ensure all of the historical data is updated with these mapping modifications. Please let us know if we can improve this experience going forward.

As an ongoing process, we are re-evaluating how we announce updates so that customers, like yourselves, can better plan for them.

We apologize for any inconvenience this might have caused.

The BCDA Team

[Nick Moore]

Thank you for confirming the dates. I did ask a couple of questions in my original post that I am hoping to get some information on.

1. What is the actual deployment strategy or schedule for BFD? Just because these fixes were committed on a certain date does not guarantee the BFD service was redeployed with these fixes. Can you provide us with these dates?
   
   
2. For these impacted records, why wasn't the last_updated date of the meta field in the FHIR resource updated? According to the specifications, this value should be updated anytime the resource itself (not upstream data, etc) is changed, see: https://build.fhir.org/resource-definitions.html#Resource.meta. This was not the case here and further complicates the issue as we now have to pull entire seven-year claim histories.
   

For #1, since the dates you confirmed are the same dates the commits were made, I must assume that the deployment to BFD happened the same day as well. Is that a correct assumption?

Thank you,

Nick Moore

Aledade, Inc.

[Beneficiary Claims Data API (BCDA) Community]

Good Morning, Nick!

Apologies for the oversight. Here are responses to your questions, in addition to the announcement correction:

1. Yes, the corrected dates in the Updated BCDA Data Dictionary announcement are indeed the deployment dates of the bug fixes in production. They are not just the commit dates.
2. For the impacted records, the last_updated date of the meta field in the FHIR resource was not updated. We have made note of the specifications shared related to changing the last_modified date for every single claim within the database, which would automatically return every single claim for the next bulk job regardless of _since usage or applicability. Based on initial conversation, this will require additional discussion, discovery, etc. prior to determining a path forward (e.g., process change, service enhancement). As we are discussing ways to help customers effectively capture data updates, are there other considerations from Aledade that we can incorporate?

Thank you, and we apologize again for the inconvenience this caused Aledade.

The BCDA Team

[Jack Shoemaker]

Does anyone know where I can direct this question to at CMS. We do get CCLF data in bulk/batch, but this API could help.

 

Thanks - Jack

 

--

Jack N Shoemaker / (336) 202-2165

Secured by Paubox - HITRUST CSF certified

[Nick Moore]

Thanks for the responses to my questions.

Regarding #2 - I agree this is likely non-trivial to implement, but nonetheless would be highly valuable and conform to the FHIR spec.

I subscribe to notifications on the Github repos, however I wonder if it would be helpful to have release notes provided either here or on Github. Another thing that would be helpful would be some visibility into the roadmap to know which fixes/features are upcoming and which are further out.

Thanks

Nick Moore

[Beneficiary Claims Data API (BCDA) Community]

Hi Jack!

Thank you for reaching out and expressing an interest in BCDA. Please send your question(s) about the ACO REACH model operations and policies to the respective help desk at ACOR...@cms.hhs.gov. 

The BCDA Team

[Jack Shoemaker]

Thank you BDCA team. The email address in your response no longer seems to be valid; however, your advice to contact the ACO REACH help desk is sound and we’ll do just that.

 

• Jack

 

--

Jack N Shoemaker / (336) 202-2165

 

--
You received this message because you are subscribed to the Google Groups "Beneficiary Claims Data API (BCDA) Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bc-api+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bc-api/4f75c88c-7d10-44a1-8e72-53055f563ecdn%40googlegroups.com.

Encryption verified by Paubox - HITRUST CSF Certified

 

Secured by Paubox - HITRUST CSF Certified

[Jack Shoemaker]

Just a quick update for the group. YES, ACO REACH entities can use BDCA. One requests credentials through the 4i portal.

 

--

Jack N Shoemaker / (336) 202-2165

 

 

From: Beneficiary Claims Data API (BCDA) Community <bc-...@googlegroups.com>
Sent: Thursday, August 11, 2022 8:35 AM
To: Beneficiary Claims Data API (BCDA) Community <bc-...@googlegroups.com>
Subject: [BCDA-API] Re: Can ACO REACH organizations use BDCA?

 

Hi Jack!

Thank you for reaching out and expressing an interest in BCDA. Please send your question(s) about the ACO REACH model operations and policies to the respective help desk at ACOR...@cms.hhs.gov. 

The BCDA Team

 

On Saturday, August 6, 2022 at 1:24:48 PM UTC-4 jshoemaker wrote:

Does anyone know where I can direct this question to at CMS. We do get CCLF data in bulk/batch, but this API could help.

 

Thanks - Jack

 

--

Jack N Shoemaker / (336) 202-2165

Secured by Paubox - HITRUST CSF certified

--
You received this message because you are subscribed to the Google Groups "Beneficiary Claims Data API (BCDA) Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bc-api+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bc-api/4f75c88c-7d10-44a1-8e72-53055f563ecdn%40googlegroups.com.

Encryption verified by Paubox - HITRUST CSF Certified

 

 

Secured by Paubox - HITRUST CSF Certified

--
You received this message because you are subscribed to the Google Groups "Beneficiary Claims Data API (BCDA) Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bc-api+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bc-api/DM5PR01MB221955E484A920BFADC7D734A66B9%40DM5PR01MB2219.prod.exchangelabs.com.