Coverage checked before the visit, not discovered at the front desk.
Pretty Good AI runs the eligibility check against the patient’s plan, reads the benefit detail your staff would otherwise dig for, writes what it finds back into the athenaOne record, and re-checks on the schedule you set so a plan change between booking and arrival is caught before the patient is standing at the desk. What the plan actually pays on a given claim is the payer’s answer, and we do not invent it.
Written for: Practice managers, front-office leads and revenue-cycle staff at athenaOne practices where coverage problems are found at check-in rather than before it.
The problem
Eligibility is cheap to check and expensive to skip. The check itself takes seconds, but reading what came back takes judgment, and the plans that need the most reading are the ones a busy front desk has least time for. So the work gets batched, or done for tomorrow only, or skipped for established patients who changed jobs in March. The practice finds out at the desk, in front of the patient, which is the worst place and the worst moment to find out.
What starts it
An appointment is booked, rescheduled or confirmed, or a configured window before the visit arrives, or a new patient registration lands with coverage attached.
What the AI does, step by step
Run the check against the plan on file
The eligibility request goes out against the coverage recorded in athenaOne and the response is read rather than merely stored. An active or inactive answer is the easy half. The useful half is what the response says about the plan underneath it, which is the part staff normally open a portal to find.
Read the benefit detail that changes what the front desk says
Copay, deductible status, coinsurance, plan type and whether the practice is in network for that specific product are pulled out of the response and recorded in plain terms. A response that technically says active while the patient sits under an unmet deductible is a different conversation at the desk, and the desk should have it before the patient arrives.
Name the problems while they are still fixable
A termination date, a plan the practice is out of network for, a subscriber mismatch, a missing member ID digit or a coverage gap on the date of service is surfaced as a specific named problem with the field that caused it, routed to whoever in your practice owns that fix. Staff get the gap, not a status code to go interpret.
Re-check before the visit, because coverage moves
A check run at booking is stale by the appointment if the appointment is six weeks out. Coverage is re-verified on the cadence you set per payer and per appointment lead time, and only a change is raised. Re-running every check nightly and reporting every result is how an eligibility report becomes something nobody reads.
What changes in athenaOne
- Coverage status and the payer response written back to the athenaOne record, so staff read it in the chart rather than in a portal.
- Benefit detail recorded against the visit in plain terms, including copay, deductible status and network status for that product.
- Named coverage problems routed as tasks to the queue your practice designates, with the specific field that caused them.
- Re-check history kept against the appointment, so a change between booking and arrival is visible as a change rather than overwriting the original answer.
- Insurance card images captured at registration attached to the record and matched against what the payer returned.
Completion milestones
Checked is not the same as resolved, and resolved is not the same as collected. A check finishes when the payer has answered and the answer is in athenaOne. A coverage problem finishes when a person has fixed the record or decided how the visit proceeds. Neither of those is a payment. Agree which athenaOne signal marks each separately before launch, because a practice measuring only the first will read a clean verification rate while the same problems keep reaching the front desk.
What your practice controls
- Which payers and appointment types are in scope, and which coverage situations your staff always handle directly.
- How far ahead the first check runs, how often coverage is re-checked per payer, and what lead time triggers a re-check at all.
- Which benefit fields matter enough to record for your specialty, because the fields that drive a conversation at a pain clinic desk are not the ones that drive it at an optometry desk.
- Which coverage problems route to which queue and which escalate to a named person rather than waiting a cycle.
- Whether the patient is contacted about a coverage problem automatically, or only after your staff have looked at it.
Where a person steps in
- Clinical decisions stay with your care team. Coverage is an administrative fact about a plan, and nothing here touches what care a patient should have or whether a service is warranted.
- The payer decides what it pays. The agent reports what the payer returned and does not promise an outcome, guarantee a benefit, or tell a patient a service is covered.
- A patient cost estimate is not a quote. Benefit detail pulled from an eligibility response is the input to an estimate, and your staff own anything presented to a patient as what they will owe.
- Authorization is a different job. An eligibility response says a plan is active and what it generally covers; whether this specific service is approved is prior authorization, and that workflow is separate.
- Coordination of benefits, unusual secondary coverage and anything where the subscriber relationship is genuinely unclear go to a person. A confident wrong answer about which plan is primary is worse than an exception.
Your payer mix and your specialty’s benefit fields
Eligibility looks standardized and is not. The transaction is standard; what a practice needs out of it is not. Which fields matter, how early to check, how often to re-check and what is worth interrupting a staff member for all depend on the payer mix and the specialty. We build to the mix you carry rather than to an average practice that does not exist.
- The benefit fields recorded are the ones your specialty acts on, and you change the set when your mix changes. Nobody waits for a release to start capturing a field.
- 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 writing the answer back where your staff already read it is a scoping question rather than a roadmap request.
- Re-check cadence is set per payer and per lead time, because the payer that changes coverage mid-month and the payer that never does should not generate the same noise.
- If your front office already runs a verification sequence that works, we automate that sequence. Re-cutting a working process to match a vendor’s opinion is not implementation work worth doing.
Illustrative walkthrough
A six-week-out appointment where the plan changed in between
A patient books a specialist visit six weeks out and the check at booking comes back active with a known copay. Four weeks later the re-check for that payer returns a termination date eleven days before the appointment. The change is raised as a named problem rather than a fresh status line, and it reaches the staff member who owns coverage fixes with the prior answer attached so the difference is obvious. Your practice decides whether to call the patient, move the visit or proceed. The front desk is not learning about it with the patient standing there, and nobody told the patient their new plan would be fine.
Synthetic example, not a customer result or a live product test.
How it gets implemented
Agree the first payer and appointment type
We pick one payer and one appointment type, usually the highest-volume combination the practice runs, and write down which benefit fields your staff actually act on and what a coverage problem should do when it is found. That document is the implementation; the transaction is the easy part.
Build to your athenaOne configuration
Production access to 820+ athenaOne APIs, with workflows built around your practice's rules. Your appointment types, departments, document classes and queue routing stay as they are.
Review and go live
Your team watches the agent verify and write back a sample of real appointments against your own rules before anything runs unattended, and keeps the exception queue in view afterwards. 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 verification turnaround or denial rate. Ask for the workflow, the period and the denominator behind any eligibility 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 tell the patient what they will owe?
No. It records the benefit detail the payer returned, which is the input your staff use to build an estimate. What a patient is told they will owe is your practice’s, and an eligibility response is not a guarantee of payment on a future claim.
Is this the same as prior authorization?
No, and conflating them causes real problems. Eligibility says a plan is active and what it generally covers. Authorization is the payer approving a specific service. They are separate workflows with separate rules, and the authorization work has its own page.
How often is coverage re-checked?
On the cadence you set, per payer and per appointment lead time, and only a change is raised. A check at booking is stale by a visit six weeks out, and re-running everything nightly produces a report nobody reads.
What happens when the response is ambiguous?
It goes to a person. Coordination of benefits, unclear subscriber relationships and odd secondary coverage are routed as exceptions rather than resolved by guess. A confident wrong answer about which plan is primary costs more than an exception in a queue.
Does it work for established patients, not just new ones?
Yes, and that is usually where the value is. A new patient’s coverage gets attention by default. The established patient who changed employers in March is the one whose card nobody re-read, and a scheduled re-check is what catches it.
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 verification workflow, using a synthetic example, and write down which benefit fields your staff act on 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.