Wearables Integration in Healthcare 2026: Google Fit Out, Health Connect In, and What Production Actually Needs

Last updated: June 2026
By: Josh Koenig, Product and Strategy, Sidebench

Healthcare teams building on wearable data hit the same conversation three times a quarter now. How do we finish the Health Connect migration we should have completed a year ago, and how do we harden the rushed version under HIPAA. Do we go direct or use an aggregator. What does the data pipeline actually need to do. What does any of this cost when HIPAA is in scope. The honest answers depend less on which devices you support than on the regulatory burden you carry, the reimbursement model you run on, and how much of the failure surface you want to own.

This article is the read we give every healthcare team that arrives at Sidebench with a wearable integration question in 2026. It covers the migration path, the architecture options, the cost bands, and the failure modes we see in production. It assumes you are building something patients or clinicians will actually use, not a prototype.

---

What changed in 2026: Google Fit deprecation and the Health Connect migration

Google Fit’s developer APIs are being deprecated in staged rollouts. Sign-ups closed in May 2024. The Android Fit API was scheduled for turndown in June 2025. The REST API is being fully deprecated through 2026, per Google’s developer documentation. Healthcare teams that ran integrations on Fit are now either on Health Connect, on third-party aggregators, or limping along on temporary workarounds that have been in production longer than they were meant to be. Google has named Health Connect as the canonical replacement for any application that needs read or write access to a user’s health data on Android.

Any healthcare team that built on Fit between 2018 and 2023 has either completed the Health Connect migration, completed a rushed version of it, or stalled. The teams we see in pre-build conversations in 2026 are mostly the second group, finishing what got shipped under deadline pressure in 2024 and 2025 and was never properly redesigned for HIPAA. The migration is meaningfully harder than the documentation suggests, because the behavioral differences between Fit and Health Connect matter more than the API surface does.

Fit was a passive aggregation surface. Health Connect is a permissioned data store with stricter user-consent flows, narrower data-type coverage at launch, and a different background-sync model. An application that worked against Fit on Android 11 will not work against Health Connect on Android 14 without rewriting the consent, the sync logic, and the failure-state handling.

Under HIPAA, the migration has implications most consumer-app teams miss. Health Connect routes data through the user’s device. The moment your application reads it, transmits it off-device, or persists it to a server, you are handling protected health information at scale and the technical safeguards under 45 CFR 164.312 apply. The migration is the right time to redesign the data path end to end rather than swap the source.

---

The five wearables stacks healthcare teams actually run

Healthcare teams settle on one of five wearable stacks, and the choice carries more downstream consequences than the device list suggests. Each stack has its own failure modes, its own cost shape, and its own regulatory exposure.

Stack	When it fits	Strengths	Weaknesses
Apple-only (HealthKit)	Concierge longevity, premium preventive medicine, iOS-skewing populations	Native API, low latency, clinical record types surface cleanly	iOS lock-in, App Store medical-app review, no BAA from Apple
HealthKit + Health Connect	Cross-platform consumer plus clinical	Broad reach, vendor-neutral data path	Two background-refresh models to reason about, two consent UX flows
HealthKit + aggregator (Terra / Vital / Validic)	Multi-device, many partners, fast launch	Single API surface, one BAA, broad coverage	Vendor lock-in, opaque failure modes, per-record pricing at scale
Direct partner SDKs (Oura, Whoop, Dexcom)	High-fidelity per-device data, FDA context	Best data quality, real partner relationships	Each integration is its own engineering project
FDA-regulated SaMD wearable	RelieVRx-class therapeutics, regulated digital health	Full clinical evidence stack, post-market data ready	510(k) or De Novo timeline, ongoing regulatory burden

A Sidebench client in the longevity space (anonymized at their request) ran an AthenaOne plus Oura plus Dexcom Stelo stack. The product brought together cardio-cognitive prevention metrics for a high-net-worth membership. The build sat in the direct partner SDK band, with a custom data pipeline normalizing across three vendors and one EHR. The build is 18 weeks in and already serving that population. The most expensive lessons came from failure-mode design that we will get to later.

---

Direct integration vs aggregator API: when each wins

The first real decision is whether to integrate directly with each device manufacturer or route through an aggregator. The answer depends on four variables: how many vendors you need to support, how much your reimbursement model depends on data fidelity, how strict your HIPAA edge cases are, and how much budget you can spend in the first 18 months.

