This post is for healthtech founders, hospital digital teams and chatbot implementers who run, or are building, a patient-facing chatbot on WhatsApp or a website. It is a technical design note. It describes a layer that sits above the language model and intercepts messages that may describe an emergency, so that the model never composes a reply to them.
The need is simple. Patients write to hospital chatbots in the middle of the night, in their own words, in English, Hindi, Hinglish, or all three in one message. Some of those messages describe a heart attack, a stroke or bleeding in pregnancy. A language model asked to answer them may produce something fluent, reassuring and wrong. The design goal is not a smarter model but a deterministic path that does not depend on the model at all.
A caution first. We do not publish clinical lists in this article, and nothing here is medical advice. Which phrases constitute a red flag, and what the bot should say, are clinical decisions that your medical leadership must make, document and review. What follows is the engineering around those decisions. Where we mention symptoms, they are examples of the categories a clinical team might consider.
The principle: an interrupt layer, not a prompt
You can ask a model in its system prompt to escalate emergencies. That is worth doing as a backup. It is not a safety control, because prompts can be overridden by long conversations, odd phrasing or an injected instruction, and the model's behaviour changes between versions.
An interrupt layer is code that runs before the model on every inbound message:
- Receive the message (and the last few messages of context).
- Normalise the text.
- Check against the red-flag rules.
- If a rule matches, send the fixed emergency response, notify a human, lock the conversation out of generation, and stop.
- If no rule matches, pass the message to the model.
The fixed response is written, translated and approved in advance by clinicians. The model never sees the message, so it cannot be argued out of the rule.
Also run a second check on the model's output. If the model produces text that appears to give a diagnosis, a dose or reassurance about a serious symptom, block it and escalate. Two gates, one before and one after, cost very little compared with one incident.
Scope: what the bot refuses to do at all
Limit what the bot is for. The examples that make an interrupt layer necessary are exactly the ones the bot should not be handling in the first place. Define the bot's job as appointments, hospital information, preparation instructions that clinicians have approved, and routing to staff. Symptom triage is a clinical function with its own regulatory and liability implications. If your product assesses symptoms and suggests actions, take regulatory advice on whether it falls under medical-device rules in your market before launch. This is one reason the safest design is a bot that recognises danger and hands over, not one that tries to judge it.
For more on setting scope in a chatbot, see our piece on whether AI chatbots convert patients and the chatbot implementation guide.
Building the rule set
A clinical team supplies the categories and example phrasings. Engineers turn them into patterns. The working structure has four parts.
Categories. Keep a small number, each with a response and an owner. Illustrative categories a clinical team might define, not a list to adopt: chest or cardiac symptoms; stroke-like symptoms; breathing difficulty; pregnancy-related bleeding or severe pain; loss of consciousness; severe bleeding; suspected poisoning or overdose; self-harm. Public health sources can help a clinical team structure their discussion. The NHS pages on stroke symptoms and heart attack both tell people to call emergency services at once and not to drive themselves, and are examples of how a public body words the instruction. Local protocols decide what applies in India.
Patterns. For each category, a set of phrases and combinations. Rules work best as combinations of a symptom term and a context term, because single words produce false positives. For example, a body-part term near a pain term, or a breathing term near a negation of normal breathing. Avoid trying to match every phrasing; aim for high recall on the common ones, then expand from real logs.
Negation and context handling. "No chest pain" and "my father had chest pain last year" should not fire the same way as "I have chest pain now". Handle negation words and past-tense markers explicitly, and when in doubt, escalate. A false alarm costs a nurse a few minutes; a missed alert costs more.
Priority. Rules that point to the most time-critical categories run first and override everything else, including an ongoing booking flow.
Handling English, Hindi and Hinglish
Hinglish, Hindi written in Roman script, is the hard part, because there is no standard spelling. The same phrase appears as several spellings, with or without vowels, with chat abbreviations.
Practical steps:
- Normalise before matching: lowercase, strip repeated letters ("dardddd" to "dard"), remove punctuation, standardise common substitutions, and handle both Devanagari and Roman forms.
- Build variant lists from real messages. Start with your own chat history, with patient identifiers removed under your data policy, and ask native-speaking staff to list how people actually write each symptom.
- Use fuzzy matching with care. An edit-distance tolerance catches typos but can match unrelated words, so limit it to longer terms and review the matches.
- Include transliteration variants for the same word, for example the several ways of writing the Hindi for "breath" or "pain" in Roman letters, which your Hindi-speaking reviewers should enumerate.
- Cover other languages you serve. If the bot also receives Tamil, Marathi or Bengali, each needs its own reviewed list. Do not assume the Hindi list covers them.
Voice notes are an additional route on WhatsApp. If the bot transcribes them, run the interrupt layer on the transcript, and treat a failed transcription as a reason to hand over to a human rather than to ignore the message.
