AI phone assistant in a medical practice: booking appointments without giving advice

Monday, just after eight. At reception, a patient is picking up a prescription and has a question about a referral. Two more are waiting behind her. Meanwhile, the phone rings for the third time. The employee decides, as she does every morning, in favor of the people standing in front of her. The call goes on hold.

In this scenario, this picture is an assumption, but a familiar one. A mid-sized practice has several tasks at once during consultation hours: reception, phone, prescriptions, billing, organizing the treatment rooms. The phone competes with everything else, and it loses whenever things are busy. But that is exactly when most people call.

Anyone who gives up on hold calls again later or tries another practice. The team does not notice, because a call that is not answered leaves no trace. All that becomes visible is the growing tension: callbacks at midday, duplicate appointment requests, annoyed patients who come to the desk and ask whether anyone is answering the phone.

The question of this study is therefore narrowly framed. It is not whether an AI should replace reception, but whether it can take over a clearly defined part of the phone, namely appointment booking, without creating new risks. Everything beyond that stays with people.

For a trade business, the worst-case scenario is a lost job. In a practice, it is a person who needs help and does not get it. This asymmetry determines every decision. An assistant that talks to patients on the phone operates in an environment where mistakes can cost more than time or revenue.

Then there is data protection. Under the GDPR, health data belongs to the special categories of personal data and requires heightened care. Even the sentence “I’ve had chest pain for days” is health data, even if it is mentioned only in passing while asking for an appointment. A system must expect that callers will volunteer more than is necessary for booking an appointment.

The third difficulty lies in the boundary between organization and assessment. Someone who says they need an appointment “as soon as possible” is expressing a wish. Someone who says they have felt dizzy since the morning may be describing a symptom. An assistant must not confuse the two, and it must not respond to the second with an assessment, not even a cautious one. Medical evaluation belongs in the hands of practice staff.

The fourth difficulty is human. Patients are often older, nervous, ill or in a hurry. They speak indistinctly, interrupt, need things repeated. A system that works in everyday office use can already fail here at the level of conversation handling. The requirements are therefore higher than for almost any other phone application, and the concept has to start from them.

A helpful mental model is the separation between the wish, the concern and the complaint. The wish relates to organization: when, with whom, how long. The concern is the type of appointment, such as a check-up, vaccination or preventive care. The complaint is the medical matter behind it. The assistant needs the wish and the concern. It does not need the complaint, and it should not ask for it.

This leads to an approach that could be called data minimization through conversation design. The assistant does not ask “What’s wrong?” but “What kind of appointment is it?” It offers a short choice instead of asking open free-text questions. The less room the conversation leaves for descriptions of symptoms, the less sensitive data enters processing at all.

Even so, not every caller will follow the guidance. Some will tell their story. For this case, a rule is needed that is set in advance: the assistant does not take in such accounts as to their content, does not comment on them and does not store them in the appointment record. It recognizes signs of something acute, refers the caller to the emergency number in case of danger and hands over to the team when the call demands more than organization.

The weighting of the requirements is unevenly distributed. Defining the tasks and recognizing emergencies carry the construction; conversation quality and appointment logic come after. This is unfamiliar, because phone assistants are usually judged by their voice. In a practice, suitability is decided by what the system refrains from doing.

The obvious alternative would be an assistant with broad knowledge that answers questions, classifies complaints and then suggests an appointment. It would feel impressive in conversation. It would also be the bigger risk, because every additional capability is an additional source of error, which is not acceptable in a practice. A sentence that sounds like a diagnosis can do harm, even if it was well meant.

We would therefore deliberately build a slim assistant whose capabilities are limited to a few tasks: arranging, rescheduling or canceling an appointment, taking a callback request, and giving opening hours and directions. Everything else leads to handover. The advantage of the restriction lies in testability. Each of these tasks can be tested completely, because there are only a few of them.

