What AI should never say to patients

Why a "never say" list matters

Front desk staff learn boundaries over months: don't discuss results over the phone, don't tell a caller what their copay will be until coverage is checked, don't confirm to a stranger that someone is a patient. Software doesn't absorb that culture. It does exactly what it was built and configured to do.

That's why a practice should write its boundaries down before automation goes live. A one-page list of what automated messages must never contain gives your vendor a clear requirement, gives your staff a way to spot problems, and gives you something to test against. Below are the three categories every list should cover, with examples.

1. Protected health information beyond what's needed

Under HIPAA, protected health information includes not only diagnoses and records but also the fact that a person is a patient, combined with identifying details. The Privacy Rule's minimum necessary standard asks practices and their business associates to limit what they use and disclose to what the purpose requires. To offer an appointment time, the purpose requires very little.

Automated messages should never include:

• The reason for the visit. "Your follow-up for your knee injury" or "your cleaning and X-rays" tells anyone holding the phone something private.
• The patient's full name. The patient knows who they are. A lock screen preview doesn't need to announce it.
• Provider specialty when it's revealing. A message from a named oncology, behavioral health or fertility provider discloses a lot on its own.
• Balances, test results or medications. None of these belong in an automated text.
• Details about another patient. Family members sharing a phone number are common; messages should never confirm who else in the household is a patient.

2. Anything that sounds like clinical advice

Front office automation should never give medical advice, interpret symptoms, or suggest urgency. Even phrases meant to be helpful can be read as clinical guidance. Examples of things automated messages must never say:

• "That sounds like it can wait until next week."
• "You don't need to come in for that."
• "That's a common side effect."
• "Your results look normal."
• "You can skip your follow-up if you're feeling better."

What to say instead when a patient raises something clinical

Patients will sometimes reply to an appointment text with a symptom or a question. The software's job is to recognize that it's out of scope and get the message to the right person. A safe response looks like this: "Thanks for letting us know. A member of our team will follow up with you. If this is an emergency, call 911." Then the thread goes to staff, flagged for review.

Notice what that response doesn't do. It doesn't acknowledge the specific symptom, guess at severity, or promise a callback time it can't guarantee. It routes, and that's all.

3. Promises the practice hasn't made

Automated messages can create commitments a practice never intended. A loosely configured system might tell a patient something that sounds reasonable but isn't true for them. Messages should never:

• Promise coverage or cost. "Your insurance will cover this" or "there's no charge" depends on details the system may not have.
• Guarantee a booking before it's final. If the front desk enters the booking, say the request has been received and will be confirmed, not that it's done.
• Waive policies. No automated message should forgive a late-cancellation fee or promise an exception.
• Commit a provider. "Dr. Lee will see you" when scheduling rules might assign someone else.
• Set clinical timelines. "We'll call you with results tomorrow."

How to build guardrails that actually hold

A list is only as good as the system enforcing it. These design choices make the boundaries hard to break:

1. Use fixed templates. Messages built from approved templates, with blanks only for practice name, times and choices, can't drift into off-limits territory the way freely generated text can.
2. Use numbered menus for replies. When patients answer with a number, nothing needs to be interpreted, and there's no opening for a model to improvise.
3. Route anything unexpected to a person. Free-text replies, questions and complaints should go to staff, not to an auto-reply.
4. Test the list before launch. Send the system the kinds of replies patients really send: a symptom, a billing complaint, a question about a family member. Check that every one gets routed rather than answered.
5. Keep a log. Every automated message and action should be recorded so you can review what was said, when and why.
6. Get the BAA first. Any vendor sending messages on your behalf handles protected health information and must sign a Business Associate Agreement before any data moves.