How does an AI phone agent work in a medical clinic?

Most explanations of this stop at "it uses AI to talk to patients", which tells a practice owner nothing about what will happen at 7:40am on a Monday when forty people dial at once.

This post is about the category rather than about my product. The four stages below are how every serious AI phone agent works, whoever built it. Where MedPhone does something specific I will say so, but the point is to give you enough to interrogate anyone you are evaluating.

How does an AI phone agent handle a call?

Four stages, in the same order every time. The interesting engineering is in what happens when a stage fails, which is the part vendors rarely demo.

1. Answer and understand. The agent picks up, greets the caller with the practice name, and classifies what is being asked into a supported call type
2. Identify the patient. Name and date of birth, queried against the EHR. This is the stage that breaks most often
3. Complete the request. Real availability read from the live schedule, offered to the caller, confirmed back
4. Write and close. The action is written into the EHR through the API, confirmed out loud, and logged

A booking that goes cleanly through all four takes somewhere between ninety seconds and three minutes, which is roughly what the same call takes a human receptionist who is not interrupted. Nobody is answering faster than that, and a vendor claiming a thirty second average is either counting only the trivial calls or counting the ones that ended in a transfer.

What happens during patient lookup?

This is the stage worth understanding properly, because it is where most of the failures live and it is the one that separates a shallow integration from a real one.

The agent needs to match a voice on a phone line to a specific record in a system holding tens of thousands of them. It normally asks for full name and date of birth, sometimes a phone number as a secondary check. Then it queries the EHR and gets back one of four outcomes.

The third row is the one to ask a vendor about directly. Two patients with the same name and a similar date of birth is not a hypothetical in a practice of any size. An agent that picks the more likely one has just booked the wrong person, and in a clinical setting that is a materially worse outcome than a transfer. The correct behavior is to stop.

How does the AI write to the EHR?

Through the EHR vendor API, if the integration is real. There are three levels of depth in this category and the marketing language for all three is identical, so this is worth checking rather than assuming.

• Read only. The agent can see the schedule but cannot change it. Every booking becomes a task for staff. This is the most common integration and the least useful, because the front desk work does not go away
• Write with a queue. The agent creates a request that lands in a worklist for someone to approve. Better, but a booking is not confirmed until a human touches it, so the patient may still get a callback
• Direct write. The appointment is created in the live schedule during the call and the caller hangs up with a confirmed time. This is what most practice owners assume they are buying

Integration depth also varies by action within a single EHR. A vendor may write appointments directly but only queue refill requests, which is a perfectly reasonable design and not something to hold against them. What matters is knowing which is which before you sign, because it changes how much front desk time you actually get back.

MedPhone is live in production on athenahealth as a verified Marketplace partner with direct scheduling writes. eClinicalWorks, ModMed, Dentrix and NextGen each have a partial integration covering core scheduling workflows, with further capability in active development. I list it that way rather than putting five logos in a row, because a logo row tells you nothing about depth.

What does a real call sound like?

Below is an illustrative booking call, written to match the shape and the timing of the ones I read every week rather than lifted from any patient record. Nothing here is a transcript of a real patient, for obvious reasons.

Fifty seconds, which is at the fast end because the caller knew what they wanted and the lookup returned cleanly. A new patient booking with insurance questions runs three to four times longer. What matters in that transcript is the last line: the change is already in the schedule when the caller hangs up, so nobody has to call them back.

What happens when the AI cannot complete a request?

It should transfer, and it should do it early rather than after four minutes of trying. The rules for when are set per practice and typically cover a handful of categories.

• Clinical questions of any kind. Symptoms, medication advice, whether something needs to be seen today. These go to a person immediately and no reputable vendor attempts them
• Urgency signals in the call, whether stated outright or detectable in how the caller is speaking
• Ambiguous patient identity, as above
• Anything outside the configured call types. Billing disputes, records requests, form completion, results
• A caller who asks for a person. This should always work, first time, without a fight

Outside opening hours there is nobody to transfer to, so the flow changes. The agent still handles what it can, and for the rest it takes a structured message and routes it into the morning queue with the patient identified and the request already categorized. That is materially better than a voicemail, which is where those calls went before.

How long does a typical call take?

Rough ranges from the call types I see most, for a single location primary care practice. Treat these as the shape rather than a guarantee, because your call mix is not mine.

The aggregate figure people quote for this is containment, meaning the share of calls resolved without reaching a person. At Synergy Medical, a family medicine practice in Michigan running athenahealth, MedPhone handles an estimated 65 to 75 percent of calls without them reaching staff, up from just over half at launch. The launch figure is the one worth internalizing, because every vendor quotes the steady state number and nobody starts there.

What this does not tell you

Two honest limits on everything above.

First, the timings come from primary care and family medicine call mixes. A dermatology practice with heavy cosmetic inquiries or an urgent care with walk in triage has a different distribution, and the containment figure will move with it.

Second, none of this covers the configuration work, which is where deployments actually succeed or fail. The technology is broadly the same across serious vendors. Whether your call flows, transfer rules and provider availability are set up correctly is what decides whether it works in your practice.

What deployment actually involves

Questions people ask

How does an AI phone agent work?

It answers the call, transcribes the caller as they speak, classifies the request into a supported call type, identifies the patient against the EHR, completes the task using live data from the practice system, and writes the result back through the EHR API before the caller hangs up. Anything outside its supported types is transferred to a person.

Does the AI actually book into our schedule, or does it just take a message?

That depends on the vendor and on the EHR. Three depths exist: read only, write to a queue for staff approval, and direct write into the live schedule. Ask which one applies to your EHR and to each call type, because a vendor can be direct write for bookings and queue only for refills.

What happens if the patient has a strong accent or a poor line?

Recognition degrades the same way it does for a person, and a well built agent asks for a repeat once, then transfers rather than looping. This is worth testing in a pilot with your own patient population rather than taking on trust, because accent coverage varies noticeably between vendors.

Can it handle two people calling at the same time?

Yes. Concurrency is the structural advantage over both a receptionist and an answering service. Forty simultaneous calls at 8am on a Monday are handled in parallel rather than queued.

What does it do when your EHR is down?

It should say so and take a message or transfer, rather than accepting a booking it cannot write. Ask a vendor to describe the failure path. Anyone who has not thought about it will not have a good answer.

How much of this is configuration versus the AI itself?

More than people expect. The models are broadly comparable across serious vendors. Call flows, transfer rules, provider level availability and the practice specific vocabulary are what decide whether it works, and that is set up during deployment rather than shipped in the box.