CGM data trust gaps that break diabetes AI models
CGM sensors produce up to 288 glucose readings per day, but between 10% and 30% of that data is missing or unreliable in published research datasets. For any AI model built on continuous glucose monitor output, the trust problem starts before the first training epoch.
A single continuous glucose monitor produces up to 288 readings per day, one every five minutes. Over 14 days, that is roughly 4,032 data points per sensor session. Multiply by the 4.7 million CGM users in the United States as of 2023 and the theoretical data volume is staggering. But volume is not quality, and quality is not trust.
The AI models now being built on CGM data, from hypoglycemia prediction to automated insulin dosing to the foundation models like Google's GlucoFM, inherit every gap, artifact, and unmeasured confounder in their training data. If the glucose trace cannot be trusted, the model cannot be trusted either.
The scale of CGM data loss nobody talks about
Sensor dropout is not an edge case. A 2020 study in the Journal of Diabetes Science and Technology found that CGM data completeness in real-world use averages between 70% and 90%, meaning 10% to 30% of expected readings are missing from any given sensor session. The causes range from signal compression artifacts to sensor-skin adhesion failure, Bluetooth disconnection, and user behavior like removing the device for sports or MRI.
The International Consensus on Use of Continuous Glucose Monitoring published in Diabetes Care (2017) established that a minimum of 70% data capture over 14 days is required for CGM metrics to be considered reliable. That threshold is a floor, not a ceiling, and many real-world datasets fall below it.
For AI training, the problem compounds. A model trained on data where 25% of nighttime readings are missing will learn a distorted picture of nocturnal hypoglycemia. The absence is not random. Sensor compression artifacts cluster during periods of rapid glucose change, exactly when accurate data matters most.
Sensor accuracy is not uniform across the glucose range
| Value (%) | |
|---|---|
| FDA iCGM threshold (70-180 mg/dL) | 15 |
| Dexcom G7 overall MARD | 8.2 |
| Hypoglycemic range error (below 54 mg/dL) | 20 |
CGM sensors measure interstitial fluid glucose, not blood glucose. The physiological lag between blood and interstitial fluid is typically 5 to 15 minutes, though it can stretch longer during rapid glucose excursions. This lag means that during the moments most clinically relevant, when glucose is falling or spiking fast, the sensor reading is least accurate.
The FDA's guidance on iCGM (integrated continuous glucose monitoring) classification requires that within the 70-180 mg/dL range, sensors must read within 15% of a reference value at least 87% of the time. Below 70 mg/dL, the threshold is even looser, ±15 mg/dL. A sensor reading of 55 mg/dL could reflect a true blood glucose anywhere from 40 to 70 mg/dL and still meet FDA accuracy requirements.
The Dexcom G7 performance data submitted to the FDA showed an overall MARD (mean absolute relative difference) of 8.2%. But MARD is an average. In the hypoglycemic range below 54 mg/dL, individual sensor error can exceed 20%. An AI model that treats every CGM reading as equally reliable is making a structural error that no amount of training data volume will correct.
Calibration drift and the recency problem
Factory-calibrated CGM sensors like the Dexcom G7 and Abbott FreeStyle Libre 3 eliminated fingerstick calibration, which improved user experience but introduced a different trust problem. Factory calibration assumes a fixed relationship between the sensor's electrochemical signal and glucose concentration. That relationship drifts.
Sensor accuracy is typically worst on day 1 and the final day of a sensor's wear period, according to a 2021 analysis in the Journal of Diabetes Science and Technology. The first 12 to 24 hours often show a warm-up artifact where readings are biased low. The final day may show drift as the enzyme layer degrades or the foreign body response around the sensor filament intensifies.
For AI models consuming longitudinal CGM data, this means the trust score of a glucose reading depends on when in the sensor session it was captured. A reading from hour 3 of a new sensor is structurally less reliable than a reading from hour 72. No timestamp alone conveys this. You need a trust dimension that captures recency in the context of sensor lifecycle, not just calendar time.
This is precisely the kind of problem that the Recency dimension in the DTI framework was built to address. A record that looks fresh by date may carry degraded signal quality that only contextual scoring can surface.
The provenance gap: where did this CGM data actually come from?
CGM data arrives in AI training pipelines through multiple routes: direct sensor downloads via manufacturer apps (Dexcom Clarity, LibreView), third-party diabetes management platforms (Tidepool, Glooko, Nightscout), EHR integrations, and research repositories. Each hop introduces provenance uncertainty.
Tidepool, which maintains one of the largest open CGM datasets, has documented the complexity of normalizing data across sensor generations and manufacturers. A Dexcom G6 reading and a Libre 2 reading taken at the same moment from the same patient will not match, because they use different sensor technologies, different calibration algorithms, and different smoothing filters. Combining them without accounting for device provenance introduces systematic bias.
The OhioT1DM dataset, widely used in academic glucose prediction research, contains data from only 12 participants with Type 1 diabetes. The 2023 update expanded to 18 participants. Models trained and validated on this dataset are learning from a sample so small that any generalization claim is suspect. Yet dozens of published papers cite it as a primary training source.
Provenance scoring, the kind that tracks not just the device but the firmware version, the transmission pathway, the storage format, and any interpolation applied, is not optional for CGM-based AI. It is foundational.
Signal processing artifacts that AI models inherit
CGM manufacturers apply proprietary smoothing algorithms to raw sensor signals before displaying them to users. These algorithms reduce noise but also suppress real physiological variation. The Dexcom G6 applies a Kalman filter variant that smooths rapid glucose changes. The Libre sensors use a different approach that creates a 15-minute rolling average effect.
When an AI model trains on the processed output, it is learning the manufacturer's signal processing decisions, not the patient's glucose biology. Two models trained on data from different CGM brands will encode different assumptions about glucose dynamics, even if the underlying patients are metabolically identical.
The raw unfiltered signal is rarely available to researchers. Dexcom provides filtered data through its API. Abbott provides filtered data through LibreView. The few datasets that include raw signals, such as those from Medtronic's Guardian sensors used in closed-loop studies, show substantially more variability than the filtered versions.
This is a data quality problem disguised as a device feature. Every smoothing step removes information. Any AI system that cannot account for which processing was applied to its training data has a concordance gap that silently degrades model performance.
What the FDA requires and what it does not
The FDA's 2023 guidance on AI/ML-enabled medical devices lists data management as a key area of predetermined change control plans. For CGM-based AI specifically, the iCGM special controls guidance specifies accuracy requirements for the sensor itself but says nothing about the quality of aggregated CGM data used downstream for AI training.
This gap matters. A CGM sensor can meet every iCGM accuracy threshold and still produce training data that is incomplete, poorly provenance-tracked, and contaminated with interpolated values that look real but are not. The FDA regulates the sensor. Nobody regulates the data pipeline between the sensor and the model.
The 2024 draft guidance on transparency for AI-enabled devices signals that regulators expect developers to document their training data characteristics. For CGM-based AI, that means documenting sensor types, wear duration, data completeness thresholds, interpolation methods, and population demographics. Meeting that standard requires scoring every record before it enters a training set.
Why diabetes AI specifically needs trust-scored data
Diabetes AI sits at the intersection of three high-risk factors: the data is continuous (hundreds of readings per day), the clinical decisions are time-sensitive (insulin dosing errors can be fatal within hours), and the patient population is heterogeneous (Type 1 and Type 2 diabetes have fundamentally different glucose dynamics).
The 2022 recall of the Tandem t:slim X2 insulin pump software illustrated what happens when glucose data quality interacts with automated dosing. The system could deliver unintended insulin when CGM readings were misinterpreted during rapid signal changes. Six serious injuries were reported.
Google's GlucoFM, announced in 2024, represents the next generation of CGM-based AI. Foundation models trained on glucose data promise to generalize across patient populations and predict outcomes days in advance. But a foundation model amplifies its training data characteristics, good and bad. If the training data includes sensor artifacts, calibration drift, and missing nighttime readings, the model will encode those patterns as biological signals.
The gap between what CGM sensors can produce and what AI models need is not closing on its own. It requires an explicit trust layer that scores every record before it enters a training pipeline.
Eight dimensions applied to CGM data
| Value (%) | |
|---|---|
| Provenance | 25 |
| Consent | 20 |
| Recency | 15 |
| Quality | 10 |
| Concordance | 10 |
| Validation | 10 |
| Breadth | 5 |
| Stability | 5 |
Applying the DTI framework's eight dimensions to CGM data reveals where trust breaks down:
Provenance (25% weight): Which sensor, which firmware, which app version, which transmission path? A Libre 2 reading routed through a third-party NFC reader has different provenance characteristics than one captured natively through LibreView.
Consent (20%): CGM data shared with a research platform may carry consent for population-level analysis but not for AI model training. The consent layering problem is acute here because patients rarely understand that their glucose trace will train a commercial algorithm.
Recency (15%): A CGM reading from 2019 may reflect a sensor generation with 11% MARD. A reading from 2024 may come from a sensor with 8% MARD. The recency of the device matters as much as the recency of the reading.
Quality (10%): Was the reading captured during the sensor warm-up period? Was it interpolated? Was it within the sensor's rated accuracy range?
Concordance (10%): Does the CGM reading align with a contemporaneous blood glucose measurement, meal log, or insulin delivery record? Isolated glucose values without metabolic context are less trustworthy.
Validation (10%): Has the sensor been verified against a reference standard within its current wear session? Factory calibration is a one-time event; validation should be ongoing.
Breadth (5%): Does the dataset represent the full 24-hour glucose cycle, or is it biased toward daytime readings when patients are more likely to check their phones?
Stability (5%): Is the data format consistent across the dataset, or did a platform migration introduce schema changes that silently altered how values are stored?
No existing CGM data pipeline scores readings across these dimensions. The data flows from sensor to cloud to research repository to AI model with no trust checkpoint along the way.
The path forward
CGM data will be the substrate for the next decade of diabetes AI, from predictive algorithms to closed-loop insulin delivery to population health models. The sensor hardware is good and getting better. The data pipeline between sensor and model is where trust erodes.
Fixing this requires three things. First, every CGM reading entering an AI pipeline needs a provenance record that captures device, firmware, processing, and transmission chain. Second, data completeness must be scored per sensor session, not per dataset, because a dataset with 85% overall completeness can mask individual sessions with 50% completeness. Third, the trust score must travel with the data, not sit in a separate system that nobody checks.
The DTI Engine scores every record 0 to 100 across eight dimensions before your AI model sees it. If your team is building diabetes AI, evaluating CGM training data, or preparing a submission to the FDA for a CGM-based algorithm, talk to the SuperTruth commercial team. Schedule a conversation or call (215) 918-4140.
Further reading:
Sources
Jason Alan Snyder
Co-founder of SuperTruth and Artists & Robots, and an inventor on the Data Trust Index patents. Twenty-plus years building technology inside Interpublic Group. He writes here nearly every day on data trust, provenance, and what AI should be allowed to act on, and publishes essays on his Substack.
About SuperTruth · LinkedIn · Substack · jasonalansnyder.com
See it in practice
DTI scores the record, not the patient.
8 dimensions. 0 to 100. Travels with every record permanently.