The second alternative is a classic voice menu: “Press 1 for appointments.” It is robust and needs no AI. But it fails in everyday use because people hate it and hang up early, especially older ones. A third variant, the purely online appointment calendar, solves the problem for the digitally savvy and leaves everyone else behind on the phone, which is exactly the group that needs the phone.

Our assessment therefore comes out like this: a conversational assistant with a strictly limited remit, which understands natural language but does only a few things. Naturalness serves usability; the restriction serves safety. Where the two conflict, the restriction wins, even if the conversation occasionally comes across as a little stiffer as a result.

The conversation begins with a disclosure. In the first few seconds, the voice says that it is a digital assistant of the practice, what it can do and that the caller may ask for a team member at any time. This is good style and corresponds to the widespread principle that people should be able to tell when they are speaking to a machine. Which obligations apply in a particular case is something the practice clarifies with its legal adviser.

Immediately afterwards comes the emergency notice, short and without drama: in case of acute danger, please call the emergency number at once. It belongs at the start and not at the end, because someone in distress will not listen as far as the appointment question. In addition, the assistant monitors the whole conversation for cues, such as terms that point to acute shortness of breath, severe pain or loss of consciousness. It does not evaluate them but refers and hands over.

The dialogue is designed to ask for little information. The assistant first clarifies whether the caller is already a patient of the practice, then the type of appointment, and then the time window and the preferred doctor. It briefly confirms each detail and summarizes at the end. Questions about symptoms, diagnoses or medications do not appear in the flow, and the assistant is instructed not to ask them even when prompted.

There is an exit at every point. Anyone who sounds unsure, is not understood three times or volunteers a concern that sounds like more than organization is handed over to the team, ideally with a short summary so that no one has to repeat themselves. The exit is not an admission of failure but a component of the design.

Technically, the assistant consists of four parts: the telephony connection, speech recognition and speech output, a dialogue control with a fixed set of rules, and the connection to the practice’s appointment calendar. The dialogue control is the heart. It does not let the language model answer freely but guides it along defined steps and checks every output against permitted content before it is spoken.

The calendar logic is less trivial than it seems. A practice has different appointment types with different durations, different practitioners and sometimes their own time windows. A vaccination clinic runs differently from a check-up, and a first consultation takes longer than a follow-up. The assistant therefore offers only slots that are explicitly released for the chosen appointment type, and observes buffer times and blocked windows.

Matching the person is particularly delicate. There is no ID on the phone. A name alone is not enough, because names are not unique and are easy to find out. At the same time, the assistant must not reveal anything a third party could misuse: neither that someone is a patient nor when their next appointment is. It asks using a few characteristics and does not confirm matches prematurely.

Data minimization cannot be pinned to a single document; it has to be built into the architecture. That starts with the question of what is stored at all. For an appointment record, a name, callback number, appointment type and time window are enough. Audio recordings and full transcripts are not needed for this. Where they are needed for quality assurance, a defined purpose, short retention periods and a clear deletion routine are required.

The path of the data is just as important. Speech processing often runs with external providers. A practice should know where the processing takes place, which service providers are involved, whether a data processing agreement is in place and whether conversation data may be used to train models. The latter should be excluded by contract. The legal assessment belongs in the hands of data protection officers or specialist lawyers; this study is not legal advice.

Technically, much can be secured. The conversation log can leave out sensitive passages, in that the assistant passes on only structured fields and no free text. Access to the calendar and logs is assigned by role and recorded. Data is transmitted and stored encrypted. And the system has no knowledge of patients that it does not need for the specific task, which is why no medical history is connected.

The most important special case is the emergency that arrives disguised as an appointment request. “I’d need an appointment today, I’ve felt strange in my chest for an hour.” A fixed rule applies here: as soon as signs of acute danger appear, the appointment process is aborted, the emergency number is given and, if the phone system allows it, the call is handed to the team at once. The rule applies regardless of how the call went up to that point.

