AI in diagnostics support: what is realistic today
What should you know about AI diagnostics support?
AI supports clinicians with retrieval, summarisation and triage; diagnosis stays with clinicians and regulated devices. The realistic wins are fast access to the right guideline, a draft summary of a long record, a prioritised worklist and fewer missed follow-ups, each with clinician sign-off and an evaluation set.
AI diagnostics support is the phrase hospital leaders use when they ask whether AI can help their clinicians diagnose faster and miss less. The honest answer has two halves. Software that itself reads an image or a signal and outputs a diagnosis is a medical device, regulated as one, and bought from a manufacturer who carries that approval. Software that helps the clinician find, summarise, prioritise and follow up is not a device, can be built for your hospital, and is where most of the practical value sits today. This article draws that line clearly, lists what is realistic on the supportive side, and explains how to build it safely.
What AI diagnostics support is, and what it is not
Clinical decision support AI covers a spectrum. At one end are approved diagnostic algorithms: a radiology AI assistant that flags a possible haemorrhage on a CT, a retinal screening tool, an ECG interpreter. These are cleared or approved by a regulator for a specific indication, validated on defined populations, and sold under a manufacturer's liability. At the other end are tools that never make a clinical claim: they retrieve the relevant protocol, summarise a discharge history, order a worklist by urgency signals the hospital defines, or draft a referral letter. The first category you buy. The second you can build, own, and evaluate against your own data. The healthcare industry page describes the second category in more detail.
Realistic today vs still marketing
| Use | Status | What it needs |
|---|---|---|
| Retrieval of guidelines and protocols in context | Realistic and low-risk | Permission-aware retrieval over the hospital's current documents, with citations |
| Summarising a long record before a consult | Realistic with clinician review | Structured source data, a draft the clinician edits, an evaluation set of real records |
| Worklist prioritisation by defined signals | Realistic where signals are explicit | Rules the hospital owns, transparent scoring, audit of overrides |
| Follow-up and result-acknowledgement tracking | Realistic and often the highest value | Integration with lab and imaging results, escalation to a person |
| Image or signal interpretation | Buy an approved device, do not build | Regulatory clearance, validation on your population, manufacturer support |
| Autonomous diagnosis or treatment choice | Not realistic and not permitted | Nothing; keep this with clinicians |
Retrieval: the right guideline at the right moment
The most reliable diagnostic support is making the hospital's own knowledge reachable. Protocols, antibiotic policies, dosing tables and care pathways live in shared drives and intranet pages, and the current version is not always the one a clinician finds. A retrieval system over those documents, with citations back to the page and a visible version date, answers "what is our sepsis pathway for a patient with this allergy" in seconds. It does not decide; it shows the source. The engineering is the same as any production retrieval system, covered in why basic RAG fails in production, with two additions: the document set must be curated by the clinical governance team, and questions that fall outside it must return "not found" rather than a general-knowledge answer.
Summarisation: reading the record so the clinician can talk
A patient with a long history arrives with years of notes, results and letters. A draft summary that pulls out active problems, current medications, recent results and open referrals, each linked to its source, saves the clinician reading time and reduces the chance of a missed detail. The draft is labelled as a draft, edited or discarded by the clinician, and never enters the record without sign-off. The evaluation set is a few hundred real (de-identified) records with clinician-written reference summaries; the system is measured on what it missed and what it invented before it is switched on, and on every model change after. The approach is the same as in private clinical assistants over discharge notes and protocols.
Triage and worklists: prioritise, do not decide
Radiology and pathology departments have queues. A worklist that surfaces studies by explicit signals, urgency flag on the request, time waiting, source department, patient location, is prioritisation the hospital already does by hand. Encoding it is safe and useful. What is not safe is ranking by a model's opinion of what the image shows, unless that model is an approved device for that indication. Where an approved device is in use, its flag becomes one more signal in the hospital's own list. Keep the scoring transparent, log every manual override, and review the overrides monthly; they tell you where the rules are wrong. A department head who can explain every position in the worklist will trust it; one who cannot will quietly go back to the paper list within a month.
Follow-up tracking: the unglamorous win
Results that nobody acknowledged and referrals that nobody actioned are a well-documented source of patient harm. Software that watches the results feed, checks for acknowledgement within a defined window, and escalates to a named person is not sophisticated AI, and it is often the most valuable thing in this category. Language models help at the edges, reading a free-text result to spot an unexpected finding phrase, but the core is integration and a rule engine, with a person at the end of every escalation.
Where the medical AI limits are
Three limits are worth stating plainly. First, a general model does not know your population, your formulary or your pathways; anything it says without retrieval is generic and possibly out of date. Second, fluency is not accuracy: a summary can read well and omit the one result that mattered, which is why measurement on real records precedes deployment. Third, liability does not transfer to software; the clinician signs, and the tool must make that sign-off meaningful by showing sources and flagging uncertainty. The World Health Organization's guidance on ethics and governance of AI for health, published at who.int, is a useful frame for a hospital's own policy. Data handling for any of this follows the rules in patient data and AI consent in India.
Private deployment is usually required
Patient records rarely leave the hospital's control, so these systems typically run on infrastructure the hospital owns or rents privately, with open-weight or privately hosted models. That is our private agentic AI practice; the model choice is a benchmark on your own evaluation set rather than a brand preference.
A worked example
A hospital network asked for "AI to help our doctors diagnose". The discovery conversation narrowed it to three problems: junior doctors could not find the current protocol quickly; consultants spent the first minutes of every clinic reading history; and imaging results sometimes sat unacknowledged. The build delivered protocol retrieval with citations and version dates, a pre-consult summary draft with clinician sign-off, and a results-acknowledgement tracker that escalated after a defined window. No image interpretation was built; the radiology department continued to evaluate approved devices separately. Each component ran in shadow mode first, with clinicians rating drafts and retrieval answers before anything was shown in the live workflow. The governance committee owned the document set and the escalation rules. The same network's multilingual voice agent handled the front-desk side of patient contact.
Team and timeline
Supportive diagnostic AI is an AI engineer for retrieval and summarisation, an integration engineer for the results and record feeds, and a clinical lead on the hospital side who owns the evaluation sets and the document governance, over eight to fourteen weeks for the first two components. The retrieval component is retrieval and knowledge engineering from $14,000 / ₹8.8L; the summarisation and follow-up components are an LLM application from $21,000 / ₹13.6L; private hosting adds infrastructure. A three-week ProofRun at $6,250–10,500 is the right first step: it builds the evaluation set on your records and tells you what accuracy is achievable before you commit. Prices and Care Plans are on the pricing page.
Before you start: a checklist
- Separate the wish list into device territory (buy) and supportive tools (build)
- Name the clinical lead who owns evaluation sets and document governance
- Collect the current versions of protocols and pathways, with owners and review dates
- Assemble a de-identified set of real records for summarisation evaluation
- Decide where models run and confirm no patient data leaves the hospital's control
- Define the shadow-mode period and the acceptance criteria clinicians will sign
- Write the escalation rules for follow-up tracking, with named recipients
- Agree how overrides and errors are logged and reviewed
Glossary
- Clinical decision support: software that gives clinicians information or prompts relevant to a decision, without making it
- Software as a medical device: software whose intended purpose is diagnosis, prevention or treatment, regulated accordingly
- Shadow mode: running the system on live data with outputs visible to evaluators only, before clinicians rely on it
- Groundedness: whether an output stays within the sources it was given
- Worklist: the ordered queue of studies or tasks a department works through
- Override log: the record of every time a person chose differently from the system's suggestion
Related reading
Private clinical assistants over discharge notes and protocols goes deeper on summarisation; permission-aware retrieval covers keeping answers inside access rights; evals: the practice that separates AI demos from AI products covers the measurement discipline.
Build the tools that put the right information in front of the clinician, buy the approved devices, and leave the diagnosis where the responsibility already sits.
Frequently asked questions
Can we build our own radiology AI?
▾
Not as a diagnostic tool; image interpretation for a clinical indication is a regulated medical device and should be bought from a manufacturer with clearance. You can build the worklist, retrieval and follow-up tooling around it.
How do we know a summary is safe to use?
▾
Measure it before deployment on a few hundred real de-identified records against clinician-written references, tracking omissions and inventions, and keep clinician sign-off on every summary in production.
Does the AI need patient data to leave the hospital?
▾
No. Retrieval, summarisation and triage tooling can run on private infrastructure with open-weight or privately hosted models, which is the usual requirement for clinical data.