Wearable biosensors are body-worn sensors that turn a physiological signal, such as light absorbed by blood, electrical activity of the heart or glucose in interstitial fluid, into data a device can process. They sit inside watches, rings, patches, chest straps and continuous glucose monitors.
For a product team, the sensor decides what the data can honestly claim. This guide covers the main sensor families, what makes their readings trustworthy, where FDA draws the wellness line, how to evaluate a sensor before building on it and the data quality failures that reach clinicians.
What are wearable biosensors?
Building on wearable sensor data?
Agnotic builds the ingestion, quality checks and clinical integrations behind wearable products, for the client.
Wearable biosensors are sensors worn on the body that detect a biological or physical signal and convert it into a measurement, such as heart rate, rhythm, oxygen saturation, skin temperature or glucose. The raw signal passes through firmware algorithms before any number appears, and those algorithms set much of the data's accuracy.
A biosensor is different from the device around it. The same optical sensor can sit in a fitness band sold for wellness and in a cleared medical device, and the difference lies in the algorithm, the validation and the intended use, not only in the hardware.
For software teams, the practical point is simple. Every reading arrives with a history: the sensor type, its placement, the algorithm version and the conditions at the moment it was taken. Products that keep that history can judge a value; products that drop it cannot.
Which sensor families appear in health wearables?
Most health wearables use one or more of six sensor families. Each one measures a different physical effect and fails in its own way.
- Optical (PPG): Light shines into the skin and a photodiode measures how much returns, giving pulse rate, pulse variability and, with two wavelengths, an oxygen saturation estimate. Motion, poor fit and skin properties affect it.
- Electrical (ECG and bioimpedance): Electrodes measure the heart's electrical activity or the body's resistance to a small current. Single-lead watch ECGs and multi-day chest patches use this family. Electrode contact and sweat affect it.
- Electrochemical: An enzyme or chemical reaction produces a current in proportion to a substance, as in continuous glucose monitors that read interstitial fluid through a small filament under the skin.
- Motion (IMU): Accelerometers and gyroscopes measure movement for steps, falls, sleep staging and tremor, and also flag when other sensors were moving too much to trust.
- Temperature: Thermistors on the skin give trends rather than core body temperature, and ambient conditions shift them.
- Pressure and acoustic: Cuff-based blood pressure, cuffless estimates from pulse timing, and microphones for cough or breathing sounds sit in this group, each with its own validation questions.
Many products combine families. A ring may use PPG, temperature and motion together, with motion data deciding which PPG samples are kept, so an algorithm change in one sensor can alter the output of another.
What makes a biosensor reading trustworthy?
A reading is trustworthy when the team can show how it was measured, under what conditions and how far it can drift from a reference method. Accuracy claims mean little without that context.
- Signal quality: The firmware or app scores each window of raw signal and marks low-quality periods instead of producing a number anyway.
- Motion context: Readings taken during heavy movement carry a flag, because optical and electrical signals degrade with motion.
- Contact and placement: The device records whether it was worn and in contact, and where on the body, since a loose band gives different data from a snug one.
- Calibration and warm-up: Sensors that need calibration or a warm-up period mark readings from that period, as glucose sensors often do.
- Timestamps: Every reading carries the device time, the time zone and the upload time, so delayed syncs do not look like new events.
- Algorithm version: The firmware and algorithm version travel with every value, so a change in results can be traced to an update.
Ask the sensor maker which of these fields its SDK or cloud API exposes. A sensor that returns only a final number leaves the product unable to tell a real change from a bad reading.
Where does FDA draw the wellness line?
FDA draws the line by intended use. Its General Wellness: Policy for Low Risk Devices guidance, issued in final form in January 2026, describes the low-risk products that promote a healthy lifestyle and that FDA does not plan to regulate as devices.
A wearable that estimates a physiological value can still fall outside that policy once its claims move toward diagnosis or treatment. A heart rate shown for exercise is a different claim from an alert that suggests a rhythm disorder, even when the sensor is the same.
Skin pigmentation is a live accuracy issue for optical sensors. In January 2025 FDA issued draft guidance on pulse oximeters for medical purposes that recommends clinical data to evaluate accuracy across the range of skin pigmentations, using both the Monk Skin Tone Scale and an objective measure of skin tone.
Product teams should treat that as a design input even for wellness products. A test plan that includes a wide range of skin tones, ages and body types catches problems before users do.
How should a team evaluate a biosensor before building on it?
Evaluate the sensor in six steps, from the claim the product wants to make to a small study with real users. Each step can end the evaluation early and save a build.
- 1. Write the claim: State exactly what the product will tell users or clinicians, such as overnight heart rate trend or a glucose reading for dosing, because the claim sets the accuracy needed.
- 2. Check regulatory status: Confirm whether the sensor and its algorithm are cleared for that measurement, or sold for wellness only, from the maker's documentation and FDA databases.
- 3. Read the validation: Ask for the maker's accuracy studies, the reference method used, the population tested and the conditions excluded.
- 4. Test the data access: Pull raw or near-raw data, quality flags and metadata through the SDK or cloud API, and confirm sampling rates and delays.
- 5. Run a bench and wear test: Compare readings with a reference device on a small group that spans skin tones, body sizes and activity levels.
- 6. Plan the lifecycle: Ask how firmware updates are announced, how long the model will be sold and what happens to the data API at end of life.
Record the outcome of each step in the design file. When a health system or investor later asks why the product trusts a sensor, the answer is already written.
Keeping quality context in the data model
Quality context is only useful if it survives storage and exchange. Design the data model so that every value can carry its device, method and quality state.
- Device reference: Point each FHIR Observation at a Device resource with the model, serial number and firmware version.
- Method: Record how the value was measured, such as optical or cuff-based, in the method element rather than in free text.
- Missing values: Use dataAbsentReason when a sensor could not produce a valid value, instead of storing a zero or leaving a gap that looks like normal data.
- Quality flags: Keep signal quality scores and motion flags as components or extensions, documented in the product's own profile.
- Raw data store: Keep raw or high-rate data in a separate store with its own retention rules, and send only validated summaries to clinical systems.
Publish these choices as a profile and share it with every team that reads the data. An analytics team that knows a reading carries a motion flag can filter on it; one that does not will average good and bad values together and report a trend that is not there.
Where biosensor data goes wrong
- Flags stripped in transit: The device marks a reading as low quality, but the cloud API passes on only the number, and the flag never reaches the clinician.
- Silent firmware change: A firmware update changes an algorithm, and a population's trend shifts overnight with no clinical cause.
- Wellness data used clinically: A consumer reading sold for wellness feeds a clinical alert, carrying a claim the sensor was never validated for.
- Narrow test group: Accuracy is checked on a small group of similar users, and errors appear only after launch in other skin tones or body types.
- Sync delays read as events: Readings uploaded hours late are treated as current, and an alert fires for a condition that has already passed.
- Mixed units and sources: Readings from two devices with different methods are merged into one trend without labels, hiding a step change.
Each failure has a test: compare cloud output with device output, pin firmware versions in test groups, block wellness sources from clinical rules, widen the test group, and use device timestamps in every rule.
How Agnotic can help
Sensor data becomes useful when its quality travels with it from the device to the person reading it. Agnotic Technologies builds that path for wearable makers and digital health teams: SDK and cloud API ingestion, signal quality and motion flags, device and firmware tracking, FHIR Observation and Device models, and clinical integrations that keep wellness and medical data apart.
Agnotic works with the client's clinical and regulatory teams, who own the claims and the device file, and supplies the software and test evidence those teams need.
Turn sensor data into reliable features
Start with wearable integration, or browse more articles in the wearables hub.
Related reading on Agnotic
Continue with wearable data in the EHR, wearable app builds, connected medical devices and the future of care.
