BCDA v3- Clarification on Claim Control Number Format for Pharmacy Claims

[Ashvani goyal]

Hi BCDA Team,

We have observed that for a large number of Pharmacy claims in BCDA v3, the Claim Control Number is being returned in a format that is significantly longer than expected. In some cases, the value also contains embedded spaces.

Previously, you advised us that:

For matching claims between v2 and v3, the v3 ExplanationOfBenefit FHIR ID will not match the v2 ExplanationOfBenefit or Claim/ClaimResponse FHIR IDs. To match a v3 claim with a claim already present in our database, the recommended approach is to use the Claim Control Number.

Since we rely on the Claim Control Number to correlate claims between BCDA v2 and BCDA v3, could you please clarify the following?

1. Is this Claim Control Number format expected for Pharmacy claims?
2. Should the entire value, including any embedded spaces, be treated as the Claim Control Number for matching purposes?
3. Is there any recommended normalization or parsing that should be applied before using these values for claim matching?

As this behavior is observed across a large number of Pharmacy claims, we'd like to confirm whether this is the expected format or if there are any known considerations specific to Pharmacy claims.

If needed, we can securely share sample Claim Control Numbers through a secure channel for further investigation.

Thank you for your guidance.

Best regards,
Ashvani Goyal

[Ashvani goyal]

We are following up on this issue, has anyone been able to look into this?

[Beneficiary Claims Data API (BCDA) Community]

Hi Ashvani,

Sorry for the delay while our team worked to compile this guidance.

Because Medicare does not process Part D / Prescription claims directly, the rules to identify related or duplicate claims are a bit different than Part A / Part B claims. 

Part D claims are submitted to CMS by the Part D Plan Sponsors. The claim control numbers are assigned differently per each Part D Plan Sponsor, so the presentation can be extremely variable. They can be up to 40 characters long. As a result, not all Part D claims have a claim control number. However, those that do have a claim control number can be deduplicated using it. ExplanationOfBenefit.related will be populated with the claim’s original control number, if different than the current control number.   

The CLM_CNTL_NUM on deleted Part D Events (PDEs) will be blank. However, even on these PDEs, EOB.related  may contain the original CLM_CNTL_NUM. 

Because the CLM_CNTL_NUM of a Part D claim is not defined by CMS, you can also use a natural key to link together related Part D Events, for a given patient.

The natural key logic is outlined in https://www.cms.gov/files/document/cclf-information-packet.pdf under Section 5.1.2, and repeated here:

Part D File:
• CLM_LINE_FROM_DT, PRVDR_SRVC_ID_QLFYR_CD 
• CLM_SRVC_PRVDR_GNRC_ID_NUM 
• CLM_DSPNSNG_STUS_CD
• CLM_LINE_RX_SRVC_RFRNC_NUM
• CLM_LINE_RX_FILL_NUM

Thanks,

The BCDA Team