CMS’s Interoperability and Prior Authorization Final Rule (CMS-0057-F) is often summarized in one line — “payers must build prior auth APIs” — but there isn’t just one API involved. There are five, each doing a different job, and each one changes a different part of the prior authorization workflow your billing team touches every day. Understanding what each API actually does makes it much easier to figure out what your practice needs to prepare for, and what’s simply a payer-side build with no direct action required from you.
The five required APIs
1. Patient Access API (expanded)
This API already existed under an earlier CMS interoperability rule, giving patients electronic access to their own claims and clinical data through a third-party app of their choice. CMS-0057-F expands what it must include: prior authorization information (excluding drug prior authorizations) now has to be part of what’s available through this API. For billing teams, the practical effect is that patients may increasingly show up already knowing the status of a prior auth request before your staff has updated them — which raises the bar on keeping your own status tracking current.
2. Provider Access API
This is a new requirement. It lets a patient’s in-network provider pull that patient’s claims, encounter data, and prior authorization information directly from the payer, with the patient’s consent. In theory, this should reduce the amount of time front-office and utilization review staff spend calling payers or logging into portals just to find out whether a prior auth exists, what it covers, or what its status is — that information becomes queryable.
3. Payer-to-Payer API
When a patient switches health plans, this API is meant to let the new payer pull relevant claims and clinical history (going back up to five years) from the old payer, with patient consent. This mostly affects care continuity and utilization management rather than day-to-day billing, but it matters for prior authorization specifically because it can carry over existing authorizations and clinical documentation that would otherwise force a patient — and your office — to start a prior auth from scratch after a plan change.
4. Prior Authorization API
This is the one most directly relevant to billing workflow. Sometimes referred to by its underlying implementation guide name (PARDD — Prior Authorization Requirements, Documentation, and Decision), this API is supposed to let a provider’s system query, in a structured way, what documentation a specific payer requires for a specific service, submit the request electronically, and receive a decision — approval, denial, or request for more information — back through the same channel. This is the piece that, if adopted well by your EHR or clearing house, could replace a meaningful share of manual portal work.
5. Provider Directory API
This one is easy to overlook because it sounds administrative rather than clinical. It’s meant to let patients (and their apps) find in-network providers by location, specialty, and other criteria pulled directly from the payer’s own directory data. It matters to billing indirectly: directory accuracy has long been a source of network-status disputes and No Surprises Act complications, and a standardized, machine-readable directory is meant to reduce those errors.
What’s actually required, and when
All five APIs carry the same headline compliance date: January 1, 2027. Before that, a set of operational requirements — not APIs, but process rules — took effect January 1, 2026: expedited prior authorization decisions within 72 hours, standard decisions within seven calendar days, specific (not generic) denial reasons, and annual public reporting of prior authorization metrics on the payer’s website. Those operational obligations apply regardless of whether the API build is finished, so a payer that hasn’t built its Prior Authorization API yet is still supposed to be meeting the decision-timeframe and denial-reason rules today using whatever channel it currently uses (portal, fax, phone).
What this means for your practice’s workflow, concretely
- Don’t assume “the API” replaces your staff. Even after January 1, 2027, someone on your team still needs to review documentation requirements, submit clean clinical support, and follow up on pended requests — the API changes the transport mechanism, not the underlying clinical documentation burden.
- Ask your EHR vendor which of the five APIs they’re building support for, and on what timeline. Vendors are typically prioritizing the Prior Authorization API and Patient Access API first because those touch patient-facing and revenue-cycle workflows most directly; Provider Directory and Payer-to-Payer support may lag.
- Reconcile your internal prior-auth tracker with what payers start publishing. Once public metrics reporting is live and mature, you’ll have an external benchmark for whether a payer’s actual denial rate and turnaround time match what you’re experiencing — useful ammunition in contract or provider-relations discussions.
Billing teams that have already lived through a CMS interoperability rollout tend to make the same observation: the API itself rarely fails outright — what breaks is the mapping between what your system sends and what the payer’s system expects, especially around documentation attachments. Building in a testing period with your top payers well before the deadline, rather than assuming a “go-live” flip will just work, tends to save the most pain.
How to prioritize your own review
Not every API deserves equal attention from your billing team right now. If you had to rank them by immediate operational impact, the Prior Authorization API and the expanded Patient Access API sit at the top — they touch the request-and-decision loop your staff manages daily and the information patients will increasingly expect to see themselves. Provider Access sits close behind, since it affects how much manual portal-checking your utilization review staff still has to do. Payer-to-Payer and Provider Directory matter more for care continuity and network-status accuracy than for daily claims workflow, so they’re reasonable to monitor rather than actively project-manage in the near term. Building a simple internal one-pager that maps each of your top payers against which of the five APIs they’ve confirmed a build timeline for is a low-effort way to keep this from becoming an abstract compliance topic and turn it into a concrete vendor-readiness tracker.
Takeaway
Five APIs, one deadline: January 1, 2027. The Prior Authorization API is the one that will change your daily workflow most directly, but the Patient Access, Provider Access, Payer-to-Payer, and Provider Directory APIs all feed into it. Start mapping which of your top payers and vendors are ready now, not in December 2026.
For the state-level “gold carding” laws exempting some providers from prior auth entirely, see our gold carding guide.