Data Ownership in Wearable Health Products: Who Owns the Data and What You Build on It

Introduction

"Who owns the data?" tends to get asked late. In our conversations with health product teams, it usually surfaces during an enterprise buyer's security review, or when the team decides to change vendors and opens the export for the first time. By then, the answer was fixed months earlier by decisions that were not framed as ownership decisions at the time.

Data ownership is the ability to access, use, change, and move a dataset without needing anyone else's permission to do it. For a product built on wearable data, that definition has to be applied layer by layer, because the data a user's Garmin sends you and the thing your product sells are different assets.

This article covers what data ownership means in a wearable stack, the four layers where it gets lost, how ownership differs from stewardship and control, and how to test your own exit path before you need it. It stays on the product and engineering side. Where your data physically sits is a different question, covered in our piece on data residency as an architecture decision, and the compliance angle is in self-hosted infrastructure and health data compliance.

What Data Ownership Means for a Health Product

The data owner definition used in data governance is a useful starting point: a data owner is the person or team accountable for a dataset, including who can use it and what happens to it. In a health product, that accountability stays with the product team even when the pipelines and scoring run on someone else's platform. The ability to act on it, by exporting or reprocessing the data, can end up with the vendor.

Wearable data makes this harder than most product data, for two reasons. The product does not produce the raw data itself: it arrives from Apple Health, Garmin, Oura, Whoop, and other sources, each with its own format, and some with limits on how far back history can be fetched. And most of the value is created after the data arrives, first by merging records from different devices into one consistent format, then by the scores and insights built on top. A team can have full access to its users' raw sleep sessions and still not own the part of the product that makes it different from a competitor's. We covered how that value stack forms in what it takes to build reliable health scores from wearable data.

Personal data ownership, meaning what users themselves control, is a related but separate topic. Users decide which providers to connect and can disconnect them. Everything below is about what the product team holds once that access has been granted.

What Determines Data Ownership in a Wearable Stack

In practice, data ownership in a wearable product is determined by four layers, and each one can end up with a different owner.

The table runs from the most commoditized layer to the most valuable one. Raw data from a given provider looks the same for every product that connects to it, while the scores and models at the bottom are specific to you. In our experience, ownership problems cluster in the bottom two rows, while due diligence questionnaires tend to ask about the top one.

The raw payload layer is the easiest to overlook. When a provider changes a field or you fix a parsing bug, the only way to correct past records is to reprocess them from the original payloads. If those payloads were discarded after processing, or only ever existed on a vendor's servers, the historical errors stay in your dataset.

Where Data Ownership Gets Lost

On sales calls, the ownership gaps we hear about follow four patterns, and each one starts as a reasonable shortcut taken early, when getting data flowing mattered more than what would happen at exit.

The Score Lives Inside the Vendor's Platform

Ready-made scores are one of the main reasons teams choose a platform: they ship a readiness or sleep feature in weeks instead of months. What they receive, though, is a number without the formula or the per-user baselines behind it. If you switch vendors, you cannot reproduce it, and users notice when a sleep score that read 78 yesterday reads 64 today on identical data.

Before relying on a vendor's scores, ask whether you get the algorithm or only its output. If you only get the output, you will have to rebuild the score, and recalibrate it for your users, whenever you move.

The Export Arrives in the Vendor's Own Schema

Most platforms offer an export, and most exports technically contain your data. The difficulty is its shape: records come out in the vendor's own schema without the device priority rules, so the link between a workout recorded by the watch and the same workout synced from the cloud has to be reconstructed by hand. Until that mapping project is done, the data is yours on paper but hard to put to work. We walk through what that mapping involves in what a wearable platform migration actually looks like.

History You Cannot Get Back

Some providers limit how far back their APIs return data. Garmin, for example, returns at most 30 days before the date a user connected, and Polar only returns data from the consent date onward. If a vendor held the only complete copy of your normalized history and the export is partial, anything older than those backfill windows cannot be recovered.

This matters more for health products than for most software, because the features users value depend on longitudinal data. Personal baselines and any score that compares today against a user's own normal need weeks or months of continuous history, so losing it sends every user back to a starting baseline.

Provider Connections Registered in Someone Else's Name

Teams are often surprised by this one when we raise it on a call. If a vendor registered the developer applications with Garmin, Oura, and the other providers on your behalf, the connections between your users and those providers belong to the vendor's credentials. Moving away means every user has to reconnect their devices through your own provider login and consent screens. For a product with an active user base, that is a planned re-consent campaign, and some share of users will not complete it.

