Medical Devices & Healthcare IoT

A data path that keeps clinical telemetry flowing when devices don’t

RelayQ is a deterministic edge runtime for industrial data systems that brings industrial equipment (Modbus, DNP3, OPC UA, BACnet/IP) and IoT sensors (MQTT, Sparkplug B) into one data path.

Healthcare environments connect bedside monitors, infusion pumps, imaging systems, and clinical platforms from many vendors. The data path carrying their non-alarm telemetry must remain predictable even when devices and networks are not. RelayQ is not a medical device, is not FDA-cleared, and does not carry clinical alarms; it carries non-alarm device telemetry.

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 data path, a stalled connection can delay other devices’ data, and inconsistent state spreads across downstream 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.

Market challenge

Medical device manufacturers and healthcare IT teams face unique pressures:

• Data integrity: delayed or corrupted telemetry degrades the downstream systems that consume it
• Regulatory burden: IEC 62304, ISO 14971, FDA 21 CFR Part 11, and HIPAA demand provable software quality and data protection
• Device fragmentation: disconnected devices from multiple vendors in a single hospital
• Continuous uptime: monitoring and asset systems cannot tolerate communication failures
• Long validation cycles: every software component in a regulated device extends V&V effort

Why dependency-heavy stacks break down in healthcare

Unlike traditional MQTT broker stacks, RelayQ does not bring hundreds of dependencies into IEC 62304 hazard analysis, does not force re-validation on every upstream update, and fits on bedside gateways where large container images do not. More importantly, traditional stacks do not control how failures propagate across devices and downstream systems.

How RelayQ addresses healthcare requirements

• An acknowledged QoS 1 message is written to disk before the acknowledgement, so a power loss after the acknowledgement does not lose it
• Connectivity loss does not corrupt system state
• Misbehaving devices cannot impact other devices or data streams
• Resource usage remains bounded per connection
• No malfunctioning device can stall the system

Supporting characteristics:

• Std-only core (zero third-party crates in Lite, twelve with TLS on Linux): a small hazard analysis scope under IEC 62304
• Deterministic behavior: thread-per-client model with no garbage collector, no scheduling jitter
• Default-deny ACL: enforces data access boundaries aligned with HIPAA principles
• Audit logging: append-only evidence trail for regulatory compliance and incident investigation
• One binary under 10 MB: fits on Linux bedside gateways
• Formal verification: Kani proof harnesses and Loom concurrency models provide evidence for regulated development programs

Where RelayQ fits in the healthcare architecture

RelayQ operates at three levels:

Integrates with:

• Clinical systems and data standards (HL7v2, FHIR): via a third-party integration engine publishing MQTT
• Medical devices: patient monitors, infusion pumps, ventilators, imaging systems (via device gateways publishing MQTT or Sparkplug B)
• Monitoring: Prometheus + Grafana for runtime health, clinical dashboards for device data
• Cloud platforms: any MQTT 3.1.1 endpoint via the MQTT bridge

Healthcare use cases

Device telemetry aggregation

Bedside monitors and other devices publish non-alarm telemetry to nursing-station dashboards and analytics. RelayQ’s deterministic latency gives consistent delivery, with no jitter from async runtimes or garbage collection pauses. A malfunctioning monitor cannot affect other devices’ data streams.

Connected medical device management

Infusion pumps, ventilators, and imaging systems publish status, usage data, and fault indications. RelayQ’s topic-level ACLs ensure each device class can only publish to its assigned namespace; a compromised pump cannot access other device streams. No single device failure can impact the broader data path.

Remote patient monitoring (telehealth)

Wearable devices and home health monitors publish vital signs to cloud platforms. RelayQ buffers messages to disk during connectivity gaps (common in home environments) and replays them when connection resumes; the bridge’s connection-liveness detection and delivery guarantees are still being hardened, so treat this as buffered best-effort delivery today, not a zero-data-loss guarantee for longitudinal patient tracking.

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 one data path connecting these disparate systems. A misbehaving sensor cannot impact other 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 (Kani proof harnesses, Loom concurrency models, fuzz testing, 4,902 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
• 4,902 automated tests: traced to the protocol specifications, with per-requirement conformance reports
• Six 1-hour soak runs, zero message loss (lab, x86_64, May 2026)
• Deterministic latency: no GC pauses, no async jitter in the delivery path
• Durability contract: an acknowledged QoS 1 message is written to disk before the acknowledgement, so a power loss after the acknowledgement does not lose it
• Under 10 MB on armv7: runs on Raspberry Pi 3B/3B+ class hardware

Expected operational improvements

Device interoperability

Hospitals struggle with disconnected devices from dozens of vendors. RelayQ provides one data path:

• Vendor-neutral: any MQTT 3.1.1 client connects, regardless of manufacturer
• Clinical standards: HL7v2 and FHIR systems connect via a third-party integration engine publishing MQTT
• 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.

Apply for a pilot →

Proof points are lab measurements on the stated hardware and build; results in your environment will differ. Method and full test evidence are shared with pilot customers.