The wrist-worn sensor gets the attention, but the software around it carries most of the risk. Wearable health device software has to pair over Bluetooth, read and write shared health data, and make claims that don't turn a wellness product into a regulated medical device.
This guide takes the layers in the order you'll build them, grounded in Android's developer documentation, a law firm's analysis of the FDA's 2026 guidance and the FTC's policy statement on health apps.
What wearable health device software is made of
Three parts make up the system: the device that senses, a phone app that connects to it, and a place where the data ends up, whether that's a backend, a health platform on the phone or both. As analysis rather than a rule, the phone app is where most decisions pile up, because it handles pairing, permissions, storage and every user-facing screen.
The wearable itself is usually a peripheral that does one job well. Your wearable health device software decides what its readings mean, who sees them and what you're allowed to say about them.
How the phone connects over Bluetooth Low Energy
Android supports Bluetooth Low Energy in the central role, so your app scans for advertisements while the wearable, as the peripheral, advertises and waits for a connection. According to Android's BLE overview, two peripherals can't talk to each other, and neither can two centrals. The phone always starts the conversation, so this part of the wearable health device software is written around scanning and connecting.
BLE is designed for significantly lower power consumption than classic Bluetooth, which is why heart rate monitors and fitness devices use it. After connecting, the phone acts as a GATT client requesting data and the tracker acts as the GATT server answering. Every current BLE application profile builds on GATT.
Four terms from the same documentation will come up in every planning meeting:
- A service is a collection of characteristics, such as a heart rate monitor service.
- A characteristic holds a single value, like one heart rate measurement.
- A descriptor explains a characteristic's value, for instance its unit or acceptable range.
- A profile is a Bluetooth SIG specification for how a device behaves in an application, and one device can implement several.
The connection flow runs in a fixed order: confirm Bluetooth is available, scan, connect to the GATT server, discover services and characteristics, then transfer data. BLE suits small amounts of data, so a design that tries to push bulky raw streams over it is fighting the protocol.
One line in that documentation deserves a place on your security checklist. Data exchanged over BLE after pairing is accessible to all apps on the device, so anything sensitive needs security at the application layer. We cover the wider connected-device picture in our piece on healthcare IoT software.
Where Health Connect fits on Android
Health Connect is Android's platform for sharing health and fitness data between apps. Your app writes its readings in, other apps with the user's permission read them out, and the platform stores the data in a structured form that accounts for how each type is measured.
Its documentation sorts data into three patterns: instantaneous readings such as heart rate, cumulative values such as step count, and session-based data such as sleep. Pick the right pattern for each metric early, since it shapes how wearable health device software stores and charts it later. The platform also supports medical records in FHIR format, with read and write APIs.
It works on Android 9 (SDK 28) and higher, and the SDK lets you check whether the API exists on a given device. Apps can also read a user's data continuously, including while running in the background, for analysis and sync.
The timing matters this year. Per the same documentation, Google Fit APIs are supported until the end of 2026, and a migration guide exists. If your wearable app still leans on Fit, that deadline is weeks away as of late October.
When does a wearable cross into FDA territory?
It crosses the line when its claims or alerts point at disease or clinical action. On January 6, 2026, the FDA issued a revised General Wellness Guidance that supersedes the 2019 version, and Cooley's analysis of the update reports that it expressly brings wearables under enforcement discretion.
That covers noninvasive products that estimate, infer or output physiological parameters, with blood pressure, oxygen saturation, blood glucose and heart rate variability given as examples. Cooley notes the FDA issued it as a final document, skipping the usual notice-and-comment period.
The room is conditional. Per Cooley, the outputs have to meet all of these:
- Be used only for wellness and pose no safety risk.
- Not substitute for an FDA-authorized medical device.
- Not prompt or guide clinical action or medical management.
- Not mimic clinical values unless validated, for example through manufacturer testing and peer-reviewed literature.
Notifications get a narrow lane. An alert can tell a user to seek a healthcare evaluation when a reading falls outside ranges appropriate for general wellness use. It can't name a disease, call a result abnormal or diagnostic, or include clinical thresholds or treatment recommendations.
Marketing counts as much as code. Cooley lists claims of clinical accuracy or "medical- or clinical-grade" status, and intended-use statements about diagnosing, screening or managing a disease, among the things that push a product into device territory.
Our view: decide which side you're on before the first sprint. If clinicians or care teams will act on your readings, plan for the regulated path and read our overview of software as a medical device. Cooley also points out the guidance is internally awkward, since it speaks of helping people live well with chronic conditions while barring references to specific diseases, so expect to interpret rather than just comply.
Privacy duties that apply even outside HIPAA
Consumer wearable health device software can fall outside HIPAA and still carry breach obligations. In a policy statement dated September 15, 2021, the FTC said its Health Breach Notification Rule covers apps and connected devices such as wearable fitness trackers that collect health information, can draw data from multiple sources and aren't covered by a similar HHS rule.
The FTC's own example is a health app that collects information from a consumer and can sync with a fitness tracker through an API. That describes a large share of wearable apps, including any that read from Health Connect.
The rule treats health data "disclosed or acquired without the consumers' authorization" as a breach, which is wider than a hack. Read that way, wiring a third-party SDK into a health screen without a clear user permission is a design decision with legal weight.
The FTC page quotes penalties of up to $43,792 per violation per day. That dates from 2021 and may have been adjusted since, so check the current amount before quoting it.
Scoping a first release
Good wearable health device software starts with one device, one or two metrics and one platform. Each extra sensor adds a service to discover, a data type to map and a claim to review, so the cheapest way to learn whether users care is a narrow build that does one thing reliably.
If the roadmap includes a clinician dashboard, a member portal or an insurer feed, design the backend for them now. Our guide to building a healthcare SaaS platform covers that side, and the staging advice in how to build a healthcare MVP applies directly.
When we designed and built OptimalMD's digital product end to end, from design through development to launch, it covered the website, the members portal and the mobile app, which you can read about in the OptimalMD case study. If you're scoping something similar, our apps and SaaS team can help.
Before the first screen is designed, write the claims sheet: every sentence the app, the store listing and the website will say about what the wearable measures. Check each one against the FDA conditions above, because a single "clinical-grade" in the marketing copy can undo a careful build.
Frequently asked questions
Does wearable health device software need FDA clearance?
Not necessarily. Under the 2026 General Wellness Guidance as Cooley describes it, noninvasive wellness wearables can fall under enforcement discretion, but references to specific diseases, diagnostic thresholds or clinical-grade accuracy push a product toward device status.
Which Android versions support Health Connect?
Android 9 (SDK 28) and higher. The SDK lets your app check whether the Health Connect API is available on the device it's running on.
Is Google Fit still an option for a new wearable app?
Not for long. Android's documentation says Google Fit APIs are supported until the end of 2026 and points developers to a migration guide for Health Connect.
Can the app read health data while it's in the background?
Yes. The Health Connect documentation says apps can continuously access a user's health data, even when running in the background, for analysis and sync.
Cover photo by Ketut Subiyanto on Pexels
Sources
- Bluetooth Low Energy overview — Android Developers
- Health Connect — Android Developers
