What's the difference between BCDA v1 and v2?

Beneficiary Claims Data API (BCDA) v1 (STU3) and v2 (R4) differ primarily in their FHIR specification. Version 1 is based on the Blue Button 2.0 Implementation Guide, while Version 2 is based on the CARIN Blue Button Implementation Guide. Additionally, partially adjudicated claims are only available with v2.

There are minor differences in the mapping and values of certain data elements. Slicing/discriminator rules can be different, and some value sets will be bound to CARIN or HL7 value sets instead of BlueButton:

• Example 1: Patient.identifier.type in v2 is bound to the C4BB Patient Identifier type value set.
• Example 2: EOB.Type is bound to the C4BB Payee Type value set and the associated value will be one of the codes in that value set.

Summary of changes

Reference the R3 Diff in the FHIR ExplanationofBenefit for more details.

• ExplanationOfBenefit (EOB)

  • Consolidated/removed elements

    Some elements were consolidated and/or removed. For instance, in STU3 there were 2 elements (Eob.Organization and Eob.Provider) that could represent the party responsible for the claim. In R4, this has been consolidated into 1 element (Eob.provider).

    Examples

    • Eob.provider
    • Eob.hospitalization

  • Added constraints

    Fifteen fields were changed from optional to mandatory. Changing the optionality in this context generally has no impact on users consuming this data. A few minor constraints were added or modified (e.g., value set bindings and reference targets).

    Examples

    • Eob.use
    • Eob.patient
    • Eob.referral
    • Eob.outcome

  • New elements

    Approximately 35 elements were added to the EOB resource type. About 65% of these are child elements of the .addItem property, which isn't supplied by BCDA. Of the remaining 35%, few are populated by BCDA.

    Examples

    • Eob.priority
    • Eob.preAuthRef
    • Eob.diagnosis.onAdmission
    • Eob.formCode

  • Renamed elements

    Four elements were renamed. For users converting to v2, it's likely that existing parsing or handling logic needs to be adjusted.

    Examples

    • Eob.information → Eob.SupportingInfo
    • Eob.careTeamLinkId → Eob.careTeamSequence
    • Eob.diagnosisLinkId → Eob.diagnosisSequence
    • Eob.service → Eob.productOrService

• Patient

  The Patient resource type is normative with a maturity level of 5, so there are minimal changes.

  • Consolidated/removed elements

    Only 1 element was removed (Patient.animal), which has no effect on BCDA.

    Example

    • Patient.animal

  • Constraints

    A handful of fields are bound to different value sets. Other minor changes were made to the default value and reference target.

    Example

    • Patient.active
    • Patient.gender
    • Patient.generalPractitioner

• Coverage

  • Consolidated/removed elements

    The Coverage.grouping element was removed. The equivalent element in R4 is Coverage.class. This element is provided in the API, so any user converting from v1 to v2 needs to make minor changes to their parsing or handling logic.

    Example

    • Coverage.grouping

  • Added constraints

    A few changes were made to certain mandatory elements. Generally this has little to no impact on users.

    Example

    • Coverage.beneficiary
    • Coverage.payor

  • New elements

    Six elements were added to the Coverage resource type. Most of these relate to costToBeneficiary and won't be supplied in BCDA.

    Example

    • Coverage.class.name
    • Coverage.costToBeneficiary
    • Coverage.costToBeneficiary.type