AI Care Pathways: What Clinical Automation Actually Means for NHS Trusts

Every Trust has now sat through the demo. A clinician describes a patient, the AI suggests a pathway, the timeline populates, the referral drafts itself, and the risk score updates in real time. It looks like the future. It usually is a good product. And then someone in the room, normally the IT Lead or the IG Lead, asks the question that ends the magic: "Where is it getting the data from?"

That question is the whole subject. AI care pathways are real, they are coming, and some of them will be genuinely useful. But the conversation around them tends to focus on the model, the interface, and the clinical logic, which are the parts that demo well. The part that decides whether any of it works inside an actual Trust sits underneath all of that, in the integration layer, where patient data is fragmented across systems that were never designed to talk to a pathway engine.

This piece is for the people who get asked that question and have to answer it honestly: the IT Lead, the Digital Lead, the CTO, the IG Lead. It is a map of what AI care pathways actually are, where they earn their place, and the thing you need in place before you automate anything clinical.

The demo that always impresses, and the question nobody asks

The demo works because it runs on clean, complete, pre-staged data. The patient record is whole. The medications list is current. The referral history is structured. Everything the pathway needs is sitting in one place, formatted exactly the way the model expects.

Your Trust does not look like that. Demographics live in PDS. The clinical record sits in your EPR. Referrals move through e-RS. Prescriptions flow via EPS. Workforce and on-call data live in ESR. Some of it speaks HL7v2, some of it speaks FHIR R4, some of it speaks a flat file that arrives overnight and occasionally does not. The patient the AI is reasoning about is not one record. They are a dozen partial records, in a dozen formats, with timing offsets between them.

So the honest version of the demo question is not "is the AI good?" It usually is. The honest question is "can this AI see a complete, current, trustworthy picture of the patient inside our environment?" Most of the time, on day one, the answer is no, and that gap is an integration problem, not an AI one.

What an AI care pathway actually is

Strip away the framing and an AI care pathway is three things stacked together.

There is a clinical model: the logic that decides what should happen next for a patient given their condition, history, and current state. Sometimes that is a guideline encoded as rules, sometimes it is a trained model producing risk scores or next-best-action suggestions, increasingly it is a mix.

There is an orchestration layer: the engine that moves the patient through steps, triggers actions, drafts referrals, books follow-ups, and escalates when something crosses a threshold. This is the part that turns a recommendation into a workflow.

And there is a data layer: everything the first two depend on. The pathway can only reason about, and act on, the data it can actually reach, in a form it can actually use, at the moment it needs it.

The market sells you the first two. The third is the one you already own, mostly in a state that is not ready. When an AI care pathway underperforms in production, it is almost never because the clinical model was wrong. It is because the data layer fed it something incomplete, stale, or in the wrong shape, and the pathway acted on it anyway.

Where clinical automation genuinely earns its place

It is worth being clear that the scepticism above is not an argument against any of this. There are places where AI-driven clinical automation already earns its keep, and they tend to share a pattern: high volume, repetitive judgement, and a clear safety net.

Think about referral triage. A steady stream of inbound referrals, each needing the same set of checks, prioritisation, and routing. An AI pathway that drafts the triage decision and flags the outliers for a human does not replace clinical judgement. It removes the part of the work that was never judgement to begin with: the reading, sorting, and routing.

Or think about long-term condition monitoring. A diabetic cohort where most patients are stable and a few are quietly deteriorating. A pathway that watches the incoming data and surfaces the few who need attention is doing something a human team genuinely cannot do at scale, which is keep continuous watch on thousands of stable patients without losing the one who is not.

The common thread is that these work because a human stays in the loop on anything that matters, and the automation handles the volume underneath. The value is not the AI making the decision. It is the AI making sure the right decision reaches the right person at the right time, which is, again, a data movement problem as much as a clinical one.

Why the model isn't the hard part

Here is the uncomfortable truth for anyone evaluating these tools. The clinical model is increasingly a commodity. Good ones exist, they are improving fast, and the gap between vendors on raw model quality is narrowing.

What does not commoditise is getting a complete, current, governed view of the patient out of your specific Trust's systems and into the pathway in real time, and getting the pathway's actions back out into the systems where care actually happens. A referral the AI drafts has to land in e-RS. A medication change has to flow through EPS. A flag has to appear in the EPR the clinician is actually looking at, not a separate dashboard nobody opens. If the integration does not close that loop, the pathway becomes another screen to check, and clinicians stop checking it.

This is the part that does not show up in the procurement conversation, because it is invisible in the demo and it is specific to your estate. Two Trusts can buy the identical AI care pathway and get completely different results, and the difference will be almost entirely down to how cleanly each one's data flows in and out.

The data layer is the real care pathway

If you take one thing from this piece, take this: the AI care pathway your Trust experiences is not the one in the brochure. It is the one your integration layer can actually feed and act on.

That reframes the buying decision. Before evaluating which AI pathway to adopt, the more useful question is whether your Trust can reliably assemble a complete, current patient picture from PDS, the EPR, e-RS, EPS and the rest, in a normalised form, and write actions back to those systems with a full audit trail. If you can do that, most decent AI pathways will work for you. If you cannot, none of them will, regardless of how good the model is.

That also means the foundational work is reusable in a way the AI layer is not. A clean, governed integration layer that can compose a patient view and orchestrate actions across NHS systems is the thing every AI care pathway will sit on top of, and the thing your next one will sit on too. The model you choose this year may be replaced in two. The integration pattern underneath it will outlast several model generations.

This is the pattern WeHub's workflow approach is built around: treat the integration and orchestration layer as the durable asset, and let the clinical models plug into it rather than the other way round. But the principle holds regardless of tooling. Build the layer that makes any AI pathway viable, and you have made a decision that does not expire.

What good looks like before you automate anything

A few things tend to be true in Trusts that get value from AI care pathways rather than a stalled pilot.

1. They can compose a complete patient view on demand. Demographics, clinical record, referrals, prescriptions and relevant workforce context can be assembled into one normalised picture, not stitched together by hand for a demo.

2. The integration writes back, not just reads. Pathway actions land in the systems where care happens, e-RS, EPS, the EPR, so clinicians never have to leave their workflow to act on what the AI suggested.

3. Every step is governed and auditable. What data went in, what the pathway did with it, and what was written back is logged at the field level. DSPT and clinical safety conversations, including DCB 0129 and DCB 0160, are far shorter when this exists from the start rather than being retrofitted.

4. A human stays in the loop where it matters. The automation handles volume and surfaces exceptions. It does not quietly make consequential clinical decisions without a clinician seeing them.

None of those four are AI features. They are integration and governance properties. Which is the point: the readiness work for AI care pathways is work you can start now, before you have chosen a single model.

The bottom line

AI care pathways are not hype, and they are not a finished product you can drop into a Trust. They are a clinical model and an orchestration engine sitting on top of a data layer you already own, and the data layer is the part that decides whether they work.

So the first move is not choosing a vendor. It is answering one question honestly with your team this quarter: can we assemble a complete, current, governed view of a patient from our core NHS systems, and write actions back to them with a full audit trail? If yes, you are ready to evaluate AI pathways on their merits. If no, that gap is the project, and closing it is what makes every AI care pathway you ever consider actually work.