AI in Healthcare: What Is Safe to Automate

It depends entirely on what the software claims to do. Admin tools sit outside medical device regulation: coding, claims, scheduling, drafting of notes. Software that makes a diagnostic or treatment call generally does not, and may be regulated as a Software as a Medical Device. The boundary is the claim a system makes, not the technology. That is one reason we are careful about how a system's purpose is described. Take formal advice on the exact tool and indication. We will give you an honest technical account of what it does.

It can, and for many hospitals it should. On-premises deployment works for most of what is described here, extraction and scheduling in particular. Some larger language models are not practical to run locally. Then the questions are which cloud region, what contractual protections apply, and whether de-identified data would do the job just as well. We settle this at proposal stage, not as an implementation detail. It changes both the architecture and the cost.

Partly, and it depends on which records. Structured data in the HIS — admissions, billing, test reports — is often enough on its own. That covers scheduling, claims and readmission work. Work that depends on the clinical narrative needs that narrative to be digital. OCR on scanned papers works, but it adds weeks and adds errors to check. Where records are largely paper, the first project is digitisation, and it is worth doing on its own merits.

By not asking them to change how they work. The systems that get adopted sit inside the workflow that exists. A draft in the queue where they expect it, an alert where prescribing happens, one action to dismiss it. The ones that fail ask a doctor to log into something new. We also involve two or three clinicians in the design from the start. A system built without them gets worked around. A system a respected colleague helped design gets a fair trial.

ABDM matters mainly for how records are shared and consented outside the hospital. It carries its own consent rules on top of DPDP duties. For internal projects it is often not the binding constraint. It is central once you exchange records with other providers, or build anything patient-facing that pulls a longitudinal record. We would rather map that early than retrofit consent handling later.

For coding or claims, six to ten weeks to a working system you can check against your own numbers. Scheduling is similar, if theatre and appointment data is clean. Documentation support takes longer: three to four months. Most of that goes on the review screen. It needs work with clinicians until it is fast enough to use. Anything clinical-adjacent should be planned in quarters, and most of that is governance rather than engineering.

Ask every vendor this and be suspicious of a vague answer. Running cost has three parts: infrastructure, model inference where a paid model is used, and upkeep. Extraction and scheduling models are cheap to run once built. Work that uses a large language model at volume, such as drafting and the agents, has a real per-use cost. It scales with use, so model it against your actual volumes before you commit.

Usually, though the method varies. Some Indian HIS products have proper APIs, some expose a database you can read, and some need file-based exchange. All three work, and they differ in effort and in how fast you find out. We settle this in the first fortnight. It sets the shape of everything else. A vendor who has not asked about your HIS before quoting has not scoped the work.

This is why we prefer models that show their evidence alongside the output. When a coding rule or a policy term changes, a system whose reasoning you can see is easy to check and correct. One that emits a bare answer has to be retrained on faith. In practice: plan for review at set times, and hold a validation set aside to detect drift. Treat guideline changes as scheduled upkeep rather than an incident.

That is seldom why hospitals do it, and we would be careful about promising it. What changes is what staff spend time on. Less typing and chasing of papers, more patient contact and exception handling. In most Indian hospitals the constraint is not headcount but the fact that clinical staff are carrying admin load. Freeing that time often shows up as shorter waits and faster discharges. It does not often show up as a smaller payroll.

Agree the measure before you build, and make sure it is one you track now. Coding accuracy and query rate. Claim rejection reasons, days in receivables, theatre use against booked hours, time from discharge decision to patient leaving. These sit in your systems today, so the baseline is there. Be wary of any measure that only appears after the project starts. There is nothing to compare it against.

Then we should find that out in the assessment phase, which is what it is for. Sometimes the honest answer is that the data is not there. Sometimes the bottleneck is a process problem no model will fix. We would rather say so in week two than in month five. An engagement that ends with you not spending money is a better outcome for us. Software no one uses is a worse one.