ChatGPT
Perplexity
Claude
Google AI
Wearable technology in healthcare means any body-worn device that collects health data — smartwatches, fitness trackers, ECG patches, continuous glucose monitors, biosensors and smart clothing. The useful question is rarely which devices exist. It is what the data from each one lets you actually do.
A wrist sensor that estimates heart rate and a prescribed cardiac patch both produce a number called heart rate. One supports a nudge to move more. The other supports a clinical decision. Treating them as the same data is the mistake I see most often when a team scopes a monitoring programme.
The category now spans four broad uses: wellness and activity tracking, continuous physiological monitoring, diagnostic sensing, and therapy delivery through devices like wearable drug pumps and neuromodulation bands. What unites them is continuity. A clinic visit gives you one reading in an unusual environment; a worn device gives you a stream from ordinary life.
Those streams feed two different destinations. Some go to the patient as feedback. Some go to a clinical team as part of a monitoring programme, which is where remote patient monitoring picks up, the workflow, staffing and reimbursement side of running one. This draft stays on the device and the data.
Key Takeaways
- Wearable technology in healthcare covers any body-worn device that collects health data, from consumer smartwatches to prescribed continuous glucose monitors. The gap between those two ends is the whole story.
- FDA clearance attaches to a specific feature and a specific claim, not to a device. A watch with a cleared ECG feature is a cleared ECG device and a consumer wellness product everywhere else.
- Wrist optical heart rate is reliable at rest and degrades with motion, cold and poor fit. It is strong for trends and weak for single readings.
- Most wearable data reaches an application through Apple HealthKit or Google Health Connect rather than from the device directly, which makes the phone a dependency in your architecture.
- Adherence decides outcomes. A programme built on a device patients stop wearing produces gaps, and gaps are what clinical teams have to work around.
- Supporting a second device family is rarely a small addition. Each vendor brings its own API, its own data shapes and its own sampling behaviour.
Types of healthcare wearable devices and what each one measures
Device names travel badly. What matters underneath is the sensor and how often it samples.
| Category | What it measures | Sensor behind it | Typical data rate |
|---|---|---|---|
| Smartwatches and fitness trackers | Heart rate, activity, sleep estimates, SpO2 estimates | PPG (optical, light through skin), accelerometer | Continuous to periodic, often summarised before you see it |
| Wearable ECG | Cardiac rhythm | Electrodes recording electrical activity | On demand, or continuous on a patch |
| Continuous glucose monitors | Interstitial glucose | Electrochemical sensor under the skin | Every few minutes, continuously |
| Blood pressure wearables | Blood pressure | Oscillometric cuff, or cuffless estimation | On demand |
| Smart clothing and patches | Respiration, posture, temperature, ECG | Textile electrodes, embedded sensors | Continuous while worn |
| Biosensor patches | Temperature, hydration, biochemical markers | Chemical and thermal sensing | Continuous while worn |
Two details in that table do more work than the device names. PPG, photoplethysmography, works by shining light into the skin and reading what bounces back as blood moves. It infers heart rate rather than measuring electrical activity directly, which is why it behaves differently from ECG.
Data rate matters because many consumer devices summarise before they hand data over. You may receive an average where you assumed a reading.
The device name tells you almost nothing. The sensor, the sampling rate and the claim tell you everything.
The Wearable Data Fidelity Ladder: what each tier of data lets you do
Rather than sorting devices by price or brand, sort the data by what it permits. Four tiers cover almost every case I see.
| Tier | What it is | What it supports | What it does not support |
|---|---|---|---|
| 1 — Engagement data | Steps, general activity, sleep estimates from consumer devices | Behaviour nudges, adherence signals, wellness programmes | Any clinical decision |
| 2 — Trend data | Resting heart rate, heart rate variability, SpO2 estimates observed over time | Noticing a change worth a clinician looking at | Treating a single reading as a measurement |
| 3 — Cleared-feature data | A specific feature cleared for a specific claim, such as an ECG feature for detecting atrial fibrillation | The cleared claim, and nothing beyond it | Any other conclusion drawn from the same device |
| 4 — Prescribed device data | Continuous glucose monitors, cardiac patches, dedicated monitors validated for clinical use | Clinical decisions inside the validated indication | Use outside the validated population or indication |
Tier three is where most confusion lives. Clearance attaches to a feature and a claim. It does not spread across the device.
The practical use of the ladder is to run it backwards. Start from what a clinician will do with the output. If they will act on an individual reading, you need tier three or four. If they will act on a change over weeks, tier two may be enough. If the output is feedback to the patient, tier one is often the right answer and the cheapest one.
Programmes go wrong when they need tier-four data and are built on tier-one devices. The numbers look plausible, the dashboard fills up, and nobody can safely act on any of it.
How accurate is wearable health data, really?
Accurate enough to be useful, and not accurate enough to be treated as a clinical measurement unless the device was validated for that purpose. The detail sits in the failure modes.
Wrist optical heart rate is generally good at rest and degrades under movement. The sensor reads a light signal that motion disturbs, so vigorous activity, cold hands restricting peripheral blood flow, a loose strap, and tattoos or skin characteristics affecting light absorption all introduce error. Validation studies have also documented variability across skin tones for some optical sensors, which is a design consideration rather than a footnote.
SpO2 estimates from consumer wearables carry wider tolerances than a clinical pulse oximeter, and several manufacturers label them as wellness features rather than medical measurements for exactly that reason.
The workable position is straightforward. Consumer wearable data is strong at showing you that something changed and weak at telling you precisely what a value is right now. Build around the change, not around the number.
That has an architectural consequence. A system that triggers on a fixed threshold will generate false alerts from artefact. A system that triggers on a sustained deviation from the individual’s own baseline gets far fewer and far better signals.
How wearable data reaches a clinical system: HealthKit, Health Connect and FHIR
Most teams picture a direct line from device to server. In practice the route usually runs through the phone.
On iOS, Apple HealthKit is the shared store where devices and apps write health data, and where your app reads it with the user’s permission. On Android, Google Health Connect plays the same role. Supporting those two platform layers reaches a large share of consumer devices through one integration each, rather than one integration per manufacturer.
Direct vendor APIs still matter where a specific device is clinically necessary, or where you need data the platform layer does not carry. They are the exception rather than the default.
The path then runs in four steps:
- Device to platform. The wearable syncs to HealthKit or Health Connect, usually via the manufacturer’s own app.
- Platform to your application. Your app reads with granular, per-data-type permission the user can revoke at any time.
- Different devices report different units, different sampling behaviour, different definitions of the same metric, and overlapping records from multiple sources. This layer is where the engineering effort actually sits.
- Into the record. Clinically meaningful values map to FHIR Observation resources, the standard structure for a clinical measurement, with coded identifiers so the receiving system knows what the number is.
One more decision belongs here. Raw continuous sensor data at full resolution is a poor fit for an electronic health record, both technically and clinically. The common pattern is a dedicated store for the stream, with summaries and flagged events written into the chart.
Where wearable programmes break: adherence, gaps and signal loss
Most wearable programmes that disappoint do not fail on sensor accuracy. They fail because the device was not on the patient.
The failure modes are mundane and predictable:
- Not worn. Interest drops after the first few weeks, particularly where the device gives the patient nothing back.
- Not charged. Continuous sensing shortens battery life, and charging happens at unpredictable times.
- Worn wrongly. A loose strap or the wrong wrist position produces data that looks valid and is not.
- Connectivity gaps. Data arrives in bursts when the phone reconnects, out of order and late.
- Seasonal and situational drift. Cold weather, showering, work environments and travel all change wear patterns.
Each has an engineering response, and none of them is a sensor upgrade. Record non-wear explicitly rather than interpolating through it, because a missing reading and a normal reading are different things. A system that silently treats absence as stability will mislead a clinician.
Design ingestion for late and out-of-order data. Surface data quality to the clinical team alongside the values, so they can see what they are looking at.
Adherence is the variable that decides whether a wearable programme works. Every other engineering decision sits downstream of whether the device is on the patient.
Choosing devices patients already own helps adherence and hurts consistency, because you inherit a mixed fleet with different sampling behaviour. Supplying a single device does the opposite. There is no free answer, and the trade-off is worth making deliberately at scoping rather than discovering at month three.
Privacy, security and regulation for health wearables
Three boundaries matter, and each one catches people out in a different way.
HIPAA follows the relationship, not the data. A patient’s own fitness tracker data sitting with them and the manufacturer is generally outside HIPAA, because no covered entity is involved. The moment that data flows into a provider’s system, or into an app operating on a provider’s behalf, it becomes protected health information and the obligations attach.
Device cybersecurity is now a statutory requirement. Devices that meet the definition of a cyber device carry premarket cybersecurity obligations under Section 524B of the Federal Food, Drug, and Cosmetic Act, covering a software bill of materials and a plan for monitoring and patching vulnerabilities after release.
Some wearables are regulated devices. Software or hardware performing a medical function may fall under FDA device rules as Software as a Medical Device, and the boundary turns on what the product concludes rather than what it measures. The full boundary, along with the interoperability and EU obligations beside it, sits in the digital health compliance post, three sentences here and a link out, per the lane boundary.
Where wearable technology in healthcare is heading
Three shifts are already visible in shipping products rather than in roadmaps.
Sensing is moving off the wrist. Patches, rings and textile-based sensors avoid the motion and fit problems that limit wrist optical measurement, and they tend to be worn more consistently because they demand less attention.
On-device processing is growing. Running signal analysis on the device rather than in the cloud reduces the volume of raw data that has to move, shortens the path to an alert, and keeps more raw physiological data off your servers. That last point simplifies a surprising number of privacy questions.
The regulatory picture around adaptive algorithms is maturing. Where a model in a cleared device changes over time, there is now a defined route for pre-authorising those changes rather than resubmitting for each one, which changes how release processes are designed for regulated wearable products.
What has not changed is the constraint underneath all of it. Better sensors produce better data from a device that is being worn. Adherence remains the ceiling.
Conclusion
The useful decision is rarely which wearable to choose. It is which tier of data your use case genuinely needs, because that answer sets everything downstream, the device, the integration, the regulatory position, and how much weight a single reading can carry.
Work out the tier first. A programme that needs tier-four data and is built on tier-one devices will produce numbers that look right and cannot be acted on.
If you are scoping a monitoring programme rather than evaluating devices, the clinical workflow, staffing and reimbursement side is a separate problem, and a bigger one.
Scoping a monitoring programme?
Our remote patient monitoring guide covers the clinical workflow, staffing and reimbursement decisions that sit on top of the hardware.
Read the remote patient monitoring guide →
