Wearable Health Monitoring Devices: What MedTech Builders Need to Get Right

The hard part of wearable health monitoring devices is the path from prototype to a regulated product that clears the clinical bar. The sensor that gives a clean signal on the bench may drift under motion, the battery budget that worked for a 2-day demo collapses under continuous monitoring and the classification call was Class IIa may pull in companion software that pushes the whole programme one tier higher.

This raises a practical question:
How do you scope the sensor stack, the architecture and the regulatory path for a wearable health monitoring device so the prototype actually becomes a product?

This article walks through what each sensor in the typical stack can actually measure, the power-vs-precision trade-off that drives architecture decisions, the MDR classification path for wearable health monitoring devices specifically, the full build stack from sensor to clinician and the five mistakes that derail wearable programmes most often. For the backend integration side, the companion piece on wearable health data integration covers APIs, FHIR and cloud architecture.

Table of Content

Why Building a Wearable Is Harder Than the Prototype

A wearable is three products in one. There is the hardware: the sensor, the MCU, the battery, the case. There is the firmware that turns raw signal into a clean measurement. And there is the companion software that takes the measurement to the user or the clinician. Each layer carries its engineering risk and has to clear its own regulatory bar.

Bench prototypes sit still, have unlimited power and run a happy-path algorithm. Real wearables move, drain batteries fast and meet patients with a wider physiology than any training set covered. So the gap between a working prototype and a product that clears MDR is mostly about handling motion, edge cases and continuous duty.

The other reason the path is harder than expected is regulatory. Most teams scope an MDR programme around the hardware alone. Yet a wearable health monitoring device mostly ship with a companion app. That app sits under Rule 11 and gets its own classification with two outcomes through the worst-case rule and frequently land at Class IIa or higher.

-> In short: A wearable is hardware, firmware and software. Each layer needs its own engineering and regulatory plan. The prototype rarely exposes the hard parts.

The Sensor Stack: What Each Sensor Can Measure

Wearables typically combine four to six sensors and the hardware is largely commoditised. The differentiator is which signal each sensor reliably produces and what level of clinical claim that signal supports under verification.

PPG: Heart Rate, HRV and SpO2

Photoplethysmography (PPG) is the workhorse sensor for wrist-worn and ring-form wearables. A green or infrared LED shines into the skin and a photodiode measures the reflected light, which changes with the blood-flow pulse. From that signal the device derives heart rate, heart-rate variability and, with a red LED added, SpO2.

PPG is accurate at rest but degrades under motion. A medical-grade implementation typically uses multi-wavelength LEDs plus accelerometer fusion to reject motion artefact. The marketing-grade ±5 bpm spec drops to roughly ±2 bpm under that approach. Same hardware family, different signal processing and verification evidence.

ECG: Lead-I and the Arrhythmia Case

ECG sensors in wearables use two electrodes for a single-lead reading. The user touches the second electrode with the opposite hand. That gives a 30-second snapshot of the cardiac rhythm. It is enough for atrial fibrillation detection, which is the most common clinical claim for a wearable ECG.

For continuous monitoring rather than spot reading, the form factor moves to a chest patch with electrodes always in contact.

For example: chest-patch ECG can be designed to IEC 60601-2-47 ambulatory ECG performance, which is what regulators expect for a clinical claim. Smartwatch ECG is usually validated for AF detection only and not for general arrhythmia analysis.

Skin Temperature and EDA

Skin temperature on the wrist is a relative measure, not an absolute core temperature. It is useful for trend tracking, sleep staging and cycle-phase estimation. Going from skin temperature to a core estimate needs a calibration model and a clear claim about what is being reported.

Electrodermal activity (EDA) measures skin conductance, which correlates with sympathetic nervous system arousal. So it is a stress-and-recovery signal and not a primary clinical metric. EDA features cleanly in wellness positioning, but it rarely anchors a regulated clinical claim on its own.

Accelerometer and Gyroscope

The inertial measurement unit (IMU) is the cheapest sensor in the stack and one of the most useful. Activity recognition, step counting and sleep-phase estimation all rely on it. So does motion-artefact rejection for the PPG, which makes the IMU a hard requirement once accuracy targets get serious.

Fall detection is where the IMU produces a medical-device claim. A validated fall-detection algorithm sits under Rule 11 as decision-support software with a defined clinical use. Although the hardware is consumer-grade, it is classified as a medical device due to the verification evidence.

-> In short: Medical-grade is not a different sensor. It is the same sensor with a verification commitment, motion rejection and a defined clinical claim that the evidence actually supports.

What To Do:

Decide the clinical claim before locking the sensor stack. Same hardware can ship marketing-grade or medical-grade depending on the claim.
For PPG-based heart rate or SpO2, plan accelerometer fusion from day one. Retrofitting motion rejection wrecks the schedule.
Cross-check every claim against the applicable performance standard early. ECG goes to IEC 60601-2-47, SpO2 to ISO 80601-2-61.

The Power Budget Drives the Architecture

The single biggest architecture lever in these devices is the power budget: battery life, sampling rate, sensor duty cycle, BLE radio strategy and edge-processing depth all trade against each other. Picking wisely on day one is the difference between a 7-day device and one that needs a daily charge.

