The Real-Time
Clinical Data Gap

This series is about infrastructure. But unlike most infrastructure conversations, this one has a clinical dimension that changes the stakes. When a trading platform's streaming layer fails, users experience bad UX. When a remote patient monitoring platform's streaming layer fails, care teams experience delayed alerts. The difference matters.

We're going to spend three parts going deep on real-time data delivery for digital health platforms - the failure modes, the architecture, and the decision framework. The same rigour we applied to the Finance series, applied to a domain where the consequences of getting it wrong are different in kind.

Part 1 (you're reading it): The failure modes - why RPM platforms fail in hospital environments and what clinical alert latency actually means.
Part 2: The MQTT-to-dashboard bridge - what a production-grade real-time architecture for health tech actually looks like.
Part 3: Build vs. buy for health IT - the framework, with HIPAA compliance and on-prem deployment built in.

The 4-Second Problem

Four seconds seems like a rounding error. In most software contexts, it is. A web page that loads in 4 seconds instead of instant is slow - but nobody gets hurt. A clinical alert that arrives 4 seconds late is a different category of problem, and the clinical literature on time-to-treatment for specific conditions makes this concrete.

The uncomfortable truth is that most RPM platforms don't measure their end-to-end alert latency in production. They measure it in the lab, on a controlled network, with a small number of simulated devices. They do not measure it in a 400-bed hospital, on a WiFi network shared with PACS imaging systems, behind a proxy server, with 300 connected devices and 80 concurrent care team dashboard sessions.

Those are two completely different numbers. And the gap between them is the real-time clinical data gap.

"A system that delivers accurate data 8 seconds late is not a real-time monitoring system. It's a delayed monitoring system with a real-time UI."

Why Hospital Networks Break Everything

Hospital networks were not designed for the real-time data delivery requirements of modern RPM platforms. They were designed for PACS imaging, EHR access, administrative systems, and staff communications - none of which have the continuous, low-latency streaming requirements of a patient monitoring system with hundreds of devices pushing vitals every few seconds.

The result is a network environment that systematically breaks the assumptions most streaming infrastructure is built on:

Hospital WiFi is not like office WiFi

Hospital WiFi environments are dense, contested, and often segmented. Medical devices, clinical workstations, staff mobile devices, and visitor networks all share infrastructure that was frequently installed in phases over years, with different vendors, different configurations, and often minimal QoS for real-time data applications. Nurses moving between wards on tablets experience handoffs that drop connections. Devices in procedure rooms operate in RF environments that create intermittent connectivity. The WiFi that "works fine" for accessing an EHR creates silent failures for a WebSocket streaming connection.

Hospital proxies silently kill WebSocket upgrades

Enterprise hospital networks - particularly those operating under strict IT security policies - deploy proxy servers and deep packet inspection systems that intercept HTTP traffic. Standard WebSocket connections require an HTTP Upgrade handshake: a client sends an Upgrade: websocket header, and the server responds with 101 Switching Protocols. A significant proportion of hospital proxy configurations either strip the Upgrade header silently or block the protocol switch entirely.

The failure mode is insidious: the connection doesn't error. It falls back to HTTP polling without the client knowing. The RPM dashboard appears to be working. Vitals appear to be updating. They are - every 30 seconds, on a polling interval, instead of in real time. The care team has no indication that their "real-time" monitoring is running 25 seconds behind.

Cellular handoffs break streaming sessions

Nurses, physicians, and care coordinators increasingly access monitoring dashboards on mobile devices - tablets and phones that move between WiFi zones and cellular coverage throughout a shift. A standard WebSocket connection is a stateful TCP session: when the underlying network changes, the session breaks. Reconnection requires a full handshake, and during the reconnection window - typically 2–15 seconds for a standard implementation - no alerts are delivered.

For a mobile care team member who steps into a stairwell, crosses a WiFi coverage gap, or moves from a ward to a procedure room, this is not a rare event. It is the normal operating condition of their workday.

The Three Failure Modes

The hospital network environment produces three distinct failure modes in RPM streaming infrastructure. Every platform we've looked at hits at least one of these. Most hit all three.

The Hospital Network Reality

The three failure modes above share a common cause: standard streaming infrastructure was built for the public internet, not for hospital networks. The public internet is heterogeneous but generally permissive. Hospital networks are restrictive by design - and that restriction creates failure modes that only surface in production, in the actual environment.

The diagram above represents the real-world connectivity profile that an RPM platform needs to support in a typical acute care hospital deployment. Standard WebSocket handles 2 of the 6 most common network environments. Lightstreamer - built from the ground up for exactly this problem - handles all 6, transparently, without the care team or the platform engineering team needing to configure anything.

The mechanism is Intelligent Streaming: automatic protocol negotiation that detects the best available transport for each client connection and falls back gracefully without breaking the session. On a standard WiFi connection, it uses WebSocket. Behind a proxy that strips Upgrade headers, it uses HTTP streaming. In a highly restricted environment, it uses long polling. The care team's dashboard sees the same real-time data either way.

"The question is whether the platform actually works in Bay 7 of a 200-bed ward at 2AM, on hospital WiFi, through a proxy server, on a nurse's tablet that just switched access points."

What Sub-Second Clinical Alert Delivery Actually Requires

The clinical standard we're targeting - sub-second end-to-end alert delivery from sensor reading to care team dashboard - is achievable in hospital environments. It requires getting four things right simultaneously.

First: last-mile transport resilience. The streaming layer must handle the full range of hospital network environments described above - proxies, WiFi handoffs, cellular transitions, restricted firewall rules — without degrading to polling and without requiring custom code for each environment. This is the problem Lightstreamer was specifically designed to solve.

Second: the MQTT bridge. Most RPM platforms use MQTT for device-to-cloud data collection - it's the right protocol for IoT devices with constrained power and connectivity. But MQTT was not designed for browser-to-dashboard delivery. The bridge between MQTT and the care team's web or mobile interface is where most platforms lose both latency and reliability. We'll go deep on this in Part 2.

Third: on-premise deployment capability. HIPAA compliance, hospital IT security policy, and data residency requirements frequently mandate that patient data not leave the hospital network perimeter. A cloud-based streaming solution that routes patient vitals through an external data center is a non-starter for many hospital system deployments. On-premise Lightstreamer deployment keeps all patient data within the hospital's own infrastructure - the streaming broker runs inside the perimeter, not outside it.

Fourth: graceful degradation without silent failure. The most dangerous failure mode is not the outright crash - it's the silent degradation where the dashboard appears functional but is actually running on stale data. A production-grade system must distinguish between "connected and streaming" and "connected but polling" and surface that distinction clearly to the care team.