January 2027 is closer than your API roadmap

January 1, 2027 is the date most payer technology teams have circled. It is when the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) expects impacted payers to have four FHIR APIs in place: an expanded Patient Access API, a Provider Access API, a Payer-to-Payer API and a Prior Authorization API.

The rule applies to Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care plans, and QHP issuers on the federally facilitated exchanges. If you are one of them, the question is no longer whether to build. It is whether what you build will hold up when real providers and real payers start calling it.

The API is the easy part

Standing up a FHIR endpoint is a solved problem. Plenty of servers and platforms will expose /Patient and /ExplanationOfBenefit in a few weeks. What takes longer is everything behind the endpoint:

• Attribution. The Provider Access API is for in-network providers with a treatment relationship to the member. That relationship has to be computed from claims, enrollment and panel data that often live in different systems with different identifiers.
• Prior authorization data. The expanded Patient Access and Provider Access APIs include prior authorization information for items and services other than drugs. In many organizations that data sits in a utilization management platform that was never designed to emit FHIR.
• Consent rules. Provider Access works on an opt-out basis. Payer-to-Payer exchange requires the member to opt in. Those two rules need to be enforced consistently, and auditable, across every request.

Where implementations tend to break

In our experience the failures are rarely in the FHIR layer itself. They happen in mapping and identity:

1. Local codes that never made it to a standard terminology. A service code that means something to the claims team means nothing to a receiving EHR.
2. Member identifiers that do not survive the hop between systems. Without a reliable master patient index, the right data goes to the wrong record, or nowhere.
3. Validation done once, in a test environment, against tidy data. Production data is messier. Profiles that pass in staging fail on the first week of real traffic.

What to do in the remaining weeks

If your build is in progress, three things are worth prioritizing now:

• Test with realistic synthetic data, not a handful of hand-made records. Volume and variety expose mapping gaps early.
• Validate against the profiles your partners will actually use, including US Core and the implementation guides CMS recommends for prior authorization.
• Instrument the pipeline. Know how many requests succeed, how many fail, and why, from the first day in production.

The deadline is fixed. The quality of what goes live on it is not.

Source: CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet.