AI and patient contact: confidentiality comes first

For most businesses, AI in customer contact starts with the GDPR: do you have a legal basis, is it in your register, is there a processing agreement. In a healthcare practice that is not the first question. There is an older and stricter rule sitting on top of it: the duty of confidentiality. It does not say "explain why you are allowed to share this", it says "you share nothing, unless". That single difference decides whether an AI assistant may touch your email, WhatsApp or phone line at all, and if so, how far it may go.

Why does a practice start with confidentiality rather than the GDPR?

Article 88 of the Dutch Individual Healthcare Professions Act (Wet BIG) imposes a duty of confidentiality on every care provider in a regulated profession. That duty covers everything that becomes known to the professional in the exercise of their profession in the field of individual healthcare. The wording is deliberately broad. So it is not only about what ends up in the medical file.

For AI in customer contact, that is exactly the point. A patient who messages at eleven at night that they have had pain in an upper right molar since yesterday and asks whether they can be squeezed in tomorrow has told you something about their health. Whether someone later retypes that into the file changes nothing. It became known to you in the exercise of your profession, so it falls under the duty of confidentiality, even if the message sits in a chat window that nobody thinks of as a medical record.

In practical terms: the moment your duty of confidentiality kicks in is the moment the message arrives. Not the moment it lands in the practice management system. So an AI reading along in the inbox is reading material covered by confidentiality from the first second. There is no in-between zone in which a message is still "just customer contact" and only becomes medical later on.

And confidentiality is not a house rule. Deliberately breaching a secret you are obliged to keep by virtue of your profession is a criminal offence under Article 272 of the Dutch Criminal Code. On top of that there is professional disciplinary law for BIG-registered professions. So a privacy fine is not the only risk you are weighing when you let an outside party look in.

What happens legally when an AI reads along?

The moment you give an AI system access to patient messages, you are disclosing those messages to someone else. That holds even when the someone else is a server rather than a person. So the immediate question is whether you may, not whether it is convenient.

Article 457 of Book 7 of the Dutch Civil Code, the confidentiality provision of the medical treatment contract act (WGBO), says that the care provider must ensure that no information about the patient, and no inspection of or copy from the file, is provided to anyone other than the patient, except with the patient's consent. So here consent is the starting point, not the exception. That is the reverse of ordinary customer data, where consent is often the weakest choice you can make.

There is one exception that matters most in daily practice, and it is the one most often read too broadly. The same article states that "anyone other than the patient" does not include those directly involved in performing the treatment contract, or the person acting as the care provider's substitute, and then only insofar as the disclosure is necessary for their work.

That is a narrow door. Two things have to be true at once: directly involved in carrying out the treatment, and necessary. An assistant who runs the diary and books the patient in is normally inside that circle. An AI service that makes the whole inbox searchable because that is pleasant to work with is not automatically inside it. And a vendor that uses messages to improve its model is doing something that by definition is not necessary for the treatment of this particular patient. That is not a grey area; it falls outside the exception.

Ask the question per task, not per vendor

"May my AI tool see patient messages?" is too coarse a question. The question Article 457 actually puts to you is finer: may this system, for this task, see this specific message, and is that needed to help this patient? The answer can differ per task. Yes for offering an open time slot. No for summarising a description of symptoms so the clinician gets through the inbox faster, because there the convenience sits with you and the risk sits with the patient.

Why is a prohibition the starting point instead of a legal basis?

With ordinary customer data you look for a legal basis. With health data it works the other way around. Article 9(1) GDPR declares the processing of, among other things, data concerning health to be prohibited in principle. So you do not start at zero but below it: first identify an exception, and only then do you get to the questions the rest of this knowledge base covers.

For a practice or clinic, the relevant exception is the healthcare one. But it does not come standalone. Article 9(3) GDPR ties it to professional secrecy: the data may be processed for those purposes when they are processed by or under the responsibility of a professional subject to an obligation of secrecy. So the exemption hangs on the duty of confidentiality. Take the data outside that circle and you also take it outside the exception, and the prohibition in paragraph 1 simply applies again.

Dutch law turns that into something usable. Article 30 of the GDPR Implementation Act (UAVG) provides that the data may only be processed by persons who are bound to secrecy by virtue of office, profession or statutory rule, or under a contract. Those last words are the hinge for anyone working with software. A contractual duty of confidentiality counts. Your AI vendor has no BIG registration, but can be bound to secrecy by agreement. That is then not a tidy annex to the contract but the statutory condition under which the vendor may see anything at all.

Note what follows from that for the chain. The requirement applies to the persons processing the data, not just to the company on the invoice. If your vendor in turn buys a language model from a third party, confidentiality has to carry through there as well. So do not ask whether your vendor signs a confidentiality clause, ask who all gets to see the message and whether the obligation has been passed on watertight to each of them.

What is the difference between an appointment reminder and a clinical question?

This is the dividing line everything comes down to day to day. Not every message in a practice is a medical message. But the line sits lower than most business owners think, and it sits in two places at once.

The first line is the sender. The mere fact that someone is a patient at your practice is itself data concerning health. At a general practice that says little. At an oncology practice, a mental health provider, an addiction clinic or a fertility clinic it says almost everything. So a bare appointment reminder from such a practice is not a neutral message, however empty the text is. That is the first thing you weigh: what does the name of my practice already reveal, apart from what the message says?

The second line is content. The moment a complaint, a symptom, a medicine, a test result or a photo is in there, it is a clinical question. An AI that answers such a message freely does two things at once that you do not want. It processes special category data outside the circle of confidentiality, and it gives the patient the impression that their complaint has been looked at on the merits. In a care setting the second is the more dangerous, because it can stop someone from calling after all.