Aggregators like Terra, Validic, and Vital make sense when you need to launch in two months across five or more device families, and your clinical workflow tolerates the data quality the aggregator can guarantee. The single API surface and single BAA save real engineering time at the start.

The downsides arrive later. Per-transaction or per-active-user pricing compounds when the product succeeds. Failure modes inside the aggregator are not visible to your application. When a vendor changes its API behavior, the aggregator’s incident becomes your incident, on the aggregator’s timeline.

Direct integration makes sense when data quality is part of the product, when the reimbursement model depends on continuity of care, or when you are at a scale where aggregator pricing crosses the build-cost line. Direct integration also makes sense in any FDA-regulated context, because the post-market surveillance burden is easier to satisfy when you own the data path.

Sidebench has built variations of this pipeline layer across direct-integration work. It started as the data-pipeline layer for a longevity client, then carried into RPM and chronic care management. Each build reuses the same schema-reconciliation, unit-normalization, gap-detection, and retroactive-correction patterns.

---

Apple HealthKit in healthcare: what production teams get wrong

Apple HealthKit is mature, well-documented, and widely deployed in healthcare, which is exactly why teams get it wrong. The traps are not in the API surface. They are in the operating assumptions around it.

iOS background refresh is the first trap. HealthKit data does not stream to your application in real time. Reads happen on launch, on user-initiated foreground actions, and through background-delivery callbacks that iOS throttles based on power state and user behavior. Applications that assume continuous data discover the gap when a patient’s overnight heart-rate window does not arrive until breakfast.

Then the clinical-records trap. Apple supports a growing set of clinical record categories: medications, conditions, lab results, immunizations. The data only surfaces if the patient has connected a participating provider through the Health app. Teams that assume the clinical record types will be populated discover that fewer than 10% of users in their cohort have actually completed the provider linkage.

App Store review adds a third drag, healthcare apps draw extra scrutiny. Apple’s review queue treats medical apps with more scrutiny than consumer apps. Apps that claim diagnostic, treatment, or monitoring functions go through additional review and often need supporting documentation about clinical evidence. Build the review timeline into the launch plan, not into the bug-fix sprint.

And the BAA gap is the one teams understand least. Apple does not sign a Business Associate Agreement for HealthKit data. The data is considered to be on the user’s device, under the user’s control, and outside HIPAA’s covered-entity perimeter until your application reads it. The moment your application reads HealthKit data and transmits it to your servers, the BAA obligation shifts to your application’s hosting and processing layer, not Apple’s.

These four traps are why we scope iOS healthcare integrations around background-refresh behavior and the clinical-record-linkage gap from the first sprint, not after the first patient cohort reports missing overnight data.

---

Google Health Connect: the migration path under HIPAA

The migration from Google Fit to Health Connect under HIPAA constraints has a five-step shape. Each step takes longer than the team expects.

Map the data types your application currently reads from Fit to the closest equivalents in Health Connect. The two APIs are not isomorphic. Some Fit data types do not exist in Health Connect at launch. Others have renamed. Consent permissions are granular per data type instead of bundled. Document the gaps before you write any new integration code.

Rebuild the consent UX. Health Connect requires explicit per-data-type permission, often through a system-mediated flow that lives outside your application. The consent screen the user sees is Android’s, not yours. The rejection path needs to be designed into your application’s empty-state handling.

Implement dual-write before cutover. While Fit is still serving production traffic, write to both Fit and Health Connect for a defined transition window. This lets you compare data fidelity, catch schema mismatches, and design rollback paths before the cutover lands.

Redesign the background-sync logic. Health Connect’s background-data-access model is stricter than Fit’s. Applications that polled Fit need to migrate to event-driven sync with batched reads. Silent-failure paths around missing permission, missing data, and missing devices need to surface to the clinical workflow, not just the developer logs.

Re-audit the HIPAA path end to end. The migration is the cheapest time to redesign data flow, encryption, audit logging, and PHI scoping. Most teams that migrate without re-auditing carry forward HIPAA gaps that were not visible against Fit.

---

RPM platform integration: 99453, 99454, 99457, 99458 and what they actually require

Remote Patient Monitoring is the most common reimbursement model that drives wearable integration in healthcare. The four CPT codes that anchor it carry specific measurement and clinical-review requirements that the prototype rarely accounts for.

