Diabetes Remote Patient Monitoring: What CGM Integration Actually Looks Like in Production

TL;DR

40.1 million Americans have diabetes and another 97.6 million have prediabetes (CDC NCHS Data Brief #516, November 2024). Continuous glucose monitors now generate 288 readings per day per patient, and that data can flow directly into RPM platforms through vendor APIs and Apple HealthKit. Clinical evidence is strong: A1C reductions of 0.25 to 3.0 percentage points and time-in-range improvements of 15 to 34% across multiple studies (PMC, 2025). CMS reimburses diabetes RPM through CPT 99453-99458, and the 2026 short-duration codes drop the monitoring minimum from 16 days to 2. The CGM device is commodity hardware. The integration layer that gets that data into clinical workflows, that is the product.

We’ve integrated Dexcom, Abbott Libre, and Apple HealthKit into five different RPM platforms over the past three years, and the hardest part was never the API documentation.

The APIs are well-built. Dexcom’s developer portal is genuinely good. Apple HealthKit is reliable. The problem lives downstream: normalizing time-series data from devices with different sampling rates, handling the 2-hour warmup gap when a patient applies a new sensor, reconciling timezone shifts for patients who travel, and getting all of that into an EHR as structured FHIR Observations that a care team can actually interpret between patients.

That integration layer is what separates a glucose number on a screen from a clinical decision that changes a patient’s trajectory. And right now, most diabetes RPM programs don’t have it.

Why Is Diabetes the Largest RPM Opportunity That Still Runs on Spot Checks?

The prevalence numbers are staggering. The CDC’s November 2024 data brief reports 40.1 million Americans with diagnosed diabetes, roughly 15.8% of the adult population. Another 97.6 million have prediabetes, nearly 38% of adults. Type 2 accounts for 90 to 95% of all cases and represents the primary RPM population.

CGM adoption is accelerating from both ends. On the clinical side, Dexcom G7 and Abbott Libre 3 are becoming standard of care for insulin-managed patients. On the consumer side, the FDA cleared Stelo by Dexcom in 2024 as the first over-the-counter CGM for non-insulin Type 2 patients (PMC, 2024). No prescription needed. That single clearance opened CGM to millions of Type 2 patients who were previously monitoring with finger sticks four times a day, or more likely, not monitoring at all.

Here is the disconnect. CGM devices generate 288 glucose readings per day (one every 5 minutes on Dexcom G7). That is continuous, high-resolution metabolic data. But most RPM platforms built for diabetes still treat glucose as a spot-check number: one reading uploaded, one threshold compared, one alert generated. They are running a continuous data stream through infrastructure designed for intermittent readings. The clinical value of CGM is in the trend, the slope, the time-in-range pattern. Spot-check architecture throws all of that away.

Visual Brief #1: Infographic showing the diabetes RPM opportunity. Left side: 40.1M diagnosed + 97.6M prediabetes = 137.7M Americans. Right side: CGM generates 288 readings/day vs traditional glucose meters generating 2-4 readings/day. Bottom: “Most RPM platforms are built for 4 readings. CGM produces 288.” Title: “The Diabetes RPM Gap: Continuous Data, Spot-Check Infrastructure.” File name: diabetes-rpm-opportunity-gap.png. Alt text: “Infographic showing 137.7 million Americans with diabetes or prediabetes and the gap between CGM continuous data output and traditional RPM platform architecture.” Sizes: 1200×800 blog, 1080×1080 social.

What CGM Devices Feed a Diabetes RPM Platform?

The CGM market has consolidated around three manufacturers, each with a different integration profile. Knowing the differences matters because the device your patients use determines how the data reaches your platform.

Dexcom G7 is the integration-friendliest CGM on the market. Five-minute readings, 10-day sensor wear, direct Bluetooth connection to the patient’s phone, and a well-documented developer API with OAuth 2.0 authentication. The API provides estimated glucose values (EGV), trend data, and calibration status. We’ve found the G7 API to be the most reliable for real-time data ingestion across the five platforms we’ve built.

Abbott FreeStyle Libre 3 generates readings every minute (the highest sampling rate of the three) with 14-day sensor wear. The Libre 3 is the thinnest sensor available and has the lowest per-unit cost, making it attractive for large-scale programs. Abbott’s LibreView platform provides data access, though the API integration path is less developer-friendly than Dexcom’s.

Medtronic Guardian 4 is tightly integrated with Medtronic’s insulin pump ecosystem (MiniMed 780G). For patients on closed-loop insulin delivery, the Guardian 4 data flows through Medtronic’s CareLink platform. Integration is possible but the data is more siloed than Dexcom or Abbott.

Dexcom Stelo changed the market in 2024. As the first OTC CGM requiring no prescription, it opens remote monitoring to the massive Type 2 non-insulin population. The integration profile mirrors the G7 API, making it straightforward to add to existing Dexcom-compatible platforms.

Beyond CGMs, a diabetes RPM program often needs companion devices for comorbidity monitoring: cellular blood pressure cuffs (diabetic hypertension affects 60%+ of Type 2 patients), weight scales (metabolic monitoring for patients on GLP-1 medications), and traditional blood glucose meters (backup and for patients who aren’t CGM candidates).

Visual Brief #2: Styled comparison table (above) with device photos/icons. Title: “CGM and Companion Devices for Diabetes RPM.” File name: diabetes-rpm-cgm-device-comparison.png. Alt text: “Comparison table of CGM devices including Dexcom G7, Abbott Libre 3, Medtronic Guardian 4, and Dexcom Stelo with reading frequency, wear duration, API access, and cost for diabetes remote patient monitoring.” Sizes: 1200×900 blog, 1080×1350 social carousel.

How Does CGM Data Actually Flow Into an RPM Platform?

This is the section most diabetes RPM content skips entirely. The clinical articles talk about outcomes. The vendor pages talk about features. Nobody walks through the data pipeline.

Here is what the architecture looks like in production:

Step 1: Device to phone. The CGM sensor transmits glucose readings via Bluetooth Low Energy to the patient’s smartphone app (Dexcom G7 app, LibreLink, etc.). This happens automatically. No patient action required after initial pairing.

Step 2: Phone to cloud. The smartphone app syncs readings to the manufacturer’s cloud (Dexcom Clarity, Abbott LibreView, Medtronic CareLink). This is the first potential data gap: if the patient’s phone loses connectivity or the app crashes, readings accumulate on the sensor but don’t reach the cloud until sync resumes.

Step 3: Cloud API to RPM platform. Our platform pulls from the manufacturer API (or from Apple HealthKit if the patient has CGM data flowing there). Dexcom’s API delivers EGV (estimated glucose value), trend direction, and sensor status. We poll every 5 minutes for real-time programs or batch-pull every hour for programs that don’t need sub-hour latency.

Step 4: Normalization. This is where the real engineering lives. A patient using Dexcom G7 produces readings every 5 minutes. A patient on Libre 3 produces readings every minute. A patient also wearing an Oura Ring generates heart rate variability data at different intervals. A connected weight scale reports once a day. Normalizing these into a unified time-series view, with aligned timestamps, consistent units, and gap-filled interpolation where data is missing, is non-trivial engineering.

Step 5: Clinical logic. Trend analysis, alert generation, time-in-range calculation, and pattern detection run on the normalized data. This is where the difference between a spot-check platform and a CGM-native platform becomes visible. A spot-check platform asks: “Is this reading above 250 mg/dL?” A CGM-native platform asks: “Has this patient spent more than 4 hours above 180 mg/dL in the past 24 hours, and is that trending worse than their 7-day average?”

Step 6: Care team dashboard. The care manager sees a patient panel sorted by risk score, not by who uploaded most recently. Glucose trend graphs with time-in-range overlays. Alert queue with AI triage (green/yellow/red).

Step 7: EHR integration. Glucose readings land in the EHR as FHIR Observations. The endocrinologist sees the RPM data inside Epic or Cerner during the patient visit, not in a separate portal they have to remember to check.

When we built the Hearty platform, we integrated Dexcom CGM alongside Apple HealthKit, Oura Ring, and Withings devices into a single biometric dashboard. The hardest integration was not the Dexcom API. It was normalizing time-series data from five devices with different sampling rates into a single patient view that made clinical sense. WearConnect now ships that normalization layer as a pre-built accelerator, cutting what took us months down to weeks.

Start a Conversation about CGM integration architecture for your diabetes RPM platform.

Visual Brief #3: Architecture diagram showing CGM data flow. Seven numbered boxes connected by arrows: CGM Sensor → Patient Phone (BLE) → Manufacturer Cloud → RPM Platform API Pull → Normalization Engine → Clinical Logic + AI → Care Team Dashboard / EHR (FHIR). Callout boxes noting: “Data gap risk” between phone and cloud, “Engineering complexity” at normalization step, “Clinical value created” at logic step. Title: “CGM-to-EHR: The 7-Step Data Pipeline.” File name: diabetes-cgm-data-flow-architecture.png. Alt text: “Architecture diagram showing how continuous glucose monitor data flows from the CGM sensor through seven steps to reach the EHR as FHIR Observations in a diabetes remote patient monitoring platform.” Sizes: 1200×600 blog, 1080×1080 social.

What Do the Clinical Outcomes Actually Show?

The evidence for CGM-based RPM in diabetes is stronger than in any other RPM condition, including heart failure. That is not something I say lightly.

A 2025 meta-analysis in PMC aggregating multiple CGM studies found consistent A1C reductions of 0.25 to 3.0 percentage points and time-in-range improvements of 15 to 34%. The average A1C reduction across studies was 0.40% compared to self-monitoring of blood glucose, with a 6% increase in time-in-range and a 4.33% decrease in time above range.

The Dexcom ONE real-world study, published in 2025, tracked actual patients (not clinical trial participants) using CGM in routine care. Results at 6 months: mean HbA1c dropped from 10.3% to 9.4% for Type 1 patients and from 10.1% to 8.3% for Type 2 patients (PMC, 2025). That 1.8 percentage point drop for Type 2 is clinically significant. It is the difference between uncontrolled diabetes and approaching target.

A December 2025 study from Montefiore Medical Center tested CGM plus RPM specifically in a safety-net hospital serving an underserved Type 2 population (PubMed, 2025). RPM with CGM improved glycemic control compared to standard care, even in a resource-constrained setting. This matters because the “CGM only works for motivated patients” objection doesn’t hold when the data shows improvement in safety-net populations.

The JMCP published a 2024 real-world evidence study showing CGM initiation was associated with reduced diabetes-related hospitalizations and lower medical costs in a large US-insured population (JMCP, 2024). Cost reduction through fewer hospitalizations, not just better glucose numbers.

One finding that surprised researchers: some benefits persisted even after patients discontinued CGM use. The behavioral change from seeing continuous glucose data, understanding how food and activity affect glucose in real time, appears to create lasting habits.

I should note what the evidence doesn’t yet show clearly. Most studies are 3 to 6 months. Long-term RPM plus CGM data beyond 12 months is still thin. And the studies measure CGM impact broadly, not RPM platform architecture impact specifically. We know CGM improves outcomes. We believe better platform architecture amplifies those improvements. But isolating the platform’s contribution from the device’s contribution is methodologically difficult. Honesty about that matters.

Visual Brief #4: Outcomes summary table. Columns: Study, Population, A1C Change, Time-in-Range Change, Duration, Source. Rows: PMC 2025 meta-analysis, Dexcom ONE real-world 2025, Montefiore 2025, JMCP 2024. Title: “Diabetes RPM Clinical Evidence: What the Numbers Show.” File name: diabetes-rpm-clinical-outcomes-table.png. Alt text: “Table summarizing four clinical studies showing A1C reductions of 0.4 to 1.8 percentage points and time-in-range improvements from CGM-based diabetes remote patient monitoring.” Sizes: 1200×500 blog.

How Does CMS Reimburse Diabetes RPM in 2026?

Diabetes RPM billing uses the same CPT codes as every RPM condition: 99453 (setup), 99454 (device supply), 99457 (interactive communication), 99458 (additional time). The critical detail for diabetes: CGM daily data transmission qualifies for 99454. The device generates continuous digital data that flows to the practitioner’s monitoring system. That meets the CMS requirement.

The 2026 changes are significant for diabetes programs specifically.

Short-duration RPM codes. New codes allow Medicare billing when data is collected for 2 to 15 days in a 30-day period, with only 10 minutes of treatment management time required (down from 20 minutes under existing codes). For diabetes patients who monitor inconsistently, or for newly enrolled patients in their first month, this dramatically lowers the billing threshold. Previously, a patient who only transmitted data for 12 days in a month generated zero RPM revenue. Now that same patient generates billable events under the short-duration codes.

Conversion factor increase. CMS raised the Medicare conversion factor by 4.09% in the 2026 PFS Final Rule (SweetSpot Health, 2026), the first increase since 2020. Every RPM code pays slightly more per unit in 2026.

Revenue at scale. Standard RPM (99457 + 99454) generates roughly $105-122 per patient per month. Add concurrent CCM (99490) for the same patients: $167-184 per patient per month combined. At 300 diabetes patients enrolled, that is $378,000 to $662,400 annually depending on program stacking and compliance rates.

UHC status. UnitedHealthcare originally planned to exclude diabetes from RPM coverage starting January 1, 2026, citing “insufficient evidence of efficacy.” After significant industry pushback, UHC paused implementation in December 2025 (Fierce Healthcare, December 2025). A new effective date has not been announced. Programs should monitor this closely and verify UHC coverage on a per-patient basis.

Request an Assessment to model your diabetes RPM revenue with the 2026 code changes factored in.

Visual Brief #5: Revenue comparison table. Two columns: “Pre-2026 (16-day minimum, 20-min threshold)” vs “2026 (2-day minimum, 10-min threshold).” Rows show patient eligibility %, billable events per month, revenue per patient, revenue at 300 patients. Title: “How 2026 CMS Changes Expand Diabetes RPM Revenue.” File name: diabetes-rpm-2026-billing-comparison.png. Alt text: “Table comparing pre-2026 and 2026 CMS RPM billing rules showing how short-duration codes and lower time thresholds increase diabetes remote patient monitoring revenue.” Sizes: 1200×500 blog.

What About Gestational Diabetes RPM?

Gestational diabetes affects 2 to 10% of pregnancies in the United States annually, and remote glucose monitoring during pregnancy is clinically well-established. CGM use in pregnancy is growing, with the ADA publishing expert perspectives on CGM clinical evidence in pregnant patients in 2025.

The controversy is the payer coverage. UHC’s 2026 policy explicitly covers “hypertensive disorders during pregnancy” for RPM but excludes gestational diabetes, stating “insufficient evidence of efficacy.” This is a narrow reading. The evidence for remote glucose monitoring in gestational diabetes isn’t zero. It just hasn’t been packaged in the specific RPM-outcome study format that payer policies demand.

Medicare is largely irrelevant here because most pregnant patients are on commercial plans or Medicaid. Aetna, BCBS, and most state Medicaid programs still cover RPM for gestational diabetes. The coverage is fragmented but not absent.

For digital health companies building maternal health platforms, CGM integration for gestational diabetes is a genuine differentiator. The clinical protocol is well-defined: fasting glucose target below 95 mg/dL, 1-hour postprandial below 140 mg/dL, 2-hour postprandial below 120 mg/dL. A CGM-fed RPM platform can automate these threshold checks and flag deviations in real time, replacing the manual four-times-daily finger stick regimen that patients struggle with.

The Hearty platform integration (Dexcom plus HealthKit plus Oura) demonstrates the architecture needed: continuous glucose data plus activity data plus sleep data flowing into a unified view. For gestational diabetes, swap the Oura sleep data for fetal monitoring inputs and the same multi-device normalization pipeline applies.

Visual Brief #6: Gestational diabetes monitoring protocol card. Sections: glucose targets (fasting, 1-hr post, 2-hr post), monitoring frequency, CGM vs finger-stick comparison, alert thresholds specific to pregnancy, and payer coverage status (Medicare N/A, UHC excluded, Aetna/BCBS/Medicaid covered). Title: “Gestational Diabetes RPM: Protocol and Payer Coverage.” File name: gestational-diabetes-rpm-protocol.png. Alt text: “Protocol card showing gestational diabetes remote monitoring glucose targets, alert thresholds, and 2026 payer coverage status across Medicare, UHC, Aetna, and BCBS.” Sizes: 1200×700 blog.

Should You Build a Custom Diabetes RPM Platform or Buy Off-the-Shelf?

The build-vs-buy question for diabetes RPM comes down to how much of the CGM data stream you actually need to use.

Off-the-shelf platforms (HRS, CareSimple, Glooko, Tenovi) handle the basic use case well: receive glucose readings, display on a dashboard, generate alerts when readings cross a threshold. HRS is ranked #1 by KLAS for RPM and has strong case study data. Glooko specializes in diabetes data management. For a program running a single CGM vendor with under 100 patients and no EHR integration requirement, off-the-shelf covers it.

Where off-the-shelf breaks down is exactly where the clinical value of CGM lives.

Multi-vendor CGM support. Most platforms are optimized for one CGM vendor. A patient population split between Dexcom and Abbott (common in large programs) needs unified data presentation regardless of device. Off-the-shelf platforms often display Dexcom data and Abbott data differently, or support one but not the other.

Time-series trend analysis. A spot-check alert (“glucose above 250”) is fundamentally different from a trend-based alert (“patient has spent 6 hours above 180 mg/dL, which is 40% worse than their 7-day average”). Building the second kind requires processing 288 readings per day per patient through statistical models, not just comparing the latest reading to a threshold.

Multi-condition monitoring. A Type 2 diabetes patient who also has hypertension and is on a GLP-1 for weight management needs glucose data plus blood pressure data plus weight data flowing into one clinical view. Adding devices means adding integration points, and each integration point is a potential failure point.

EHR-native dashboards. If glucose trend data lives in a separate portal that the endocrinologist has to remember to log into before a patient visit, it won’t get used consistently. Embedding RPM glucose insights inside the Epic or Cerner workflow (as FHIR Observations with trend annotations) is what makes the data actionable.

WearConnect ships the multi-device normalization layer. HealthConnect CoPilot handles the RPM-to-EHR pipeline. Together they compress the custom platform timeline from six months to six weeks for teams that have the clinical workflow defined.

Start a Conversation about your diabetes RPM platform architecture.

Visual Brief #7: Decision matrix. Three columns: “Off-the-Shelf” / “Hybrid (platform + custom integration)” / “Full Custom Build.” Rows: CGM vendor support, trend analysis depth, multi-condition support, EHR integration, patient volume sweet spot, time to launch, relative cost. Title: “Diabetes RPM: Build vs Buy Decision Framework.” File name: diabetes-rpm-build-vs-buy-matrix.png. Alt text: “Decision framework comparing off-the-shelf, hybrid, and full custom build approaches for diabetes remote patient monitoring platforms across seven dimensions.” Sizes: 1200×600 blog, 1080×1080 social.

What Should Your Diabetes RPM Implementation Look Like?

Three phases, 90 days to clinical value. The same pattern we use across RPM programs, adapted for the specific demands of continuous glucose data.

Phase 1: Foundation (Days 1-30)

• Select primary CGM device based on patient population (Dexcom G7 for broadest API access, Libre 3 for lowest per-unit cost, Stelo for OTC Type 2 patients)
• Integrate CGM API or Apple HealthKit data feed into your monitoring platform
• Add companion devices if the program covers comorbidities: BP cuff (hypertension), weight scale (GLP-1 patients)
• Train care team on glucose trend interpretation, not just spot values. Time-in-range (TIR) is the CGM-native metric. A1C is a 90-day lagging indicator. Care teams trained only on A1C will underuse the CGM data
• Enroll first 50 patients: start with high-risk Type 2 (A1C above 9%) who are already on CGM or willing to start

Phase 2: Calibration (Days 31-60)

• Review alert accuracy: what percentage of glucose alerts led to clinical action? Adjust thresholds based on real data
• Begin 99457 billing: document interactive communication time per patient per month
• Deploy patient-specific trend baselines: the first 30 days of CGM data per patient creates their personal baseline. Now the system can flag deviations from their normal, not just from population thresholds
• Identify patients who need concurrent CCM enrollment (most Type 2 patients with comorbidities qualify)

Phase 3: Scale (Days 61-90)

• Expand enrollment to 100+ patients
• Measure outcomes: compare A1C trends (if available) and time-in-range improvements against baseline
• Add the 2026 short-duration billing codes: capture revenue from patients who monitor intermittently (2-15 days per month)
• Assess EHR integration readiness: are endocrinologists using RPM data in clinical visits? If not, the data pipeline has a last-mile problem to solve

The key insight we learned across multiple diabetes RPM builds: care teams that understand time-in-range adopt CGM-based RPM faster than care teams trained only on A1C. TIR provides daily feedback. A1C provides quarterly feedback. A care manager reviewing a patient’s TIR trend can spot a deteriorating pattern in two days. Waiting for the next A1C result takes 90 days. Train on TIR first.

Visual Brief #8: 90-day implementation timeline in three phases. Each phase shows: key actions, team roles, billing milestones, and a risk flag. Phase 1 risk: “CGM API integration delay.” Phase 2 risk: “Alert threshold overfire.” Phase 3 risk: “EHR last-mile adoption.” Title: “Diabetes RPM: 90-Day Implementation Roadmap.” File name: diabetes-rpm-90-day-implementation.png. Alt text: “Three-phase 90-day implementation roadmap for diabetes remote patient monitoring showing foundation, calibration, and scale phases with milestones and risk flags.” Sizes: 1200×500 blog.

The Integration Layer Is the Product

The CGM device is commodity hardware. Dexcom, Abbott, and Medtronic will keep improving sensors. Smaller, cheaper, more accurate, longer wear time. That trajectory is set.

The RPM platform is the clinical workflow layer. Off-the-shelf handles basic use cases. Most programs start there and many should stay there.

The integration architecture is where the value compounds. The layer that normalizes multi-device data from five different Bluetooth protocols, applies patient-specific trend analysis across 288 daily glucose readings, embeds glucose insights directly in the EHR workflow so the endocrinologist sees them without switching tabs, and captures every billable minute across standard and short-duration RPM codes. That layer is the product.

Programs that treat diabetes RPM as “connect a glucose meter to WiFi” will get the same outcomes that have been available for a decade. Programs that build CGM-native monitoring infrastructure, where the platform thinks in trends and time-in-range instead of spot checks and static thresholds, will produce the outcomes the 2025 studies are starting to document.

Actually, let me sharpen that. The Montefiore study showed CGM plus RPM improved glycemic control at a safety-net hospital. Safety-net. Underserved population. If the integration works there, it works anywhere. The technology isn’t the bottleneck. The architecture is.

If you’re integrating CGM data into an RPM platform and hitting the same API edge cases we did (timezone reconciliation across a multi-state patient population is the one that will quietly ruin your trend analysis), we should compare notes. Reach out.

Request an Assessment to evaluate your CGM integration architecture and diabetes RPM program design.