Every athenahealth Surface a Front Office Actually Touches

Ask a multi-specialty group how their last front-office AI purchase went and you will usually get a careful answer. The demo was good. The phone got quieter. And the work did not go away, because the tool touched one athenahealth surface and handed everything behind it back to the same overloaded person.

This is the most common story in the segment right now, and it is not a story about bad software. It is a story about scope.

A point tool that answers calls can book a visit. It cannot work the open order that should have produced the visit, close the follow-up task that tracked it, route the refill request that arrives the next morning, or schedule the callback a clinician owes a patient. Those live on different surfaces, and each one that a vendor cannot reach becomes a queue somebody on staff still owns.

The result is a practice that bought coverage and got a new supervision job. Staff now do the original work plus the work of watching a tool do part of it. Nobody planned that, and nobody wants to say it out loud on a renewal call.

So the useful question to ask a vendor is not how good the voice is. It is which surfaces the automation can actually reach, and what happens on each of them after the call ends.

Adoption is high and relief is not

The gap between buying AI and feeling it is now measurable rather than anecdotal.

Among practices using AI in patient visits, 44% said it had not reduced staff workload, 39% said it had, and 17% were unsure. That is close to a coin flip on the only outcome that matters to an operations budget. The same polling found that practices reporting broader use across more of their encounters were more likely to report a positive workload effect.

Breadth being the variable that correlates with relief is not surprising once you have watched a partial deployment. A tool covering one step in a five-step workflow does not remove a fifth of the labor, because someone still has to hold the whole thing in their head, check the tool’s output, and do the remaining four steps at the moment the tool stops.

That is the argument for reaching more surfaces, and it is worth stating without dressing it up: partial automation of a connected workflow can cost more attention than it saves.

The order and follow-up queue is where the revenue sits

Every multi-specialty group has a queue of open orders and follow-up tasks that represent care already decided and not yet scheduled.

Those are patients a clinician has already said should come back. The order exists. The task exists. What does not exist is the hour in somebody’s day to call three hundred of them. So the queue grows, and it grows quietly, because nothing in the schedule looks broken while it happens.

Working that queue is an athenaOne task, not a phone task. Read the open orders and the follow-up ticklers, call the patients on them, book the visit against the correct appointment type, then satisfy and close the task with a note recording what happened. The note matters more than people expect, because a closed task with no record produces an argument three weeks later about whether anybody called.

The complication that breaks naive versions of this is the generic template slot. A search for a specific appointment type frequently returns an “Any 15” or “Any 30” opening, and whether that generic slot can legally hold a 45-minute new-patient visit depends on the provider and the department. Getting that mapping right, per provider per department, is most of the actual engineering. Getting it wrong produces a booked patient and an angry clinical staff member at 8 a.m.

A refill request is intake, and only intake

Refill requests are the clearest example of a workflow where the administrative half and the clinical half are easy to separate and easy to confuse.

The administrative half: a patient calls or messages asking for a refill, the request has to be matched against the active medication list, a case has to be created and routed to the right staff bucket, and the patient has to be told what happens next. Phone tasks like this are a measurable share of front-desk time, with practice leaders naming prescription refills among the time-intensive phone tasks alongside eligibility and prior authorization at 45% and scheduling at 31%.

The clinical half is the decision, and it stays with the prescriber. Always.

Where it gets operationally interesting is the rules layer in between, which practices write themselves. A typical psychiatry group policy requires that a patient has been seen inside a defined window and has a scheduled appointment before a refill request is processed, with a hard exception: for medication classes where stopping abruptly is dangerous, the automation must stop asking and transfer to a live person immediately. Controlled substance handling can also vary by state for groups with prescribers across state lines.

Those lists are authored by the group’s clinical leadership. The automation matches a request against them and routes accordingly. It never decides which list a medication belongs on, and the exit is always toward a person.

Results callbacks are a booking problem wearing a clinical coat

The callback a clinician owes a patient after a result arrives is one of the highest-stakes pieces of front-office logistics in a group practice, and it is almost always handled by whoever has a gap in their afternoon.

A study of more than 5,400 records across 23 primary care practices found a 7.1% rate of failure to inform patients of clinically significant outpatient test results, with practice-level rates ranging from 0% to 26%. That spread is the interesting part. It says the failure is operational rather than inevitable, because some practices in the same study got very close to zero.

The administrative contribution is booking the call and making sure it lands with the right person. That second part has a trap in it. The chart’s primary provider field is stale at most practices and cannot be trusted for routing, so the workable fallback is who has actually seen the patient recently. A callback routed to a physician who has not seen the patient in four years is technically assigned and practically lost.

So the automation books the callback, puts it on the calendar of the clinician the recent visit history points to, confirms it with the patient, and records it. It does not open the result, characterize it, or say anything to the patient about what it contains. The clinician makes the call and owns every word of it.

Breadth only counts when the surfaces connect

Pretty Good AI integrates with 440+ athenaOne APIs, and that number is worth exactly as much as the connections between the things it reaches.

A count of integrations is easy to put on a slide and hard to feel. What a practice feels is whether one workflow completes without a person carrying it across a gap. A patient calls about a refill, the request is matched and routed, the policy says they need a visit inside a window, a slot of the right type is offered and booked, the follow-up task is closed with a note, and the whole thing happened in one contact. That is a single workflow crossing four surfaces, and it either works or it does not.

When it does not, the failure is almost never the voice. It is a mapping that was never built between an appointment type and a provider group, or a task that can be read but not closed, or a case that lands in a bucket nobody owns.

So when a group evaluates breadth, the question to hold onto is not how many surfaces a vendor names. It is whether they can walk one real workflow across all of them, live, with the practice’s own configuration loaded.

Key Takeaways

Measure a front-office tool by which athenaOne surfaces it can reach after the call ends, not by demo quality on the call itself.
Work the open order and follow-up task queue as a scheduling program, and close each task with a note recording what happened.
Resolve generic template slots to specific appointment types per provider and per department before offering a time.
Treat refill requests as intake and routing against rules clinical leadership authored, with an immediate transfer path for the exceptions they define.
Route results callbacks by who has recently seen the patient rather than by the chart’s primary provider field.
Ask a vendor to walk one workflow across every surface it touches with your own configuration loaded, rather than counting integrations.

Breadth is not a bragging point, it is the difference between removing a workflow and supervising one. A group evaluating front-office automation should keep asking the same question at every step: after this, who is holding the rest of it.

Sources