CPT 99453 reimburses initial setup. The activity required is patient enrolment and device configuration. The implementation reality is identity verification, BAA infrastructure, App Store onboarding flow design, and a clinical-staff handoff that does not blow up the first encounter. The reimbursement is a one-time fee per patient.

CPT 99454 reimburses ongoing device supply and data transmission, on the order of $45 to $55 per 30-day period. The exact amount is set by the CMS Physician Fee Schedule, adjusted annually and varying by locality, so confirm the current figure for your region before you model revenue. The activity required is 16 days of measurements in any 30-day window. The implementation reality is gap detection, retroactive correction when a device was offline, and conflict resolution when a patient uses two devices that report the same metric.

CPT 99457 reimburses the first 20 minutes of clinical staff time spent reviewing data each month. The activity required is documented clinical review. The implementation reality is an audit trail of who viewed what data, when, and what clinical decision followed, all surfaced in a UX that does not slow the clinician down.

CPT 99458 reimburses each additional 20 minutes beyond 99457. The activity compounds the 99457 complexity.

The lesson that carries into RPM: continuity of care is a data-pipeline problem before it is a clinical-workflow problem. Late, missing, and conflicting data is what breaks an RPM program, not the clinical logic sitting on top of it.

---

The data-pipeline layer almost everyone underspecifies

The biggest gap we see in healthcare wearable builds is the data-pipeline layer between the device source and the clinical or product workflow. Aggregator APIs hide this layer. Direct integrations make it visible. Either way, what the pipeline does turns out to be where the real engineering investment lives.

Multi-vendor schema reconciliation is the first concern. Apple HealthKit, Google Health Connect, Oura, Whoop, and Dexcom each report heart rate, sleep, and activity with different units, sampling rates, and completeness guarantees. A pipeline that does not reconcile these explicitly delivers clinical noise to the application layer, and the application layer is the wrong place to handle the noise.

Unit normalization is the second. A patient’s sleep duration in HealthKit’s enumeration is not the same as Oura’s. The difference matters if the downstream clinical decision depends on a duration threshold. Normalization belongs in the pipeline.

Gap detection is the third concern, and it is where most pipelines break first under real production load. Wearables drop data for predictable reasons (device removed, battery dead, sync interrupted) and unpredictable reasons (firmware update, vendor API outage, sandbox quirk). A pipeline that does not detect gaps and surface them to the application cannot drive RPM workflows. The clinical staff end up looking at incomplete data they cannot trust.

Retroactive correction is the fourth. Wearables report late, sometimes by days, when a device syncs after a long gap. The pipeline needs to ingest the late data, re-emit downstream events that depended on the now-corrected window, and audit the correction in a way that survives an OCR audit.

In our experience, clients that try to build this layer on top of an aggregator end up rebuilding it from scratch when the aggregator’s failure modes start costing money. We’ve built variations of this pipeline for multiple clients, each time reusing the same four patterns. Rebuilding the layer per-client is the kind of work that makes engagements unprofitable for both sides.

---

FDA-regulated wearable integration: what changes when SaMD is in scope

Once the wearable application qualifies as Software as a Medical Device, the integration sits inside a regulated quality system and the engineering work changes shape. Sidebench shipped AppliedVR’s RelieVRx, the first FDA-authorized VR therapeutic for chronic lower back pain (FDA De Novo, November 2021). The lessons from that build still inform how we scope every SaMD-adjacent project.

The 510(k) or De Novo path drives a documentation burden that runs parallel to the engineering build. Design History File, Software of Unknown Provenance assessment, hazard analysis, verification and validation protocols, all of these need to be maintained from the first commit. Teams that wait to think about regulatory documentation until late in the project pay months in remediation.

Post-market surveillance data requirements change how the data pipeline gets designed. The pipeline needs to retain data in a form that supports adverse event detection, performance monitoring, and trend analysis across the regulated population. Standard healthcare data retention is not enough.

Software change control gates every meaningful update to the integration. Changes that affect device interaction, data processing, or clinical algorithms require regression testing against the design controls. The testing artifacts need to be maintained for the device’s commercial lifetime.

