Patient Flow Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a capacity project end as a dashboard nobody acts on?

Because a dashboard is the easiest thing to specify and the easiest thing to demonstrate. It shows well in a steering meeting, it does not require anyone to change how they work, and it can be delivered without touching the departments whose behaviour actually determines flow.

Capacity management is a morning discipline that presents as an afternoon crisis. At 8am the information exists to know that a particular unit will be two beds short at 3pm, that three discharges need transport slots booked now, and that a placement decision should be made before the operating list starts. By the time the board turns red, the useful window has closed.

Make the first release something that produces actions with owners, not a display. A morning capacity brief listing a small number of specific tasks, each with a named person, outperforms a perfect real time board and does not require a prediction model to be useful. It also builds the operational habit everything else depends on: if the brief is worked daily for two months, the organisation will accept prediction and placement recommendations later. If the first thing shipped is a wall board, the project has trained everyone to look at software rather than act on it, and that is very hard to reverse.

Ask any prospective developer what they will ship in the first eight weeks. If the answer is a dashboard, push back.

What goes wrong when you unify bed and unit definitions across hospitals?

In a system built through acquisition, no two hospitals define a unit the same way, and this surfaces as soon as anyone tries to compare or balance across them.

• Beds that are not beds. Hallway positions, overflow spaces, observation chairs and procedural recovery bays all appear in bed lists at one hospital and not at another. Counted inconsistently, your occupancy percentage is not comparable and your load balancing is fiction.
• Licensed versus staffed versus available. These are three different numbers and they get used interchangeably in conversation. Model them separately or every capacity figure becomes an argument about definitions.
• Unit names that mean different things. Step down at one hospital is a level of care, at another it is a physical location, and at a third it is both depending on staffing that shift.
• Blocked and closed beds with no reason code. A bed closed for renovation, closed for staffing and closed for infection control need entirely different responses, and migrations that carry only a blocked flag lose the distinction permanently.
• Historical records keyed to renamed units. Units get renumbered during a rebuild, and last year's turnaround and length of stay history stops resolving. Keep a stable internal key with an alias history.

Resolve definitions before any cross hospital metric is published, because the first published number that a hospital's leadership does not recognise will cost you their participation.

Why do ADT feeds and EVS integrations drift after go live?

The admission, discharge and transfer feed is the spine of the system, and it degrades quietly rather than failing loudly.

New unit and bed codes get created in the electronic health record without anyone telling the flow team, so patients appear in locations the capacity model does not recognise and drop out of the count. Message behaviour changes after an upgrade. A hospital joins and its feed uses a different convention for the same event. Because the flow system keeps running on the events it does understand, nothing alerts.

Environmental services and transport integrations drift for a more human reason. Those requests come from a mobile workflow used by staff under time pressure, and if the workflow adds a step it gets bypassed. A bed marked clean from the nurses' station rather than from the room is faster for the person doing it and worthless to everybody else.

Reconcile rather than trust. Run a daily comparison between the census in the electronic health record and the census in the flow model, and alert on unrecognised location codes rather than discarding them. For environmental services and transport, monitor for workflow patterns that indicate bypass, such as completion events arriving with implausible durations, and treat them as a design signal rather than a compliance issue. If staff are bypassing a step, the step is wrong.

What happens when transfer centre acceptances and override capture are not covered?

Three gaps convert a well built system into one that gets overridden and then ignored.

The first is bed status truth. A bed becomes ready when someone says it is ready, and that person is measured on how quickly beds become ready. So beds get marked clean while cleaning is still in progress and marked occupied hours after the patient left. Every downstream calculation inherits the error, which is why reported turnaround improves while the experience does not. Corroborate instead of trusting: use location badges or door sensors where they exist, and secondary signals that already exist where they do not, such as the discharge order time, the last medication administration, the last documented vital sign and transport completion. A bed reported clean four minutes after the patient left with no cleaning presence recorded is an exception to surface, not a fast turnaround to celebrate. The point is not to police staff, it is that a capacity model built on optimistic timestamps produces plans that fail at 2pm and nobody understands why.

