The unowned position is between the watch and the EHR.
NPJ Digital Medicine reviewed the state of clinical-grade sensors in consumer wearables in late 2025. Apple Watch ECG, Apple Watch SpO2, the emerging continuous-glucose-monitoring features in Oura and the next-generation Apple wearable family, Garmin's clinical-validation arc on heart-rhythm monitoring. Each sensor class now meets the technical threshold for remote-patient-monitoring (RPM) billing codes — CPT 99453, 99454, 99457, 99458 — that pay providers for collecting and acting on patient-monitored data.
_The unowned position is between the watch and the EHR._ Hold that frame in view. Everything that follows traces back to it.
The reimbursement arbitrage is structural and largely uncaptured. The data exists, the billing codes exist, and the workflow that connects them doesn't. The watch generates clinical-grade data. The EHR can ingest billable monitoring data. The middleware that translates between them is the unowned position.
That position is structurally distinct from anything either Apple/Garmin/Oura or Epic/Oracle Health are built to occupy. Apple's operating model is consumer device sales plus services; clinical-billing-class workflows are not their category. Epic's operating model is health-system-class enterprise software; consumer-device-data ingestion at scale is not their category. The middleware layer requires fluency in both consumer-device APIs and CPT-billable workflows, plus a clinical-staff coordination layer that neither category-leader has built.
Trace the position back to the binding commercial constraint and the labor bottleneck surfaces. The CPT 99457 / 99458 codes pay for clinician interaction time with the monitored data. A wearable-RPM program at scale requires clinical staff to review the data, decide on intervention, and document the workflow — and the per-patient time per month under the codes is calibrated to roughly 20 minutes of clinical-staff time per month per patient. A health system running a 1,000-patient wearable-RPM program needs roughly 333 clinical-staff hours per month for the review work alone. That labor capacity isn't sitting idle in primary-care practices in 2025-2026.
The middleware that solves the labor bottleneck is the operator-class position. AI-assisted triage of monitored data (the AI surfaces the high-priority cases for clinical review, the clinician spends time on those rather than on screening every patient's data) reduces the per-patient time substantially. The middleware operator who builds the AI-triage layer plus the billing-workflow integration plus the clinical-staff coordination is the operator who captures the rents the unowned position generates.
Trace the position back to the incumbent class and the build-conflict surfaces. Neither hardware companies nor EHR vendors will build the middleware natively in the 2026-2028 window. Apple is structurally allergic to clinical-billing workflows; the regulatory exposure and the operational complexity don't fit the consumer-device operating model. Epic and Oracle Health are structurally calibrated to enterprise procurement cycles that don't reach the consumer-device data layer at the granularity the codes require. The middleware will be built by a third party. The question is which third party, and whether they're operationally positioned to capture the category before the category-leader incumbents recognize it.
Trace the position back to the regulatory-and-reimbursement environment and the operator-tier window widens. The regulatory frame is permissive (RPM codes have been on CMS's list since 2018-2019, under-utilized because the workflow infrastructure didn't exist), the AI-assisted-triage capability that closes the labor bottleneck is now operationally feasible, and the combination of established codes plus AI-enabled-workflow plus consumer-device-data-availability is the structural opportunity. By 2027-2028 multiple operator businesses will be competing in the middleware category. By 2029-2030 the category-leader will have visible scale.
The same shape recurs across categories where consumer-device data has clinical relevance. Sleep monitoring (Oura, Apple Watch sleep tracking → sleep-disorder clinical billing). Cardiac monitoring (Apple Watch ECG, Garmin → arrhythmia clinical billing). Fertility tracking (Natural Cycles, Apple Cycle Tracking → fertility-treatment clinical workflows). Each category has its own version of the unowned position with category-specific billing codes and category-specific workflow requirements.
What survives all of this is that the consumer-device-to-clinical-billing middleware is one of the cleaner uncaptured operator-tier positions in healthcare-AI as of 2025-2026, the labor bottleneck is the binding commercial constraint that AI-assisted triage solves, and the operator class building in the window has structural advantage over later entrants because the early-build captures the workflow integrations and clinical-staff coordination that compound over time.
The unowned position is between the watch and the EHR. The labor bottleneck is the binding constraint. The middleware that captures both is the category-creation event healthcare-AI investors should be tracking. Most are not, because the position doesn't fit either the consumer-device or the EHR-platform investment thesis. That mismatch is precisely the reason the position is uncaptured.
Operator founders building toward the middleware in 2026 are positioned to capture rents that the established categories cannot. Operator-grade investors looking for healthcare-AI categories with structural durability should be tracking the middleware buildout as the canonical 2026-2028 opportunity. The category-creation will be visible to the trade press by 2028. The operator who recognized it earlier captures the position the trade press names later.
—TJ