Prior authorization · X12 278 · agent native
Prior authorization,
prepared by software.
Released by a person.
Agents read the schedule, ask the health plan what it needs, assemble the request and chase the answer. Nothing reaches a payer, and nothing reaches a chart, until a licensed human releases that exact submission.
- 72h / 7d
- CMS decision windows tracked per request
- Two rails
- X12 278 today, FHIR PAS from 2027
- Zero
- Authorizations sent without a human release
A surgery goes on the schedule. Somebody has to find out whether the plan requires authorization, what documentation it wants, which questions it will ask, and then chase it for a week. Miss it and the procedure happens anyway - and the claim is denied afterwards, when nothing can be done.
That work is legible, repetitive and deadline-bound. It is also consequential enough that nobody sensible wants it fully automated.
How one authorization actually moves
Four real paths through the same process. AI agents prepare; a licensed person releases. Pick a path, or click any step to hold it.
- Surgery scheduled
- Read the schedule
- Ask the plan
- Assemble
- Human release
- Transmit202
- Sent backpended
- Gather documents
- Human release
- Resubmit202
- ChaseA4
- PartialA2
- Human release
- Write back
A procedure is booked. Nobody has yet asked whether it needs authorization.
What it does
Finds the work
Reads scheduled surgeries and in-office procedures out of the EHR, before anyone has thought to ask about them.
Asks the plan
Rather than consulting a code list we curated, it asks the health plan whether this member’s plan requires authorization for this procedure. The plan answers; we do not guess.
Assembles the request
Pulls the diagnoses, the order and the coverage, checks the two systems agree about who the patient is, and builds the 278.
Chases the answer
Durable, leased polling that tightens as the decision window closes. A payer that takes four days is still being chased on day four.
Writes back
Puts the authorization number on the appointment and the payer status in the chart - both released by a human, both marked as automated in the record itself.
Says when it cannot
Where no verified source answers, it abstains, raises a task, and names what it could not determine.
The agent never sends
This is the product, not a setting. There is no autonomy level that removes it, no configuration a practice can change, and no customer who gets it turned off.
- No authorization is transmitted without a named licensed human releasing that specific request.
- A release is single-use and bound to the exact content approved. Approving one request does not authorise a similar one.
- No adverse determination is ever communicated or acted on by software.
- Nothing is attached to a clinical record without a human release, and anything written says in the chart that it was automated.
How it is built
Practice isolation
Every record carries the practice it belongs to. A read that does not name a practice is refused rather than returning everything - the filter is not something a caller remembers to apply.
Minimum necessary by default
List views are masked at the server. Full identifiers are never sent to the browser, so they cannot be recovered from the page source or a screenshot.
Autonomy that expires
An agent may act above proposing only while a recent test suite says it should. After fourteen days the licence lapses and it drops to proposing, whatever its configured ceiling says.
One door
Agents reach nothing directly. Every call passes one gateway that checks the practice, the permission, the autonomy level, the PHI level, the bounds, the budget, and writes the audit record.
Vendors behind ports
The clearinghouse and the EHR sit behind adapters. When a payer moves to FHIR, an adapter changes and the agents do not.
Severity-weighted evaluation
An eval that counts errors equally lets a system trade one wrong-patient event for twenty formatting nits. Ours weights them orders of magnitude apart, and a single never-event fails the gate outright.
Two rails, on purpose
CMS-0057-F requires impacted payers to decide expedited requests in 72 hours and standard requests in seven calendar days, with a compliance date of 1 January 2026, and to stand up a FHIR prior authorization API from 1 January 2027. QHP issuers on the exchanges are excluded from the decision timeframes, and drugs are excluded from every provision.
So X12 278 does not go away when FHIR arrives - both rails run, for years. The adapter boundary is there so a payer can move without the agents noticing.
89 FR 8758 · CMS fact sheet
What it will not do
Most of this page is a list of things the software declines to do on its own. That is the design, and it is worth being explicit about the rest.
- It does not practise medicine. No diagnosis, no treatment recommendation, no coverage determination. It prepares paperwork.
- It does not guess a payer rule. Where no verified source answers, it abstains and says so. An unanswered question becomes a task, never a silent clearance.
- It is not a HIPAA compliance certificate. Compliance is a determination made about a deployment by people who examined it, not a property a vendor asserts about itself. We describe the controls that are built and invite you to check them.
- It does not train on your data. PHI is not used to train, tune or improve any model. Vendor agreements carry that term or we do not use the vendor.
Getting started
Six steps, in this order, because each one is enforced by the step before it. A practice can complete the whole sequence itself. Nothing here needs us on a call.
Bring your own Availity credentials
MinutesYour practice holds the trading relationship and the entitlement; we submit under it, never under ours. You supply the client ID and secret from your Availity developer application, plus the scope (healthcare-hipaa-transactions, which covers both Service Reviews and Coverages) and a customer ID if your organisation structure needs one.
Settings · ConnectionsThey are validated before they are stored
SecondsWe call Availity with the credentials you gave us and keep them only if the call succeeds. If no validation probe exists for a vendor, the connection fails closed rather than being accepted on trust. The secret is encrypted at rest, never displayed again, never written to a log, and never placed in an audit record.
AutomaticThen, and only then, mint your API key
Under a minuteKey generation is blocked while any required connection is missing, unvalidated or revoked. Once it is green you issue your own client ID and secret for your systems to call us with. The secret is shown exactly once. If it is lost you rotate the key, because we cannot retrieve it for you.
Settings · API keysName the people who can release
Your decision, not our processA machine credential cannot release a clinical determination, and no permission level grants it. That authority belongs to a named licensed human, so the practice records who those people are before anything can leave the building.
Admin · RolesRun against recorded traffic first
For as long as you wantNew connections default to replay, which answers from recorded payer interactions. A request with no matching recording aborts rather than falling back to an invented response, so a gap in your test coverage shows up as a failure instead of a plausible answer.
Replay by defaultAutonomy is earned, and it expires
Renewed every 14 daysEvery agent starts at proposing. Acting above that requires its evaluation suite to have passed inside the last fourteen days; when the licence lapses the agent drops back to proposing whatever its configured ceiling says. A never-event quarantines it immediately, without anybody watching.
Agents · Autonomy
Steps 1 to 3 are a single sitting. Steps 4 to 6 are decisions and evidence rather than configuration, and they take as long as they take. Obtaining the Availity application itself is between you and Availity, so we do not put a number on it.
Why your own keys, and not ours
Most platforms hold one clearinghouse relationship and submit for every customer under it, separated by an internal tenant ID. We do not, for four reasons that are properties of the design rather than promises about our conduct.
An isolation bug fails instead of succeeding quietly
There is no house credential to fall back on. Every outbound call has to resolve which practice it is acting for, and if that resolution is missing or wrong the call fails. Under an umbrella account the same bug submits successfully, under a credential the payer accepts, and nobody finds out until reconciliation.
Revocation is yours, and needs nothing from us
The credential lives in your Availity account. If you want us to stop, you turn it off there and we stop. No ticket, no notice period, no cooperation required from a vendor who may be the reason you want to stop.
Your evidence comes from the payer, not from us
Transactions appear in your own Availity audit trail under your own credential. You can reconcile what we say we submitted against what Availity records as submitted, which means our logs are checkable rather than authoritative.
See it work
The console runs on synthetic data. Every screen shows its own evidence - what was checked, what abstained, and what is waiting on a person.