The second case is the caller who wants advice. “Should I stop taking the medication?” The assistant does not answer on the substance, but does not just curtly say no either. It explains that it cannot provide information on this, offers a callback from the practice team and takes down the phone number. The tone is calm and matter-of-fact, so that no one gets the feeling of being brushed off.

Third: people who are hard to understand. Dialect, hearing impairment, background noise, a child’s voice in the background. Speech recognition becomes more error-prone here. The concept provides that after repeated failure to understand, it does not keep guessing. A misunderstood name produces, at best, a callback and, at worst, an appointment for the wrong person. Better to hand over once too early than once too late.

The fourth case is the request for appointments for third parties, such as for parents or relatives in need of care. Here the patient’s identity becomes blurred. The rule is to set up the process as a request and leave the confirmation to the team. Calls outside consultation hours are also a special case: the assistant takes down requests, says honestly when a reply can be expected and, for urgent matters, refers to the on-call medical service and the emergency number.

Reliable figures from a real practice do not exist for this scenario, and we do not invent any. It is plausible that two things change: fewer calls go unanswered, and the team spends less time on pure appointment organization on the phone. How much depends on practice size, call patterns and the share of simple appointment requests, and that can only be determined in operation.

Measurement can be done in stages. First availability: the share of calls answered, average waiting time, number of drop-offs, each from the phone system’s data. Then the quality of the processes: how many appointments were accepted without correction, how many handovers made sense, how many were there too many or too few? Finally the effect on the team: callbacks per day, time on the phone, feedback from staff.

Particularly revealing is a sample of the conversations, insofar as they are documented in a legally and organizationally permissible way, or an analysis of the log fields. This shows whether the assistant keeps to its limits: are there cases in which it advised or reassured? Are there emergency notices that came too late? Every deviation is a finding for the rule set, not an isolated case.

What cannot be promised is a particular time saving, a cost reduction or higher patient satisfaction. Patient acceptance is also open, because some will reject the assistant and prefer to speak to a team member. The concept ensures that they can do so at any time. A pilot with a clear evaluation after a few weeks provides more clarity than any forecast.

Three insights carry beyond the practice. First: the boundary of the task is the most important design element, not the voice. Second: data minimization comes from the conversation design, because what is not asked does not have to be protected. Third: handover to people is part of the product and should be designed, measured and improved from the start.

A step-by-step approach is recommended for getting started. In the first phase, the assistant answers calls only outside consultation hours and logs callback requests. The risk is low and the benefit quickly visible. In the second phase, it takes overflow during consultation hours, that is, calls that would otherwise end up on hold. In the third phase, actual appointment booking is added, initially for just a few appointment types.

Before each phase, the team tests the conversation scripts, the emergency behavior and the handovers in a trial run with staged calls, including difficult ones: dialects, interruptions, deliberately vague requests. It pays to involve staff early. They know their patients’ quirks better than any concept study and quickly notice when a sentence sounds wrong.

A maintenance process is part of the long-term setup: the rule set is reviewed regularly, new appointment types are released deliberately, and anything unusual from handovers feeds back in. An assistant that is no longer looked after after launch drifts, because practice routines change. And the practice keeps the option to switch the assistant off at any time without the phone system collapsing.

An AI phone assistant can make sense in a practice if it does little and does it reliably. Booking and rescheduling appointments and taking callback requests are a suitable field because they can be described clearly. Advice, assessments and information about individuals are not. Whether the concept works in your practice depends less on the technology than on the willingness to hold these limits consistently.

The next step is unspectacular. For one week, write down when the phone went unanswered and what the call was about: appointment, prescription, test result, information. This shows what share is suitable for an assistant at all and what should stay with people. On that basis, a pilot phase can be planned without promising anything that cannot be kept.

We are happy to discuss this with you, including the points that concern your data protection officer or your legal advisor. We will tell you openly where an assistant does not make sense. That, too, is part of an honest assessment, and sometimes the best solution is better organization of the front desk instead of new technology.