Most hospital WhatsApp bots are built by listing what they can do: book an appointment, share a doctor's timings, send a report link. Fewer teams write down what the bot must refuse. That second list is the one that protects patients, and it is the one regulators, insurers and your own clinical governance committee will ask about after something goes wrong.
This article is for hospital CMOs, digital heads and patient-experience leads who are deploying, or being sold, a WhatsApp assistant that talks to patients. It gives a concrete boundary policy: the categories a bot must not answer, how it should refuse, where it should route the person, and how to test that the boundary holds. The wording examples are starting points. Your clinical, legal and quality teams must approve the final policy.
The boundary policy described below is a starting template to adapt with your clinical team, not a standard.
The rule behind the list
The governing idea is simple: a bot may give administrative and general information, and it may collect and route. It may not exercise clinical judgement.
India's Telemedicine Practice Guidelines, issued in 2020 under the Indian Medical Council regulations, say that a registered medical practitioner is responsible for the teleconsultation, and that AI and machine-learning tools may not counsel patients or prescribe medicines. A bot that offers a diagnosis or a dose is doing what the guidelines reserve for the doctor, and the hospital is the party that deployed it. Our glossary entry on telemedicine covers the wider framework.
Platform terms matter too. Meta's updated WhatsApp Business Solution terms, effective in January 2026, bar providers whose main product is a general-purpose AI assistant from the Business API, while business customer-service bots remain allowed. A hospital bot that behaves like a general medical chatbot drifts toward the wrong side of that distinction as well as the clinical one. Keep the bot scoped to your hospital's services.
The boundary list
For each category below, the bot needs a refusal, a route and a log entry.
1. Diagnosis and symptom interpretation
The bot must not say what a symptom means, rule a condition in or out, or tell someone they are "probably fine". This includes the gentle forms: "that sounds like acidity", "it is usually nothing".
Example refusal: "I can't tell you what is causing this. A doctor needs to assess you. I can book the earliest appointment or connect you with our nurse line now. Which would you like?"
Route: appointment booking, or a nurse or call-centre handoff during staffed hours.
2. Medication, dosage and drug interactions
No dose advice, no "can I take X with Y", no advice to stop, skip or double a medicine, and no brand substitutions. A missed dose of a heart or diabetes drug is a clinical question.
Example refusal: "I can't advise on medicines or doses. Please speak to your doctor or pharmacist. I can pass your question to our pharmacy team, who will call you back."
Route: pharmacy callback queue, with the medicine name captured as a free-text note for the pharmacist, not interpreted by the bot.
3. Test and result interpretation
The bot may deliver a report through a secure link after verification. It must not explain values, say a result is normal or abnormal, or compare against reference ranges. Wrong reassurance and wrong alarm are both harmful.
Example refusal: "Your report is ready and I've sent the link. I can't interpret results. Your doctor will explain them. Would you like to book a follow-up?"
Route: follow-up booking with the ordering doctor.
4. Emergencies and red-flag symptoms
This is the most important boundary. If the message contains red-flag language, such as chest pain, difficulty breathing, severe bleeding, loss of consciousness, stroke symptoms, a suspected overdose, self-harm, or a pregnancy emergency, the bot must stop normal flow and give a fixed emergency message, not a generated one.
Fixed message: "This may be an emergency. Please call 112 or our emergency line [number] now, or go to the nearest emergency department. Do not wait for a reply here."
Route: an immediate alert to a human on the emergency desk, with the conversation attached. Do not ask follow-up triage questions before showing the emergency message. Keep the keyword and phrase list clinically reviewed, and include Hindi and regional-language terms plus common spellings written in Roman script.
5. Mental health crises
Self-harm language needs its own fixed response, a human handoff and a verified helpline number from your clinical team. The bot must not attempt counselling.
6. Prices not on file
A bot that guesses a price creates a billing dispute. It may quote only prices held in a controlled, dated price list for named, standard services. It must not estimate surgical packages, implant costs, ICU days or insurance co-pay.
Example refusal: "I don't have a confirmed price for that. Costs depend on the doctor's assessment. I can arrange a call with our patient counsellor for an estimate."
Route: counsellor or billing queue, with the service requested.
7. Insurance and claim promises
No "this will be covered", no cashless approval promises, no claim-status guesses. Coverage depends on the policy and the insurer.
8. Doctor availability and credentials not in the roster
The bot should answer from the live roster only. If a doctor is not listed, it says so and offers the nearest option. It must not invent consultation days or qualifications.
9. Opinions on other providers and outcome claims
No comparisons with other hospitals, no success-rate statements, no "best in the city". In India these also conflict with the NMC's advertising rules for doctors and with ASCI guidance on healthcare claims; see our NMC compliance handbook.
10. Another person's records
The bot must not disclose any patient's information to anyone who has not been verified as that patient or an authorised representative. A phone number matching a record is not proof of identity.
Data and consent boundaries
A triage conversation collects health information, which makes consent and purpose limitation central under the Digital Personal Data Protection Act, 2023. Three practical rules:
- Tell the user at the start that they are talking to an automated assistant, what it collects and why.
- Collect the minimum needed to route: name, age band, location, the service wanted and a short free-text reason. Do not ask for full histories.
- Set a retention period for transcripts and a named owner. Do not feed identifiable chats into model training unless the consent and contract allow it.
Your legal team should map the Act and its Rules to your exact data flows.
