Contact

What medical-grade wearable data means for the app you build on it

We worked with CardioMood on a medical-grade wrist wearable, and as technology partner with Corsano Health, which makes CE-MDR and FDA cleared patient-monitoring devices. Founders ask us regularly whether they need a device like that or whether a consumer smartwatch would do. The answer depends on what you are going to claim and what you are going to do with the data. This is what medical-grade changes in practice.

What the clearance means and what it does not

CE-MDR is the European medical device regulation; FDA clearance is the American equivalent. Both mean the manufacturer has shown, with documented evidence, that specific measurements from the device are accurate enough for a specific intended use, and that the company has a quality system behind the product. A device cleared for continuous heart rate and oxygen saturation is not thereby cleared for everything its sensors could compute.

For the software you build on top, this changes three things. The data has a known accuracy, validated against clinical references, so when a reading moves you can treat it as a signal rather than a guess. The device will not change its algorithms under you without a documented process. And your software has to respect the line: present the cleared measurements as what they are, and do not dress up a derived metric as a diagnosis.

A consumer wearable has none of these guarantees, and it is not pretending to. The optical sensor may be excellent, but the firmware can change with an app update, the raw signal may be inaccessible, and the vendor’s terms usually forbid medical claims. For a sleep-coaching or fitness product that is fine. For a product where a coach or a clinician will act on a change, it is not.

What the data looks like

A continuous device produces a lot of numbers. Heart rate every few seconds. Beat-to-beat intervals from which heart-rate variability is computed. Blood pressure estimated from the pulse wave, calibrated against a cuff. Sleep stages derived from motion, heart rate and HRV through the night. Activity, skin temperature, oxygen saturation. On CardioMood this runs for thousands of people wearing the device around the clock, which is where the lessons below come from.

HRV is the metric people build on and the one that punishes carelessness. It varies with time of day, posture, breathing, alcohol, a cold, a late dinner. A single value tells you almost nothing. What is useful is the night-time resting value, measured consistently, compared against that person’s own history.

Blood pressure from a wrist device is a cleared measurement with a calibration requirement, and the calibration drifts. Build the reminder and the cuff workflow into the app, or the data goes slowly wrong without anyone noticing.

Sleep data looks precise and is less so. Stage boundaries are estimates. Total duration and the resting heart rate during sleep are the reliable parts. Make the product depend on those and treat the hypnogram as colour.

Baselines and noise

The first thing the platform does with a new user is nothing. For one to two weeks it learns what normal looks like for that person: their resting heart rate, their night-time HRV distribution, their usual sleep window. Only after that can a change mean something. CardioMood’s alerts are about deviations from a personal baseline, because population norms for HRV are so wide that a value in the healthy range for one person is a warning sign for another.

motion off alert baseline hrv nights
Nightly HRV against a personal baseline band: excluded nights are hollow, and the alert fires when the line stays below the band.

Noise comes from everywhere. The device slips on the wrist. The user takes it off to charge and a six-hour gap appears in the night. A workout or a fever spikes everything. Motion corrupts the optical signal and the beat intervals from that window are garbage. The pipeline has to detect all of this before it computes anything, with quality flags that travel with the data, so the chart a coach sees does not show a stress event that was a shower.

We treat every derived metric as having a confidence attached, and we show the gaps rather than interpolate across them. Coaches trust a chart with holes in it more than a smooth one that lied to them once.

Background sync and the phone

The device talks to the phone over Bluetooth, and the phone talks to the server. Both mobile operating systems kill background work to save battery, and each year they do it more aggressively. A companion app that syncs only when open will have days-old data when the coach looks.

This is the least glamorous and most time-consuming part of a wearable product. It means careful use of the background modes each platform allows, a device that buffers when the phone is away, a sync that is idempotent so retries never duplicate data, and monitoring on the server that notices when a fleet of devices goes quiet after an OS update. The Corsano partnership is where we learned how large a share of the total effort this is. Budget for it.

Health data is special-category data under GDPR and protected health information when it touches a US covered entity. These are engineering decisions made on the first day, and the privacy policy is written afterwards to describe what the code already does.

Consent is a record, with a version and a timestamp, and the app behaves differently depending on what the user has agreed to. Access is logged: every read of a person’s data by a coach, a clinician or an admin is recorded, and the user can see it. Data is minimised: the server keeps what the product needs, and raw signals it does not need are not kept. Deletion is a function that works end to end, including backups and the analytics store. Encryption at rest and in transit is the easy part.

The professional layer is where it gets specific. A coach sees their own clients and nothing else. A client can revoke a coach. A clinic has a role structure the product has to model. Getting this right late is a rewrite; getting it right early is a week.

What to build on top

The product is what a person does with the data. On CardioMood that is a coach seeing that a client’s night-time HRV has been sliding for three weeks while the client reports feeling fine, and having that conversation early. The platform computes the baseline, detects the slide and raises an alert in plain language; the coach decides what to do.

The same shape applies to clinics watching patients after discharge, corporate programmes watching for burnout, and research teams running studies. Baselines, anomaly detection, summaries a non-specialist can read, and a portal with the right access model. The AI layer sits on top of that, and it only works when the data underneath is clean and the quality flags are honest.

If you have a device, or you are choosing one, the wearables and health tech page covers what we build, and you can write to us about the product you have in mind.

Technology partner

CardioMood

A physiological early-warning system for executive coaching with continuous medical-grade stress, recovery and performance data. We built the platform and apps.

About CardioMood

Technology partner

Corsano Health

Medical-grade wearables for continuous patient monitoring in hospitals, at home after discharge and in clinical research. S12V Labs is a technology partner.

About Corsano Health

More writing

  1. Keeping a fleet of wearables synced through phones that want to sleep

    BLE reconnection, iOS background modes and Android Doze, device buffering, idempotent uploads, clock drift, and fleet monitoring that catches a quiet device.

  2. Building an evaluation set from past cases, and keeping it alive

    How we build and keep an evaluation set for an LLM feature: choosing cases, labelling with the people who do the job, size, and growing it from production.

  3. Classifying messages at line rate

    Putting a classifier inline in a messaging platform: the millisecond budget, small models on your own traffic, the uncertain tail, fail-open versus fail-closed.