Where AI belongs in the patient journey — and where it does not

Every hospital group I have worked with has made the same mistake in the same order. Someone demos a conversational agent. It answers three questions beautifully. Within a fortnight there is a plan to put it across the website, the app, WhatsApp, the IVR and the Google Business listing, because if it can answer those three questions it can surely answer everything. Nine months later the thing is quietly switched off on the channels that mattered and left running on the ones nobody uses.

The error is not technical. It is that nobody mapped the patient journey first and asked, stage by stage, what the cost of being wrong is. Those costs are wildly different. Getting a doctor’s OPD timing wrong on a discovery page is an annoyance. Getting a post-operative instruction wrong on WhatsApp at eleven at night is a clinical incident with your group’s name on it.

So here is the map, and my honest view of where automation belongs, where it needs a human in the loop, and where a bot actively destroys value. I have been wrong about at least two of these and I will say which.

The eight stages, and what each one actually is

Patient journey diagrams in hospital strategy decks are usually drawn by people who have never sat in the contact centre. The real journey, in a multi-unit Indian group, looks like this:

• Discovery — symptom search, condition search, doctor-name search, aggregator listings, AI answer engines, a relative’s recommendation.
• Enquiry — a call, a form, a WhatsApp message, a walk-in at the front desk, a DM on a social handle. Usually more than one of these for the same patient.
• Booking — appointment, slot, unit, doctor, payment or no payment, and the question of whether that slot exists in the HIS or only in the contact centre’s head.
• Pre-visit preparation — fasting instructions, documents, insurance or TPA paperwork, directions, which gate, which floor, which counter.
• In-visit — registration, waiting, consultation, diagnostics, billing.
• Discharge — summary, medication, restrictions, red-flag symptoms, follow-up date.
• Follow-up — the review visit, the report that came back after the patient left, the therapy that needs a second cycle.
• Recall — annual health check, vaccination due, screening due, chronic-care review.

Notice that only three of those eight stages involve the patient being inside your building. The rest happen on a phone, and that is exactly where automation has leverage — and exactly where you have no clinician standing behind the patient to catch a mistake.

Discovery: automate without hesitation

This is the one stage where I would let machines do almost everything. Discovery content is high volume, templated by nature, and the failure mode is invisibility rather than harm. Doctor profiles across dozens of specialities and several units, condition pages, procedure pages, location pages, the same content in two or three languages — no human team is going to produce and maintain that at the rate search and answer engines now demand.

The honest caveat is medical accuracy, and the answer is not to stop automating. It is to separate the layers. Clinical claims come from a reviewed source — your own clinicians, a signed-off content spine per speciality. Everything around the claim can be generated: the structure, the FAQs, the internal linking, the regional-language version, the schema. I have watched teams try to review every generated word and collapse under the volume. Review the spine once, then review samples. That distinction is what makes the programme survivable.

Enquiry: the stage everyone automates and nobody designs

Enquiry is where the money is and where the bots embarrass you. A patient typing “my father has chest pain since morning, which doctor” is not an enquiry. It is a triage event. A patient asking “do you have a paediatric neurologist in the east-side unit on Saturday” is a genuine enquiry and should be answered in four seconds at two in the morning.

The design that works is a narrow, confident automation sitting on top of a fast human escalation. Automate: availability, speciality mapping, location, timings, what to bring, whether a particular insurer is empanelled, approximate package ranges if and only if your pricing is genuinely standardised. Escalate immediately: anything symptomatic, anything with a time qualifier that suggests acuity, anything involving a child under a certain age, anything where the patient has said a word that belongs in an emergency department.

The part teams get wrong is treating escalation as failure. We measured containment for a long time and it taught us the wrong lesson — the bot looked better the less it handed over. A contained conversation that ended in no appointment and no human contact is not a success; it is a lost patient who now thinks your hospital does not answer the phone.

Booking: automate the transaction, not the judgement

Booking automation fails for an unglamorous reason: the slot data is not true. In most multi-unit groups the HIS holds a schedule that the doctor’s secretary overrides, the unit overrides again during theatre days, and the contact centre quietly keeps a parallel list of who will actually see a patient at four on a Thursday. Put a bot on top of that and you will confirm appointments that do not exist, which is worse than not booking at all.

Fix the schedule master before you automate booking. That is not a technology project, it is a governance fight with unit heads and clinician offices, and it takes a quarter. Once the schedule is trustworthy, booking is the single best automation in the journey: high volume, clear success criteria, immediately measurable, and the patient genuinely prefers it to waiting in a queue.