Data Ownership vs Data Stewardship, and Where Control Fits

Data ownership vs data stewardship is a distinction data governance teams use, and it maps well onto the vendor decisions a health product makes.

Ownership is accountability plus the right to decide what happens to the data, including moving it. Stewardship covers the day-to-day work of keeping data accurate and usable, which in a wearable product means running pipelines, handling provider changes, monitoring sync health, and fixing data quality issues. Between the two sits control, the technical ability to access, export, delete, and reprocess the data yourself, and in practice this is the concept that decides how an exit goes.

Stewardship is the part that can safely be delegated. Many teams should hand it to a platform or a partner, because running wearable pipelines well takes specialized experience, as we described in the top challenges of working with wearables in healthcare. Trouble starts when control is handed over along with it. A healthy arrangement is a partner who runs the system while you keep the provider credentials and the code, so ending the relationship becomes an operational handover.

Vendor Lock-In in Wearable Health Products

Vendor lock-in is the situation where leaving a vendor costs more than staying, even after staying has become the worse option. In wearable products it builds up in small, separate steps: provider credentials in the vendor's name, a proprietary schema, vendor-computed scores, and history held only on the vendor's side. Each step feels harmless on its own, and together they turn a vendor switch into a project with its own roadmap.

Per-user pricing is often what makes a team look at its exit options for the first time, a pattern covered in why teams outgrow SaaS wearable aggregators. By the time pricing becomes the trigger, the ownership gaps above decide how expensive the move will be.

Avoiding vendor lock-in with wearable data comes down to keeping hold of the layers that are hard to rebuild:

• Store raw provider payloads yourself, even when a vendor processes them.
• Register provider developer credentials in your own name from the start.
• Keep the code for every score your users see in your own repositories, whoever wrote it.
• Run a test export at least once a year.

Each of these is a configuration choice at the start of a project and a migration later, so the cost of putting them in place grows the longer you wait.

What Open Source Changes, and What It Doesn't

Open source moves the infrastructure layer into your ownership. Open Wearables, the open-source wearable data platform Momentum built and maintains under the MIT license, runs on infrastructure you operate. The data sits in a database you control and does not pass through Momentum's servers, including when Momentum deploys and configures the instance on your infrastructure for you. Raw provider payloads can be captured before processing, and the unified data model is documented. The platform's live health scores, Sleep and Resilience, are built on published algorithms you can inspect or replace. The Open Wearables documentation covers each of these in detail.

Open source does not build the layers at the bottom of the table for you. The scores you calibrate and the models you train are still your work, and they stay yours: building proprietary scores or models on top of Open Wearables does not require publishing them. The answers to the common questions about this are in the Open Wearables FAQ on avoiding vendor lock-in.

It also does not do the stewardship. Someone has to run the deployment and respond when a provider changes its API. That can be your team or a partner, and our wearables integration services cover that work, but the choice of who does it stays separate from the question of who owns what.

The practical result is that the connection to each provider, the commodity layer, is no longer a dependency, and your investment goes into the layers that differentiate the product. That includes the AI layer. Models trained on data you cannot reprocess are hard to retrain later, which is why both our guide to making health data ready for AI and our healthcare AI implementation work start from the assumption that you hold the data and the pipelines.

Health Data Portability: How to Test Your Exit Path

Health data portability, seen from the product side, is whether you could take your wearable data and everything built on it to a new environment and keep running. You find out by testing it. I ask a version of these questions on most first calls, and the answers usually show where the gaps are within a few minutes:

1. Where are the raw provider payloads stored, and could you reprocess your full history from them?
2. In whose name are the developer credentials for each wearable provider registered?
3. If you exported everything today, what schema would it arrive in, and would it include the complete history?
4. Can you recompute every score your users see from code you hold?
5. Where do the training pipelines and feature definitions for your models live?
6. When did you last run an export end to end?

The last question is the one that most often gets a pause. A test export does not need to be large. Take a sample of users, export their data, load it into a clean environment, recompute the scores, and compare the results with production. Matching numbers mean your exit path works. Any difference points to the layer you do not fully control, and finding it during a test costs far less than finding it during a migration.

Map What You Own Before You Need To

Our Data Governance & Residency Review goes through your current wearable data setup layer by layer, showing which parts you control and what an exit would take in practice. If you would like a second opinion on your own exit path, talk to our team.