Types of message in a practice and what an AI assistant may do with them

Type of message	Does it contain health data?	What an AI may do with it
Question about opening hours, directions or parking, from a stranger	No, as long as no treatment relationship is apparent	Answer independently
Enquiry about open slots, with no reason given	Not yet; there is only interest	Show and record time slots, without asking about the complaint
Appointment confirmation or reminder to an existing patient	Yes; at a specialised practice the sender alone reveals something	Send, but without the treatment type in the text and with a discreet sender name
Request to reschedule or cancel	Only the fact of the appointment	Process in the diary; do not ask for or summarise the stated reason
Question about an invoice or reimbursement	Yes, the treatment code often says what was done	Hand over to a member of staff; do not read out from the records
Message containing a complaint or symptom	Yes, unambiguously	Acknowledge receipt and hand over; no substantive answer, no triage
Photo of a wound, rash, teeth or skin	Yes, and often biometrically identifiable too	Do not open or analyse automatically; pass to the clinician unread
Request for a test result or for access to the file	Yes	Route onward only; verifying identity is a job for a person
Request to send records to the general practitioner	Yes, and it is a disclosure to a third party	Only log that the request exists; the disclosure itself belongs to the care provider
Message that looks urgent	Yes	Refer straight to the agreed urgent-care channel, clearly marked as an automated reply

The thread running through that table is that an AI in a practice is good at arranging the circumstances of care, not at the care itself. Anything about time, place and availability a system can handle perfectly well. Anything about the complaint goes to a person.

How long do you actually have to keep an AI conversation?

Two retention periods get tangled here, and that is where it usually goes wrong. For the medical file, Article 454 of Book 7 of the Civil Code applies: the care provider keeps the file for twenty years, counted from the moment the last change was made to it, or longer if that reasonably follows from the standard of a good care provider. So twenty years, and the clock restarts with every change.

That period does not apply to ordinary customer data. A change of address, a parking question or a newsletter sign-up you keep for as long as the purpose requires, and no longer.

What makes AI in customer contact awkward is that it produces both, mixed together in the same thread. One WhatsApp conversation has a reschedule request at the top and a description of symptoms three messages down that belongs in the file. Treat that thread as one thing and you automatically choose wrong: either you keep parking questions for twenty years, or you delete records after one. Both are wrong, and the second is worse.

The workable answer is to separate on arrival. What belongs in the file goes to the file and follows the healthcare period. What does not stays in the channel with a short period you have written down yourself. That asks something of the setup: you have to be able to point out which message ended up where, and the AI system must not make that call quietly on its own.

While you are at it, look at the vendor's side too: conversation logs, phone call transcripts, intermediate storage and backups. A service that keeps everything for a few months by default and then wipes it does not fit a twenty-year retention duty. A service that keeps everything indefinitely does not fit the principle that you keep nothing longer than needed. So you need a vendor where the period is configurable per data type, and it is your job to configure it rather than leave the default in place.

What belongs in the contract that a webshop would not need?

Alongside the usual arrangements with a processor, healthcare adds a few points you genuinely need. They follow straight from the articles above, not from good intentions.

• Confidentiality by contract, passed on to every person and every subcontractor who can see the data. This is the requirement from Article 30 UAVG and it is not negotiable.
• No use for model training, evaluation or product improvement. That is not a disclosure necessary for the treatment, so the exception in Article 457 does not cover it.
• Configurable retention periods per data type, plus demonstrable deletion that also covers logs, transcripts and backups.
• An up-to-date list of sub-processors with the right to refuse a new one, because every new link is another person seeing the message.
• Workability of the retention duty: whatever belongs in the file you must be able to extract in a form that stays readable for twenty years, including when you switch vendors.
• What happens on termination or insolvency, because a twenty-year retention duty outlives most software contracts.

When do you have to assess this beforehand?

Article 35 GDPR names new technologies in so many words: where a type of processing, in particular one using new technologies, is likely to result in a high risk to people's rights and freedoms given its nature, scope, context and purposes, the controller must carry out an assessment beforehand. For a practice putting an AI on patient messages, two warning lights are on at once: new technology and special category data.

The word that counts is beforehand. This is homework before you switch on, not a report afterwards when something has gone wrong. For a small practice it need not be a weighty document, but it does have to write down which messages the system sees, who in the chain looks along, what goes wrong when it fails and why you still consider it responsible. That same document is later your answer when a patient or a regulator asks how you weighed this up.

How do you turn this into a workable setup?

If you take one thing away: in a healthcare practice you design AI around what it may see, not around what it can do. The order that follows from that is fairly simple.

1. First work out which tasks sit entirely outside the content of care. That is the area where an AI may work on its own.
2. Make sure messages with a complaint, photo or test result are recognised and go straight to a person, with an acknowledgement that makes clear nobody has looked at the substance yet.
3. Put a pointer to the urgent-care channel in every automated message. A patient who gets a reply waits, and waiting is exactly what you do not want in an emergency.
4. Fix confidentiality contractually down to the last link in the chain, and ask for that list in writing.
5. Separate file-worthy messages from ordinary customer contact at the moment they arrive, and set a retention period per type.
6. Write the assessment down beforehand, including what you deliberately do not automate. In healthcare that last part is policy just as much as what you do automate.

The result is usually more modest than the demo you started from, and that is exactly right. A practice where the diary runs itself and where every complaint reaches a person within office hours is both legally defensible and pleasant for the patient. A system that answers medical questions on its own is neither.