AI Chatbots for Medical Clinics: Scheduling, Screening, and What to Keep Off the Bot

I build and run voice and chat agents for medical clinics, most of my hours in podiatry and advanced wound care. That specialty matters, because a wound care practice has a call mix that looks nothing like a pediatrician's: a lot of recurring weekly visits, a lot of referral coordination, a lot of insurance verification, and patients who genuinely cannot drive themselves. What I say below is shaped by that, but the structure holds across most outpatient specialties.

The blunt version first. A clinic's phone problem is almost never "we need smarter conversations." It is that three staff members are sharing one front desk, the phone rings while someone is checking in a patient, and roughly a third of calls go unanswered between 11am and 2pm. An agent that only picks up the overflow and books appointments correctly already pays for itself. Everything past that is bonus, and some of it you should deliberately not build.

What calls and chats a clinic actually gets

Across the clinics I work with, the split lands roughly like this:

• Scheduling. New patient appointments, reschedules, cancellations, "when is my next visit." This is the largest single bucket and the most automatable.
• Prescription and refill requests. High volume, and almost entirely a message-taking job, not a decision job.
• Results and records. "Did my labs come back." "I need my records sent to another doctor."
• Insurance and billing. Do you take my plan, what will this cost me, I got a bill I do not understand.
• Referrals. Another office's staff calling to send a patient over, often with a fax or portal document in hand.
• Clinical questions. "My foot is red and swollen, should I come in." These are the calls that decide whether your agent is safe.
• Directions, hours, parking, which suite. Trivially automatable and a surprising share of volume.

Web chat is skewed heavily toward the last two categories plus new patient scheduling. People who are already patients call. People deciding whether to become patients chat.

What the bot should handle versus hand off

Here is where I draw the line, and I draw it conservatively on purpose.

The bot handles

• Hours, location, parking, which entrance, what to bring, whether you need a driver.
• New patient scheduling into a defined set of appointment types, with the intake fields the front desk actually needs.
• Reschedules and cancellations for an identified patient.
• "Do you take my insurance," answered from a maintained plan list, with a clear disclaimer that eligibility is verified before the visit.
• Taking a refill request as a structured message: patient name, date of birth, medication, pharmacy, callback number. Taking, not deciding.
• Routing referral calls from other offices to the right coordinator, with the referring practice and patient name captured.
• After-hours triage that ends in either "call 911," "go to the emergency room," or "we will call you first thing."

A human handles

• Every clinical question. Every single one. The agent does not assess symptoms, does not say whether something sounds serious, does not suggest home care.
• Results. The agent never reads a lab value, an imaging result, or a pathology report out loud.
• Anything about cost of a specific treatment for a specific patient.
• Anything where the caller is distressed, or where the agent has already missed once.

The clinical line is not negotiable and it is not enforced by hoping. It is enforced with an explicit refusal list in the prompt. I learned to write these lists the hard way in another industry, when a receptionist agent hallucinated the ability to block a caller's phone number and told people confidently that it had done so. Models will invent capabilities when the prompt describes only what they can do. So I write the opposite: a block titled "abilities you do NOT have," enumerating the specific things patients ask for that the agent must decline and route. In a clinic that block covers medical advice, results, dosage, prior authorization outcomes, and anything resembling triage beyond the emergency script. See stopping chatbot hallucinations for how I structure it.

There is also an emergency script that runs before anything else. If the caller mentions chest pain, difficulty breathing, uncontrolled bleeding, signs of a serious infection, or says anything about self-harm, the agent stops the flow, says to hang up and call 911, and does not attempt to book them.

HIPAA and PHI: the caution that actually matters

I am not a lawyer and this is not legal advice. What I can tell you is how I build, and the guiding principle is that the agent should touch as little protected health information as possible and store almost none of it casually.

Practical rules I hold to:

• Do not let the agent store PHI in places nobody audited. Transcripts, analytics dashboards, logging services, and Slack notifications are all storage. A transcript with a patient name, a date of birth, and a stated condition is PHI sitting in a third-party log. Decide deliberately where it lives.
• Minimize what you capture. The agent needs enough to book and identify. It does not need a symptom narrative. If a caller volunteers detail, the agent should not repeat it into a summary field it did not need.
• Prefer identifiers over descriptions. Writing a patient ID and an appointment type into the practice management system is very different from writing "caller reports draining ulcer on left heel" into a CRM note.
• Do not send PHI to anything without a signed BAA. That covers the model provider, the telephony provider, the transcription layer, the automation platform in the middle, and wherever transcripts land. Every hop. If a vendor will not sign, that vendor does not see patient data, full stop.
• Turn off model training and set retention deliberately. Ask vendors for the retention control, do not assume the default is short.
• Be careful with SMS. Appointment reminders by text are common, but the content should be minimal and the patient needs to have opted in. Consent is not a formality, it is the whole ballgame. I treat it as a hard gate that code cannot bypass, the same way I built an SMS assistant for another industry where the bot is structurally incapable of texting a number that has not opted in. See TCPA compliance for AI SMS.
• Say what it is. The agent should identify itself as an automated assistant early. Patients are fine with it. Being tricked is what upsets people.

