Care Pathway Automation: Why NHS Trusts Are Moving From Documenting Pathways to Running Them

The discharge summary that took 14 days

The discharge summary sits in a queue for 14 days. The patient is back in A&E within 10. The GP, who was supposed to follow up the medication change, never sees the letter because it is still in a "ready to send" tray waiting for a human click.

This is not an exotic failure mode. It is what a working NHS care pathway often looks like when the pathway is documented but not actually running. The map exists. The flow exists. The systems are connected, mostly. But the pathway itself, the thing that is supposed to move a patient from one clinical decision to the next, depends on someone remembering to click.

Care pathway automation is the shift from documenting how care should happen to running it. For NHS IT Leads, Digital Programme Managers, and CTOs, the change is already underway. The question is no longer whether to automate pathways, but which pathways to start with, and what an automation that actually holds up looks like.

What care pathway automation actually means

A care pathway is the sequence of clinical and operational steps a patient moves through for a given condition: referral, assessment, treatment, follow-up, discharge. Most Trusts have these documented somewhere. Many have flowcharts on the intranet. A few have them embedded in the EPR.

Care pathway automation means the pathway runs itself between the systems that already exist. A referral arriving via e-RS triggers a demographics check against PDS, a slot search in the appointment system, and a pre-assessment questionnaire sent to the patient by SMS. A "did not attend" event triggers a re-booking workflow and a flag to the clinical team. A discharge written in the EPR triggers a structured letter via the Spine to the registered GP, a medication update to the pharmacy system, and a follow-up reminder set against the patient record.

The pathway is the same. What changes is the number of human clicks needed to keep it moving. Done well, automation does not replace clinical decision-making. It removes the operational drag between decisions.

Why care pathways break in the first place

If you have spent any time in a Trust digital programme, you already know the answer: pathways break at the seams between systems. The clinical decision is made in one place. The patient demographics live in another. The appointment is booked somewhere else. The letter is generated by a fourth system. The follow-up is tracked, if at all, in a spreadsheet owned by a service manager.

Every seam is a place where a human has to bridge two systems by reading from one and typing into another, or by sending an email, or by remembering to act next Tuesday. Each handoff is small. The cumulative drag across a pathway with twenty steps and six systems is the reason two week wait performance never quite holds, and why discharge to GP times look worse than they should.

The honest framing is this: NHS Trusts do not have a clinical pathway problem. They have an integration problem dressed up as a clinical pathway problem. Which is why the answer increasingly looks less like another EPR module and more like clinical pathway automation built on the integration layer.

The shift: from documenting pathways to running them

The first generation of digital care pathways technology was about visibility. Trusts mapped the pathway, displayed it in a dashboard, and produced compliance reports. Useful, but it did not move the patient through faster. The map of the pathway is not the pathway.

The current generation, what is increasingly called digital care pathway automation, treats the pathway as an executable workflow. Each step is a rule. Each transition is an event. The pathway listens to the systems it depends on (ESR for staffing, e-RS for referrals, EPS for prescriptions, the local EPR for clinical events) and responds without waiting for a human to notice.

This is the part that matters for IT leaders. The technical pattern is not new. It is the same pattern used in any modern operational system: events, rules, orchestration, audit. What is new is that the pattern is finally arriving inside NHS pathways, where for years the integration was either absent or too expensive to maintain.

What good care pathway automation looks like

Across the Trusts already running automated care pathways in production, four characteristics show up consistently.

1. Pathways are event-driven, not schedule-driven. A nightly batch job that checks for discharges and triggers letters the next morning is not automation, it is a delay with a process around it. Real automation responds to the event when it happens. A discharge written into the EPR at 16:42 should trigger the downstream actions before the consultant has left the ward.

2. Every transition is logged at the field level. When a pathway step fires, the audit trail captures what came in, what was decided, what was sent, and to which system. This is not an extra. It is the only way DSPT and DCB 0129/0160 conversations stay manageable when automated workflows touch clinical decisions.

3. Human checkpoints are deliberate, not accidental. Some steps in a pathway should pause for clinical review. A medication change needs a clinician's sign off. A safeguarding flag needs a human read. The pathway should pause exactly there and nowhere else. The current state in most Trusts is the opposite: human checkpoints exist by accident wherever the integration ran out of budget.

4. The pathway is owned by a team, not a vendor. AI-powered care pathways and clinical pathway automation tools that arrive as black boxes from a single supplier tend to age badly. The pathways that hold up over five years are the ones a Trust's own digital team can modify, version, and audit without raising a change request with an external party.

Where to start

For Trusts beginning to think seriously about clinical pathway automation tools, the temptation is to pick the most complex pathway, usually cancer or stroke, and start there because the impact is largest. This is almost always the wrong move.

Start with a pathway where the clinical complexity is low and the operational drag is high. Outpatient follow-up scheduling. Discharge to GP letters. Pre-assessment questionnaires. Recall lists for routine screening. These are the pathways where the steps are well understood, the clinical risk in automating is low, and the operational cost of the current state is high.

Get one of those working end to end. Prove the pattern. Then move to the more complex pathways with the integration layer, the audit trail, and the team capability already in place.

The bottom line

Care pathway automation is not a single product or a single project. It is a shift in how Trusts think about the operational layer underneath clinical care. The pathway stops being a document and starts being a system that runs.

If you are an IT Lead or Digital Programme Manager evaluating where to put the next year's integration spend, the most useful exercise this week is shorter than it sounds. Pick one pathway in your Trust that depends on humans clicking to keep it moving. Map every system involved, every handoff, every delay. The case for automation will be visible in the map itself, and the place to start will be the obvious one.