Connected Health IoT: Wearables, Remote Monitoring

Connected health devices — pulse oximeters, continuous glucose monitors (CGMs), ECG patches, smart inhalers — sit at the intersection of the tightest power budgets in IoT and the least tolerance for dropped data. A missed arrhythmia alert or a gap in a glucose trace isn't a minor UX issue; it can be a clinical event. This makes remote patient monitoring (RPM) one of the few IoT verticals where link budget, sampling fidelity and regulatory compliance are all first-order design constraints simultaneously.

The Reference Topology

Almost every connected health product follows the same three-tier path:

[Sensor/Wearable] --BLE/NFC--> [Gateway: phone/hub] --Wi-Fi/Cellular--> [Cloud: ingestion, EHR, alerts]
     Class 1/2            edge buffering,              time-series DB,
     RFC 7228             protocol translation          rules engine, clinician UI

• Perception tier (the wearable): a Class 1 or Class 2 constrained device (per RFC 7228) — think tens of KB RAM, a low-power MCU, one or more biosignal front ends (PPG, ECG AFE, bioimpedance).
• Gateway tier: usually a smartphone app or a dedicated hub. It handles protocol translation (BLE GATT → HTTPS/MQTT), local buffering during connectivity gaps, and sometimes edge inference (e.g., R-R interval arrhythmia flagging before cloud round-trip).
• Cloud tier: time-series ingestion, alarm rules, and integration into EHR/HL7 FHIR pipelines for clinician access.

This is a direct instance of the generic device-classification and edge/fog/cloud patterns used elsewhere in IoT, but with two health-specific twists: data provenance (every sample needs a timestamp and device ID that survives the whole pipeline for regulatory audit) and alarm criticality tiers (a disconnected Wi-Fi router shouldn't silently drop a fall-detection event).

Sensing Front Ends: What's Actually Being Measured

Two things stand out for a hardware engineer sizing a design:

1. Duty cycle dominates power, not the ADC. A PPG front end drawing 2 mA active current but sampled at 1% duty cycle (e.g., 100 Hz burst, then sleep) averages ~20 µA — the radio, not the sensor, usually ends up as the largest power consumer over a day.
2. CGM's low rate hides a hard problem. One sample every few minutes sounds trivial for a radio link, but the enzyme sensor drifts over its 10–14 day wear life, so most of the "signal processing" budget goes to calibration algorithms, not sampling.

Link Budget Worked Example: BLE Wearable to Phone

Take a chest-strap ECG patch transmitting at BLE 1M PHY, 0 dBm TX power, with a phone in a pocket at 1 m, then again at a more realistic 3 m with body attenuation.

Free-space path loss (FSPL): FSPL(dB) = 20·log₁₀(d) + 20·log₁₀(f) + 32.44 (d in km, f in MHz)

At f = 2440 MHz, d = 0.003 km (3 m):

20·log₁₀(0.003) = 20 × (−2.523) = −50.46 dB
20·log₁₀(2440)  = 20 × 3.388   = 67.76 dB
FSPL = −50.46 + 67.76 + 32.44 = 49.74 dB

Add a conservative on-body attenuation margin of 10 dB (clothing + tissue shadowing) → total path loss ≈ 59.7 dB.

Received signal: Prx = Ptx − PathLoss = 0 dBm − 59.7 dB = −59.7 dBm

Compare to a typical BLE receiver sensitivity of −95 dBm (1M PHY): margin = 95 − 59.7 ≈ 35 dB, comfortable even with additional fading. This is why BLE works reliably for on-body-to-pocket links but explains why the same patch fails badly if the phone is left in another room (add ~20–30 dB more path loss for walls/distance, and the link drops below sensitivity).

Check: −59.7 dBm is well above −95 dBm, margin is positive and large — consistent with BLE's known reliable range of several meters indoors. Design implication: the weak point in RPM systems is rarely the BLE hop; it's the gateway-to-cloud hop when the patient's phone loses Wi-Fi/cellular coverage, which is why local buffering (hours of on-device or on-phone storage) is a standard requirement, not an optional feature.

Data Path and Criticality Tiers

RPM traffic isn't homogeneous — treating a low-battery notice the same as a fall-detection alarm wastes both bandwidth and clinician attention:

• Telemetry: continuous vitals (HR, SpO₂, glucose trend) — buffered, sent in batches, tolerant of seconds-to-minutes latency.
• Alarm: arrhythmia detection, fall detection, glucose out-of-range — needs sub-second to few-second delivery, retried aggressively, often escalated via SMS/push if the primary channel fails.
• Config/command: threshold updates, firmware parameters pushed to the device — low frequency, must be acknowledged and versioned.
• Device health: battery, connectivity status, sensor self-test — low priority but essential for remote fleet management of thousands of deployed wearables.

Most platforms implement this with separate MQTT topics or message priorities so an alarm can preempt a queue of routine telemetry.

Regulatory and Data Handling Constraints

Connected health is one of the few IoT categories where the wireless design is gated by more than FCC/CE radio compliance:

• Data privacy: HIPAA (US) / GDPR (EU) require encryption in transit (TLS 1.2+/DTLS for constrained links) and at rest, plus access logging — this shapes protocol choice (CoAP+DTLS or MQTT+TLS rather than unencrypted UDP telemetry).
• Device classification: depending on intended use, a wearable may fall under FDA Class II (e.g., pulse oximeter, CGM) requiring clinical validation, not just RF certification — a materially longer and costlier path than a consumer fitness band.
• Interoperability: HL7 FHIR is the de facto standard for getting device data into clinical systems; a gateway that only speaks a proprietary cloud API creates integration friction for hospital IT.

Practical Design Implications

• Battery life is a systems problem, not a component spec. Radio duty cycle, advertising interval, and connection interval on the BLE link typically matter more than sensor front-end current.
• Buffer for the worst link, not the average. Gateway or on-device storage covering several hours of telemetry protects against Wi-Fi dropouts without losing clinical data.
• Separate alarm delivery from telemetry delivery. Different reliability, latency and retry requirements mean they shouldn't share a single best-effort queue.
• Plan for calibration and drift, especially for chemical/enzymatic sensors. CGM-class sensors need firmware-level compensation algorithms, not just accurate ADCs.
• Design the compliance path early. Whether a device is a wellness product or a regulated medical device changes clinical trial requirements, quality system obligations, and time-to-market by months to years.

Key Takeaways

• Connected health follows the standard device→gateway→cloud IoT topology, but adds strict requirements on data provenance, alarm criticality, and regulatory compliance not present in consumer IoT.
• Sensing modalities (PPG, ECG, CGM, accelerometer, bioimpedance) trade sample rate for different bottlenecks — motion artifact, AFE noise, or chemical sensor drift.
• A BLE link budget for a typical wearable-to-phone hop carries ~35 dB of margin at 3 m even with body attenuation; the real reliability risk is usually the gateway's backhaul, not the on-body link.
• Traffic should be split into telemetry, alarm, config, and device-health tiers, each with its own latency, retry, and delivery guarantees.
• HIPAA/GDPR and medical device classification (e.g., FDA Class II) can dominate the design timeline as much as RF or power engineering.