Start with the decision, not the model

A recognisable pattern has formed in healthcare AI. An organization commits to the category, assembles a group, and asks where AI could be applied. Candidate use cases are gathered, one is selected, a proof of concept is built, and it performs reasonably. Then it does not go into production, and eighteen months later it is difficult to explain what changed.

The failure is usually attributed to data quality, integration difficulty or change management. Those are real obstacles, but they are consequences. The determining choice was made at the start, when the project was framed as "apply AI" rather than "improve this decision".

Capability framing versus decision framing

A capability-framed project has no natural definition of success. It can demonstrate accuracy, but accuracy against a benchmark is not the same as changing what someone does. There is no threshold at which it becomes obvious the work should be adopted, so adoption depends on enthusiasm — which is not durable across a budget cycle.

A decision-framed project starts somewhere far less exciting: a specific decision, made repeatedly, currently made with worse information than is theoretically available. Who to review first. Which claim to work. Which patient is likely to miss an appointment. Which document needs a human read.

If you cannot name the person making the decision and what they would do differently, the model has nowhere to land.

Questions worth answering before building anything

• What decision is being made, how often, and by whom?
• What information does that person have today, and what is missing?
• What would they do differently if the missing information were available and trustworthy?
• What is the cost of being wrong, in each direction? False positives and false negatives are rarely symmetric in healthcare.
• Where in the existing workflow would this appear, and how many extra steps does it add?
• How will we know, six months later, whether it helped?

The fifth question eliminates a great many otherwise promising ideas, and it should. A model surfaced in a separate application that a clinician must remember to open will not be used. The prediction has to arrive inside the work.

Data readiness is a consequence, not a prerequisite

Organizations often decide they must fix their data before they can do anything with AI. This sounds disciplined and usually stalls. Data quality is not a global property — it is specific to a use. The fields required for one decision may be reliable while the estate as a whole is not.

Choosing the decision first makes the data question tractable: rather than assessing everything, you assess the handful of inputs that decision depends on. That is a scoped piece of work with an answer, and the answer is sometimes that the inputs will not support it — which is a useful finding delivered in weeks rather than a discovery made after a year.

Where generative approaches genuinely fit

Generative models are well matched to tasks involving unstructured text where a human remains in the loop and the cost of a poor draft is low: summarizing a long document set, drafting correspondence for review, extracting structure from documents that arrive in inconsistent formats. These are real efficiency gains and they are being realised now.

They are poorly matched to situations demanding deterministic output, complete auditability of reasoning, or autonomous action affecting patient care. The distinction is not permanent, but it is the current one, and being clear about which side a use case sits on is more valuable than enthusiasm about the category.

The organizations getting value are not the ones with the most ambitious programmes. They are the ones that picked a decision made a thousand times a week, improved the information behind it, put the result where the work already happens, and measured whether it made a difference.