Engineering

From EHR to IoMT: Engineering Interoperability Without Compromising Safety

Bridging Electronic Health Record systems with the Internet of Medical Things demands disciplined integration architecture. Here is how we build it without putting patients at risk.

3 min read
Healthcare technology team discussing EHR and IoMT integration

EHRs were built to be the system of record for clinical encounters. IoMT devices were built to stream continuous physiological data. Most failed integrations we are asked to rescue happen because someone tried to make the EHR pretend it was a stream processor, or made the IoMT platform pretend it was a system of record.

This article walks through the architecture we use to connect these two worlds without compromising clinical safety, audit traceability, or the velocity at which both teams ship.

#1Why IoMT projects stall at the EHR boundary

Vendor demos make EHR↔IoMT integration look like a single API call. Production reality is messier: heterogeneous device protocols, vendor-specific message profiles, network jitter, and consent frameworks that vary by region. Teams either underestimate the surface area and ship brittle point-to-point links, or over-engineer a heavyweight ESB that nobody enjoys operating.

  • Devices that batch overnight versus devices that stream every second.
  • EHRs that accept v2 HL7 messages over MLLP versus EHRs locked to a proprietary REST profile.
  • Identity systems that map a device to a patient through different identifiers per organisation.
  • Consent flags that gate which data flows can legally cross which hop.

#2A FHIR-first mindset, not an HL7 retrofit

FHIR is the lingua franca of modern healthcare integration. We treat it as the internal contract between subsystems, even when one endpoint speaks HL7v2 and another speaks a proprietary JSON. The mapping layer translates inbound payloads into canonical FHIR resources at the edge, runs them through validation, then routes them to downstream consumers.

#3Bringing device streams into a clinical-grade pipeline

Continuous device data is not just 'more rows in an Observation table'. We separate the high-frequency telemetry plane (Kafka or MQTT, time-series store, deterministic backpressure) from the clinical events plane (FHIR resources, audit logs, EHR sync). Aggregations move from telemetry to clinical only when they cross a clinically validated threshold.

  • Edge gateway buffers and normalises raw device payloads.
  • Streaming layer aggregates rolling windows and emits derived events.
  • Validator confirms the event is well-formed, references a known patient, and is consented.
  • EHR adapter writes a single, semantically meaningful Observation or DiagnosticReport.

#4Safety by design — fail-closed, alert-aware

Connectivity bugs in IoMT become safety bugs the moment a missed alert lengthens a hospital stay. We default to fail-closed behaviour everywhere PHI crosses a boundary, and we ensure alert pathways have a separate, independently monitored circuit so a downstream EHR outage cannot silence a critical alarm.

  • Heartbeat checks across every adapter and a single observability board for clinical engineering.
  • Duplicate-event suppression keyed on a deterministic content hash to prevent alarm fatigue.
  • Replay tooling that lets engineers re-run a day of telemetry through a new transform without touching production EHR data.
  • Documented escalation paths for partial-degradation modes so clinicians know which features are temporarily off.

The takeaway

EHR↔IoMT integration is not a one-off project — it is a long-running surface that grows as new devices and care models arrive. Investing in a FHIR-canonical middle, a streaming telemetry plane, and explicit fail-closed semantics is what turns 'we connected the new wearable in a sprint' from marketing copy into reality.

Frequently asked questions

Should every IoMT data point land in the EHR?
No. EHRs are systems of record, not stream processors. Only clinically meaningful, validated events should be persisted as Observations or DiagnosticReports. Raw telemetry belongs in a purpose-built time-series store with explicit retention.
How do you handle device-to-patient identity mismatches?
We pair every device with a verified Patient FHIR resource at provisioning time and re-validate on every reading. Mismatches trigger a soft quarantine where data is retained for forensic review but never surfaces to clinicians.
Keep reading

Similar articles