Patient Flow Is a Queueing Problem Your Hospital Management System Refuses to Model
Bed managers work the phones because the data sits in six systems with no single view. Patient flow is a data platform problem, not a staffing one.
Walk into any acute hospital at 11am and find the bed manager. They will be on the phone.
They are calling ward sisters to ask which patients are actually going home today. They are calling pharmacy to find out whether the discharge medications are ready. They are calling portering to find out where the wheelchair is. They will do this for six hours, and by 17:00 they will have assembled, in their head and on a whiteboard, a picture of the hospital that was accurate at about 14:00.
Every fact they gathered by phone already existed in a database. That is the whole problem, and it is not a clinical problem or a staffing problem. It is a data platform problem, and it is unusually tractable.
Why the data is there and the answer is not#
A modern Hospital Management System knows an enormous amount. Admission and transfer events, order status, medication dispensing, results availability, theatre schedules, transport bookings. It records all of it faithfully.
What it does not do is answer the question the bed manager is actually asking, which is not “who is here” but “when will a bed become available, and what is stopping it.”
That question fails for three structural reasons.
The data is per-system, and the question is cross-system. Discharge readiness depends on the clinical decision (in the EPR), the medications (in pharmacy), the transport (in a logistics tool), and sometimes a social care assessment (in a completely different organisation’s system). No single system can see the chain, so no single system can tell you where it is stuck.
Everything is stored as state, not as events. The record says the patient’s status is “for discharge”. It rarely says when that status changed, and almost never retains the sequence of prior statuses. Without the event history you cannot compute how long anything took, which means you cannot forecast how long the next one will take. This is the single most consequential design mistake in operational healthcare software, and it is nearly universal.
Reporting is built for the month, not the hour. The data warehouse runs overnight, produces excellent monthly performance reports, and is completely useless at 11am. It answers “how did we do” for a room full of executives. Nobody built the thing that answers “what is happening” for the person who can change it.
The architecture that fixes it#
We have built this several times now. The shape is consistent and it is not a large project — three to four months in a hospital of reasonable size, and considerably less than that if the source systems have usable interfaces.
Emit events, do not poll state. Every status change becomes a timestamped event on a stream: admitted, clinically_ready_for_discharge, tto_prescribed, tto_dispensed, transport_booked, left_ward, bed_cleaned, bed_available. HL7v2 ADT messages already carry a good deal of this and most hospitals are already generating them; frequently the work is capturing a feed that currently goes nowhere useful.
Model the pathway as a state machine with durations. Once you have events, every patient’s journey is a sequence of transitions with measurable dwell times. Now you can answer the question that was previously unanswerable: for patients like this one, on this ward, on a Thursday, the median time from “clinically ready” to “bed available” is 4.2 hours, and the ninetieth percentile is eleven.
Put it in a store that answers in under a second. This is where the operational and analytical requirements genuinely diverge. A bed manager will not use a tool that takes eight seconds to filter. Our default here is ClickHouse behind the event stream — it holds the raw event grain and still returns ward-level aggregates fast enough that people explore rather than request. If the answer is slow, the whiteboard wins and your project failed.
Surface the blocker, not the status. This is the part that determines adoption. A dashboard showing “14 patients for discharge” is information. A list showing “14 patients for discharge; 6 waiting on pharmacy over two hours; 3 waiting on transport; 2 waiting on a social care assessment since yesterday” is an instruction. One gets looked at, the other gets used.
The forecast is simpler than people expect#
Once dwell-time distributions exist, the predictive layer that changes behaviour is not sophisticated.
Take current occupancy, expected admissions from the ED arrival pattern and the elective list, and the discharge pipeline weighted by empirical stage-completion times. Project forward four hours. That gives you a bed position with a confidence range, refreshed every few minutes.
That is queueing theory and basic survival analysis, not deep learning, and it is deployable in weeks. It also demonstrably outperforms the informal method, because the informal method has no memory of how long pharmacy actually takes on a Friday afternoon.
Add machine learning later, where it earns its place: predicting individual length of stay at admission, flagging patients whose pathway is deviating from their cohort, forecasting no-shows against the elective list. Those are useful. They are not the first thing to build, and teams that start there usually produce a model nobody trusts because the operational baseline it should have been compared against never existed.
The two failure modes#
Building the dashboard before the events. Teams frequently start with the visualisation because it is the visible deliverable and it demos well. Without the event history underneath, the dashboard shows current state — which is exactly what the existing screens already show, so nothing changes and the project is judged a failure. Build the event spine first, even though nobody can see it.
Ignoring the last mile. A tool that requires a bed manager to open a separate application, log in again, and check it periodically will lose to the whiteboard. It has to be on a wall display in the operations room, in the ward’s existing interface, and pushing a notification when a blocker crosses a threshold. The integration into existing workflow is not polish; it is the difference between deployment and adoption.
Why this is worth doing#
Delayed discharge is the most expensive queue in a hospital. A bed occupied by a patient who is clinically ready to leave is a bed unavailable to an admission, which backs up the ED, which breaches waiting standards, which is measured and penalised. The financial and clinical case is direct.
And unlike most healthcare technology projects, this one does not require changing clinical practice, purchasing new hardware, or asking anyone to enter additional data. Every input already exists. What is missing is the join, the history, and a surface that shows the blocker.
That is an engineering problem. Those, we can fix.
If your bed managers are on the phone, your data is fine and your architecture is not. We build the event spine that turns six systems into one answer. Tell us where your patients get stuck.