Authorization is a paperwork race against the procedure date. AI runs the paperwork.
Pretty Good AI assembles the prior authorization packet from the athenaOne chart, names what is missing while there is still time to fix it, submits in the shape the payer expects, and reads status back out of the payer portal into athenaOne. Whether the service is warranted is your clinicians’ judgment, and whether it is authorized is the payer’s decision. Everything between those two points is clerical, and the clerical half is the part we automate.
Written for: Practice managers, revenue-cycle leaders and authorization team leads at athenaOne practices where procedures get moved because the authorization was not ready in time.
The problem
Authorization work is spread across systems that do not talk to each other. The documentation is in athenaOne, the rules are in a payer portal, and the tracking is in somebody’s spreadsheet. A practice usually finds out a submission was incomplete days later, when the payer says so, and by then the procedure date is close enough that the visit moves. The delay is rarely a disagreement about care. It is usually a missing field nobody saw in time.
What starts it
An order is placed for a procedure, imaging study, service or medication that the patient’s plan requires authorization for, or a referral accepted into the practice arrives carrying an authorization requirement.
What the AI does, step by step
Check whether an authorization is required at all
Before any packet is built, the plan and the service are checked against that payer’s rules, including no-authorization-required determinations and out-of-state benefits. A submission nobody needed to make is the cheapest one to avoid, and repeated checking of the same question by three different people is a surprisingly large share of queue volume.
Assemble the packet from the athenaOne record
The documentation, order detail, coding, demographics and coverage that payer asks for are pulled from the chart and assembled into a submission shaped for that payer specifically. Payers disagree with each other about what complete means, so requirements are configured per payer rather than averaged into one template that satisfies none of them.
Name what is missing while it can still be fixed
Anything the packet needs and the chart does not have is surfaced to the ordering provider and the authorization team early, with the specific gap named and a corrective action suggested. This happens before the submission goes out, not after a rejection comes back. Supplying missing clinical content is your clinicians’ work; knowing it is missing is ours.
Submit, then track status back into athenaOne
Status is pulled from the payer portals and written back to the athenaOne record, so the authorization team reads it in the chart instead of logging into each portal in turn. Approvals, denials, pended requests and requests for more information all land where the rest of the visit already lives.
What changes in athenaOne
- Authorization status written back to the athenaOne record as it changes, so the chart is where staff read it.
- The submitted packet and the payer’s response attached to the patient record as documents.
- Order and case documentation updated with what was submitted, when, and to which payer.
- Requests for more information recorded against the authorization with the specific gap named, rather than as a generic pending status.
- No-authorization-required determinations recorded, so the same question is not researched three times.
Completion milestones
Submitted is not authorized, and authorized is not scheduled. A submission finishes when the payer holds a complete packet. An authorization finishes when the payer issues a determination, which is the payer’s decision and never the agent’s. The visit finishes when the approved service sits on the schedule inside the authorization window. Agree which athenaOne signal marks each of those three separately before launch, because a practice measuring only the first one will believe the backlog is clear when it is not.
What your practice controls
- Which payers, service lines and order types are in scope, and which the authorization team always handles directly.
- What a complete packet looks like for each payer, which is yours to set and to change when that payer changes it.
- Whether a complete submission goes out automatically or waits for a named reviewer to release it.
- How often status is re-checked per payer, and what escalates to a person rather than waiting another cycle.
- Who owns the exception queue, and how long an item sits before it escalates.
Where a person steps in
- Clinical decisions stay with your care team. The agent does not judge whether a service is warranted, decide what care a patient needs, or write clinical justification.
- The payer issues the determination. Nothing here approves, denies or forecasts an outcome, and no patient is told their care is authorized before the payer has said so.
- Medication authorizations are administrative handling only. The agent can assemble the request, track it and route it to the queue you designate. It does not create, approve, sign or transmit a prescription.
- A peer-to-peer review is scheduled, never conducted. The agent can arrange the call and put the documentation in front of your provider. The conversation with the payer’s reviewer is your clinician’s.
- An appeal is assembled as a package, not argued. Your staff decide whether to appeal and what the argument is.
Your payer mix, not a generic template
Prior authorization is where a one-size product breaks fastest, because the rules are neither yours nor ours. They belong to each payer, and they change. A practice carrying a heavy Medicaid managed-care mix and a practice built on two commercial plans are running different jobs under the same name. We build to the payer mix you actually carry.
- Requirements are configured per payer and per service line, and you change them when a payer changes theirs. Nobody waits for a release to correct a packet rule.
- Depth of integration is what makes an unusual workflow buildable at all. Most vendors on the marketplace pick a narrower wedge and build deeply inside it; we carry significant depth across athenaOne, so pulling the one element your payer asks for out of the chart is a scoping question rather than a roadmap request.
- New workflow scope is measured in days and weeks, not quarters. A payer rule identified during onboarding ships inside the same onboarding window.
- If your authorization team already runs a sequence that works, we automate that sequence. Re-cutting a working process to suit a vendor’s opinion is not implementation work worth doing.
Illustrative walkthrough
An imaging order eight days out, missing one element
An order is placed for an imaging study eight days before the appointment. The plan is checked and the study does require authorization. The packet is assembled from the chart and one required element is absent, so the gap reaches the ordering provider that day rather than arriving as a payer rejection the following week. Once the documentation is in the chart the packet submits, and the pended status the payer returns two days later appears in athenaOne instead of in a portal nobody thought to open. If the payer asks for something further, that request reaches the authorization team with the history attached.
Synthetic example, not a customer result or a live product test.
How it gets implemented
Agree the first payer and service line
We pick one payer and one order type, usually the highest-volume authorization the practice runs, and write down what a complete packet looks like for it. That document is the implementation; the automation is the easy part.
Build to your athenaOne configuration
Production access to 820+ athenaOne APIs, with workflows built around your practice's rules. Your order types, document classes, queue routing and authorization team structure stay as they are.
Review and go live
Your team watches the agent assemble and track a sample of real authorizations against your own rules before anything submits unattended, and keeps the exception queue in view afterwards. Typical time from kickoff to the first workflow live is 3 to 6 weeks. We agree on the first workflow, how success will be measured, and the pricing for continued use before launch. There are no setup fees. Your first 30 days live are free. The clock starts when your first agreed workflow goes live in your practice, whether that is voice, web scheduling, referrals or another workflow. When the free 30 days end, service continues automatically, month to month, at the pricing in your order form. New workflows are priced when activated.
Evidence and its limits
Commonwealth Pain & Spine runs Pretty Good AI across 35 locations on its existing athenaOne configuration. That establishes deployment at scale across a multi-site specialty group, not a measured change in authorization turnaround. Ask for the workflow, the period and the denominator behind any authorization figure, ours included.
See where it is deployed →Deployment evidence is not a measured conversion improvement. Read any outcome figure with its stated workflow, period and denominator. Customer-reported results. Your numbers will vary by workflow, staffing, seasonality and call mix.
Questions buyers ask
Does this decide whether a service is medically necessary?
No. That judgment is your clinicians’ and it stays with them. The agent assembles what the payer asks for out of the record, names what is missing and tracks the response. It does not write clinical justification and it does not decide what care a patient needs.
Can it approve an authorization?
No. The payer issues the determination. Nothing here approves, denies or forecasts an outcome, and no patient is told their care is authorized before the payer has said so.
Does it handle medication authorizations?
The administrative handling only. It can assemble the request, track it and route it to the queue you designate. It does not create, approve, sign or transmit a prescription. That boundary is regulatory, not a configuration setting.
Do our staff still have to log into payer portals?
Status is pulled from the portals and written back to athenaOne, including no-authorization-required determinations and out-of-state benefits checks, so the chart is where your team reads it. A portal that genuinely needs a person is surfaced as an exception rather than quietly skipped.
What happens when a payer changes its requirements?
You change the packet rule for that payer, and only that payer. Requirements are held per payer rather than averaged into one template, which is the whole reason the configuration is shaped that way.
How is it priced?
We agree on the first workflow, how success will be measured, and the pricing for continued use before launch. There are no setup fees. Your first 30 days live are free. The clock starts when your first agreed workflow goes live in your practice, whether that is voice, web scheduling, referrals or another workflow. When the free 30 days end, service continues automatically, month to month, at the pricing in your order form. New workflows are priced when activated.
Tell us how your front office runs today.
Book a scoping session and we will walk one real authorization workflow, using a synthetic example, and write down what a complete packet looks like for your highest-volume payer. Do not send patient information through public website or booking forms.
Book a scoping session →Opens our scheduling calendar. Choosing a time books the session.