Ambulance diversion remains one of the clearest signals that an emergency department has reached its breaking point. But behind every diverted unit lies an information gap: bed status is captured in a nursing whiteboard, an EHR module, or a hallway huddle, then transmitted by phone. This case study examines how a large academic health system eliminated that gap with FHIR Subscriptions for real-time ED bed tracking, using a Pub/Sub model that pushed bed-status events to dispatch teams, charge nurses, and capacity dashboards the moment they happened.
Why Real-Time Bed Tracking Is an Interoperability Problem
An ED bed is not binary. It can be occupied, empty but dirty, awaiting environmental services, in a deep-cleaning hold, or physically unusable because of a staffing shortage. Most hospitals capture these states in a patchwork of sources: an ADC system, a transfer command log, a nurse assignment grid, and the electronic whiteboard inside each zone. The bed count on any given screen is usually several minutes old and frequently contradicts what a charge nurse sees in the hallway.
For years, integration engineers have wired these sources together with HL7 v2 ADT messages and scheduled queries. ADT messaging excels at tracking patient admissions and transfers, but it does not natively model the lifecycle of a bed. Periodic FHIR polling improves on this because it uses a standardized resource model, but it is still fundamentally pull-based. The ED is an event-driven environment. When a trauma team rapidly vacates three beds at 2:00 a.m., those changes need to propagate in seconds, not on the next 15-minute job cycle.
Case Study: A 1,450-Bed Health System Rebuilds Its ED Capacity Signal
The organization we examined here—a three-campus academic health system—was facing 1,840 hours of ambulance diversion per year and an average ambulance offload time of 42 minutes. Its existing interface mapped HL7 v2 ADT messages into a SQL table, and a custom dashboard queried that table every 15 minutes. The result was a familiar pattern: a dashboard showed an unoccupied bed that was still being turned over, while the actual staffing hole in another pod was invisible for another polling cycle.
The project began with two explicit goals. First, the system would treat bed status as a first-class FHIR resource, not a derived report. Second, no downstream consumer would poll more than once every five minutes; capacity information would arrive as a push notification through a FHIR-based Pub/Sub model. Those decisions shaped every subsequent design choice.
The FHIR Pub/Sub Architecture Behind Live Bed Updates
The system ran on FHIR R4, so the team implemented the R5 Subscriptions model using the Subscriptions R5 Backport Implementation Guide. The backport defines a SubscriptionTopic resource, a SubscriptionStatus notification envelope, and a RESTful subscription lifecycle that works on R4 servers. This allowed the hospitals to benefit from the R5 design without waiting for a full EHR platform upgrade.
Modeling Bed Status with Location and Encounter
Bed state was represented as a composition of three resources:
- Location: each physical bed is a Location resource with an
operationalStatusthat transitions between unoccupied, occupied, housekeeping, and offline. The logical pod and zone are represented in the Location hierarchy. - Encounter: when a patient is placed in a bed, the Encounter’s
locationfield is updated with the specific bed Location and the time of placement. Bed assignment and transfer events flow directly from the activity in the ED. - Observation: a lightweight profile called
BedTurnoverStatuscarries the housekeeping phase—dirty, cleaning-in-progress, clean-hold, ready. This captured the operational state that the official bed-management system did not express.
Subscribing to Change Events
The integration layer exposed several SubscriptionTopics: encounter-bed-assigned, location-operational-status-changed, and bed-turnover-phase-completed. Each topic applied a FHIRPath filter so that only relevant change events were transmitted. The subscription endpoint delivered a standardized notification bundle to an internal Kafka topic, where downstream consumers—the capacity dashboard, the nurse assignment board, and a secure EMS dispatch feed—could act on it independently.
A key decision was publishing an event only when the business state actually changed. Re-running the same operational status did not create a new notification. This prevented downstream systems from double-counting bed availability and kept the consumer logic predicated on event semantics rather than repeated raw updates.
The Notification Handshake and Delivery Guarantees
Reliability made or broke this implementation. The backport specification includes a lifecycle from requested to active to error, plus heartbeat periods that let the subscriber detect a dead connection. The team configured a 15-second heartbeat, so any gap in the connection triggered an immediate escalation to the local integration support team.
For messages that did not arrive, the subscription used a dead-letter queue and an idempotency key on each notification event. If the same bed status notification was retried, the receiving capacity calculator reapplied the last known state rather than adding an extra available bed. The team also set a maxCount on the subscription topic to control bundling during surge periods, because a sudden influx of traumas could generate fifty bed events in under a minute.
Operational Results: Diversion Hours Drop by 88%
Within 90 days of going live, the new subscription-based feed replaced the polling dashboard. The most visible improvement was speed: the time from a charge nurse marking a bed “ready” to the bed appearing on the EMS dispatch screen dropped from a median of 9 minutes to under 5 seconds. Real-time ED bed tracking became the backbone of the system’s capacity command center.
- Ambulance diversion hours fell from 1,840 to 210 hours annually—an 88.6% reduction.
- Average ambulance offload time decreased from 42 minutes to 23 minutes.
- The “phantom bed” problem—where different systems disagreed on bed availability—fell by roughly 75%.
- Bed turnaround visibility improved enough that environmental services could be dispatched proactively, rather than after a nurse made a follow-up phone call.
FHIR Subscriptions did not replace human judgment. Charge nurses still made the final call on whether a bed was safe for the next patient. But the subscription model compressed the cycle time between a clinical action and the information reaching every person who depended on it.
Lessons for Health Systems Planning a Similar Deployment
The case study offers several takeaways for organizations evaluating the same approach:
- Build the event catalog first. The hardest part was not configuring a subscription topic; it was agreeing that bed turnover is a distinct business event from patient arrival and departure.
- Treat the backport as a first-class standard. The R4-to-R5 Subscription backport is production-ready, but it still requires careful testing against the EHR’s notification delivery semantics, especially around retry behavior.
- Clarify resource ownership. Bed status proved to be an operational workflow state, not simply a clinical fact. The team had to formalize which system was authoritative for each transition and when a manual over-ride was permitted.
- Plan for notification bursts. During a multi-vehicle accident or an internal disaster, bed events arrive in clusters. Subscription topics must support batching, and consumers must be idempotent.
- Bring EMS dispatch into the design early. The organizations that benefited most were those that gave paramedics a live, mobile-friendly status view instead of a telephone operator speaking to a charge nurse.
For the health system in this case, FHIR Subscriptions transformed the ED from a stale pull-based board into a real-time event signal. The same pattern—standardized resources, topic-based subscriptions, and a push-based notification model—is applicable well beyond bed tracking. Surgery scheduling, lab capacity, and inpatient discharge logistics all face the same fundamental problem of acting on information that changes faster than any poller can keep up with.
