CMS-0057-F’s API requirements generally take effect January 1, 2027 — a date that’s now about three months out. Some process requirements, including decision-timeframe and denial-reason rules, already began January 1, 2026. Exact applicability varies by payer type. (CMS final rule fact sheet)
One detail holds steady across both of those dates: drug prior authorizations are excluded from the rule’s Prior Authorization API requirements. That carve-out was true when the rule was finalized. It’s more operationally important now, three months from the API deadline, because it’s the exact seam where specialty pharmacy operations are most likely to misjudge their own readiness.
What the rule actually requires
CMS-0057-F requires certain payers to build and expose several distinct API capabilities, on compliance timelines that vary by payer type:
- an updated Patient Access API
- a Provider Access API
- a Payer-to-Payer API
- a Prior Authorization API
- process requirements — shortened decision timeframes and specific denial-reason disclosure — that apply independently of the API build-out
These aren’t one deadline. The process requirements are already in effect for many payers; the API requirements are the piece still approaching its general 2027 date. What the rule requires by that date is a real, substantive change to how PA information can move between systems — but “required by” and “already deployed everywhere” are different claims, and this article is only making the first one.
What the rule does not do, on any timeline, is bring drugs into that API-driven PA process. Drug benefit prior authorizations continue to run through whatever mechanism a payer already uses for them — which may already be electronic, a portal, or another established channel — largely unchanged by this specific rule.
That single fact splits many specialty pharmacy cases into two operationally different tracks, even though both tracks can sit inside the same referral.
Two tracks, one case
Take a referral that includes both an item/service component and a drug component — a common structure in infusion, administration, equipment, and provider-based service models, though not the shape of every specialty pharmacy referral.
Covered item/service PA CMS-0057-F treatment: Included for impacted payers, subject to applicable provisions and compliance dates. Operational requirement: Track which API/process applies, current state, owner, deadline, and next action.
Drug PA CMS-0057-F treatment: Excluded from the rule’s PA-API requirements. Operational requirement: Preserve visibility into the existing payer/PBM and benefit-specific process — don’t assume it moved.
An operations team that treats the referral as one undifferentiated case — rather than two tracks with two different information environments and two different timelines — will misjudge which parts of their process are actually moving toward the API deadline, and which parts aren’t touched by it at all.
Where the risk actually shows up
The risk here isn’t regulatory in the sense of “someone might violate CMS-0057-F.” Continuing to process drug PAs the way a payer already handles them is exactly what the rule expects — that’s what the exclusion means. Organizations can still carry other regulatory, contractual, state, accreditation, or timeliness obligations around drug PA; this article isn’t addressing those, and nothing here should be read as clearing that ground generally.
The risk that this piece is about is operational, and it shows up in expectation-setting. Consider a plausible scenario: a staff member hears “the new CMS APIs are coming” and assumes that means drug PA turnaround will improve. A manager repeats that assumption up the chain. A patient is told their medication PA should move faster “because the systems are more connected now.” None of that has happened yet in this scenario — it’s a risk of what gets assumed, not something we’re reporting as already occurring industry-wide.
That’s a workflow failure, not a compliance failure — the same category this newsletter keeps returning to: a system-level regulatory change doesn’t automatically translate into an accurate operational understanding of what actually changed, for which cases, and for whom.
Making the two tracks visible — not just describing them
Naming the distinction isn’t enough on its own. For each case that carries both a drug and an item/service component, the two tracks should be represented separately, each with:
- which authorization pathway applies (API-covered process vs. drug’s existing channel)
- current state
- active blocker, if any
- responsible team or owner
- expected response or follow-up date
- next action
- elapsed time
- any dependency between the two tracks (does fulfillment wait on both, or can one proceed independently?)
That’s where this stops being a regulatory explainer and becomes an operating-model question — the same State/Blocker/Owner/Next Action/Time frame this newsletter has applied all month, now pointed at a specific seam most teams haven’t separated out yet.
The sequence that actually gets a team there isn’t “build an integration.” It’s:
- Identify which case types carry both a drug and an item/service authorization.
- Separate the two authorization requirements explicitly, per case type.
- Document the current information channel for each — API-bound, portal, fax, phone, whatever it actually is.
- Define ownership and escalation for each track independently.
- Only then evaluate where integration or automation is actually justified.
Most of that is mapping work, not infrastructure work. Skipping straight to “we need an API integration” before the mapping is done is its own version of the same mistake this article opened with — treating a regulatory change as a technology project before it’s been understood as an operational one.
The question to ask before the 2027 date lands
For your highest-volume case type that carries both components: can you answer, cleanly and by case type rather than case by case, which step sits inside the API-driven timeline and which step runs on the drug’s existing process?
If that requires opening an individual case and tracing it by hand, that’s not a regulatory gap — it’s the same operating-state gap this newsletter has described all month, applied here to the drug-versus-service distinction inside a single referral.
The compliance date is fixed. What an operation does with the months on either side of it is not.
The rule changed the rails for part of the case. It’s still your job to know which part.