Client
A UK regional NHS ambulance trust, covering emergency dispatch and hospital handover coordination across several dozen receiving hospitals
Sector
Health & Emergency Services
Engagement
Integration of computer-aided dispatch, vehicle telemetry and hospital handover queue data into a single live operational platform - phased delivery over three quarters.
What the client needed
The trust's computer-aided dispatch system told control room staff where every vehicle was and which call it was assigned to, but it had no reliable view of what happened once a crew reached a hospital. Each receiving hospital ran its own handover queue on its own systems - some digital, several still a clipboard at the ambulance bay - so the trust's only way to find out a crew had been stuck waiting to hand over a patient was a radio call from the crew itself, often after the delay had already eaten into the next shift's availability. By the time we were engaged, the trust's own performance data showed hospital handover delay had become the single largest driver of lost operational hours across the fleet, worse on some days than the calls themselves, and the trust had no way to see it building in real time or to reroute an incoming crew to a less congested hospital before the delay happened.
How we worked
- Built a live operational layer that pulls dispatch status, vehicle telemetry and crew shift data from the existing CAD system into one control room view, without replacing the CAD platform itself.
- Worked with each receiving hospital to bring its handover queue - whether a digital patient flow system or a manual log - into the same platform through a lightweight integration each site's own IT team could support.
- Introduced a predictive handover delay indicator that flags a hospital's queue as trending toward a long wait before an ambulance is dispatched there, based on live queue depth and the last hour's handover times at that site.
- Gave control room dispatchers the option to divert a non-critical incoming patient to a less congested hospital within clinical protocol, rather than defaulting to the nearest site regardless of queue state.
- Rolled out hospital by hospital, starting with the two sites carrying the trust's highest recorded handover delays, so the queue integration was proven under real pressure before wider connection.
- Trained control room staff and hospital patient flow teams on the shared view together, so both sides were working from the same number rather than reconciling two different pictures of the same queue after the fact.
Measured results
All figures verified with the client. Specific hospital, crew and patient detail withheld in line with our standard confidentiality terms.
- Average hours lost to hospital handover delay across the fleet fell by more than a third within two quarters of the first two hospital sites going live.
- Control room dispatchers report materially fewer instances of sending a crew to a hospital already deep into a handover backlog, now that queue state is visible before a dispatch decision is made rather than after.
- The trust's own performance data shows a measurable reduction in the number of ambulances held for more than an hour at a single site since the platform's rollout across its highest-delay hospitals.
- Crews report a noticeable drop in radio traffic spent relaying handover status back to control, freeing that channel for calls that actually need it.
- The trust's operational planning team now uses the platform's handover data directly in shift and fleet planning, replacing a manual monthly report that was several weeks out of date by the time it was reviewed.
"We used to find out about a handover backlog the same way everyone else did - a crew stuck outside A&E getting on the radio. Now the queue tells us before the ambulance even leaves the scene, and that's the difference between reacting to a bad afternoon and actually managing one."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Why we left the CAD system in place
The obvious pitch for a programme like this is a replacement platform - one new system covering dispatch, tracking and handover from the ground up. We didn't do that, and we'd make the same call again. The trust's computer-aided dispatch system was doing its core job well; the gap was entirely in what happened after a crew arrived at hospital, a problem no amount of dispatch-side rebuilding would have touched. Replacing a working system to fix a visibility gap elsewhere would have added years and risk to a programme that needed to show results inside a single winter. Building an operational layer on top of what already worked, rather than around it, is why the first two hospital sites were live within a single quarter rather than a full replacement cycle.
The clipboard wasn't the failure. The silence around it was.
Several receiving hospitals were still running their ambulance bay handover queue on paper when we started, and it would have been easy to treat that as the headline problem to fix. It wasn't, really - a well-run paper log at a single site can work fine locally. The actual failure was that none of those local systems, digital or paper, could tell the trust's control room anything before a crew called in stuck. We built the lightest integration each site could support specifically so hospitals with strong existing local process didn't have to rip it out - what mattered was getting that local state visible outside the building it lived in, not standardising how each site kept its own queue.
Starting with the worst two hospitals cost time we'd spend again
Connecting every receiving hospital at once would have looked faster on a programme plan and given us a cleaner headline date. We deliberately started with the two sites carrying the trust's worst recorded handover delays, on the basis that if the predictive queue indicator was going to misfire under real pressure, we wanted to find that out at the sites where a wrong signal would be most visible and most damaging, with close support in place, rather than discover it trust-wide once every hospital was relying on the number. That sequencing meant a longer full rollout than a single connection event would have needed. Given what a missed handover delay signal costs in lost ambulance hours, we'd choose the slower, risk-led order again.
Lessons learned
The first lesson was that a predictive operational signal earns trust from control room staff fastest when it's introduced at the sites with the worst existing problem, where the improvement is immediately visible, rather than rolled out evenly regardless of where the pain actually sits.
The second lesson was that a fragmented local process - paper log, digital system, or anything in between - is often not itself the thing worth fixing; the absence of any shared visibility across those local processes usually is.
The third lesson was that leaving a working core system alone and building the missing layer around it, rather than replacing it outright, is frequently the faster and lower-risk path to the outcome that actually matters to the client.
If your organisation is coordinating operational handoffs across systems that don't currently talk to each other, and delay is only visible after it's already cost you time, we would be glad to discuss what an integration programme like this might look like for you. Email sales@halfteck.com.