Sampling Rate, Duty Cycle and Battery Life

Continuous sensing is expensive. For example: a PPG running at 100 Hz drains battery several times faster than the same sensor at 1 Hz. Most consumer wearables run PPG at 1 Hz baseline and burst to 100 Hz only when an event triggers (high heart rate, exercise mode, sleep stage detection).

For medical wearables, the duty-cycle strategy depends on the clinical claim. AF detection needs enough sampling density to catch the arrhythmia window and continuous oxygen-saturation monitoring needs different rates again. Each claim translates to a sampling and duty-cycle profile that has to be designed into the firmware.

On-Device Processing vs Cloud Offload

Sending raw signal over BLE eats power. With a modern MCU this is fixable. It can run filtering, feature extraction and even small ML inference on-device. So the architecture trade-off is: process locally and send features, or send raw samples and process in the cloud.

On-device processing reduces radio time, extends battery life and avoids streaming raw data over a constrained link. It also constrains what you can change after launch, since model updates need OTA firmware deployment. Cloud offload is more flexible but burns battery and depends on connectivity, so most medical wearables mix the two.

Connectivity: BLE, Cellular and Cradle-Synced

BLE is the default radio link for these devices and it is power-efficient, ubiquitous on phones and integrated into every relevant MCU. The trade-off is that BLE needs a paired host nearby. So the user's phone becomes part of the regulated system.

Cellular wearables (NB-IoT, LTE-M) remove the phone dependency, which makes them suitable for elderly patients or unattended monitoring. The cost is significantly more power draw, which pushes towards charge-cradle designs rather than always-worn forms. Cradle-synced wearables collect data locally and dump it on charging contact, which suits long-duration sleep or recovery monitoring.

-> In short: Power drives sampling rate, BLE drives the phone dependency and edge processing drives flexibility. The architecture is the trade-off between these three, picked against the clinical claim.

MDR Classification for Wearable Health Monitoring Devices

MDR classification for these devices is rarely a single-rule call. Three rules typically apply at the same time. The worst-case rule then decides where the programme sits. For the broader context, the parent piece on medical device classes under MDR walks through all four classes and the 22 classification rules.

Rule 10: Active Diagnostic and Therapeutic

Rule 10 covers active devices intended for diagnosis or therapy. Most wearables fall here as a starting point with the default class being IIa. The rule lifts to IIb when the device monitors vital physiological parameters where variations could result in immediate danger to the patient (heart rate, respiration, oxygen saturation at risk thresholds).

So a fitness wristband that reports activity stays at IIa and a continuous oxygen-saturation monitor on a respiratory patient hits IIb. The same hardware can land in different classes depending on the intended purpose statement.

Rule 11: Companion Software

The mobile or web app that consumes the wearable's data is software in its own right. If the app provides information used for clinical decisions, Rule 11 applies. And the default outcome is IIa, escalating to IIb when wrong decisions could cause serious deterioration in health and to III when wrong decisions could be fatal.

Plus, MDCG 2019-11 is the qualification step that comes before classification. So the app has to be qualified as a medical device first and without that qualification, the classification call is wrong. Most teams run MDCG 2019-11 in parallel with the hardware-side Rule 10 analysis.

Where Class IIa Becomes Class IIb

The most common reason a wearable jumps from Class IIa to IIb is the vital-signs clause in Rule 10. For example: continuous SpO2 monitoring on a respiratory patient, continuous arrhythmia monitoring on a cardiac patient and closed-loop glucose-insulin control all trigger the lift. And closed-loop control around blood glucose can reach Class III under Rule 22.

Worst-case is the rule that closes the analysis. Annex VIII Section 3.5 fixes the device's class as the highest result among all applicable rules. So a wearable health monitoring device that is IIa under Rule 10 and IIb under Rule 11 lands at IIb overall.

-> In short: Most wearables land at Class IIa as a baseline. Vital-signs monitoring or higher-harm software decisions push them to IIb. Closed-loop therapy can reach III.

What To Do:

Classify the hardware and the companion app separately. Apply the worst-case rule afterwards.
Run MDCG 2019-11 qualification on the companion app before settling on a Rule 11 class.
Check the intended purpose statement carefully. The vital-signs clause in Rule 10 turns on the wording, not just the hardware.

The Build Stack From Sensor to Clinician

A wearable is a four-layer stack.

Sensor and firmware sit on the device.
Mobile app sits on the user's phone.
Backend and integration layer sit in the cloud.
Each layer has its own engineering and regulatory shape.

Firmware and Real-Time Constraints

Firmware runs the sensor, the duty cycle and any on-device signal processing. The MCU is usually an ARM Cortex-M class part with BLE 5.x integrated and common choices include Nordic nRF52840, Apollo4 or STM32WB. The firmware lifecycle has to align to EN IEC 62304, with most wearables landing in software safety Class B.

Real-time constraints matter most for ECG and motion-fusion paths. Sampling and timestamping have to be deterministic enough that downstream algorithms can rely on the data. A jitter budget is part of the firmware design from the start.

