Bed Turnover and Environmental Services Dispatch
A discharge raises the room's cleaning request, tracks it against a target time and tells the bed board the moment the room is ready.
These images are illustrations of the concept, not screenshots of the actual product.
Overview
This concept is a FluidGrids workflow for hospital bed turnover, the stretch between a patient's discharge and the moment the room is clean and ready for the next admission. In a hospital, that gap shapes how long emergency department patients wait for a bed on a ward. The design envisions a workflow that starts from the discharge itself, raises the environmental services cleaning request, watches the clean against a target time and reports each bed's state to a live bed board.
Bed turnover often runs on phone calls. The unit rings environmental services, the bed manager rings the unit to ask whether the room is ready, and a clean that stalls is noticed only when someone goes looking. Without one view of which rooms are waiting, being cleaned or overdue, bed managers chase answers by phone while emergency department holds build up.
The illustration shows a live run of a Bed Turnover workflow for one sample unit, marked Active, following a single bed through six steps with a progress bar and View runs and Stop controls. An ADT discharge webhook, fed by the hospital's interface engine, starts the run. A Create Clean Request step raises the job with environmental services at a priority that reflects emergency department holds, and a Wait for Clean Complete step counts elapsed minutes against its target, with a branch that escalates to the house supervisor's channel if the clean runs past an hour. Execution logs below the canvas record the steps run so far, including the cleaning request reference and a clean status update that arrived while the run waits. Beside the canvas, a Beds in flight panel lists beds across all units with their unit, discharge time, clean status and elapsed time, from requested and in progress to ready, or overdue and escalated.
The fifth step is a BigConsole DataSink node that upserts bed status, and the Beds in flight panel is labeled as feeding a BigConsole live bed board. The design intent is that FluidGrids owns the sequence and its timing, while BigConsole is designed to receive every bed state change and show pending, in-progress and ready beds to bed managers and the emergency department without anyone calling the unit. And because the turnover is an ordinary FluidGrids workflow, the design lets a stuck bed be traced to its own run, step and log line.
What this concept shows
- A webhook trigger that receives discharge events forwarded by the hospital's interface engine, with the unit and bed in the payload
- A cleaning request raised with environmental services at a priority that reflects emergency department holds
- A wait step that tracks each clean against a target time, showing minutes elapsed on the running node
- An escalation branch that alerts the house supervisor's channel when a clean runs past an hour
- A BigConsole DataSink step that upserts each bed's status for a live bed board
- A Beds in flight panel across all units with bed, unit, discharge time, clean status and elapsed minutes
- Clean statuses for requested, in progress, ready, and overdue beds that have been escalated
- Live execution logs with a level filter, auto-scroll, pause and download controls
How it works
- A discharge reaches the FluidGrids webhook through the hospital's interface engine, carrying the unit and bed.
- The workflow raises the cleaning request with environmental services, setting its priority from emergency department holds.
- It waits for the clean-complete update against the target time, logging the status updates that arrive in the meantime.
- If the clean runs past the escalation threshold, the workflow alerts the house supervisor's channel.
- Each bed state change is upserted to the BigConsole bed status datasink, which is designed to keep the live bed board current.
- Bed managers watch Beds in flight across units and follow a single bed's run through its steps and log lines.
Who it's for
- Bed managers and patient flow coordinators
- Environmental services managers
- House supervisors and nursing leadership
- Hospital operations and integration teams
Illustrations
1 illustration of this concept. Select one to view it full size.
Live Bed Turnover Run with Beds in Flight
The illustration shows a Bed Turnover workflow for a sample unit, marked Active, in a live run for one bed, with a progress bar at three of six steps and View runs and Stop buttons. On the canvas, an ADT discharge webhook from the interface engine and a Create Clean Request step for environmental services, set to an emergency department hold priority, both show success. A Wait for Clean Complete node is running with its target and elapsed minutes, and branches to a pending step that escalates past 60 minutes to the house supervisor's channel. A BigConsole DataSink step that upserts bed status and an End node are pending. The Beds in flight panel, labeled as feeding a BigConsole live bed board, lists sample beds with unit, discharge time, clean status and elapsed time, one of them overdue and escalated. Execution logs below show timestamped entries for the steps run so far and a clean status update, with a level filter, auto-scroll, pause and download controls.
Topics
- hospital bed turnover automation
- environmental services dispatch workflow
- bed management workflow
- discharge to clean bed tracking
- ADT discharge webhook
- live bed board
- hospital patient flow automation
- emergency department bed holds
- EVS cleaning request escalation
- healthcare workflow automation
Related concepts
Run History, Inspection and Recovery
Follow every workflow execution node by node, then retry, resume or approve runs from a desktop or a phone.
5 illustrations
Datasinks and Live Dashboards
End a workflow with a datasink node and its output flows into a live dashboard that refreshes on a schedule.
2 illustrations
Triggers, Schedules and Webhooks
Decide what starts a workflow — a cron schedule, an incoming request, an API call or a chat message — and keep every trigger under control.
3 illustrations
Visual Workflow Builder
Draw an automation on a canvas - trigger, branches, connectors and merges - then watch a test run light the same picture up step by step.
4 illustrations
Part of an industry solution
This concept appears in a cross-product solution on burdenoff.com — see how it works alongside other Burdenoff products to solve a problem in that industry.
