278 Prior Authorization

A 278 Request identifies the requester, the subscriber and patient, the service being requested with its coding and dates, and the servicing provider. The 278 Response returns a certification action (certified in total, certified partial, pended, denied) along with a certification number when granted.

The gap that defines real-world prior authorization is that the clinical justification usually cannot travel in the 278. The payer's decision requires a chart note, an imaging report, a conservative-treatment history. The 278 has no natural home for that, which is why so much prior authorization work happens in fax machines and payer portals despite the standard existing since the 1990s.

The 275 is the intended answer: a separate attachment transaction linked to the parent 278 by control number. Adoption is uneven. Payers differ on whether they accept 275, what documentation they require, and how they want the linkage expressed. This variance, more than the absence of a standard, is why prior authorization automation stalls.

A 278 Response commonly returns a pended status: the payer has neither certified nor denied, and needs more information or more time. Pended authorizations are the majority of the administrative burden. They require follow-up, they have no deterministic resolution date, and they are where the clinical documentation exchange actually occurs.

Workflows that treat the 278 as a request/response pair and stop reading after the first response are handling the easy half. The expensive half is the pended queue and the documentation round-trip that resolves it.

This is also where CMS-0057-F's substantive requirements bite: the rule addresses decision timeframes and the requirement that denials include a specific reason. Those are process obligations on payers, beyond the API obligations.

CMS-0057-F requires impacted payers (Medicare Advantage, Medicaid and CHIP managed care, state Medicaid and CHIP fee-for-service, and QHP issuers on the Federally Facilitated Exchanges) to implement a FHIR-based Prior Authorization API, alongside Patient Access, Provider Access, and Payer-to-Payer APIs. API compliance dates begin January 1, 2027.

Two things follow that are frequently misunderstood. First, the rule does not eliminate the X12 278. Payers must support the FHIR API; the X12 transaction remains the HIPAA standard transaction. For a considerable period both paths will exist, and organizations will need to operate against whichever a given payer supports for a given service.

Second, the rule's obligations are asymmetric. It obligates payers. It creates opportunity, without obligation, for providers and the vendors serving them. A provider organization's prior authorization burden changes only when something on the provider side consumes the API a payer stood up.

Note on dates: some circulating material cites January 2026 for CMS-0057-F API compliance. That is incorrect. API compliance dates begin January 1, 2027.

The pragmatic architecture for the next several years is dual-path: X12 278 where that is what a payer supports, FHIR PAS (Prior Authorization Support) where a payer has implemented it, with a single workflow surface above both so the requesting clinician does not have to know which is which.

This is unglamorous integration work and it is where most of the actual value sits. The organizations that benefit from CMS-0057-F will be the ones that made the payer's path irrelevant to their own users.

PNT supports 278 and 275 transactions and FHIR-based prior authorization exchange.

Prior authorization is the transaction type most likely to carry rich clinical documentation: operative reports, imaging, chart notes. It is therefore the transaction where retention policy matters most.

PNT routes 278 and 275 transactions and their FHIR equivalents in transit and retains no PHI at rest. The clinical documentation supporting an authorization request reaches the payer without accumulating at the intermediary.