Medical Devices & Healthcare IoT

Messaging that keeps clinical systems operating when devices don’t

Healthcare systems are among the most demanding environments for communication software: patient lives depend on timely, accurate data delivery. The messaging layer connecting bedside monitors, infusion pumps, imaging systems, and clinical platforms must remain predictable even when devices and networks are not.

RelayQ ensures patient telemetry, alarms, and device data remain consistent across failures, restarts, and misbehaving equipment.

Clinical systems fail unpredictably

Devices restart. Network segments drop. Sensors malfunction. Equipment is moved between wards without reconfiguration.

In traditional messaging systems, these failures propagate: a malfunctioning monitor can flood the alarm bus, a stalled connection can delay critical alerts, and inconsistent state spreads across clinical decision systems.

RelayQ is designed to contain these failures.

Each device is isolated. Each connection is strictly bounded. The system continues operating across device restarts, connectivity gaps, and misbehaving equipment.

No cascading failure. No system-wide disruption.

Failure remains contained — by design.

The system behaves predictably even when the clinical environment does not.

Market challenge

Medical device manufacturers and healthcare IT teams face unique pressures:

• Patient safety — delayed or corrupted telemetry can degrade clinical decision-making
• Regulatory burden — IEC 62304, ISO 14971, FDA 21 CFR Part 11, and HIPAA demand provable software quality and data protection
• Device fragmentation — hundreds of disconnected devices from multiple vendors in a single hospital
• Continuous uptime — ICU monitoring and critical care systems cannot tolerate communication failures
• Long validation cycles — every software component in a regulated device extends V&V effort

At the same time, medical devices behave unpredictably — and traditional messaging layers do not isolate these failures.

Why traditional brokers break down in healthcare

• 200+ dependencies enlarge hazard analysis and risk documentation under IEC 62304
• Frequent upstream updates force re-validation cycles that regulated release schedules can’t absorb
• No ingress validation means malformed device data can propagate to clinical decision systems
• Large container images don’t fit on bedside gateways or embedded medical hardware
• Complex SBOMs create ongoing maintenance burden that compounds across device fleet lifecycles

More importantly, traditional brokers do not control how failures propagate across devices, clinical systems, and alarm pathways.

How RelayQ addresses healthcare requirements

RelayQ enforces controlled behavior under real-world clinical conditions:

• Device restarts do not result in data loss
• Connectivity loss does not corrupt system state
• Misbehaving devices cannot impact other devices or data streams
• Resource usage remains bounded across hundreds of connected devices
• The system remains predictable under load and failure conditions
• No malfunctioning device can stall the system or delay critical patient alarms

Supporting characteristics:

• Zero dependencies (non-TLS) — minimal hazard analysis scope under IEC 62304
• Deterministic behavior — thread-per-client model with no garbage collector, no scheduling jitter
• WAL persistence — messages survive device restarts and power events without data loss
• <50ms startup — fast recovery after device power cycle in clinical environments
• Default-deny ACL — enforces data access boundaries aligned with HIPAA principles
• Audit logging — append-only evidence trail for regulatory compliance and incident investigation
• <1MB binary — fits on bedside gateways and embedded medical device hardware
• Formal verification — mathematical proofs provide evidence for regulated development programs

Where RelayQ fits in the healthcare architecture

RelayQ operates as a single execution boundary, ensuring consistent system state across ingestion, buffering, and delivery — even across distributed clinical environments with unpredictable device behavior.

RelayQ operates at three levels:

Integrates with:

• Clinical systems: EHR platforms (Epic, Cerner/Oracle Health), clinical data repositories
• Data standards: HL7 FHIR (via FHIR-to-MQTT bridge), HL7v2 (via integration engine)
• Medical devices: patient monitors, infusion pumps, ventilators, imaging systems (via device gateways)
• Monitoring: Prometheus + Grafana for broker health, clinical dashboards for patient data
• Cloud platforms: AWS HealthLake, Azure Health Data Services, Google Cloud Healthcare API
• Integration engines: Mirth Connect, Rhapsody, InterSystems HealthShare

Healthcare use cases

Real-time patient monitoring (ICU/telemetry)

Bedside monitors stream heart rate, SpO2, blood pressure, respiratory rate, and ECG waveforms to nursing stations and clinical decision systems. RelayQ’s deterministic latency ensures consistent delivery — no jitter from async runtimes or garbage collection pauses that could delay critical alarm propagation. A malfunctioning monitor cannot affect other patients’ data streams.

Connected medical device management

Infusion pumps, ventilators, and imaging systems publish status, dosage data, and fault alerts. RelayQ’s topic-level ACLs ensure each device class can only publish to its assigned namespace — a compromised pump cannot access patient records or other device streams. No single device failure can impact the broader clinical network.

Clinical alarm management

Alarm fatigue is a leading patient safety concern. RelayQ’s rate limiting prevents malfunctioning devices from flooding the alarm bus, while Sparkplug validation ensures only well-formed alarm messages reach clinical staff. No noisy device can delay critical alerts from other equipment.

Remote patient monitoring (telehealth)

Wearable devices and home health monitors publish vital signs to cloud platforms. RelayQ buffers messages during connectivity gaps (common in home environments) and delivers them when connection resumes. No data loss for longitudinal patient tracking. The system continues operating regardless of network state.

Hospital asset tracking and environment monitoring

Temperature sensors in medication storage, air quality monitors in operating theatres, and RTLS tags on equipment publish status via MQTT. RelayQ provides the unified messaging backbone connecting these disparate systems. A misbehaving sensor cannot impact clinical data pathways.

Security mapped to healthcare threats

Compliance and regulatory readiness

RelayQ is not a medical device and is not FDA-cleared. It is designed as infrastructure software with regulatory readiness in mind — the engineering evidence (formal verification, fuzz testing, 1,837+ spec-traceable tests) supports integration into regulated medical device systems.

Proof points

• 6 million fuzz inputs, zero panics — codec hardened against malformed packets from any device
• 1,837+ protocol tests — full MQTT 3.1.1 conformance with spec traceability
• 6-hour soak test — sustained load with zero message loss (simulates continuous monitoring)
• Deterministic latency — no GC pauses, no async jitter in critical alarm delivery paths
• WAL recovery after hard power cut — zero message loss across simulated clinical power events
• <1MB binary — validated on medical-grade ARM gateway hardware

Measured operational improvements

Device interoperability

Hospitals struggle with hundreds of disconnected devices from dozens of vendors. RelayQ provides a unified messaging layer:

• Vendor-neutral — any MQTT 3.1.1 client connects, regardless of manufacturer
• Protocol bridging — HL7v2-to-MQTT and FHIR-to-MQTT adapters connect legacy clinical systems
• Namespace isolation — each device class, department, or vendor gets its own topic namespace
• Incremental adoption — start with one ward or device class, expand without disrupting existing infrastructure
• No vendor lock-in — standard protocol, single binary, removable without side effects

Deployment options

All deployments are a single static binary — no runtime, no interpreter, no shared libraries required.

Systems that behave predictably under failure — not just under ideal conditions.

Request evaluation access →