None of this is a reason to avoid SaMD. RelieVRx shows the regulated path can ship and scale: FDA De Novo authorization in November 2021, with a production application now operating inside the regulated quality system. It also isn’t a reason to assume FDA clearance alone guarantees commercial success. Pear Therapeutics shipped three FDA-authorized prescription digital therapeutics, then filed for Chapter 11 in April 2023 after payer reimbursement failed to materialize. Budget the regulatory work from day one, and budget the post-approval reimbursement work alongside it.

---

Failure-state design: when the watch dies, the phone is offline, the API rate-limits

Every wearable integration eventually faces three failure modes in production. The build that designs for them up front ships smoother than the one that handles them in incident response.

Network loss comes first. The patient’s phone is in airplane mode, on the subway, in a hospital room without cellular. Reads queue locally. Writes need to retry idempotently. The clinical workflow needs to surface stale data with a stale-data indicator, not pretend it is current.

Then conflict resolution, when two devices report the same metric and disagree. A patient wears both an Apple Watch and an Oura ring. Both report heart rate. They disagree by three beats per minute. The pipeline needs a policy: source of truth by data type, by accuracy class, by recency. The policy needs to be auditable when a clinician asks why a particular value drove a particular decision.

Retroactive data ingestion is the one that quietly corrupts the timeline. A patient’s Dexcom CGM syncs five days of data on a Sunday afternoon. The pipeline ingests it. Downstream events that depended on the data window now need to re-fire, the clinical workflow needs to know which decisions are still valid and which need re-review, and the audit log needs to show the corrected timeline.

Clinical decision lockout is the design pattern that catches all three failure modes. When data integrity is uncertain, clinical decisions that depend on the data should be soft-locked until a clinician acknowledges the uncertainty. The lockout pattern is not popular with product teams who want frictionless UX. In our experience, it is the difference between an RPM platform that survives its first OCR audit and one that does not.

---

The 2026 cost bands: what wearable integration actually costs

Costs depend on scope, regulatory burden, vendor depth, and the team that ships the build. The bands below reflect Sidebench engagement ranges across more than 10 wearable-data builds we have shipped in the last three years.

Build depth	Range	Timeline	When it fits
Aggregator API + thin glue	$40K to $120K	6 to 10 weeks	MVP across a single vendor or aggregator, low regulatory burden, sufficient data quality
Direct integration, one stack	$80K to $250K	10 to 16 weeks	Concierge longevity, single-OS consumer health, constrained device list
Full multi-vendor pipeline + HIPAA	$250K to $700K	16 to 28 weeks	RPM platforms, chronic care management, multi-device clinical builds
SaMD-compliant build	$500K to $2M	28 to 52 weeks	FDA-regulated wearable therapeutics, post-market surveillance baked in

---

A pre-build checklist for wearable healthcare apps

Before scoping the engineering, settle these ten items. Each one shapes the cost and timeline more than any technical decision downstream.

1. HIPAA scope. Is your application a covered entity or a business associate of one? Where does PHI enter, transit, and rest?
2. FDA scope. Does the application qualify as SaMD? If yes, budget the regulatory work from day one.
3. Multi-vendor data. Which device families, in what order, and what is the data fidelity guarantee per vendor?
4. Identity model. How is the patient verified, how is the clinician verified, and how do you handle proxy access (guardians, family members)?
5. Reimbursement model. RPM, RTM, CCM, cash-pay, or hybrid. Each one drives different measurement-cadence requirements.
6. Audit log. Who looked at what data, when, and what decision followed. Designed in, not bolted on.
7. Failure design. Network loss, vendor outage, late sync, conflict. All surfaced to the clinical workflow.
8. App Store posture. Healthcare apps get extra scrutiny. Budget time.
9. BAA coverage. Every infrastructure vendor that touches PHI needs one. Map the dependency tree.
10. Post-launch ownership. Who maintains the integration in year two, when the SDKs deprecate?

---

Where Sidebench has shipped this

Sidebench has shipped wearable integrations across longevity, behavioral health, pediatric, RPM, and FDA-regulated SaMD. Each engagement informs the next.

A longevity-tech client (anonymized) built a cardio-cognitive prevention product on an AthenaOne plus Oura plus Dexcom Stelo stack. The build is 18 weeks in and already serving a high-net-worth membership population.

Hoag Compass 3.0 launched as an Epic-integrated subscription preventive medicine experience with a New Patient Center and a virtual-only membership tier.