One boundary: do not let automation decide which doctor. Speciality mapping from a symptom description is a clinical judgement dressed up as a routing problem. Offer the list, let the patient choose, or route to a human. I have seen a well-meaning symptom-to-speciality mapper send a suspected cardiac case to general medicine because the patient typed “gas problem”. That is the kind of thing that ends up in a committee room.

Pre-visit preparation: the most underrated automation in the hospital

This is where I would spend money next if I had to choose one stage. Pre-visit is almost entirely deterministic. Fasting instructions for a given test, documents needed for a TPA approval, which gate to enter after nine at night, whether the radiology unit is in the basement of the old block. The information exists, it rarely changes, and the current mechanism for delivering it is a harried voice on a call or nothing at all.

Automating it reduces no-shows, reduces repeat calls into the contact centre, and reduces the single most common front-desk dispute in Indian hospitals — the patient who arrived without the paperwork their insurance required. No clinical judgement is involved. The content can be reviewed once per test and per unit. If your group has not automated pre-visit communication properly, the conversational agent on the homepage is a distraction.

In-visit: keep the bot away from the patient

Inside the building, the useful AI is pointed at staff, not patients. Ambient documentation for the consultation, queue and flow prediction for the front office, coding and billing support, prior-authorisation drafting for TPA desks. All of those have real returns and none of them involve a model speaking to a patient unsupervised.

Patient-facing automation inside the hospital tends to be self-service kiosks and status screens, and those are fine — they are software, not judgement. But the instinct to put a conversational agent in the waiting area, answering questions about the patient’s own case, should be resisted. The patient is fifteen feet from a nurse. Use the nurse.

Discharge: where a bot does active harm

Discharge is the one stage where I will be absolute. No model answers a patient’s question about their own discharge instructions without a clinician in the loop. Not with a disclaimer, not with a confidence threshold, not with retrieval over the discharge summary.

The reason is not that the answer will usually be wrong. It is that the consequence distribution is skewed. Ninety-nine answers about when to resume walking are harmless; the hundredth is a patient asking whether the bleeding they are seeing is normal, and an approximately correct answer at that moment is a clinical event. There is no containment metric that makes that trade acceptable, and in India the medico-legal picture is unsettled enough that you do not want to be the group that tests it.

What you can automate at discharge is delivery and structure — getting the summary to the patient in a language they read, in a format they can follow, with the follow-up date already in their calendar and the medication schedule laid out plainly. Automate the logistics. Leave the interpretation to a human.

Follow-up and recall: automate the nudge, never the interpretation

Recall is where automation earns its keep quietly. Screening due, vaccination due, annual check due, second cycle due — these are rules over a database, they run at scale, and they produce revenue that no campaign can match for efficiency. The work is not AI at all; it is data hygiene and consent.

Follow-up is subtler, because the messages drift towards clinical ground. “Your report is ready” is safe. “Your report shows nothing concerning” is not a message any automation should send, and I have had to kill a version of that template written by a team who genuinely thought they were reducing anxiety. The rule I use: automation may tell a patient that something exists, that something is due, or where to go. It may not tell them what it means.

The test I apply to every stage

Three questions, in this order:

• If this answer is wrong, who gets hurt and how badly? If the answer involves a body rather than a calendar, a human signs off.
• Is the underlying data true today? Not “does the system have a field for it” — is the value in that field what the unit actually does this week. Most automation failures are data failures wearing a model’s clothes.
• Does a human have to do this anyway? If the automation produces something a nurse or a coordinator must verify before it is used, you have added a step, not removed one. That is the trap half of hospital AI falls into.

If you’re starting this next quarter

1. Map your own eight stages with the contact centre and one unit’s front desk in the room. Not with the vendor. A day’s work, and it will contradict your strategy deck.
2. Fix the doctor schedule master. Nothing downstream of booking is trustworthy until this is done, and it is the least interesting work in the programme.
3. Automate pre-visit communication for your top ten diagnostic preparations and your two or three commonest TPA document sets. Low risk, immediate effect on no-shows and call volume.
4. Put a narrow enquiry agent on availability, location and empanelment only — and instrument the handover path before you instrument the bot. Measure resolved enquiries and booked appointments, not containment.
5. Write the never-answer list and have the medical director sign it. One page. Discharge interpretation, symptom triage, medication queries, report interpretation, anything paediatric with an acuity signal.
6. Leave discharge and follow-up interpretation alone for now. Automate their logistics instead and come back in a year when your logging and review process has a track record.

The journey does not need more intelligence. It needs automation placed where being wrong is cheap, and humans kept where being wrong is not.

Questions people ask