MQTT

In one line

MQTT (Message Queuing Telemetry Transport) is a tiny publish/subscribe messaging protocol designed for unreliable networks and constrained devices — which is why most connected medical devices and remote-monitoring kits speak it.

The problem it solves

Device telemetry has to survive flaky Wi-Fi, cellular dropouts, and battery limits, and a ward may have hundreds of devices that shouldn't each open a heavy connection to every consumer. MQTT's publish/subscribe model decouples senders from receivers through a central broker, so devices stay simple and the network stays light.

How publish/subscribe works

Devices don't talk to each other directly:

• Each client connects to a central broker (Mosquitto, EMQX, HiveMQ…).
• A publisher publishes to a named topic — ward3/bed12/spo2.
• A subscriber subscribes to a topic or a pattern with wildcards — ward3/+/spo2 (all beds' SpO₂) or ward3/# (everything under ward3).
• The broker routes each message from publishers to all matching subscribers.

The features that matter clinically

Feature	What it does	Why it matters
QoS 0/1/2	at most once / at least once / exactly once	trade delivery guarantee vs overhead
Retained message	broker keeps the last value per topic	a new dashboard gets the latest reading instantly
Last Will & Testament	broker announces a client that vanished	a monitor knows a sensor went offline vs "all fine"

That Last Will is the difference between a dashboard that says "no alarms" and one that says "this sensor stopped reporting" — a patient-safety distinction.

MQTT vs CoAP vs HTTP

MQTT shines for continuous telemetry to a backend. CoAP is better for tiny, battery-pinching request/response at the very edge; plain HTTP is heavier but ubiquitous. A common stack: CoAP/BLE at the edge → MQTT to the cloud → FHIR after that.

Where it shows up in digital health

RPM kits publish vitals over MQTT (often via a home gateway); hospital IoMT platforms ingest device streams through brokers before converting them to FHIR Observations; simulation bridges stream synthetic vitals the same way. In this platform's IoT lab, the device → broker → FHIR pipeline is exactly what you build — with synthetic patients on the other end.

Common pitfalls

• Wrong QoS — QoS 0 for a critical alarm can silently drop it; QoS 2 everywhere wastes bandwidth.
• No Last Will — you can't distinguish a silent sensor from a healthy one.
• Flat topic design — a good hierarchy (site/ward/bed/metric) makes wildcards and access control sane.
• Unsecured brokers — MQTT needs TLS + auth; an open broker is a data breach.

Key takeaways

• MQTT is a tiny pub/sub protocol: clients publish/subscribe to topics via a broker.
• QoS, retained messages, and Last Will give it clinical-grade delivery semantics.
• Design topic hierarchies deliberately; always secure the broker.
• The backbone of IoMT telemetry — edge protocols feed it; FHIR consumes it.