AppliedVR’s RelieVRx is the first FDA-authorized VR therapeutic for chronic lower back pain (FDA De Novo, November 2021). Sidebench shipped the production application that now operates inside the regulated quality system.

CHLA Baby Steps is an iOS app supporting NICU families transitioning home, serving 17,000+ families with a 4.7-star satisfaction rating and 30,000+ downloads. Awards: American Hospital Association Innovation Challenge 2019 (3rd place), Fast Company Best Mobile Apps, and w3 Gold Award.

---

FAQ

What is Google Health Connect and why does it matter in 2026?

Health Connect is Google’s canonical replacement for the deprecated Google Fit API. It is a permissioned on-device data store with per-data-type consent and a stricter background-sync model than Fit. Any healthcare application that read from Fit before 2024 needs to migrate to Health Connect through 2026 or lose Android data access entirely.

When is Google Fit officially deprecated?

Google Fit’s developer APIs are deprecated in staged rollouts. Sign-ups closed May 2024, the Android Fit API was scheduled for turndown in June 2025, and the REST API is being fully deprecated through 2026. Google’s developer documentation has the per-stage timeline.

Should we build directly on Apple HealthKit or use an aggregator?

Direct when data fidelity matters, when the device list is constrained, or when you are in an FDA-regulated context. Aggregator when you need to launch in two months across many devices and your clinical workflow tolerates the data quality. The decision rarely reverses cheaply.

Is Apple HealthKit HIPAA-compliant?

HealthKit itself is on the user’s device under the user’s control. The moment your application reads HealthKit data and transmits it off-device, the HIPAA Security Rule under 45 CFR 164.312 applies to your application’s data path. Apple does not sign a Business Associate Agreement for HealthKit data.

What does an Apple Watch healthcare integration cost in 2026?

Single-stack direct integration runs $80K to $250K over 10 to 16 weeks. Multi-vendor with a full HIPAA pipeline runs $250K to $700K over 16 to 28 weeks. Costs scale with regulatory burden and pipeline depth, not screen count.

How do we handle multi-vendor wearable data?

A real data pipeline does the work: schema reconciliation across vendors, unit normalization, gap detection, retroactive correction. Aggregators hide this work behind their API. Direct integrations require it explicitly. Either way, the pipeline layer is where most of the production engineering investment lives.

What is required to support RPM CPT codes 99453, 99454, 99457, and 99458?

99453 requires enrolment and device setup. 99454 requires 16 days of measurements in any 30-day window, with gap detection and retroactive correction. 99457 requires 20 minutes of documented clinical review per month, with audit-trail logging. 99458 compounds 99457.

What is the difference between RPM and RTM?

Remote Patient Monitoring (RPM) is the original CPT-coded reimbursement for physiologic data monitoring. Remote Therapeutic Monitoring (RTM) is a newer family of codes covering rehabilitation, respiratory, and musculoskeletal monitoring. Both require similar pipeline architecture; the clinical workflows and reimbursement schedules differ.

How do we handle failure states when a wearable is offline or the API rate-limits?

Design the failure states into the data pipeline and the clinical workflow up front. Stale-data indicators, idempotent retry, soft-locking of clinical decisions when data integrity is uncertain. The build that handles these as exceptions in incident response is the build that ships late and runs hot.

What does FDA SaMD clearance change for a wearable integration?

It adds a documentation, verification, and validation burden that runs parallel to the engineering build. Design History File, hazard analysis, software change control, post-market surveillance. All of this needs to be maintained from day one, not retrofitted before submission.

Build vs buy on the wearable data pipeline: when does each path win?

Buy when the goal is to launch fast across many devices and the data fidelity is sufficient. Build when data quality is part of the product, when scale crosses the aggregator pricing curve, or when an FDA-regulated quality system requires control over the data path. The wrong path is reversible, but it is expensive.

---

---

About the author

Cited sources

• Google Developers, Health Connect API documentation and Google Fit deprecation notice
• Apple Developer, HealthKit clinical records and developer documentation
• HHS Office for Civil Rights, HIPAA Security Rule (45 CFR § 164.312)
• CMS, RPM CPT code reimbursement schedule (99453, 99454, 99457, 99458) and Physician Fee Schedule
• FDA, Software as a Medical Device guidance
• AppliedVR, RelieVRx FDA authorization public record