MQTT, Hospital Networks,
and the Last-Mile Problem

Part 1 closed with a promise: the fix is architectural. Today, we discuss this fix in production detail, with the specific Lightstreamer capabilities that make each layer work, and the on-prem deployment model that keeps HIPAA compliance intact.

Why MQTT Doesn't Solve the Last-Mile Problem

MQTT is excellent at what it was designed for. It was designed by IBM in 1999 for monitoring oil pipelines over satellite links[1] with constrained hardware, unreliable networks, minimal bandwidth. A protocol that could survive those conditions is exactly what you want for medical IoT devices: low power consumption, small packet overhead, reliable delivery with QoS levels[2], and native handling of intermittent connectivity.

MQTT was not designed for browsers. There is no native MQTT client in any browser. To get MQTT data into a web application, you need either MQTT over WebSocket - which requires broker-side configuration and still hits every proxy and firewall problem from Part 1 - or a server-side bridge that translates MQTT messages into a browser-compatible protocol.

"MQTT is a device protocol. The care team's dashboard is not a device. Expecting MQTT to handle both ends of the data journey is asking the protocol to do something it was never designed to do."

The practical consequence is that every RPM platform must have something between the MQTT broker and the care team's dashboard to carry data in the last mile. A bridge that handles hospital network environments securely, efficiently and reliably.

The Full Architecture Stack

The production architecture for sub-second clinical alert delivery has four layers. The Lightstreamer MQTT Connector sits between the broker and the care team clients - it's the bridge. Importantly, it runs inside the hospital network perimeter, which means patient health information never leaves the hospital's infrastructure.

The architecture is minimal. We are not replacing anything in your existing stack - not the MQTT broker, not the device firmware, not the EHR integration. We add one component between the broker and the clients: the Lightstreamer MQTT Connector. It subscribes to your existing MQTT topics and handles every last-mile delivery problem that MQTT alone cannot handle efficiently

What the connector actually does

The connector maintains a persistent subscription to the MQTT broker on behalf of all connected care team clients. When a vital sign update arrives on a topic, the connector processes it once and fans it out to all subscribed sessions, applying delta delivery (only changed fields) and per-client bandwidth adaptation in the process.

This matters for scale. At a 200-bed ward with 300 monitoring devices each publishing vitals every 2 seconds, and 80 concurrent care team sessions, a naive fan-out would generate 300 × 80 = 24,000 deliveries per second. With delta delivery, most of those deliveries are a handful of bytes - only the SpO₂ value that changed, not the full vital signs record. With selective fan-out, a nurse monitoring patients in Bays 1–6 only receives updates for those patients. The actual network load is a fraction of the theoretical maximum.

The Sub-Second Alert Pipeline

In Part 1, we called out the clinical target: sub-second end-to-end alert delivery from sensor reading to care team dashboard. Here's what that actually looks like, step by step, in a production deployment.

The sub-300-millisecond figure reflects end-to-end latency in controlled deployments under comparable network conditions (on-prem broker, local WiFi, with minimal competing traffic). Real hospital environments introduce additional variance: contested WiFi adds 20–40ms, cellular handoffs add 50–150ms. All paths remain comfortably sub-second under normal operating conditions. For Lightstreamer's own benchmarking data, see their published performance documentation.[10]

MQTT Direct vs. MQTT + Lightstreamer

For teams evaluating whether the bridge is worth adding to the stack, the comparison below may be helpful. MQTT direct-to-browser may work well in ideal conditions. But, hospital environments are not ideal conditions.

The most important row in the table above, is the connection state. MQTT gives you binary state - either it is connected or not. Lightstreamer gives you explicit, granular state: i.e. streaming at full quality, degraded to HTTP streaming, degraded to polling, offline. For a care team relying on that connection for clinical decisions, the difference between "I know I'm in a degraded state" and "I don't know if this data is stale" is an important patient safety consideration. Unreliable Alarm systems (Alarm Fatigue) is a documented contributor to adverse patient events[8] and a Joint Commission National Patient Safety Goal[9]. This makes connection state transparency a very critical clinical requirement, not just a nice-to-have capabiltiy.

On-Prem Deployment and HIPAA Compliance

In healthcare, HIPAA compliance is an important architecture consideration, that must be addressed. The Privacy Rule and Security Rule establish requirements for how protected health information is stored, transmitted, and accessed.[7] For real-time streaming specifically, the question is: does patient vital signs data leave the hospital network perimeter, and if so, under what conditions?

Cloud-based streaming solutions route data through external infrastructure by definition. For many hospital system procurement teams, this is a may be a non-starter, regardless of the vendor's compliance certifications - the data residency requirement is absolute. Patient vitals do not leave the building.

Lightstreamer's on-premise deployment model satisfies this requirement through correct architecture. The server runs inside the hospital network. The MQTT broker runs inside the hospital network. The connector runs inside the hospital network. The only outbound traffic is the encrypted, minimal delta payloads to the care team's client devices - and those payloads contain only the specific vital sign values (delta only) the care team member is authorised to see, not raw patient records.

What "Simple to Add" Actually Means

Part 1 promised the bridge is simpler than it sounds. Here's what that means in practice for an engineering team with an existing MQTT-based RPM platform.

Your existing device firmware doesn't change. Devices continue publishing to MQTT topics exactly as they do today. The Lightstreamer MQTT Connector is a subscriber to your existing broker - it doesn't require any changes to the device layer or the topic structure.

Your MQTT broker doesn't change. Whether you're running Mosquitto, HiveMQ, AWS IoT Core, or Azure IoT Hub, the connector integrates as a standard MQTT subscriber. Broker migration and topic restructuring is not required.

Your EHR integration doesn't change. The Lightstreamer layer handles only the last-mile delivery from broker to dashboard. Your upstream data pipeline, your EHR data model, your clinical decision support rules - none of these are touched.

What changes is the client layer. The care team's dashboard replaces its current data source - whether that's polling, direct MQTT-over-WebSocket, or a bespoke bridge - with the Lightstreamer client SDK. For web dashboards, this is a JavaScript SDK. For iOS and Android apps, native SDKs are available. The SDK abstracts all transport negotiation; the application layer simply subscribes to items and receives updates.