Mobile Companion App

The companion app is where most of the regulated logic lives. It pairs with the device, handles data sync, runs the cleaning and analysis that the device cannot do on its own and surfaces results to the user. So it has the heaviest Rule 11 exposure.

iOS and Android both treat medical-device apps as a distinct category in the app stores. Each store has its own review process for health claims. So building both in parallel means duplicating store-listing work and clinical-claim language. To avoid that many teams launch with iOS first because the review path for medical apps is more predictable.

Backend, Standards and Interoperability

The cloud backend holds longitudinal data, runs heavier analytics and integrates with clinician-side systems. Interoperability is where standards bite: HL7 FHIR is the default exchange format for clinical systems and IEEE 11073 covers device-side personal health data.

For backend security, ISO 27001 alignment plus the EN IEC 81001-5-1 health software cybersecurity lifecycle covers the regulator's expectations. The GDPR adds a separate set of obligations on patient data. Also, the closer the backend integrates with clinician systems, the heavier the obligations get.

-> In short: Firmware for real-time, app for the regulated logic, backend for the interoperability and longitudinal data. Each layer needs its own standards and its own lifecycle plan.

Common Mistakes on Wearable Health Monitoring Devices

From real projects, the same five mistakes around these devices come back again and again. They show up where the prototype was used as a basis for the product plan without testing the harder questions.

1. Claiming Clinical-Grade From Marketing-Grade Sensors

The hardware is the same in many cases. The clinical claim depends on verification evidence, not on a sensor upgrade. Teams that promise medical-grade accuracy without planning the verification studies find the claim does not survive notified body review. So plan the verification studies up front.

2. Under-Budgeting Power

The bench prototype runs on a tethered supply, but the product runs on a 200 mAh battery. Power budgets that work at 1 Hz collapse when the clinical claim forces 100 Hz continuous sampling. Build the power model alongside the algorithm and re-check it whenever the algorithm changes.

3. Missing the Companion App Classification

Teams classify the hardware and forget the companion app, which sits under Rule 11 and gets its own class. Once added with the worst-case rule, the overall programme often lands one tier higher than the hardware alone. MDCG 2019-11 is the qualification step that has to happen before Rule 11 applies.

4. Skipping the Motion Test

Bench PPG looks great, walking PPG drifts and running PPG often fails. The motion test is what separates a wellness wristband from a medical wearable. So design the verification protocol around realistic patient movement, not idealised lab conditions.

5. Treating Interoperability as Phase 2

FHIR and IEEE 11073 mapping is treated as a post-launch problem and the backend ships with proprietary data shapes. The first clinical partner asks for FHIR endpoints and the data model has to be reshaped under live conditions. So design the data model against FHIR from day one, even if FHIR endpoints ship later.

-> In short: Marketing-grade claims, under-budgeted power, missing app classification, no motion test, deferred interoperability. Five paths to the same launch slip.

FAQs About Wearable Health Monitoring Devices

Q1: What class do wearable health monitoring devices fall into under MDR?

A1: Most wearable health monitoring devices land at Class IIa under Rule 10. Vital-signs monitoring with immediate-danger potential lifts them to IIb. Also, the companion app gets its own Rule 11 classification. The worst-case rule fixes the overall class as the highest of the two, so plan for IIa as a baseline and IIb as a realistic upside.

Q2: How accurate does a wearable have to be to make a clinical claim?

A2: The accuracy bar depends on the claim. For SpO2, ISO 80601-2-61 sets the performance standard at roughly ±2% accuracy across skin tones. For ambulatory ECG, IEC 60601-2-47 applies. And for heart rate from PPG, there is no single harmonised standard, so manufacturers usually align to FDA wearable guidance and demonstrate motion-rejected ±2 bpm or better.

Q3: Do I need a notified body for a wearable health monitoring device?

A3: Yes. From Class IIa onwards, a notified body audits the QMS and reviews the technical file. Self-declaration is not available for wearables that make any clinical claim. So plan a notified body engagement early since audit slots are tight, often six to twelve months ahead of when the file is ready.

Q4: What standards apply to the firmware in a wearable?

A4: EN IEC 62304 covers the software lifecycle. Most wearable firmware is classified as software safety Class B, and EN IEC 81001-5-1 covers cybersecurity, while ISO 14971 covers risk management. IEC 60601-1 applies to the general safety of medical electrical equipment. Specific sensor or function standards (IEC 60601-2-47 for ECG and ISO 80601-2-61 for SpO₂) are applied on top of these.

Closing Thoughts

Wearables are deceptively simple at the prototype stage and demanding at the product stage. The sensor stack is largely commoditised, but the verification work is what turns a marketing-grade signal into a clinical claim. The power budget drives the architecture in ways that only show up when continuous monitoring meets battery limits. And the MDR classification call brings the companion app into scope and frequently lifts the whole programme one tier higher than the hardware alone.

For teams scoping a wearable health monitoring device for the first time, a structured wearables and custom hardware engagement is the fastest way to fix the sensor stack, the architecture and the regulatory path before committing to a product timeline.