x278Prior Authorization
Introducing x278: An Agent-Native Protocol for Prior Authorization
x278 models prior authorization as a structured exchange between agents, not a fax-and-wait loop.
x278 models prior authorization as a structured exchange between agents, not a fax-and-wait loop.
Most prior authorization still moves at the speed of a phone call, a portal login, or a fax. A staff member assembles a request, sends it into a queue, waits, and eventually receives an answer that is often incomplete. When the payer needs another chart note or a different code, the case does not resume. It restarts. Someone re-reads the policy, re-collects the documentation, and re-submits.
That pattern is expensive even when every person involved does their job well. The problem is not effort. The problem is that the exchange itself was never designed to be acted on by software. The request is unstructured, the response is opaque, and the audit trail is a pile of confirmations that do not explain the rule.
We are increasingly going to ask software agents to run these workflows. An agent can read a chart, find the relevant policy, and assemble a request faster than a person can open the portal. But an agent is only as useful as the exchange it operates inside. If the response is a free-text denial with no next action, the agent is stuck in the same place the human was.
That is the gap x278 is meant to close.
x278 is a proposed protocol and TypeScript SDK that models prior authorization as a typed exchange between a provider-side agent and a payer-side agent. A provider agent submits a structured request: patient, provider, service, diagnosis, urgency, and supporting information. A payer agent returns an actionable determination. The workflow continues without restarting the queue.1
The point is not to add another transaction format. The point is to make the exchange legible to the software that will run it. A request has a known shape. A determination has a known shape. Each side can reason about the other without screen-scraping a portal or parsing a PDF.
The reference implementation is open source, and the SDK is published so teams can run the full request-and-determination loop against an in-memory reference payer before they touch a real endpoint.2
The most important design decision in x278 is that a determination is not a verdict the agent has to interpret. It is one of four explicit states, and each non-approval carries a next action.
approved means the authorization was granted by rules or by a reviewer. denied means the request was declined, with a coded reason and an appeal path, so the agent knows whether to correct and resubmit or start an appeal. info-needed means specific documentation is required; the agent attaches the evidence and resumes the same authorization context. pended means the request was accepted but is not final; the agent awaits the returned subscription or update handle rather than polling blindly. A fifth state, error, signals that the exchange itself was malformed or unprocessable.
The difference between this and a typical denial is that the response tells the agent what to do, not just what happened. A denial that says only "not covered" forces a human to reconstruct the reasoning. A determination that says "info-needed, attach the operative note, resume on this authId" can be handled by the agent that submitted the request.
When a payer asks for more information today, the case usually goes back to the start of the queue. The provider re-opens the request, re-collects the documentation, and re-submits, often losing the thread that connected the original request to the follow-up.
x278 treats documentation as a retry, not a restart. The provider agent attaches the missing evidence and resumes the same authorization using the same identifier. The context is preserved. The payer is responding to a continuation of the original request rather than receiving a new one. For a human, that is a convenience. For an agent running thousands of these exchanges, it is the difference between a workflow that converges and one that loops.
x278 is not an attempt to replace the standards that already govern this space. It is designed to map onto them.
Prior authorization already has adopted transaction standards. CMS lists the X12 278 as the standard for health care services review information, the request-and-response transaction that prior authorization rides on today.3 The clinical and documentation layer increasingly runs through FHIR, where the Da Vinci Prior Authorization Support implementation guide defines how prior authorization requests and responses are represented as FHIR resources.4
x278 maps its requests and determinations onto those FHIR and PAS-style resources while keeping the SDK surface agent-friendly. The goal is to give an agent a clean, typed shape to work with, and to keep that shape translatable to the formats payers and EHRs already use, rather than asking the ecosystem to adopt something disconnected from its existing infrastructure.
The regulatory direction is toward APIs, and the readiness gap is wide. CMS has finalized prior authorization interoperability requirements for impacted payers, including a Prior Authorization API intended to improve transparency and automate parts of the process, with key provisions phasing in for 2027.5 At the same time, CAQH reported that only 35% of prior authorizations were processed electronically in its 2024 index, and that only 9% of surveyed organizations could support the electronic prior-authorization API the rule will require.6
A mandated API moves a request faster. It does not, by itself, make the response something an agent can act on. An API can carry a denial; it does not guarantee the denial explains what to do next. The agent-native layer is what turns a transaction into a workflow that resolves.
That is the bet behind x278: as more of this work shifts to APIs and to agents, the bottleneck moves from sending the request to acting on the answer. A protocol that makes the answer actionable is the part that is currently missing.
x278 is a proposed protocol and a reference implementation. It is not a certified payer integration, and it is not a substitute for Da Vinci PAS conformance testing or for the compliance work a production deployment requires. It is not legal or compliance advice.
It is also, today, a Backwork-authored standard rather than a neutral foundation specification. We think that is the honest framing. The protocol is open and the implementation is public, but it has not yet been through the kind of multi-party governance that turns a useful convention into an industry standard. If other implementers, payers, EHR vendors, and contributors find it worth building on, neutral stewardship is the right next step. For now, it is a concrete proposal with running code behind it.2
Backwork's first product, Verity, answers the coverage question: whether a service is supported by payer policy, whether prior authorization is required, and what documentation the payer will need, with the source behind each answer. x278 is the exchange that carries that work to the payer and back.
The two fit together. Coverage intelligence determines what a defensible request looks like before it is sent. x278 defines how that request and its determination move between agents, and how the case resumes when the payer needs more. One decides what to ask. The other decides how the asking and answering happen.
Prior authorization will not stop being adversarial because we gave it a cleaner data model. Policies will still be ambiguous, some cases will still need a human reviewer, and a typed exchange does not make a denial correct.
But the current exchange is built for a fax machine, and we are about to hand it to agents. The useful move is to fold the gatekeeping handshake into the action, so the request, the determination, and the retry all happen in a shape software can reason about, and the human is left to handle the exceptions that actually need judgment.
That is what x278 proposes. The protocol, the SDK, and the spec are available now at x278.backworkai.com, and we would rather build it in the open than describe it in the abstract.1
Backwork. "x278 by Backwork." x278.backworkai.com ↩ ↩2
Backwork. "x278: agent-native prior authorization protocol reference implementation." github.com/backworkai/x278 ↩ ↩2
HL7 Da Vinci Project. "Da Vinci Prior Authorization Support (PAS) Implementation Guide." hl7.org ↩
CMS. "CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)." cms.gov ↩
CAQH. "The Path Forward for Prior Authorization Reform." caqh.org ↩
