A phone knows where you are because you carry it. A wearable can know when your heart rate changes while you sleep, how often you wake, how hard you train, and whether your routine is becoming irregular. That difference is easy to underestimate because the device looks like a watch or a ring, not a medical record.
The data is continuous, intimate, and inferential
A phone usually produces episodic signals: an app opens, a location is requested, a photo is taken, or a message is sent. A wearable is designed to sample continuously. Depending on its sensors and settings, it can record heart rate, heart-rate variability, blood oxygen estimates, skin temperature, movement, sleep windows, workout routes, elevation, and device identifiers. Some devices also collect microphone, contactless, or stress-related signals.
None of those fields needs to say “depression,” “pregnancy,” or “cardiac risk” to become sensitive. Timing and correlation can do the work. A model can infer a change in sleep, a new commute, a period of illness, or a medication routine from ordinary measurements. The direct reading may be noisy; the pattern across weeks can still reveal a great deal.
Health data becomes more revealing when it is joined: a timestamped pulse sample, a location trace, a calendar routine, and a model’s confidence score can describe a person more precisely than any one field.
This is why “the watch only records steps” is an incomplete privacy argument. The important question is what the service can derive after combining steps with sleep, location, age, device model, and account history.
Permissions are an access contract, not a privacy guarantee
On iOS, an app may request read or write access through Apple HealthKit. A training app might ask to read heart rate and workouts while requesting permission to write exercise sessions. On Android, an app can use Health Connect permissions such as HeartRateRecord, sleep sessions, steps, or distance. The labels are useful, but they are not the entire contract: the app’s server may receive a copy after synchronization, and a connected analytics service may receive a derived result.
Review permissions at three levels:
- Device: Which sensors are enabled? Is continuous monitoring necessary, or would a workout-only schedule be enough?
- Phone health store: Is the app allowed to read historical records, write new records, or both? Can it read categories unrelated to its stated feature?
- Cloud service: After sync, what leaves the phone? Which OAuth scopes, export jobs, webhooks, or partner integrations are active?
Permission prompts answer “may this app access this category?” They do not necessarily answer “will the provider use it to train a model, retain it for five years, sell an audience segment, or combine it with a data broker profile?” Read the privacy notice and the app’s deletion controls with the same care you give the prompt.
What a wearable API can expose
An API is not just a button that returns a daily score. A well-authorized wearable or health-platform API can expose timestamped samples, aggregates, and context. The exact fields vary, but a technical integration may receive:
- Measurements: heart rate at intervals, resting heart rate, HRV, calories, oxygen estimates, steps, temperature, or respiration-related values.
- Events: sleep start and end, awakenings, workouts, falls, irregular rhythm notifications, menstrual-cycle entries, or recovery scores.
- Context: GPS points, elevation, timezone, device model, firmware, battery state, and whether a reading was manually entered.
- Identity and authorization: an account identifier, email, age range, locale, OAuth refresh token, and a record of which scopes were approved.
APIs also expose operational facts. A request for data from the last 30 days tells a provider something about the app’s behavior. Webhooks reveal when a new workout or sleep event occurs. A “read all history” scope is materially different from “read today’s workout.” Engineers should minimize both the fields and the time window, cache only what the feature needs, and revoke tokens when a connection is removed.
Example minimum scope review
read:heart_rate → needed for a live training zone?
read:sleep → needed for the stated recovery feature?
read:location → needed after the route is complete?
history:all → why is a narrow date range not enough?
write:workout → does the user expect this app to alter the health record?AI changes the question from collection to inference
AI can summarize a week, predict recovery, detect anomalies, coach a workout, or rank a user for an offer. Those features can be useful without being mysterious, but the privacy risk moves from raw collection to invisible conclusions. A system that never stores a diagnosis may still store a risk score, a “likely fatigue” label, a personalized baseline, or a confidence value. Those outputs can affect notifications, pricing, eligibility, and what a human operator sees.
Ask four technical questions. Is the model running on the device or in a provider cloud? Are raw samples sent to the model, or only aggregates? Are prompts, embeddings, and outputs retained for debugging or training? Can a user correct an inference and have the correction propagate to downstream systems? “AI-powered” should describe a data flow, not substitute for one.
A responsible design separates telemetry from identity where possible, limits access to the smallest useful dataset, logs model versions, and provides an explanation in ordinary language. It also sets a purpose boundary: a model built to coach sleep should not silently become an employment or insurance risk classifier.
Encryption protects the channel; governance protects the meaning
Use TLS for device-to-phone and phone-to-cloud transport, authenticated encryption for stored records, and managed key rotation for backups. Those are baseline controls. They do not make a provider unable to read the data. A service may decrypt records in order to calculate a score, search an account, moderate content, or run an inference.
For consumers, the practical questions are: Is encryption used in transit and at rest? Are backups encrypted separately? Who can access production databases? Are support exports time-limited and audited? Are tokens stored in a hardware-backed keystore on the phone? Does the provider offer deletion of raw data, derived data, and backups, or only deletion of the account view?
End-to-end encryption is a stronger property than “encrypted.” If the provider can operate the recommendation engine over your raw health history, it probably has a point where the plaintext or a reversible representation is available. That can be acceptable when the purpose is clear and controls are strong, but it should be stated plainly.
Retention decides how long a mistake can travel
Retention is a product decision, not a footnote. A service may keep raw samples for 30 days, daily aggregates for two years, model features indefinitely, and audit logs longer still. Deleting the app does not necessarily delete the cloud account. Disconnecting HealthKit or Health Connect stops a future permission path; it may not delete records already exported to a provider or partner.
Look for a retention schedule that distinguishes raw data, derived scores, backups, support tickets, and legal holds. Prefer systems that let you delete a connection, an individual data source, and the account separately. If you share an export, assume the recipient’s retention policy now matters too. Keep a personal record of what you authorized and when; screenshots of permissions and cancellation confirmations are useful evidence.
Insurers, employers, and the boundary of voluntary sharing
Wearable programs often offer a discount, wellness benefit, coaching service, or rewards in exchange for activity data. The benefit may be real, yet “voluntary” can feel different when a price, promotion, or workplace culture creates pressure. Before enrolling, identify the legal entity receiving the data, the exact fields, the evaluation period, and whether the program shares raw records or only a score.
With insurers, ask whether the data affects underwriting, a wellness reward, claims review, or only an individual dashboard. With employers, ask whether the employer receives named records, aggregate statistics, participation status, or nothing beyond a vendor invoice. A vendor may operate the program while the contract gives it separate rights to analyze or retain data. Never infer a boundary from a friendly app screen; read the program terms.
| Recipient | Useful question | Safer default |
|---|---|---|
| Wearable maker | Does the core feature require cloud history? | Local processing and shortest retention offered. |
| App developer | Which fields and date range are sent? | Per-feature scopes, no all-history access. |
| Insurer | Is the output a reward, price input, or eligibility signal? | Written purpose and appeal path. |
| Employer | Can a manager identify an individual? | Aggregated reporting and no participation penalty. |
A practical trust checklist
- List every sensor, health category, location field, and identity field the feature could use.
- Grant the narrowest iOS HealthKit or Android Health Connect scope; deny unrelated history.
- Confirm whether processing happens on-device, in the provider cloud, or with a third party.
- Check TLS, encryption at rest, key custody, production access, backups, and breach notification.
- Find retention periods for raw samples, derived scores, model inputs, logs, and backups.
- Read insurer or employer terms for named data, aggregate reports, pricing, eligibility, and appeals.
- Test disconnect, token revocation, export, correction, and deletion before relying on the service.
- Review permissions quarterly and after an app, firmware, ownership, or policy change.
For a technical review, draw the data flow from sensor to device, health store, API, model, recipient, and deletion job. Put an owner and a measured control at every arrow. If a team cannot show where a raw sample goes after a user presses “delete,” trust is still an assumption.
Frequently asked questions
Are wearable health data the same as phone data?
No. Wearables can collect continuous, intimate signals such as heart rate, sleep stages, location, and movement that a phone may not observe.
What does a wearable API expose?
Depending on permission, an API may expose timestamped measurements, summaries, device metadata, location, profile data, and OAuth access scopes.
Can insurers or employers receive wearable data?
They can receive data when a person authorizes a program or shares an export, but the recipient, purpose, retention, and deletion terms must be checked.
What should I check before enabling a health-data app?
Check permissions, purpose, encryption, retention, third-party sharing, account deletion, and whether AI training or inference uses the data.
What comes next
Wearables will become better at sensing context while disappearing into ordinary objects: rings, earbuds, clothing, and medical-adjacent devices. AI will turn more streams into recommendations and classifications. The winning privacy model will not be “collect nothing,” because useful care and coaching need data. It will be visible boundaries: narrow permissions, local processing where practical, short retention, accountable recipients, and a real way to revoke trust.
Need help making health data trustworthy?
NSI helps teams turn sensitive data flows into clear, testable controls that people can understand and audit.
CONTACT NSI