AI Strategy for Hospitals: A Plan a Hospital Group Can Execute
Reviewed on by Gaurav Phogat. Statistics checked against their original sources on the same date.
An AI strategy for hospitals 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.
Updated 29 October 2026: added a 12-month AI transformation roadmap for a hospital group and a scoring method for choosing your first five AI use cases.
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.
What are the six decisions in a hospital group AI strategy?
A hospital group’s AI strategy should be six written decisions, not a maturity model: what to automate and why, in what order against which readiness test, what a machine will never do, who is accountable when it breaks, where the money comes from and goes, and who reviews it, how often, with the power to stop it.
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
Automate where volume is high, decisions are low-stakes, the same answer repeats and a wrong answer is recoverable. That covers appointment logistics, pre-visit preparation, insurance and empanelment queries, report availability, directions, recall nudges and internal content search. Anything involving frightened patients, clinical judgement or regulatory exposure is not yet an AI problem.
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
Order AI work by data readiness, not executive enthusiasm, because the most exciting ideas often sit on the worst data. Test each problem: does one system hold the truth, is there a working patient identifier across units, is the doctor master accurate, and is purpose-specific consent in place? Problems failing two tests become data work first.
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.
How to choose your first five AI use cases
Score every candidate from 1 to 5 on four things: value, risk, data readiness and time to proof. Risk and time to proof are scored so that higher is better (lower risk, faster proof). Pick the five highest totals, but only if none scores 1 on risk or data readiness, and make sure at least one is a quick, visible win.
When I run this exercise with a leadership team, the long list is always longer than anyone expected, and most of it was brought in by a vendor or a board member. The scoring is not there to be precise. It is there to make the trade-offs visible, so that the conversation is about evidence rather than about who proposed the idea. I score with four people in the room: the business owner, someone from IT who knows the systems, a clinician for anything near patients, and someone from finance.
| Criterion | Scores 5 when | Scores 1 when |
|---|---|---|
| Value | High volume, a clear cost or revenue line, and the saving lands in one budget you can name | Nice to have, benefit spread thinly across several teams, nobody will miss it if it stops |
| Risk (5 = lowest) | No patient-facing judgement; a wrong output is caught by a person before it matters | Touches diagnosis, triage or treatment, or a wrong answer reaches a patient unreviewed |
| Data readiness | One source of truth, a working patient identifier, clean doctor master, consent for this purpose | Data sits in several unlinked systems, or consent does not cover the use |
| Time to proof | A measured result inside 90 days, against a baseline you already have | Needs a year of integration before anyone can tell whether it works |
Here is how a typical long list scores in a multi-unit Indian hospital group. The numbers are illustrative; yours will differ, and the point is the pattern.
| Candidate use case | Value | Risk | Data readiness | Time to proof | Total | Decision |
|---|---|---|---|---|---|---|
| Contact centre call summaries into the CRM | 4 | 5 | 4 | 5 | 18 | First five |
| After-hours WhatsApp booking and logistics replies | 5 | 4 | 3 | 4 | 16 | First five |
| Insurance and TPA document handling | 4 | 5 | 3 | 4 | 16 | First five |
| Patient education drafts with doctor sign-off | 3 | 4 | 4 | 5 | 16 | First five |
| CRM callback prioritisation (lead scoring) | 4 | 5 | 3 | 3 | 15 | First five |
| Ambient documentation in OPD | 4 | 3 | 2 | 3 | 12 | Pilot later, clinician-led |
| Group-wide bed demand forecasting | 5 | 5 | 1 | 2 | 13 | Data workstream first |
| Symptom checker on the website | 3 | 1 | 3 | 3 | 10 | Out: clinical governance |
Three rules keep the scoring honest. First, a 1 on risk or data readiness disqualifies a use case regardless of total; bed forecasting scores well on value, but without a working patient identifier and clean census data it becomes a data project, not an AI one. Second, the five should span at least two functions, so the programme is not seen as a marketing or IT toy. Third, each of the five gets one owner, one baseline and one metric before any vendor is called. If a use case cannot name its metric, it is not ready to be scored. For the marketing side of this list, stage by stage, see AI in healthcare marketing across the patient journey.
Decide what stays human, once, in writing
Write down, before commercial pressure builds, what a machine will never do. A short list covers it: no machine gives a diagnosis or interprets a result, handles a distressed caller beyond the first sentence, communicates about a discharge or complication, or writes a claim about an outcome. Everything else can be judged case by case.
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
Give each AI problem one accountable owner, with digital, IT, clinical and finance named as mandatory reviewers, each with a defined veto scope. Digital owns the patient experience, IT owns integration and identity, clinical owns the boundaries and review of anything touching care, and finance owns funding. A single steering committee owning everything owns nothing.
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
Per-seat AI licensing rarely survives budget reviews in cost-sensitive Indian hospital groups. Fund the first problem from the operating budget of the function that benefits rather than a central innovation pot, negotiate consumption pricing or group-level ceilings instead of per-seat fees, and budget integration and data work separately, because it usually costs more.
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
Real AI governance needs a quarterly review with three powers: continue, stop or convert to a data workstream. Bring the same four numbers each time: containment that actually held, escalation rate, cost per interaction against the human baseline and complaint count. The owner should state openly what would have to be true to stop.
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
Indian hospital groups face constraints Western strategies ignore: WhatsApp-first patient communication, fragmented hospital information systems bought unit by unit, DPDP consent as a build requirement, regional languages from day one, NMC rules on what generated content can say, and the shift of patient discovery into AI search results and assistants.
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 quick tests separate a strategy from a portfolio of projects: a stated criterion for why one initiative beat another, a sequence that follows data readiness rather than enthusiasm, a written list of what stays human signed by clinical leadership, and evidence that something has actually been stopped. A portfolio shrinks by attrition; a strategy shrinks by principle.
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.
Using AI in hospital operations without clinical risk
Hospitals in India can use AI in operations without clinical risk by starting with work that sits around care rather than inside it: the patient conversation, scheduling, content, feedback and the back office. The rule that keeps it safe is simple. AI can route, remind, draft and summarise, but any output that could change a diagnosis, a treatment or a triage decision goes to a qualified human before it reaches a patient.
The table below is how I would tier the options. Start in the first tier, earn trust with measured results, and only then move down.
| Risk tier | Examples | Guardrail that makes it safe |
|---|---|---|
| Tier one: no patient-facing judgement | Contact-centre call summaries and quality checks, marketing and web content drafts, review response drafts, lead scoring, invoice and claim document handling, internal search over policies | Human approval before anything is published or sent, and no clinical content generated from scratch |
| Tier two: patient-facing, administrative only | Appointment booking and rescheduling bots, reminders and confirmations on WhatsApp, directions and visiting information, bill and package queries, enquiry routing to the right department | A fixed scope the bot cannot leave, an instant handover to a person, and no answers to symptom or medication questions |
| Tier three: touches clinical context, human decides | Enquiry triage that flags urgency for a nurse, discharge instruction reminders written by clinicians, doctor content drafts reviewed by the doctor | A named clinician signs off, every flag is logged, and the model never tells a patient what to do clinically |
| Out of scope for an operations programme | Diagnosis, treatment advice, clinical triage decisions made by the model | These belong to a separate clinical governance process, not to digital or operations |
Two more conditions matter in India. Consent and data handling under the DPDP Act apply to every tier, so patient data in prompts and transcripts needs the same care as the CRM. And each project needs a measure agreed before launch, which is covered in measuring non-clinical AI projects. For the most common first project, see AI enquiry triage without clinical calls.
Where AI already shows up in Indian hospitals
Beyond clinical tools, AI already appears across the parts of Indian hospitals that digital teams own: voice bots and call summaries in the contact centre, booking and report notices in messaging, drafting and translation of patient content under review, CRM prioritisation of follow-ups, and ambient documentation trials in consultation rooms. Most groups have more than they realise.
Most searches about AI in hospitals in India are about clinical tools (imaging, pathology, early-warning scores), and those decisions belong to clinicians and the medical director, not to this document. The part a digital and growth function owns is quieter and, in most groups, further along than anyone admits.
- The contact centre: voice bots handling appointment logistics, call summaries, routing by language and specialty.
- Messaging and chat: booking, rescheduling, report-ready notices and pre-visit instructions, with a person behind every thread.
- Content and search: drafting and translating patient content under clinical review, and making the hospital legible to AI search.
- The CRM: prioritising which enquiries and advised procedures to follow up first.
- The consultation room: ambient documentation trials, where the doctor’s time is the measure.
Each of these already has a sponsor somewhere in a large group. The strategy’s job is to decide which of them the group will fund properly, and which it will stop.
If you are starting this next quarter
In weeks one and two, inventory every AI activity with its sponsor, cost and status. In weeks three and four, run the readiness test and sort each into continue, stop or data work first. In month two, write the six-decision document and get the boundary list signed. In month three, stop at least one initiative publicly.
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, in 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 12-month AI transformation roadmap for a hospital group
Quarter one sets the rules and proves two low-risk use cases. Quarter two adds the first patient-facing use case and starts the data work that later ones depend on. Quarter three scales what worked across units and stops what did not. Quarter four connects the use cases to the CRM and finance view and resets the portfolio for year two.
The 90-day plan above gets a strategy written. This is what the year after looks like when the strategy is executed. I lay it out across five tracks, because a roadmap that only lists use cases is how groups end up with ten pilots and no data foundation.
| Quarter | Use cases | Data work | Governance | People | Metrics |
|---|---|---|---|---|---|
| Q1: foundations and two quick proofs | Call summaries into the CRM; patient education drafts with doctor sign-off | Inventory of systems and data owners; doctor master clean-up starts; consent audit against DPDP purposes | Six-decision document signed; clinician-signed list of what stays human; AI use policy; approved tools | Name one owner per use case; medical content reviewers; short AI training for managers | Baselines for every use case; agent wrap-up time; time from draft to approved page |
| Q2: first patient-facing use case | After-hours WhatsApp booking and logistics replies in two units; insurance document handling | Patient identifier matching across units; consent fields in the CRM; conversation logs stored and reviewable | Bot scope signed by a clinician; handover rules; weekly log review; first quarterly review with power to stop | Contact centre team trained on handover; a product owner for the bot | Enquiry to appointment rate; resolution rate; escalation rate; complaints |
| Q3: scale what worked, stop what did not | Roll proven use cases to all units; add CRM callback prioritisation; first ambient documentation pilot, clinician-led | Offline conversion import from CRM to ad platforms; data quality dashboard by unit | Second quarterly review: at least one stop or convert-to-data decision; vendor and security review | Unit champions; internal prompt library owners; IT support model for AI tools | Cost per interaction against the human baseline; show rate; cost per honoured appointment |
| Q4: connect to the P and L and reset | Lead scoring in the CRM; AI search visibility tracking; choose the next five use cases from the long list | Cohort view from enquiry to billed patient; retention and deletion rules ahead of DPDP obligations from May 2027 | Annual review of the human-boundary list; sunset dates renewed or enforced; board update | Budget moved into the owning functions; roles adjusted where work changed | Savings and revenue landing in named budget lines; decisions changed because of the data |
Two things in this roadmap matter more than they look. The data track runs a quarter ahead of the use cases that need it, so patient matching is under way before the bot needs it and offline conversion import is ready before lead scoring. And every quarter has a review that can stop something. The national Strategy for AI in Healthcare for India (SAHI), launched by the Ministry of Health and Family Welfare in February 2026, makes the same point at a national level: classify AI tools by risk and keep monitoring them after launch. A group roadmap with no stop decision by month nine is a portfolio, not a strategy.
A strategy is not the list of what you are doing with AI. It is the reason the list is short.
The full guide: AI in hospital operations in India: a non-clinical risk framework.
Key statistics, with sources
Generative AI enthusiasm in healthcare is high, but results are uneven. Many Indian healthcare organisations have started proofs of concept, hospitals cite skills and resistance to change as their biggest digital obstacles, and broad business research finds that only a small share of custom enterprise AI tools reach production at all, which strengthens the case for a narrow, governed strategy.
- In India, 66% of healthcare organisations had started generative AI proofs of concept, and 44% reported higher revenue and customer satisfaction from their implementations, according to EY’s The AIdea of India 2025 study. Source: EY India, The AIdea of India 2025, February 2025.
- Six in ten Indian hospitals named workforce capability building and IT team upskilling as their biggest obstacle to digital transformation, and nearly two-thirds of chief information officers cited stakeholder resistance to change, according to the CII-EY HealthTech Survey 2025. Source: CII and EY HealthTech Survey 2025, reported by Free Press Journal, September 2025.
- Only 5% of custom enterprise AI tools reach production, and 95% of organisations report no measurable business return from generative AI despite USD 30 to 40 billion in enterprise spending, according to MIT NANDA’s The GenAI Divide: State of AI in Business 2025. Source: MIT NANDA, The GenAI Divide, reported by Virtualization Review, August 2025.
Further reading from primary sources
- WHO: Ethics and governance of artificial intelligence for health (2021): global principles for accountable AI in health.
- ICMR: Ethical guidelines for AI in biomedical research and healthcare (2023): India’s guidance on responsible AI in healthcare.
- NITI Aayog: National Strategy for Artificial Intelligence (2018): India’s national framing of AI, including healthcare.
For where these tools fit across a hospital today, see generative AI in healthcare: where it works in India.
Read next
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, and 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.
Clinical uses such as imaging and pathology support get the attention, but the widest use is operational and patient-facing: voice bots and call summaries in the contact centre, booking and reminders over messaging, drafting and translating patient content under clinical review, and CRM prioritisation of follow-ups. Clinical AI decisions belong to clinicians; the patient-facing layer is where most groups already have live, if uncoordinated, deployments.
Quarter one sets the rules and proves two low-risk use cases, such as call summaries and content drafts. Quarter two adds one patient-facing use case and the data work behind it. Quarter three scales what worked and stops what did not. Quarter four connects results to the CRM and the P and L and picks the next use cases.
Score each candidate from 1 to 5 on value, risk, data readiness and time to proof, with lower risk and faster proof scoring higher. Take the five highest totals, drop anything that scores 1 on risk or data readiness, and give each one an owner, a baseline and one metric before talking to vendors.
Read my takes first in Google Search
