Comprehensive list of BCDA fields?

[hnchi...@gmail.com]

I have the FHIR specification documentation and the CCLF to BCDA mapping, but is there a document that lists all fields we should expect to receive in the BCDA files, including extensions? Not all FHIR fields are used, and many extensions have been added, and digging through the sample files for every EOB type to produce a list is proving time consuming.  

Thanks in advance,

Holly

[Dave Sukharan]

Hello Holly!

I will ask our FHIR expert whether there are any resources that can help with this (including extensions). Thanks for your work so far, Holly.

-Dave Sukharan

[Beneficiary Claims Data API (BCDA) Community]

Hi Holly,

We are working on a more comprehensive data dictionary, which will be similar to the BCDA data dictionary that currently provides a Claim and Claim Line Feed (CCLF) file crosswalk, but it will list all data elements in the FHIR output, along with extensions.

We aim to release a first iteration of that comprehensive data dictionary in the spring of 2022.  

If you need information on any particular data elements or extensions sooner than that, please feel free to reach out to us again.

The BCDA Team

[Jeremy Colson]

Was this [BCDA-specific] data dictionary ever released by any chance? I've searched the website, but the only thing I've found is the data dictionary that is more focused on the lineage between CCLF and BCDA. Same ask/reason as Holly... it does not seem there is a clear definition anywhere of all the data elements that could potentially be provided by BCDA. I am completely new to CCLF and BCDA; so please forgive me if this information has already been publishing somewhere. Thanks!

-Jeremy

[Beneficiary Claims Data API (BCDA) Community]

Hi Jeremy!

Welcome, and thank you for reaching out because this is the perfect place to ask that type of question.

We are happy to hear that you are ready to gain insights from a more comprehensive data dictionary in addition to what is currently provided through the BCDA Data Dictionary. While we are not yet able to offer a timeline on the release, we welcome insight into how documenting all the data elements provided by BCDA could better serve your organization's goals. Some questions to get you started:

• How might your organization make use of this data documentation?
• How would your organization envision seeing and analyzing this documentation? Would you have a preferred format for the BCDA data definitions?
• How does your organization obtain this information now, if at all?

As always, inquiries like yours and Holly's help our team to prioritize and develop features that meaningfully improve BCDA.

Thank you for your support of the API!

The BCDA Team

[Jeremy Colson]

Honestly, I expect this would be very valuable to help ensure all users/consumers understand the exact data elements the various API responses could provide. Otherwise, it can quickly become an iterative game of trial and error when attempting to process the response... and it's just good documentation practices for APIs. We ideally, want to read and understand the API (your Swagger is a good start) and all the data elements that will potentially be provided in the payload, so we can perform adequate analysis and design upfront. Not having this documentation makes working with these APIs significant more difficult and time consuming due to that lack of documentation. There are plenty of examples where the government has done this elsewhere... here's an example from the USPS where you can see how they have fully defined the response of each endpoint: https://developer.usps.com/api/18/1/routes/address/get

End of the day, having better documentation would save countless hours across all the ACOs that start to use BCDA and (in my opinion) would help foster adoption.