Custom athenaOne Workflow Automation: What to Do When No Vendor Will Build It

The workflows nobody will build for you

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.

These are not edge cases. They are the ordinary texture of running a practice, and they are consistently the last thing to get automated, because most front-office software is sold as a fixed feature set. If your workflow is on the list, you are served. If it is not, you are told it is on the roadmap.

We built the product the other way round, and this page explains what that means in practice — including the parts we will not do.

Front door to back office, in one place

The reason a custom request is tractable for us and awkward for a point tool is coverage. A booking product can automate booking. An intake product can automate intake. When the workflow crosses stages — and the expensive ones always cross stages — the automation stops at the seam and a human carries the work across.

We cover the whole path a patient and their money take through the practice:

Patient discovery and acquisition. Self-referral web forms, a provider referral portal, fax and email referral intake with the referral parsed and de-duplicated, new-patient registration collected before day one, and closed-loop attribution from the source of the referral to the visit that resulted.

Getting the patient booked and into the room. Inbound voice 24/7 with smart routing, booking and rescheduling against real provider availability, waitlist backfill on cancellations, no-show recovery, lapsed-patient reactivation, tickler and order outreach, appointment reminders and confirmations, and multilingual service.

Everything that decides whether you get paid. Eligibility and insurance verification before the visit, prior-auth status tracking and preparation, denials and appeals worked by reason code, patient balance collection, and payment links and plans.

The back office nobody demos. Records requests, document classification, fax intake and routing, demographic and pharmacy updates, referral status tracking back to the referring provider, and per-call QA with KPI reporting on all of it.

That list is not a wishlist. It is the work our AI does inside athenaOne today, and it is only possible because we connect 500+ athenaOne APIs out of the roughly 800 endpoints athenahealth exposes and support nothing else.

Why depth in one system is what makes custom work cheap

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 custom request that lives outside the intersection is genuinely expensive for them to build — not because they are unwilling, but because it means new work in the translation layer for every system they support.

Building only for athenaOne removes that constraint. 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”.

That is why an unusual request is often a configuration exercise for us and a roadmap conversation elsewhere.

The three-question test for whether a workflow can be automated

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” — 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. Does every object live in athenaOne, or somewhere we can read? If the rule depends on a spreadsheet on someone’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? We automate the logistics around clinical work, never the clinical decision inside it. We prepare a prior auth, track it, chase it and tell you where it stands; a licensed human decides what care is appropriate. We route a refill request through your approval workflow; we do not approve it. This is a firm line and it does not move for a large contract.

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 fulfilment. Intake, verify, fulfil and log, which is pure administrative work and almost never automated.

How to scope one with us

Bring the workflow, not a feature request. The scoping call is short and it is mostly us asking what happens today: who touches it, in what order, what they look at to decide, what they type into athenaOne when they are done, and what makes a case go wrong.

Out of that call you get one of three answers, quickly. Yes, and here is the scope, the build time and the price in writing before work starts. Yes, but the practice has to settle a rule first, and here is which one. Or no, with the reason — usually that it is a clinical decision or that the data does not exist.

Nobody enjoys the third answer, but a vendor who never gives it is a vendor whose roadmap you are about to join.

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 custom work usually arrives in month two or three, once the obvious volume is handled and what is left is the specific stuff.

If you already know which workflow is eating your staff, you can start there instead. Practices come to us having asked other vendors to build exactly this and been told no, or having failed to find anyone who covers it. That conversation is a good use of a call even if the answer turns out to be no.