The safest architecture I have found is one where the agent authenticates lightly, writes to the practice management system directly, and keeps its own memory thin. The system of record should be the system of record.

A realistic scheduling call flow

Greeting and disclosure. "Thanks for calling, this is the clinic's automated assistant. I can book, move, or cancel an appointment, or get you to the front desk."

Emergency screen. Passive, running against everything the caller says, with an immediate hard exit.

Intent. New patient, existing patient, refill, records, billing, or something else. Anything outside the first three routes to a person or a message.

Identify. For existing patients, name and date of birth, matched against the schedule. For new patients, collect name, callback number, reason for visit at the category level (not the clinical level), insurance carrier, and referring provider if there is one.

Offer times. Real availability pulled from the scheduling system, filtered by appointment type and provider. Two options at a time, never a wall of slots. If the patient needs a specific provider or a specific location, that constrains the query before it runs, not after.

Confirm and write. Read back date, time, provider, and location. Write the appointment. Trigger the confirmation the clinic normally sends.

Close. Offer the "anything else," then end cleanly.

The mechanics of the availability query and the write-back are the part people underestimate. I go into it in chatbot appointment booking.

Integration points

System	Role
Practice management / EHR scheduling	Availability, appointment types, provider rules, the write-back
Phone system	Forwarding the main line or the overflow path to the agent's number
Front desk queue	Warm transfer target during business hours
Secure messaging or task queue	Where refill and records requests land as tasks, not as free text in a chat log
Website chat widget	New patient intake and insurance questions

Some EHRs have a usable scheduling API and some have a portal and a prayer. Where there is no API, the practical fallback is that the agent collects a complete, structured request and drops it in a queue for staff to enter, which still removes the phone tag even though it does not remove the typing. Do not pretend otherwise in a sales conversation.

On the phone side, most clinics do not need to change carriers. You forward the main number, or better, you forward only the calls that roll over after a set number of rings. That gives you a safety net deployment: the humans still pick up first, the agent catches the overflow, and nobody's experience gets worse on day one. If the clinic's carrier phone system has an auto-receptionist in the path, check that it is not swallowing the call before forwarding applies, which is a specific trap I have hit on a business carrier setup. Phone forwarding for AI agents has the details.

Cost expectations

As of mid-2026, described as models rather than firm quotes:

• Voice usage is per minute, in the cents-per-minute range all in. A three-minute booking call is trivial against the value of a booked visit.
• Chat is typically per message or per conversation, cheaper than voice by a wide margin.
• Build. A booking-capable clinic agent with a real EHR integration is a project measured in weeks, not an afternoon. Agency setup fees for this class of work run in the hundreds to low thousands depending on the integration surface. Monthly management for small practices commonly sits between about $99 and a few hundred.
• The number that actually matters is captured appointments. A clinic that misses even a handful of new patient calls a week is losing more than the agent costs, and that arithmetic is usually the entire business case.

Testing, because clinics are unforgiving

Two habits I will not skip. First, simulator testing cannot inject system variables like caller ID, so an agent that behaves perfectly in a test console can still fail on a real call. Always place real test calls from a real phone before rollout. Second, verify the wiring rather than the logic. Replay real historical scenarios through the deployed system and confirm the appointment actually landed in the schedule. I have seen green tests hide a broken hand-off that cost a client eleven leads. In a clinic, eleven leads is eleven patients.

FAQ

Can an AI agent be HIPAA compliant? The agent is not compliant or non-compliant on its own. The architecture is. That means BAAs with every vendor that touches patient data, deliberate retention settings, minimal capture, and no PHI leaking into unaudited logs or notifications. Have your compliance person review the data flow before go-live, not after.

Should the bot answer clinical questions if the answer is obviously simple? No. There is no clean boundary between simple and not, and a model cannot see the patient. The agent's only clinical behavior should be the emergency script and routing to a nurse or provider.

Will patients hate it? Older patients do better with it than people expect, as long as it is fast, it identifies itself, and it gets them to a human when they ask. What patients hate is a bot that pretends to be a person or refuses to transfer.

Front line or overflow? Start on overflow and after hours. You get real volume with near-zero risk, and you learn how your actual patients phrase things before you put the agent in front of everyone.

What about no-shows? Outbound reminder calls and texts are a genuinely good use, but only for patients who have consented, with minimal content in the message. Reminders are also where you can offer a one-touch reschedule, which is usually worth more than the reminder itself.