The second is transfer centre acceptance. A transfer centre accepting patients from referring hospitals is a revenue engine and a capacity consumer at once, and the two decisions are usually made by different people with different information. Accepted and in transit is a real occupancy state that most systems do not track at all, which is precisely where afternoon surprises come from. Put projected capacity, including what has already been accepted and not yet arrived, in front of the acceptance decision at the moment it is made.

The third is override capture. Placement rules include service line cohorting, isolation constraints, telemetry availability, room configuration, tonight's staffing ratios and soft rules that exist because of an incident three years ago. The rules that matter most usually will not fit a configuration screen, so the supervisor overrides the system, and once she overrides it routinely the system becomes a record of decisions rather than a participant in them. Make every recommendation explain its reasoning so it can be argued with, and capture the override reason in one tap. Within a month you will have documented the real placement policy, which most hospitals have never had written down.

Should you build custom or configure what you already own?

Some hospitals should stop here. If you are a single hospital on Epic, turn on Grand Central. It gives you event flow without an interface project and covers the fundamentals, and if your real problem is that physicians write discharge orders at noon, no software of any kind will fix that. Solve the discharge process first and you may not need anything else.

If you need mature bed management and transport and your placement policy is reasonably conventional, TeleTracking effectively created this category and its modules are proven. If your binding constraint is scheduled capacity in operating rooms or infusion chairs rather than inpatient beds, LeanTaaS iQueue addresses a genuinely different mathematical problem and addresses it well. Qventus is aimed at nudging specific workflows. These are serious products and the right answer more often than agencies admit.

A specific caution: if you have already bought a capacity product and nobody uses it, diagnose the cause before buying or building anything. That outcome is almost always a workflow fit problem rather than a feature gap, and a second product will reproduce it. The usual causes are placement rules that cannot be expressed in the configuration, a bed status model nobody believes, and output arriving as a display rather than as tasks with owners.

Build when the constraint is coordination across a system rather than visibility within one hospital: several hospitals with different electronic health records and different placement policies, a transfer centre making acceptance decisions without capacity context, or a network that wants genuine load balancing rather than each hospital optimising alone.

How do hidden costs get into the quote?

• Hospital count and definition reconciliation. Agreeing what a bed and a unit mean across sites is governance work involving people who do not report to the project, and it gates everything downstream.
• Real time location hardware. Corroborated bed status is a physical deployment as much as a software one, with badges, readers, maintenance and a battery replacement programme.
• Multiple record instances. Each additional electronic health record is another feed, another set of conventions and another upgrade calendar you do not control.
• Perioperative scope. Operating room and procedural scheduling is a distinct optimisation problem, and adding it mid project reliably doubles a phase.
• The daily brief owner. Somebody has to run the morning brief and chase the actions. Costing the software without costing that role is the most common way these projects quietly stop working in month four.

What separates a build that works from one that fails here?

Ask how they will know a bed is actually clean. If the answer is that the environmental services system says so, they will rebuild the optimistic model you already have and the numbers will improve while the emergency department keeps boarding.

Ask how a placement recommendation is explained. A ranked list without reasoning gets overridden and then ignored, and the override is where the real policy lives, so capture it in one tap.

Ask how discharge prediction will be trained. It has to learn from your own history, because discharge behaviour is intensely local: surgical services that round early and discharge before nine, a medicine service that discharges after attending rounds, post acute placements gated by two facilities whose acceptance patterns your case managers could describe from memory. None of that transfers from another hospital's model. Predict the barrier rather than only the date, and publish prediction accuracy openly, because a visible model gets trusted and a hidden one gets ignored within a month. Then ask what ships in the first eight weeks, and require it to produce actions with owners.

Finally, settle ownership of the code, the infrastructure and the accumulated flow data before kickoff. At Digital Heroes the client owns the repository from the first commit and the system runs in the client's own accounts. Years of your own discharge, placement and turnaround history is what makes any prediction worth having, and it should never sit inside a product you cannot query directly.