Custom athenaOne Workflow Automation: Scope to Live

We adapt to your practice. Your practice does not adapt to us.

Ask a practice administrator which tasks eat the most staff hours and you rarely get a feature name back. You get something specific: chasing one payer for prior-auth status because that payer will not accept the portal submission. Triaging inbound referrals against acceptance criteria that exist in one person’s head. Working denials for a reason code that keeps recurring. Migrating a departing provider’s panel without losing the patients.

The national data says the same thing from a different angle. In a March 10, 2026 MGMA Stat poll of 294 practice leaders, the most time-consuming phone work was eligibility and prior authorization at 45% and scheduling at 31%. Those are not categories a fixed feature set covers evenly, because the rules inside them differ by payer, by department and by practice.

So this page is not a feature list. It is the path from a workflow you describe out loud to that workflow running in athenaOne: what we need from you, what we come back with, and how long each stage takes.

The path, stage by stage

Stage 1. We look at how your front office actually runs. What we need: read access to your athenaOne data, and about an hour of the person who runs the workflow. What we come back with: the last 90 days of appointments, departments, providers and appointment types, ranked by volume, next to the rules you told us. Those two things disagree more often than anyone expects. In a joint session with an EHR vendor the working estimate was that roughly a fifth of the logic a practice hands over is outdated, and the booking history is what corrects it. The rules that matter are a mix of what is written down, what is not written down, what is in athenaOne, and what is not.

Stage 2. We scope it, in writing. What we need: a decision on the two or three edge cases the data surfaced. What we come back with: the workflow written as steps, the exception paths, what gets written back to athenaOne, what gets handed to a person, the build time and the price. Scope, time and price are agreed before work starts rather than discovered afterwards.

Stage 3. We build it. What we need: nothing from you during the build, which is the point. What we come back with: the workflow running against your real templates, slot types, provider groups, departments and queues. New workflow scope is measured in days and weeks, not quarters, inside an onboarding window that already runs weeks. A workflow identified during onboarding usually ships inside that same window rather than waiting for a release.

Stage 4. Supervised live blocks, then a written change list. What we need: a half day where your team listens to real calls and files what they want changed. What we come back with: a written report and a list of changes to build. One practice filed eight issues in a single morning. Three of them were compliments. This stage is where the rules that were never written down finally get written down.

Stage 5. Refit, continuously. What we need: a heads-up when something changes on your side. What we come back with: the remap. The work after launch is the product, and it is priced the same way the first workflow was.

Why the window is short

The reason a custom request is tractable for us and awkward for a point tool is coverage.

A vendor supporting several EHRs has to express every workflow in a model general enough to translate into all of them. That model is the intersection of what the supported systems have in common, and a request that lives outside the intersection means new work in the translation layer for every system they support.

Building only for athenaOne removes that constraint. Production access to 820+ athenaOne APIs is what makes an unusual workflow buildable at all. Most marketplace vendors pick a narrower wedge and build deep inside it; we carry significant depth across the whole of athenaOne. When a practice describes a workflow, the objects in the description, appointment types, provider groups, order and tickler queues, eligibility responses, referral orders, claim and denial reasons, document classes, are objects we already read and write.

The question stops being “can we reach the data” and becomes “can you tell us the rule”.

The three-question test

Before anyone quotes anything, a workflow has to pass three tests. We run them on a call and the answer is sometimes no.

1. Can the decision be written down? Not “is it simple”, but written down. Payer-specific prior-auth rules are intricate and highly automatable, because the rules are real and knowable. A referral triage where two experienced schedulers handle the same case differently and neither can explain why is not automatable by anyone, including us, until the practice decides which one is right. That is a genuinely useful outcome of the scoping call even when it ends in no.

2. Can we read the inputs from athenaOne, and write the outcome back or hand it to staff? The workflow needs a readable input, a defined outcome and a path for exceptions.

