AI in patient service: a clinic chatbot that does no harm, and when it makes sense at all

I sometimes ask clinic owners what the chat they want on their website is supposed to do. The most common answer is "answer patients". When I ask which questions, it gets more interesting. Opening hours and prices make the list, but so do "is this pain something serious" and "which medicine should I take before the procedure". That is where the whole boundary of this piece runs.

A chat on a clinic website can take a good deal of repetitive work off the front desk and book a patient in the evening, when nobody is picking up the phone. It can also do harm: to the patient who got a made-up answer, and to the clinic that does not know where conversations about its patients' health end up. This piece is about telling one from the other before you buy anything.

One caveat up front. This is about chat on the website. The phone is a separate channel with separate problems, and I covered it in the piece on voice assistants in a clinic. Where it is worth comparing the two channels, I point you there.

A good clinic chat does three things: it books, it informs and it redirects. Each of them is concrete.

It books, moves and cancels appointments. A patient writes that they want to see a dermatologist next week, the chat shows free slots and writes the appointment into the calendar where the front desk will see it. Same for rescheduling and cancelling. There is one condition and no way around it: the chat needs access to the real calendar. Without that, it is a contact form in disguise, and someone at the desk will retype the request by hand anyway. It is the same choice I described when writing about booking portals versus your own system: a calendar you do not control limits everything you can build on top of it.

It answers the questions the front desk hears dozens of times a day. How much a consultation costs, whether you are open on Saturdays, where to park, whether an abdominal ultrasound requires fasting, what to bring to the first visit. These are questions about facts the clinic knows and can write down. A chat that answers them saves the front desk calls about the obvious and saves the patient time on hold.

It passes things on when they are beyond it. A question about a test result, a complaint, something that is not in the knowledge base. The chat does not try to handle it alone. It hands the conversation to a person or gives a clear path: a phone number, hours, a form someone will read the same day.

Chat has one advantage over the phone: it works exactly where the patient already is. Someone reading about implants on your website at ten at night will not call. They can, however, ask a question and book a consultation on the spot.

We see five ways in which a chat on a clinic website does more harm than good. Each is predictable, and each can be prevented at the design stage.

It answers medical questions. "Is this chest pain something serious?" A chat built on a language model will answer that willingly and fluently, because that is how it works. It should not. An assistant on a clinic website does not assess health and does not decide urgency. When a patient describes symptoms, the chat says plainly that this is not its job and shows the way: book an appointment, call the front desk, and for symptoms that may be life-threatening, the emergency number 112, which works across the EU. That refusal has to be designed and tested, not left to the model's good will.

It makes things up. A language model that does not know the answer can invent one in a tone of complete confidence. In an online shop that is a nuisance. In a clinic, the patient turns up for a test unprepared or with the wrong price in mind. That is why the chat answers only from a knowledge base the clinic has approved: prices, preparation notes for tests, hours, directions. If something is not there, it says "I don't know, I'll pass your question on", and that is a correct answer, not a failure.

It collects health data it does not need. A chat that opens with "how can we help?" will receive descriptions of symptoms, treatment history and sometimes a photo. Every one of those sentences is special category data. More on what follows from that below.

It blocks the way to a human. The patient writes "I want to talk to reception" for the third time, and for the third time the chat offers an article from the knowledge base. That is the fastest route to a bad Google review. Getting to a person should be possible at any moment, with one sentence or one button, including out of hours. Then the honest answer is: "reception will reply tomorrow from eight".

It pretends to be human. A chat called "Kate" with a photo of a smiling receptionist that never says it is a program. Patients notice anyway, and the ones who notice feel deceived. Since August 2026 this is no longer only a matter of trust but also of law.

The simplest test of whether a chat is well designed is one question: does it ever tell the patient anything about their health? If it does, the line has been crossed.

On one side are organisational matters: appointment, price, hours, address, test preparation as written by the clinic, documents to bring. On the other is everything that requires judgement: whether a symptom is urgent, which specialist to see, whether a medicine can be stopped, what a result means.

