The AI strategy a hospital group can actually execute
An AI strategy in healthcare is six decisions, not a technology view: which few problems to automate, in what order, what stays human, who owns it, how it is funded and what review can stop it. This piece separates a genuine strategy from a portfolio of disconnected pilots.
Most hospital groups in India already have an AI portfolio. A chatbot on the website, a voice bot somewhere in the contact centre, an ambient documentation trial running in two consultation rooms, a radiology tool a department head brought in on his own, and a proof of concept with a startup somebody on the board introduced. Each has a sponsor. Each has a slide. None of them were ever chosen against each other.
That is the whole difference between a portfolio and a strategy, and it only becomes visible when something has to be said no to. Ask a group to stop one of its five AI initiatives and you find out immediately whether there was a strategy underneath. If there was, the answer takes ten minutes and cites a criterion everyone already agreed to. If there wasn’t, it takes a quarter, becomes political, and ends with all five surviving at half funding — which is the worst outcome available.
An AI strategy is not a view on AI. It is a short set of decisions: which few problems are worth automating at all, in what order, what stays human, who owns it, how it gets funded, and what review can kill it. Six decisions. Everything else in the deck is context.
The six decisions, and everything else is context
Vendor decks and consulting frameworks push you towards a maturity model — assess, pilot, scale, transform. That language is not wrong, it is just not a decision. A board cannot approve a maturity stage. It can approve a list of problems with money attached and a named owner.
So write the strategy as six answers, each one paragraph long. What are we automating and why those. What order and against what readiness test. What we have decided a machine will not do. Who is accountable when it breaks at 9pm. Where the money comes from and what happens to it if the thing works. Who reviews it, how often, and what they are empowered to stop. If you cannot fill all six in on a single page, you do not yet have a strategy — you have an interest in AI.
Choosing the few problems worth automating at all
The filter that has held up for me is unglamorous: automate where volume is high, the decision is low-stakes, the same answer repeats, and a wrong answer is recoverable. That set is smaller than the enthusiasm in the room suggests. Appointment logistics, pre-visit preparation, insurance and empanelment queries, report availability, directions and timings, recall nudges, internal search across your own content — these are genuinely worth the money.
Notice what that filter excludes. Anything where the patient is frightened, anything where the answer depends on a clinical judgement you do not hold, anything where being wrong once costs you a relationship or a regulator’s attention. Those are not AI problems yet, whatever the demo showed.
The asymmetry matters more than the volume. A wrong answer about visiting hours costs a phone call. A wrong answer about whether a symptom needs attention costs something you cannot price, and in a multi-unit group one such incident sets the entire programme back by a year because every subsequent proposal is read through it. I would rather automate six boring things completely than one interesting thing partially.
Most groups skip this filter entirely and start from the technology — someone saw a good agent demo and now there is a project. Reversing that is the single most valuable thing a strategy does. It is also the point where AI stops being a separate initiative and becomes part of what digital transformation already meant in your group: fixing the front door, the data underneath it, and the operating rhythm around it.
Sequence against data readiness, not against excitement
The order of an AI programme should be determined by where your data is already clean enough to trust, not by which idea got the most nods in the executive committee. This is the least popular sentence in any strategy conversation, because the most exciting ideas usually sit on the worst data.
Run a blunt readiness test per problem before it enters the sequence. Does one system hold the truth, or three? Do we have a working identifier for the patient across units? Is the doctor master accurate enough to answer a scheduling question? Do we hold purpose-specific consent for the communication this would generate? A problem that fails two of these does not get deprioritised politely — it gets a data workstream instead of an AI workstream, with its own budget line and its own owner.
This is where most AI programmes quietly break, and it is why so many initiatives that demo beautifully never reach production. The sequencing decision is the cheapest one you will make and the one with the longest consequences.
Decide what stays human, once, in writing
A strategy that only says what gets automated is half a strategy. The half that protects you is the list of things a machine will not do, written down before there is commercial pressure to move the line.
Mine is short and I have not needed to change it much: no machine gives a diagnosis or an interpretation of a result, no machine handles a distressed caller past the first sentence, no machine communicates anything about a discharge or a complication, and no machine writes a claim about an outcome. Everything else is negotiable case by case. Deciding where AI belongs stage by stage is a longer exercise, but the boundary list is the part that has to be agreed by clinical leadership and signed off, because it is the thing you will be held to.
Who owns it when digital, IT and clinical all have a claim
Every function has a legitimate claim and none of them can carry it alone. Digital owns the patient-facing experience and the conversion consequences. IT owns integration, identity and the systems the thing has to talk to. Clinical owns the boundary list and the review of anything that touches care. Finance owns whether it keeps being funded.
The arrangement that works is one accountable owner per problem — not per programme — with the other three named as mandatory reviewers with a defined veto scope. A single AI steering committee that owns everything owns nothing. And whoever is accountable must also own the run: the escalation path, the person who checks the transcripts weekly, the budget for the year after launch. If nobody wants the run, you have not found an owner, you have found a sponsor.
How it gets funded in a cost-sensitive group
Indian private healthcare runs on margins that make per-seat AI licensing genuinely hard to justify. A tool priced at a monthly fee per doctor, multiplied across a multi-unit group, produces a number that will not survive the second budget review — and it should not, if the value is soft.
So structure the funding the way the group actually buys things. Fund the first problem from the operating budget of the function that benefits, not from a central innovation pot, because a central pot removes the pressure to prove anything. Push for consumption pricing or a group-level ceiling rather than per-seat. Budget the integration and data work as a separate, larger line than the licence — it will be — and put a sunset date on every initiative so that continuation is an active decision rather than a default renewal.
Then decide in advance where the benefit lands, because this is the part that gets fudged and it is the part the CFO remembers. If an assistant takes volume off the contact centre, either the headcount plan changes or the same team absorbs more demand without growing — say which, in the business case, before launch. A saving that nobody can point to in a P&L after two quarters makes the next AI case harder to fund than if you had never run the first one.
The review that has to be able to kill something
Governance in most groups means a monthly meeting where each initiative reports progress and nothing ever stops. A review that cannot stop anything is not governance, it is a status call.
Give the review three powers and use them: continue, stop, or convert to a data workstream. Hold it quarterly, not monthly, because the useful signal on an AI initiative does not arrive in four weeks. Bring the same four numbers each time — containment or deflection that actually held, the escalation rate, the cost per interaction against the human baseline, and the complaint count — and make the owner say out loud what would have to be true to stop. The first time you actually stop something, the entire programme becomes more credible with the CFO than any success story would have made it.
The Indian constraints that shape the whole thing
A strategy written for a Western hospital system will not survive contact with an Indian group, and the differences are not cosmetic.
- Patient communication is WhatsApp-first. Design for it as the primary channel, not as an add-on to email and SMS, and accept the template approval and opt-in mechanics as a design constraint.
- Your hospital information systems were bought at different times by different units. Assume fragmentation is permanent for the next three years and build around it rather than waiting for consolidation.
- DPDP-era consent is a build requirement, not a legal review at the end. Purpose-specific consent and a working withdrawal path have to exist in the system before the first automated message.
- Regional languages are not a phase two. In most catchments, an assistant that only works in English serves the smaller half of your demand.
- Advertising and solicitation rules under the NMC code constrain what any generated content can claim. Every template and every generated answer needs the same review a hoarding would get.
- Discovery is shifting. Being in AI search results when a patient asks an assistant about a procedure is now part of the same strategy, not a marketing side project.
How to tell a strategy from a portfolio
Four tests, and they are quick. Can you state the criterion by which one initiative beat another? Does the sequence follow data readiness or enthusiasm? Is there a written list of what stays human that clinical leadership has signed? Has anything ever been stopped?
A group that fails all four still has useful projects. It just does not have a strategy, and it will keep discovering that every time budgets tighten, because a portfolio has no principle for shrinking gracefully. It shrinks by attrition — whichever sponsor left, whichever vendor’s contract lapsed — and the group ends up keeping the wrong things.
If you are starting this next quarter
Do it in this order. In weeks one and two, inventory every AI activity in the group, including the ones no one told you about, with its sponsor, its cost and its status. Most groups are surprised by the count. In weeks three and four, run the readiness test across all of them and sort into three buckets: continue, stop, or needs data work first.
In month two, write the one-page six-decision document and get the boundary list signed by clinical leadership. Take it to the executive committee as a set of decisions to approve, not a strategy to admire. In month three, stop at least one thing publicly and fund one thing properly — the same quarter, so that the group sees both halves of the trade. Then set the quarterly review and put the second problem in the queue.
A strategy is not the list of what you are doing with AI. It is the reason the list is short.
Questions people ask
It is a short set of decisions, not a view on technology. Which few problems are worth automating at all, in what order, what stays human, who is accountable, how it gets funded, and what review is empowered to stop something. Six answers on a single page. If a document cannot answer all six, it is a statement of interest in AI, not a strategy.
A portfolio is a set of initiatives that were never chosen against each other. A strategy has a criterion, so one initiative can beat another and something can be stopped. The difference is invisible while budgets are growing and obvious the moment you ask a group to cancel one of five projects. If that takes a quarter and turns political, there was no strategy underneath.
Automate where volume is high, the decision is low-stakes, the same answer repeats, and being wrong is recoverable. That means appointment logistics, pre-visit preparation, insurance and empanelment queries, report availability, timings and directions, recall nudges and internal content search. It excludes anything where the patient is frightened, anything depending on clinical judgement, and anything where one wrong answer costs a relationship.
About a quarter to write and agree it, considerably longer to execute. Spend the first month on an inventory of every AI activity already running and a readiness test across all of them. Month two is the one-page document and the clinical sign-off on what stays human. Month three is the first real funding decision and the first public stop.
Data readiness, which is the least popular answer in the room. The highest-value ideas usually sit on the worst data, and starting there produces an initiative that demos beautifully and never goes live. Test each problem: does one system hold the truth, is there a working patient identifier across units, is the doctor master accurate, do you hold purpose-specific consent. Two failures means a data workstream first.
One accountable owner per problem rather than per programme, with digital, IT, clinical and finance named as mandatory reviewers with defined veto scope. A single steering committee that owns everything owns nothing. Whoever is accountable must also own the run — the escalation path, the weekly transcript check, next year’s budget. If nobody wants the run, you have a sponsor, not an owner.
Write the list before there is commercial pressure to move it. Mine: no machine gives a diagnosis or interprets a result, no machine handles a distressed caller past the first sentence, no machine communicates anything about a discharge or a complication, and no machine writes an outcome claim. Everything else is negotiable case by case. Clinical leadership signs this list, because it is what you will be held to.
The licence is rarely the biggest number. Integration and data work usually cost more, and should sit as a separate, larger budget line. Per-seat pricing multiplied across a multi-unit group produces a figure that will not survive a second budget review, so push for consumption pricing or a group-level ceiling. Fund the first problem from the benefiting function’s budget, not a central innovation pot.
Ask where the benefit lands and who will be able to point to it in the unit numbers two quarters from now. If an assistant takes volume off the contact centre, either the headcount plan changes or the same team absorbs more demand — the business case should say which before launch. Also ask what the sunset date is and what would have to be true to stop.
Quarterly, not monthly, because useful signal does not arrive in four weeks. Give the review three real powers: continue, stop, or convert to a data workstream. Bring the same four numbers every time — containment that actually held, escalation rate, cost per interaction against the human baseline, and complaints. A review that has never stopped anything is a status call, not governance.
Patient communication is WhatsApp-first, not email-first. Hospital information systems were bought at different times by different units, so assume fragmentation is permanent for a few years and build around it. DPDP-era consent is a build requirement, not a closing legal review. Regional languages are not phase two. And NMC advertising rules constrain what any generated content can claim.
A single hospital has an easier version of the same problem. One information system, one consent regime, one clinical leadership to sign the boundary list. The six decisions are identical, the sequencing is faster, and the funding conversation is shorter. What a single hospital loses is the ability to spread integration cost across units, which makes per-seat pricing even harder to justify.
Starting from the technology. Someone sees a good agent demo and a project exists before anyone asked which problem deserved automating. The second failure is a central innovation pot, which removes the pressure to prove anything. The third is governance that reports progress and never stops work, so five half-funded initiatives survive instead of one properly funded one.
When the underlying data cannot answer the question the assistant would be asked, when no one will own the run after launch, and when the process being automated is broken rather than slow. Automating a broken referral or scheduling process makes it fail faster and more visibly. Fix the process, then decide whether what is left is worth automating at all.
