Removing Provider Tax Identification Numbers

[Beneficiary Claims Data API (BCDA) Community]

Effective February 26, 2026, BCDA will no longer include providers' Tax Identification Numbers (TIN) in ExplanationOfBenefit (EOB) or Claim resources. This change will apply to all versions of BCDA in both production and sandbox datasets.

What's changing

The results of any $export requests made after this change will no longer include the following elements:

• TAX_NUM in ExplanationOfBenefit resources
• FED-TAX-NB in Claim resources
• BILL-PROV-EIN in Claim resources

How you can prepare

For BCDA users relying on TINs for uniquely identifying providers, our recommendation is to instead use the National Provider Identifier (NPI) moving forward.

If you have any questions, please don't hesitate to reply to this thread or contact our team directly at bc...@cms.hhs.gov.

Thanks,

The BCDA Team

[Liz Blair]

Hi BCDA Team,

We just read through this notification and wanted to reach out to better understand the rationale behind this change and discuss the significant operational impacts this will have on value-based care organizations like Aledade.

Request for Clarification:
Could you please help us understand the driving factors behind this decision? Is this related to privacy concerns, data standardization efforts, or other policy considerations? Understanding the "why" will help us better align our feedback and potential solutions.

Critical Business Impact:
The removal of TIN data will fundamentally disrupt core VBC workflows that rely on accurate provider identification and attribution. Specifically:

• ACO Operations: MSSP and REACH programs require TINs on ACO rosters, with NPIs properly linked to TINs in PECOS for Medicare enrollment. NPI alone cannot support these regulatory requirements.

• Claims Processing: TINs are mandatory on Medicare claims for proper adjudication. Without this data, we cannot validate claim accuracy or identify potential billing issues that could delay payments to our provider partners.

• Quality Reporting: MIPS performance reporting requires the NPI + TIN combination to properly distinguish providers, as the many-to-many relationship between NPIs and TINs is essential for accurate attribution.

• Provider Attribution: TINs identify not just individual providers but also groups, practices, and suppliers. Providers often bill under multiple TINs specific to different payers, programs, or services within their organizations.

Additional Questions:

1. Will TIN information be removed from other CMS data sources beyond BCDA (e.g., other FHIR endpoints, bulk data exports)?
2. Is there a planned transition period or alternative data source that will maintain TIN information?
3. Are there interim solutions CMS can recommend for organizations that require TIN data for regulatory compliance?

Given that this change is happening in less than one month's time, we'd appreciate a timely response to our questions. We're also open to meeting and discussing potential solutions.

Thank you

Liz

[Maddy Blakeslee]

Hi all,

This is a last minute breaking change that impacts analytics and operations for 69 MSSP and REACH ACOs at our multi payer and program org. I also want to highlight that it breaks linking across multiple programs' data sources, including but not limited to attribution, CCLF claims data and claim reduction files.

TAX_NUM is used to identify WHO is receiving payment. In the CCLF files TAX_NUM is equivalent to the CLM_RNDRG_ PRVDR_TAX_ NUM. It is extremely important to know both the NPI and the TINs on claims. TINs do not just represent individual providers they identify physicians, groups, practices and suppliers. Providers can bill with multiple TINs and NPIs, and the TINs can be specific to payers, programs, lines of business, locations and services across the org(s) they work at. For MSSP and REACH, TINs are required to be on an ACO's TIN roster and NPIs need to be properly linked to ACOs' TINs in PECOS for Medicare enrollment. NPI is not sufficient due to this many:many relationship. In addition, provider's TINs are required on Medicare claims and if they are incorrect claims can be denied and adjudication can be delayed. For MIPs the NPI + TIN combination is required for distinguishing providers for MIPS performance reporting. 

MIPS: "Individuals (TIN/NPI). CMS uses both your TIN and your NPI to distinguish you as a unique MIPS eligible clinician. If you have more than one TIN/NPI combination—because, for example, you move at multiple practices during the performance year—you will be assessed separately for each one."

Questions: Can you revert or postpone this change?  Why are you removing TINs? Are TINs going to be removed for ALR, PAR, BAR and CCLF?  What data elements are you providing that can address all of the use case I've outlined above (and any other use cases that I discover are impacted)? 

If the answer is that the TINs are still available via the claim resource, that resource is specific to partially adjudicated claims. REACH is the only program that's enabled and the REACH program is ending in 2026.

[Maddy Blakeslee]

Additional questions:

• Is it correct to assume that 2/26/26 is the date the API is going to be enabled for PY 2026 or are you going to provide 7 years of claim history with the TIN still included?
• Have you explored other options that would address the root cause for this change and reduce downstream negative impacts to end users and the resulting drop in API utilization from removing a core data element? One option that VRDC implements for example is hashing TINs. 

[Beneficiary Claims Data API (BCDA) Community]

Hi Liz and Maddie,

We appreciate your feedback on the importance of these fields.

After further review, providers’ Tax Identification Numbers (TINs) will remain in the Explanation of Benefit (EOB) and Claim resources for BCDA. We recognize this differs from prior communication and apologize for any confusion; please consider this the current guidance.

Thank you, 

The BCDA Team

[Maddy Blakeslee]

Great news! Thank you for your timely and decisive follow-up! I really appreciate that you considered our feedback and any other pertinent information, leading to the decision to keep TINs in the eob and claim resources. Despite the subject matter, your responsiveness and adaptiveness to feedback actually build my confidence in the service and reliability of the BCDA API.

That being said, I will emphasize that our organization deeply values the stability and reliability of our core data sets, as this data is foundational to our operational processes and analytics. Therefore, it is very important to me, as the MSSP and REACH infrastructure and analytics product owner at my company, that my confidence in the BCDA API continues to increase as it evolves thoughtfully. I look forward to leveraging the API further and collaborating on future improvements and changes.