AI agents for healthcare
Three channels, one boundary. What AI agents for healthcare actually handle, where they must hand a patient to a person, and how to evaluate one.
Most AI agents for healthcare are sold on what they can answer. Vendors demonstrate a booking, a refill, an eligibility check, and the agent sounds convincingly human throughout.
The harder question, and the one that decides whether a clinic keeps the thing running past month three, is where the agent stops.
What an AI agent for healthcare actually is
An AI agent is software that holds a conversation, decides what the person needs, and completes the task inside your existing systems. It differs from a chatbot in the last part. A chatbot answers. An agent books the appointment, writes it to the practice management system, sends the confirmation, and records the outcome.
In healthcare that work divides cleanly in two.
Administrative work is scheduling, rescheduling, cancellations, referral capture, preparation instructions, billing enquiries, reminders, follow-up on people who did not arrive. It is high volume, rule bound, and it is what consumes a front desk.
Clinical work is deciding whether a symptom needs imaging, whether a contrast agent is safe for a given patient, what a result means. It requires a registered professional and a duty of care.
Almost every failure of a healthcare AI deployment traces back to a system that blurred those two, usually because blurring them made the demonstration better.
The three channels patients actually arrive on
A patient reaches a practice in one of three ways, and each one needs a different agent rather than one agent wearing three costumes.
| Channel | What it handles | Why it exists |
|---|---|---|
| Voice | Inbound calls, any volume, around the clock | Most patients still ring, and a queue is where bookings are lost |
| Chat | Enquiries on your website, any device | Patients who will not phone, and after-hours traffic |
| Forms | Referral and intake capture | Structured data the other two cannot collect reliably |
The three are not interchangeable. A patient holding a referral at 8:05 on a Monday wants the phone answered. A patient comparing two clinics at 10pm wants a chat window. A referrer sending a scan request wants a form that reads the referral rather than a conversation.
What matters is that all three write to the same place. Agents that each keep their own record produce competing versions of the truth, and reception ends up reconciling them by hand, which is the job the agents were bought to remove.
Where the agent stops
This is the section most vendor pages leave out, and it is the one a practice manager should read first.
An agent handling patient contact needs three properties, and a system missing any of them should not go live.
It names itself. The opening sentence says it is an AI assistant, before any question is asked. Not in a footer, not on request. A patient who realises three minutes in that they have been talking to software feels deceived, and they are right.
It offers a person at every point. Transfer stays available for the whole interaction, not buried behind a menu. When the agent hands over, the transcript travels with the patient so nobody repeats themselves.
It refuses clinical questions and routes them. Asked whether a contrast dye is safe with a kidney condition, the correct behaviour is to say plainly that it cannot advise on that and connect the patient to the clinic. Not a hedge, not a general reassurance, not a link to a fact sheet.
That last one is worth being concrete about, because it is where the temptation lives. An agent that says something helpful about a clinical question demonstrates better than one that declines. It also creates liability for the practice, and it is the behaviour that gets a deployment switched off.
Preparation instructions sit on the line and are worth naming separately. Reading back the fasting requirement for a booked CT is administrative: it is the instruction the practice already issues for that modality. Deciding whether a patient’s medication should be held is clinical. The first belongs to the agent. The second does not.
Administrative, not clinical
There is a commercial reason to draw the boundary hard, beyond the obvious safety one.
Administrative work is where the measurable money is. A practice does not lose revenue because its clinicians are slow. It loses revenue because the phone rang out at the busiest hour of the week and the patient rang somewhere else, and nothing in the system records that the booking was ever available.
Staying administrative also keeps a deployment outside the regulatory perimeter that clinical decision support sits inside. A system that books scans and one that suggests them are different products with different obligations, and conflating them raises the cost of every conversation with a compliance team.
Connected, not replacing
Healthcare software is not a field where the newest system wins by replacing the incumbent. The RIS, the EHR and the practice management system hold the schedule, the rules and the record, and they are not going anywhere.
An agent has to work as a layer on top: reading real availability, applying the site’s own rules, and landing the booking where the practice has decided bookings live. That is one of three modes. Where the system of record exposes a supported write path and it is enabled, the agent writes the confirmed booking back. Where the practice runs the agent’s own booking system, the booking is confirmed there, and synchronising it with the RIS is a separate, explicit piece of work rather than something to assume. Where neither confirmed-booking path is in use, the agent hands staff a booking request to complete, and it should be labelled as exactly that: a task, not a booking. What must never happen is a booking that exists in the agent, is presented to the patient as confirmed, and is invisible to the system reception is looking at. That is worse than no booking.
That layer is also where the practice’s own logic lives. Which modalities run at which sites, which appointments need a referral before they can be confirmed, when a request should go to a person instead. Radiology makes this obvious because the rules are unusually strict, which is why we started there rather than somewhere easier.
How to evaluate one
Six questions, in the order that saves the most time.
| Question | What a weak answer sounds like |
|---|---|
| Does it write to my PMS, RIS or EHR? | ”We integrate via export” or “we email your team” |
| What happens when it cannot help? | Anything other than an immediate route to a person |
| Does it say it is an AI to every patient? | ”It can if you configure it that way” |
| Where does patient data live? | A region that is not the one you practise in |
| What does it refuse to do? | Nothing, or a list the vendor has to think about |
| What can I measure on day 30? | Interactions handled, with no outcome attached |
The last one deserves emphasis. A dashboard reporting calls answered tells you the system ran. The numbers that decide renewal are bookings made, transfers required, and appointments recovered after a no-show, reported per site so a group can see which centres are leaking capacity.
On data location, the answer should be infrastructure rather than intent. Where a platform hosts patient data is a property of how it is built, not a policy it can adopt later.
What to measure
Pick the numbers before the pilot, not after.
Answer rate. What share of inbound contact gets a response at all, including the calls that currently reach an engaged tone. This is usually the number nobody has.
Resolution without a person. Of the contacts the agent handled, how many finished without a transfer. Falling is not automatically bad: a rise in transfers on urgent cases is the system working.
Bookings created. Not intent detected. Appointments in the schedule.
Recovery. No-shows rebooked, and vacated slots refilled from a waitlist. A missed appointment costs twice, and only counting the rebooking measures half of it.
Escalation quality. How often a transfer arrives with the context attached. This is the number patients feel most directly, and the one most vendors do not report.
Start with the calls you are already missing
Ring your own practice at 8:05 on a Monday morning, from a mobile, and time it. Then count how many of the last hundred referrals became booked appointments, and how long the gap was.
Those two numbers describe the problem an agent is meant to solve. If a vendor cannot tell you which of them will move, and by when, the demonstration is not the thing being sold.
The agents are the easy part. The boundary is the product
Any vendor can show you a booking. What decides whether it survives contact with your practice is what happens on the calls it cannot finish, and whether the booking lands in the system your reception is actually looking at. Talk to us about improving your web presence and the experience a patient meets when they choose you.