Technical / EDI
X12 278 Prior Authorization Explained
The X12 278 is the EDI transaction for electronic prior authorization: the 278 request asks a payer to authorize a service, and the 278 response returns the decision. It can automate what is usually a manual portal-and-phone process, but payer adoption is uneven, which is why many authorizations still require portal or fax work.
Prior authorization is one of the most manual, painful steps in the revenue cycle, and the EDI standard meant to fix it - the X12 278 - is also the least consistently adopted. If you are automating prior auth, understanding the 278 (and its limits) tells you exactly where clean automation ends and where you still need portal or phone work.
What the 278 is
The X12 278 is the standard EDI transaction for a health care services review - in practice, prior authorization and referrals. It is the authorization counterpart to the 270/271 (eligibility) and 837 (claims): a structured, machine-readable request and response instead of a portal form.
Request and response
The 278 request carries the patient, provider, service and diagnosis details the payer needs to make a decision. The 278 response returns the outcome: certified (approved), pended (needs more information), or not certified (denied), often with an authorization number when approved. Some payers support real-time 278; others process it in batch.
Why adoption lags
Unlike eligibility, where 270/271 is near-universal, 278 support is patchy. Many payers require clinical documentation that does not fit neatly into the transaction, or route certain services through their own portals. That is why, even in 2026, a large share of authorizations still involve a portal login or a phone call.
Where FHIR and Da Vinci fit
Newer standards are pushing electronic prior auth forward: the HL7 Da Vinci prior-authorization work (built on FHIR APIs) aims to make auth requirements and submissions programmatic, including attaching clinical documentation. It is promising and gaining regulatory momentum, but it coexists with 278 and portals rather than having replaced them.
How AI bridges the gap
Because the landscape is mixed, reliable prior-auth automation cannot depend on 278 alone. The practical approach is to use the 278 where a payer supports it, and use AI agents to work the payer portals and follow up where it does not - determining what needs auth, submitting with the right documentation, and tracking to a decision, whatever channel the payer uses.
How MedXFlow AI agents handle this
MedXFlow's AI agents work directly with the EDI transactions behind this - 270/271, 837, 835, 276/277 and 278 - and fall back to payer-portal automation where a transaction is not supported, so the workflow runs whatever channel each payer uses.
Related resources
Frequently asked questions
What is the X12 278 transaction?
It is the EDI standard for a health care services review - prior authorization and referrals. The 278 request asks a payer to authorize a service, and the 278 response returns the decision, often with an authorization number.
Why do payers still require portals if the 278 exists?
Adoption of the 278 is uneven. Many payers require clinical documentation that does not fit the transaction well, or route certain services through their own portals, so a large share of authorizations still involve portal or phone work.
How is prior authorization automated end to end?
By combining the 278 where payers support it with AI agents that handle the rest: detecting what needs authorization, submitting with documentation, working payer portals where there is no 278, and tracking each request to a decision.