• Read: inputs and decision context from athenaOne.
• Write: the outcome back to the athenaOne object, or a staff task and note when write-back is not available.
• Exception: a routed staff task with the reason and supporting context attached.

If the rule depends on a spreadsheet on somebody’s desktop or a payer portal with no interface, we will say so and scope around it rather than pretend.

3. Is the decision administrative rather than clinical? Clinical decisions stay with your care team. Everything around them, from the first call through the visit and the bill, is in scope. We prepare a prior auth, track it, chase it and tell you where it stands; a licensed human decides what care is appropriate. We handle the administrative steps around a refill and route the request to the right clinician; prescribing decisions stay with your care team.

What custom actually looks like

The requests that come to us cluster, which is the tell that they are underserved rather than exotic:

• Payer-specific prior-auth preparation and chasing. One workflow per difficult payer, because the payers differ and a generic prior-auth feature averages them.
• Referral triage against a practice’s acceptance criteria. Parse the inbound referral, check it against what this practice actually accepts, book it or route it back with a reason.
• Specialty-specific recall and order cadence. The interval that matters in sleep medicine is not the one that matters in vascular surgery.
• Provider-departure panel migration. Reach every patient on a departing provider’s panel and move them to the right remaining provider before they go looking elsewhere.
• Denial rework by reason code. A queue per recurring reason, worked on a schedule, with the appeal prepared.
• Records-request fulfillment. Intake, verify, fulfill and log, which is pure administrative work and almost never automated.

Patients reach the practice by phone or secure two-way text on the same athenaOne integration, so a workflow that starts on a call and finishes over text is one conversation rather than two, and the voice side runs the full administrative call in 10 languages.

What a real change after launch looks like

A dermatology practice consolidated its appointment-type catalog without notice. Cosmetic types, two biopsy durations, cryotherapy and the generic procedure type were all retired and folded into one follow-up type. The surviving type was fifteen minutes, so a forty-five-minute service no longer had anywhere to go, and the practice still wanted the reason for visit to carry the specific service name.

Our engineer flagged the cascade rather than letting it book wrong, and asked for a heads-up next time. The fix took a decision from the practice: keep the retired types internally, map them onto fifteen and thirty-minute equivalents, and carry the service name through as reason for visit. Cases that hit an unmapped type in the meantime went to staff with the context attached.

That is the honest shape of this work. Nothing about it is set-and-forget, and the refit is the part most vendors do not price for. Ask any vendor you are evaluating what happens on the day your appointment types change.

Where we are not a fit

Three boundaries, stated plainly.

Clinical judgment. We do not diagnose, screen by acuity, or decide what care is appropriate. Those stay with your care team, always.

Data that does not exist. If the rule depends on something that lives only in a person’s head or in a system with no interface, the scoping call will say so. We would rather lose the scope than build something that guesses.

Rules the practice has not settled. When two experienced staff handle the same case differently and neither can say why, that is a decision the practice owns. We can surface it from the booking data. We cannot make it for you.

Why the staffing math pushes this

Front-office roles turn over faster than almost any other seat in the practice. MGMA’s 2023 Practice Operations data report put front-office turnover at 40% in 2022, against 33% for clinical support and business operations support staff. Every departure restarts the training clock on exactly the workflows that were never written down.

Writing a workflow down so it can be automated has a second benefit that nobody puts in a business case: the rule survives the next resignation.

Terms

No setup fees. Your first 30 days live are free, and service continues month to month after that. Where a practice wants a workflow built beyond the standard modules, that build is scoped and quoted in writing before work starts, and new workflows are priced when activated.

Where to start

Most practices begin with voice at the front door because it is the loudest problem and it produces the structured data everything downstream needs. The specific work usually arrives in month two or three, once the obvious volume is handled and what is left is the stuff nobody else would build.

If you already know which workflow is eating your staff, start there instead. Tell us how your front office runs today and we will tell you what we would build against it.