From wearable to EMR: a reading's journey

A reading on a wearable device is useless until it reaches the chart a clinician is actually looking at. The distance between "the sensor measured something" and "it's in Epic, on the right patient, triggering the right alert" is where most medical-device software lives — and where it most often breaks. Here's the journey a single reading takes, drawn from the platform we built behind a wearable hemodynamic monitor.

The four layers a reading crosses

Getting a value from skin to chart means crossing four distinct layers, each with its own failure modes:

1. Device & Bluetooth — the sensor measures and transmits.
2. Gateway / edge — something nearby receives it and gets it to the cloud.
3. Middleware — a canonical store, orchestration, and translation.
4. EMR — the value lands in the record the care team uses.

Skip or hand-wave any one of these and data goes missing silently.

Off the device: Bluetooth that survives the real world

Our wearable measures hemodynamic parameters and advertises readings over BLE 5.0 every few minutes. A small gateway (we wrote ours in Python) scans for the device, subscribes to its characteristic, parses the payload, and forwards it.

The hard part isn't the happy path — it's the bedside reality. Bluetooth drops. Wi-Fi blips. So the gateway forwards over HTTPS with key-based auth and exponential-backoff retry, and treats disconnects as normal: it simply re-discovers the device on the next scan. The guiding rule for device ingestion is that a lost connection should never mean a lost reading.

A canonical store, then translate outward

Every reading is written first to a canonical FHIR R4 store (we use HAPI FHIR) as an Observation — including a custom code system for the device's proprietary biomarkers, since they don't all have a standard LOINC code yet. This canonical-first approach is the most important architectural decision in the whole pipeline: by storing once as FHIR and translating outward, we can add a new EMR target later without touching device or gateway code.

From there, a FHIR Subscription fires a webhook on every new reading. An orchestration layer (n8n) picks it up, and Mirth Connect translates the FHIR resource into an HL7v2 ORU^R01 result message — the format hospital interface engines expect.

Landing in the EMR — three ways at once

Different EMRs want different things, so the platform speaks to each on its own terms:

• Epic — a direct FHIR R4 write-back (via SMART on FHIR / OAuth 2.0) updates flowsheet rows, fires Best Practice Alerts to the care team's InBasket, and supports remote-patient-monitoring billing (CPT 99453–99458).
• Oracle Health (Cerner) — HL7v2 through Bridges and CareAware.
• Everything else — the universal HL7v2 ORU^R01 path covers EMRs that only speak v2, which is still most of them.

One reading, written once, can reach all three.

The lessons that actually matter

• Map terminology before you write code. A reading in the wrong flowsheet row is worse than no reading. Decide your LOINC/SNOMED/custom codes and where each lands in each EMR up front.
• Make ingestion idempotent and observable. Retries will resend; the system must not create duplicate observations, and you must be able to see where a reading is in the pipeline at any moment.
• Separate "measured" from "delivered." A canonical store decouples the device from the EMR. It's the difference between adding a new hospital in days versus rebuilding the integration.
• Plan the alert path, not just the data path. The clinical value is the alert that reaches the right person — flowsheets, BPAs, and notifications are first-class features, not afterthoughts.

This is the shape of Vysio: device to gateway to FHIR to HL7v2 to Epic, Cerner, and beyond. The sensor is the easy part. The engineering is everything that happens after the reading exists — and that's what determines whether it ever helps a patient.

Building a connected device or RPM product? Tell us about it.