The chat can ask "what would you like to book?", because without that it cannot put the appointment in the right clinic. It should not probe for symptoms in order to do something with them. I wrote the same sentence about voice assistants and the regulations, because the line is the same whatever the channel.

The EU regulation on artificial intelligence, Regulation (EU) 2024/1689, known as the AI Act, requires in Article 50(1) that AI systems intended to interact directly with people are designed so that the person knows they are dealing with an AI system. The exception is where this is obvious to a reasonably well-informed person. Article 50(5) adds that the information has to be clear and distinguishable, at the latest at the first interaction.

This provision applies from 2 August 2026, so it applies now.

Formally the obligation sits with the provider of the system, usually the company you buy the chat from. In practice, it is on your website that the patient either sees this information or does not, so it is worth checking before you sign. The first line in the chat window is enough: "I'm the clinic's AI assistant. I can help you book an appointment and answer questions about hours and prices. You can ask to speak to reception at any time." Giving the assistant a name is fine. Pretending to be a person is not.

The GDPR defines data concerning health broadly: personal data related to a person's physical or mental health, including the provision of health care services, which reveal information about their health status (Article 4(15)). So a patient only has to write "I'd like to book a psychiatrist" for the conversation to contain special category data under Article 9. I covered this in more detail in the piece on what the GDPR requires from a clinic website.

Processing such data is prohibited as a rule and allowed only under one of the exceptions in Article 9(2). Clinics usually rely on the ground related to the provision of health care (Article 9(2)(h)), which applies on condition of professional secrecy under Article 9(3). We are not a law firm, and the specific basis for your chat is for your data protection officer to settle. From the system's point of view, though, three practical decisions follow.

Collect only what the chat needs. To book an appointment, a name, a phone number and the type of visit are enough. The chat should not invite people to describe symptoms, and if a patient does, it should not keep them longer than necessary.

Check where the conversation goes. Chat content usually passes through several companies: the widget provider, the language model provider and sometimes a conversation analytics tool. Each of them processes your patients' data, so each must be covered by a data processing agreement and listed in your record of processing activities. The questions for the vendor are concrete: where the conversations are physically stored, for how long, who in the admin panel can read them, whether they leave the European Economic Area, and whether they are used to train the model. A "no" to that last one belongs in the contract, not in an email from a salesperson.

Set retention as a number, not a statement. "We delete after thirty days" is an answer only if someone can show where that thirty is configured.

A good starting point, for clinics in Poland in particular, is the set of checklists published in August 2026 by UODO, the Polish data protection authority, for organisations deploying AI tools, including a separate version for small and medium businesses using ready-made systems. UODO notes there that the compliance question usually comes up only once the tool is already running. It is worth asking it earlier. Clinics elsewhere in the EU should look for the equivalent guidance from their own supervisory authority.

This is the part people think about least, and one of the first things a patient notices. A chat widget is an interactive element and is subject to the same accessibility requirements as the rest of the site. Under WCAG, in practice, that means a few things.

A chat that opens by itself after three seconds and covers half the page hurts every patient, not only those using assistive technology.

To be honest: not every clinic needs a chat, and not every clinic should have one right now.

Before you talk to any vendor, spend a week noting what patients ask the front desk by phone and email. Tally marks per category are enough: booking, rescheduling, price, hours, test preparation, directions, medical matters, everything else. If most of it is booking and facts about the clinic, a chat has something to live on. If most of it is medical, the chat will not take it over and should not.

Then check three things: whether the calendar has an interface through which appointments can be booked, whether your site has current prices and preparation notes, and who will own the conversations.

Chat is one part of the layer between the patient and the practice management system. Online booking, text reminders and reviews are described on our page for healthcare providers. Booking, reminders and the AI receptionist for clinics, with pricing, are on medova.health.

If you are wondering whether chat makes sense for your clinic, or you already have one that answers questions it should not, write to me and we will suggest where to start. I lead the conversation about scope myself, and if it comes to implementation, it is done by the team the clinic works with directly. Sometimes the honest advice is: sort out the prices on your website first, and add chat in six months.