AI in healthcare: the administrative work is where it lands
Healthcare is the sector where the gap between what is discussed and what is deployed is widest, and the reason is structural rather than cultural. A system that participates in a clinical decision may be a regulated medical device, which means a different approval path, a different evidence burden and a timeline measured in years rather than quarters. That is a legitimate programme for an organisation that wants one. It is not a first project, and teams that treat it as one spend eighteen months producing nothing while the administrative burden that actually consumes clinical time goes untouched. The deployments that finish in this sector are correspondence triage, coding support, discharge summarisation, prior authorisation and referral sorting. None of it is what anyone trained for, all of it consumes enormous hours, and returning those hours is both easier to deliver and considerably more welcome than anything touching diagnosis.
Healthcare, in short
| The constraint | Anything touching a clinical decision carries a regulatory burden of a different order, so the work that lands is almost always administrative rather than clinical. |
|---|---|
| The distraction | Diagnostic support, which attracts attention and sits behind the heaviest approval path available. |
| A first project that works | Correspondence triage, coding support or discharge summarisation: administrative, reviewed, and where staff time is genuinely scarce. |
| Where ground truth lives | Coded records and prior clinician decisions, which exist and are rarely accessible without a governance process of their own. |
What shows up most often, not a description of any particular organisation. No named clients and no case studies: see editorial policy.
Where the clinical boundary actually sits
The question is not whether a system touches clinical information. Almost everything in a hospital does. It is whether the system's output is intended to inform a decision about a particular patient's care.
Summarising a discharge letter for a clinician who then reads the underlying record is one thing. Producing a suggested diagnosis is another. The line is not always obvious and the organisation's own clinical governance team is the right place to establish it, in week one, before an architecture exists.
Teams that skip this conversation because they are confident their system is administrative are taking a risk with an asymmetric payoff. The cost of asking is an hour. The cost of being wrong is a project that has to stop.
Data governance is the plan, not an obstacle in it
Patient data carries obligations that are genuinely enforced and that the people guarding it take seriously, for good reasons. Access runs through a process with a committee, a schedule and its own evidence requirements.
The practical consequence is that the governance calendar is the project calendar. A plan that shows a build phase and treats access as a prerequisite to be arranged is a plan that will slip by exactly the length of the committee cycle, which nobody put in the Gantt chart.
What works is submitting the access request in week one with the evaluation set in mind, rather than requesting build data first and evaluation data later. Two cycles instead of one is the most common avoidable delay in healthcare projects, and it comes from treating the evaluation set as something to sort out once the system works.
Clinicians are the hardest and most valuable reviewers
The adoption problem here has a particular character. Clinical staff are time-poor, professionally sceptical by training, and personally accountable for outcomes in a way that few other professions are.
That combination means a system gets one chance. A tool that is wrong in front of a consultant, in a way that would have mattered, does not get a second look, and word travels through a department faster than any rollout plan. Designing for visible uncertainty matters more here than raw quality: a system that flags what it is unsure about is trusted far more than one that is slightly more accurate and uniformly confident.
The compensating advantage is that clinicians are excellent at defining correctness. Getting three of them to argue about what a good summary contains produces a better evaluation set in an afternoon than any amount of specification, and it produces buy-in as a side effect.
The shorthand problem in the records
Clinical and administrative notes are written in a compressed shorthand that is precise to the team that uses it and opaque to everyone else. Abbreviations differ between departments in the same hospital, and the same three letters can mean different things on two floors.
This is not a data quality problem to be cleaned up. It is the domain, and a system that normalises it away loses the information clinicians rely on. What works is building the vocabulary explicitly, with the team, as part of stage one, and treating the resulting glossary as a deliverable in its own right. It usually outlives the project, because nobody had written it down before.
What to scope for a first healthcare project
Something administrative, high volume, with a human reading the output anyway, and with an existing record of correct examples. Coding support and correspondence triage both fit.
Budget the governance cycle explicitly rather than hoping. Ask the clinical governance team where the clinical boundary sits before designing. And find the ground truth, which is the coded record, and secure access to it in the same request as the build data rather than in a second one.
The five stages hold, with stage two stretched further than in any other sector on this site and stage four unusually decisive because of who the users are.
