Prior authorization in athenahealth runs through athenaOne, which flags when an order needs authorization, stores the authorization number on that order, and routes some requests through electronic prior authorization where the payer supports it. What athenaOne does not do is complete each payer's request for you, follow up on pending ones, or key the approval back onto the order on its own. That manual middle is where AI fits. A browser agent signs into athenaOne the same way your staff does, reads the order and the authorization requirement, submits the request through the payer's channel or a call, and writes the authorization number, status, and dates back onto the athenaOne order. The mechanism is plain: read the order, work the payer, write the result back, with anything uncertain escalated to a person.
How does prior authorization work in athenahealth?
In athenaOne, prior authorization is tied to the order, and it starts from an eligibility check. athenaOne runs real-time eligibility through the 270/271 transaction, which is where the member's plan and any authorization requirement first surface. When a provider then places an order that needs authorization, athenaOne flags the requirement, gives you a place to record the authorization number and dates, and, for some payers and services, supports an electronic prior authorization path that maps to the 278 authorization transaction. From there a staff member confirms the requirement against the member's plan, assembles the clinical documentation, and submits on whatever channel the payer accepts. Many requests still route to a payer portal or a phone queue rather than a clean electronic path, so the person works outside athenahealth to submit and then returns to the order to log the result. athenaOne holds the record of the authorization, but the submission and the day-to-day chasing of pending requests remain manual, because the platform tracks the outcome rather than doing the payer-side work for you.
Can AI automate prior authorization in athenaOne?
Yes, by driving the same screens the work already runs on. A browser agent opens athenaOne in a session, reads the order and the authorization requirement, and gathers the diagnosis, procedure code, and clinical notes the payer will ask for. Where the payer accepts an electronic request, the agent completes it; where the payer only offers a portal, the agent works the portal; where the payer requires a call, a voice agent places it, works the phone tree, and captures the reference number. The agent then returns to the athenaOne order and records the authorization number, status, and dates. The load this offsets is real: the American Medical Association reports that physicians complete about 39 prior authorizations per physician per week, taking roughly 13 hours of physician and staff time. Running that work consistently, and checking pending requests every day, catches problems before they turn into denials. Flexbone builds this specifically for practices on the platform, described on our AI for athenahealth page.
See what AI can run at your facility. In a 30-minute audit we map the calls, eligibility, and follow-ups Flexbone can take off your team first.
Book an auditWhat are athenahealth's prior authorization limits?
athenaOne is strong at telling you an order needs authorization and at storing the result, but the manual burden sits in the steps between those two points. Someone has to read each payer's medical-necessity criteria, assemble the documentation, submit on the payer's channel, and then check the pending queue day after day until a decision lands. Coverage of true electronic prior authorization depends on the payer and the service, so a meaningful share of requests still fall back to a portal login or a phone call that athenahealth does not automate. athenaOne also records the authorization number but does not, on its own, verify that the coded service on the eventual claim matches what was approved, which is a common source of avoidable denials. In short, the platform tracks authorization state well; it does not do the payer-side submission, the follow-up, or the coding cross-check, and that gap is exactly where staff hours and preventable denials accumulate.
How does AI write authorization status back into athenahealth?
Once the agent submits a request or receives a decision, it returns to the specific athenaOne order and records the result in the same fields your staff use: the authorization number, the approved or denied status, the effective and expiration dates, and the payer's reference number. Because the agent drives the athenaOne interface rather than a separate system, the update lands on the exact order the claim will bill against, so billing sees a current authorization without a second hand-off or a manual re-key. When the payer denies or pends the request, the agent records the reason and routes the case to a person for appeal or additional documentation instead of leaving it silent in a portal. Standardized transactions and codes still underpin the work, from the 278 authorization request to the 276/277 claim status check that catches an aging claim and the 835 remittance whose CARC and RARC codes explain a downstream rejection, but the agent, not a staff member toggling between windows, does the writing-back. The result is that the athenaOne chart reflects the true authorization state without depending on someone remembering to update it. For the broader pattern across payers and platforms, see prior authorization automation.
Flexbone can map which parts of your athenahealth prior authorization workload run cleanly with AI, from reading the order and submitting the request to working the payer's portal or phone queue and writing the status back onto the athenaOne order. To walk through your athenaOne workflows and see what AI can take on, book a call with Flexbone.