The CGM Patent That Could Save Lives

A patent that describes detecting unreliable CGM readings has the potential to protect users from harm. And yet…

“The Patent That Could Save Lives” — Concept by Dan Heller; illustration by ChatGPT.

In December, 2025, a woman told me about a coma she experienced from an acute hypoglycemic event; her husband had to revive her. I asked to see her CGM data from the night of her event to see why her Omnipod-5 automated dosing algorithm might have miscalculated her dose. The moment I saw her CGM chart, I recognized a pattern immediately: a series of chaotic glucose readings, zig-zagging around in seemingly incoherent ways, all clustered together.

I recognized them because I wrote about them in my 2023 article, Continuous Glucose Monitors: Does Better Accuracy Mean Better Glycemic Control? In that article I wrote about my experiment with the new Dexcom G7 at the time, where I wore it alongside the G6 for a month to see how they compared. The left-hand chart below is from that article; on the right are the CGM readings from the woman’s Dexcom data. I refer to the woman as Jane Doe to protect her identity.

The patterns were similar. And our experiences were also similar. She suffered a coma and I came pretty close to it. What the two graphs have in common is what I wrote in my article: sudden, spontaneous and physiologically implausible glucose movements that I predicted would harm users. I wrote:

Turns out, the G7’s data shot up to 270. If this really was my real glucose level, the stacked boluses I’d taken would have perfectly corrected these readings, and I would have had a soft landing. But, as the insulin started to kick in, my glucose levels plummeted to 49. And I was being conservative! Had I taken just one more unit, I may well have gone into hypoglycemic coma, and I might not be here to be writing this article.

My immediate speculation was that Jane Doe’s Omnipod-5 algorithm saw the same noisy data, and didn’t discriminate it from the rest of the readings and just dosed too much insulin. The same mistake I made in 2023.

It turns out, this is hardly an outlier—it happens very frequently, and the severity is increasing. An article published by Hunterbrook Media titled Dexcom’s Fatal Flaws cited 60 claimants alleged hospitalization and deaths as of September, 2025. In late October, they published a follow-up article reporting three more deaths. A number of individual and class-action lawsuits are in progress. All tied to the same G7 “accuracy” problems.

But to put this into perspective, while these deaths and injuries are only alleged in litigation, not yet adjudicated, they represent an implied mortality rate of roughly 1 in 2,600 to 1 in 3,000 among US AID users.

And we know that not all the adverse events associated with the sensors are captured in this data. Jane Doe is not represented here, nor are similar accounts found in Facebook and Reddit discussion groups.

To put this into perspective, when the FDA moved to restrict the Johnson & Johnson COVID-19 vaccine in May 2022, the agency cited 9 confirmed deaths attributable to a rare clotting disorder across 18.7 million doses administered — a death rate of roughly 1 in 2 million. The agency had actually moved faster than that: the initial pause came after just 6 cases and 1 death among 7 million doses, a rate of approximately 1 in 7 million.

Against that backdrop, just the known adverse events with the G7 is somewhere between 700 and 2,700 times the threshold that triggered the FDA’s J&J pause.

Could it be that these clusters of zig-zagging glucose readings might be responsible? I pose the question this way because of what I observed and wrote about in my 2023 article: Those are physiologically implausible glucose readings. Glucose doesn’t move like that in the body. If that’s the case, then we can presume that Jane’s real glucose levels were unknowable. The numbers are as good as random. The Omnipod-5 algorithm probably assumed that her real glucose levels were somewhere in the middle, so it just averaged the numbers together. That may work. But not always. And that’s the risk.

Clusters of physiologically implausible glucose readings are like Russian Roulette: It’s good to be lucky, but you shouldn’t be playing the game. It only takes one to cause real harm. The more clusters there are, the more bullets you load into the empty chambers in the gun—your risk profile rises.

The real issue is that they should never happen in the first place.

We’ll tackle that another day. What we’re faced with now is a different problem: Can we detect these clusters of incoherent data, and if so, what do we do? What we’re talking about here is CGM sensor integrity. To be clear, fault detection methods for CGM data have been explored in academic and artificial pancreas research contexts: Facchinetti et al. (2013) and Mahmoudi et al. (2016) describe real-time detection of CGM failures — spikes, drift, pressure artifacts — but in controlled research settings where the raw materials are artifacts of the CGMs themselves rather than the resulting readings they produce.

What I’m presenting in this article is different: The characterization of spontaneous clusters in real-world commercial CGM exports and their correlation with adverse insulin dosing events, has not, to my knowledge, been addressed in the published literature or in any public tool.

To that end, I wrote an algorithm that detects these patterns in real-world glucose readings produced by any CGM with two objectives: first, to assess the runtime “health” of a sensor; and second, to correlate unreliable glucose readings to adverse events. In the interest of general public health, I am making this algorithm and the package freely available for continued research and development. More on that later.

From Jane Doe’s Coma to an Algorithm

Once I made the connection between my data and Jane’s, I spent the next few months developing an algorithm to detect these patterns. Using statistical analyses described in medical literature (much of which I cited in my 2023 article), I developed an algorithm that detects when reported glucose readings become less probabilistically likely to follow one another. When you put them in sequence, they tend to collect into clusters that can be categorized into degrees of severity.

I call my algorithm a sensor integrity detector (SID). As its name implies, it detects clusters of physiologically implausible glucose readings (PIGRs).

Below is an analysis of Jane’s CGM readings over her 24-hour period, interpreted by my SID algorithm. As you can see, it identified many clusters of PIGRs from that single day where she suffered from the event.

The red boxes are “critical” clusters and the orange boxes are “elevated” clusters. We’ll get into the details of what those mean later. The “1” and “2” labels identify hypo events that come after a cluster. Black represents a nocturnal hypo; yellow represents hypos that happen during the day. Jane’s coma happened at the “1”.

NOTICE THE BLACK CIRCLES. These represent manual BGM readings that Jane did. Many times, they matched the CGM readings. These are the fortunate events. But you can see at 3:30am, she had several readings that were over 100 mg/dL lower than what the CGM said, and her pump algorithm never knew it. That’s why it kept dosing insulin, leading to her coma.

If the algorithm recognized that the clusters were unreliable, it would not have dosed anything. Therefore, her event was preventable.

This struck me as so obvious, that I couldn’t believe I was the only one to discover it. I searched online for any discussion of this sort of thing, in T1D discussion boards, AID development sites, and people I knew.

Crickets.

It was only when I started to describe the aims of why this algorithm would work that I discovered one citation: a patent filed by Dexcom on exactly this phenomenon.

Dexcom Patent for Detecting Unreliable CGM Data

Dexcom filed a series of patents that precisely characterize the methods for detecting the same noisy glucose patterns that my algorithm just did. The first one was filed in 2013, WO2014107275A1, Outlier detection for analyte sensors, US 12,354,030 B2 (granted July 2025), which focuses on detecting unreliable CGM data in real time. The language in the patent includes this line:

“One goal is to prevent closed-loop systems from incorrect dosing based on end-of-life noise, and to suspend or modify dosing when EOL signatures are detected.”

The patent then goes on to describe what should happen when these criteria are met:

1. Display instructions to change the sensor.

2. Transmit data to connected devices (pumps) indicating degraded data quality.

3. Prevent automated delivery systems from dosing based on erratic readings.

Despite the existence of these patents and the methods they describe, I have found no public evidence that they are being deployed in a way that warns connected systems before automated insulin dosing occurs.

That changes the entire framing of how the adverse events associated with the aforementioned lawsuits would be interpreted.

To understand why, let’s look at the lawsuits currently filed against Dexcom.

The Dexcom Lawsuits

As noted by the Hunterbrook Media article, the lawsuits are generally citing “the G7’s inaccuracy”, without much more detail than that. To support their claims, the claimants point to an FDA warning letter that revealed Dexcom made an unauthorized design change to a key component of the G7 that internal studies showed was inferior by “every accuracy metric.”

But this could be a red herring. Dexcom stands by its accuracy claims, asserting that the G7’s MARD value is a standard throughout the industry and has remained the same ever since the sensor was released in 2023. (MARD stands for Mean Absolute Relative Difference, where the CGM readings are compared against a blood glucose analyzer. The lower the MARD rating, the closer the CGM data matches the blood analyzer data.)

Indeed, my 2023 analysis (and a new 2026 review of the latest G7 algorithm covered later) show that the G7 has always performed largely on par with the G6 and almost every other CGM on the market—in the aggregate. That is, when you calculate longer periods of time.

The following chart from my 2023 article shows how the differences in actual readings between the two sensors over days and weeks are largely the same with the G7 reporting slightly lower values on average:

The G6 averaged 121 mg/dL, versus the G7’s 116, and the standard deviations (SD) were 33 vs. 34, respectively. By the traditional metrics of measuring a CGM’s “accuracy”, the G7 and G6 are nearly indistinguishable.

So, again, in the aggregate, the G7 is just as accurate as the G6.

As for the victims that suffered adverse events from these faulty sensors, Dexcom can say they already acknowledged and demonstrated that some sensors can, indeed, fail, and they showed it in the clinical trial they conducted to gain FDA approval for the G7.

In their article, Accuracy and Safety of Dexcom G7 Continuous Glucose Monitoring in Adults with Diabetes, the results showed that roughly 2% of sensors can have MARD values northward of 20%, with an additional 2-3% having MARD ratings exceeding 14%. But they also have no idea why; as they stated in their filing, “the basis of anomalously poor accuracy in a small proportion of sensors is unknown.”

Below is a figure included in that report, representing the MARD values for 619 sensors placed on the arm or abdomen:

Dexcom’s defense could be that those users were unfortunate enough to have encountered one of the outlier sensors, and that the company had already disclosed it in clinical testing, and that whatever the FDA letter means, the G7’s overall accuracy profile has not fundamentally changed.

There’s a lot of “ands” in that sentence.

Therefore, attributing the G7’s known ratio of inaccuracies doesn’t change the reality that these are statistically consistent with what’s always been known about the G7. We’re sorry for your loss, but medtech is an imprecise business — or so the argument would go.

A more consequential framing is whether Dexcom could have detected these bad sensors while they were in use and, if so, warned either the user or the AID system that the readings were unreliable for dosing. You know, exactly as described in their own patents. That new framing has never been proposed from my research.

Again, Dexcom could say that they are detecting noise in sensors, which explains the “sensor error” messages people get.

But is that sufficient? Dexcom may say “yes, it’s sufficient. And those erratic glucose readings you see, well, we believe they are still viable enough for dosing.”

That’s what they might say. Of course, we don’t know. But to consider it, we’d have to see the patent or its application in action.

This is why it matters that I wrote an algorithm that effectively performs the same class of detection and that I can directly correlate clusters of unreliable data to hypoglycemia. My SID algorithm can be used as a tool to test that assertion quantitatively and objectively—to determine the degree in which these detectable patterns arise.

But again, this is not unknown — Dexcom’s trial said that a small percentage of sensors can have MARD ratings north of 20%. But is it really? Now that I have my algorithm, I ran it against my entire dataset from my 2023 article, where I wore both the G6 and G7 at the same time. The results speak for themselves:

The G7 produced 24x more clusters of PIGRs than the G6. To validate it further, I ran the SID against CGM data from open source AID users from the OpenAPS Data Commons, which covered over 360,000 hours of sensor time. Below are the results: Each bar represents the percentage of time that each sensor spent producing unreliable data. The G7 performed far worse than all of their own sensors.

That’s what brings us back to Jane Doe’s event and the unreliable CGM readings that her Omnipod-5 algorithm interpreted as requiring an amount of insulin that caused her coma. The Omnipod’s algorithms are designed to be as conservative as possible; hypoglycemia is the primary risk to be avoided. If the dosing algorithm did its calculations right, this shouldn’t have happened. But if the data it was using was unreliable, then this might explain that mis-dosing calculation.

In a legal proceeding, if discovery were ever to show that these more severe signatures were detectable—especially those that resulted in death or injury—and that meaningful safeguards were left under-deployed (i.e., the algorithm didn’t flag the data as “unreliable enough” to trigger a “Sensor Error” fault), the case would begin to look more serious than ordinary negligence.

If this is the case, the reverberations would not stop with Dexcom.

Who Does This Affect?

The next obvious question is this: if Dexcom could have detected these unreliable events, and I was able to demonstrate a workable method as well, should pump algorithms have been able to detect them too? That is, why should pump algorithms have to rely on Dexcom if pump algorithms could also detect unreliable glucose readings?

If the answer is yes, then the liability landscape widens considerably to include any technology that uses CGM data to either administer insulin, or present glucose values to users in a way that would affect their in-the-moment dosing decisions.

This is where the duty-of-care question becomes harder to avoid: once a hazard is knowable, companies that act on the data cannot easily treat reliability as someone else’s problem. That, in turn, complicates some of the protections they might otherwise hope to invoke later, including PMA-related defenses.

If it was not common operating knowledge before, it is much harder to treat it that way after this. And one does not necessarily have to have access to some mysterious, proprietary, secret algorithm to detect these signatures. My code demonstrates it sufficiently. The patent’s importance here is not that it blocks inquiry, but that it shows the problem had already been worked up into something concrete. The important point is not patent doctrine in the abstract. It is that nothing about this problem makes it off-limits to other companies that rely on CGM data and have reason to take reliability seriously.

In fact, not doing so may pose its own risks: If someone is harmed in ways that can associate unreliable glucose readings to dangerous insulin dosing, it’s no longer possible to say, “We didn’t know”, or that “Dexcom didn’t tell us”, because the methods are there.

Now, just because pump companies may also be responsible for assuring glucose readings are reliable, this doesn’t alleviate Dexcom. The duty question does not end with the last actor in the chain.

The Problem is Getting Worse

Because Dexcom is the largest player in this market, there’s concern the problem could get worse due to three critical catalysts. The proverbial “perfect storm”.

The first is the rapid uptake of AID systems, increasing the number of users who delegate more of their daily management to algorithms and are therefore less likely to notice these errant glucose patterns in real time. (I discuss this and other moral hazards of automation in my article, Medical Literature Analysis: The Performance Paradox of AID Systems.) So long as AID algorithms do not have safeguards for these spurious CGM readings, the risk rises.

The second catalyst is unnecessarily high basal rates, which are the “background” insulin doses that pump algorithms infuse like a leaky faucet. The default settings are set so high that people have far more insulin onboard than is physiologically necessary, so they’re constantly teetering on the brink of hypoglycemia as it is. A simple miscalculated bolus from a cluster of unreliable CGM readings can quickly trigger an acute event.

(I discuss basal dosing at length in Basal Dosing: How Much Do We Need?, which cites DeFronzo, et al., in 1979, who found that in T1D, alpha cell dysregulation is so severe that there’s nearly an imperceptible amount of “background glucose production” that needs to be taken care of by basal insulin. But high basal rates from AID systems is pushing too much insulin into people, raising the risk of hypos. The problem has reached the point where section 9.27 of the ADA’s 2025 guidelines now recognizes overbasalization as a major health concern for T1Ds.)

So, with high basal rates and automated dosing calculators relying on potentially unreliable glucose readings, the risk elevates substantially.

Now comes the third catalyst: Dexcom announced discontinuation of the G6 as of July 1, 2026, requiring users to move over to the G7. And yet, Dexcom’s own study shows that approximately 26% of the new 15-day Dexcom G7 sensors are expected to fail or not last the full duration.

I can’t overstate how monumental this declaration is.

It’s not just a simple case that someone’s Dexcom app suddenly posts a short message: “Change your sensor”, and then they are sent a replacement. It’s not that simple.

Before a sensor technically fails, it goes through a period of gradual degradation. The days, and most importantly, the readings leading up to the ultimate failure are going to devolve into a mess of unreliable glucose readings. Data shown later in this article illustrates this perfectly, raising the pivotal question: How is this “replacement” protocol supposed to work? Users aren’t sophisticated enough to know that their sensors are producing unreliable data. Heck, until now, no one knew that such a thing could even happen.

And if users don’t know, will Dexcom tell them? What will the cutoff point be where Dexcom notifies the user that the sensor is eligible for replacement? Without guidance—let alone awareness—users are going to be more like Jane Doe and just accept whatever the system is doing. This raises the risk profile considerably.

Dexcom’s own patent has the ability to detect when a sensor is starting to degrade. When they choose to alert the user now becomes a policy decision, not a technical decision.

By taking the G6 offline—an otherwise very safe and effective sensor—users will be forced to use a risky sensor that Dexcom declares will fail at least 26% of the time, possibly more. And it’s not just everyday users that will be affected. The G6 is deeply integrated across the entire healthcare system, including hospitals, ICUs, and many other critical care settings. If the G6 has to be swapped out for the G7, this puts at risk the most vulnerable among us.

So, who’s going to come to the rescue? The FDA?

The regulatory framework that governs CGM approval has no requirement for manufacturers to characterize how often individual sensors produce physiologically incoherent readings, how severe those readings are, or whether real-time anomaly detection is functional and deployed. The only thing the FDA requires is that a CGM shows comparable performance against a reference platform, and as we’ve already seen, a sensor can easily appear to be “accurate” by these measures, while also producing exactly the kind of erratic clusters described in Dexcom’s own patents as end-of-life failure signatures.

The approval framework is silent on this. Until that gap is addressed, the question of what constitutes an acceptable failure rate remains entirely in the hands of the companies whose business interests are directly affected by the answer.

But there is one more pressure point.

Regulation Through Litigation

If there’s one thing Americans are really good at, it’s litigation. And that can be a very powerful tool for instituting change. The concept of Regulation Through Litigation describes changes — particularly those affecting industries — that were brought about by litigation rather than legislation or self-regulation. Tobacco being one of the textbook examples, but the list is extensive.

In the case of CGM data being unreliable for dosing a lethal drug, lawsuits are no longer hypothetical. The industry will be watching very closely how the Dexcom cases proceed. And more may well come. And that’s why the focus of this article is on both the Dexcom cases and the company’s patent. These may be the canary in the coal mine.

One thing to be on the watch for is how companies will seek protections under the auspices of PMA approval (“pre-market approval”). This is where companies often enjoy broad protection from liability claims after the FDA has approved a product.

But there are carve-outs for this. If a clinically important hazard is knowable, if it intersects with duties already embedded in postmarket surveillance, hazard analysis, warning, complaint handling, or risk management, then the inquiry does not stop at “the FDA approved it.”

So the inquiry does not necessarily end there. And as they do, we’re not necessarily looking for what a trial, judge or jury finds — although, that could be monumental — it’s what was found during the discovery process. That’s the work lawyers do to collect evidence leading up to a trial. That is often where the most consequential changes are made (whether or not the public is made aware of them).

During discovery, lawyers collect internal communications and documents surrounding a claim. And defendants are required to turn them over. And, as stated before, it’s not just Dexcom. It’s anyone that is part of a chain of technologies that led to a person suffering harm. It’s a classic case of the paper trail between what engineers knew, and what was implemented.

If discovery were to show that engineers understood this class of unreliability and failed to address it, PMA would become a less comfortable refuge. And it’s not just that they knew, but had every opportunity to act to mitigate the risk. And the existence of the patent and my independent implementation of detection makes this all the more apparent.

A practical fallout from this is straightforward: any company touching CGM data in a way that influences dosing or treatment decisions has reason to think seriously about data integrity. Third parties do not necessarily need to wait for Dexcom to deploy anything. If they have the data, they can begin testing for these signatures themselves.

With that accountability landscape in mind, the next question is what detection actually looks like in practice — and whether it’s as technically daunting as it might sound. It isn’t.

Detecting Physiologically Implausible Glucose Readings in CGM Data

As stated earlier, my SID algorithm detects PIGRs — Physiologically Implausible Glucose Readings — by tracking CGM readings, one by one, looking for stretches where the oscillation between them exceeds what physiology can explain. Once the pattern is detected, the severity of the cluster elevates till the pattern subsides. Obviously, a little jumpiness is tolerable, but clusters of increasingly larger amplitudes can actually be dangerous. This is where there’s a strong indication that something in the hardware is amiss, so there’s no way to know what the true glucose level could possibly be. This is where dosing decisions become dangerous. Not assuredly so. And, like the Russian Roulette analogy earlier, noisy data may very well be within range of real data. But this doesn’t mean we should be complacent with it.

With that in mind, my algorithm’s aim is mechanism, not policy. The parameters in my code are tunable. You can set how much amplitude is necessary to elevate a cluster’s severity, which will catch clusters that are, technically, physiologically implausible. Reasonable people can disagree as to when the noise is sufficiently bad for dosing decisions, and the ratio of Russian Roulette risk tolerance. This is where policy decisions affect health outcomes. This can and should be baked into minimum FDA standards, but those don’t exist. Therefore, it’s in the hands of companies and their business risk/reward analyses.

This article is not going to get into any technical detail about how the algorithm works. All that is laboriously explained in the documentation that accompanies the code, which is being made publicly available under the MIT license: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software

The code can be downloaded from GitHub.

The distribution is a zip archive. When you download it to your computer, you then unzip it (usually, double-click on it in your file finder), and you’ll get four more zip archives and a README.md file:

After downloading the package, users are encouraged to run the code using an AI assistant, such as Claude, ChatGPT, Gemini, etc. It is so much easier than running analysis by hand.

NOTE: Some have reported that not all AI assistants will understand what to do with the code, despite the fact that there are clear instructions to the AI. In my own testing, the same AI agent will know what to do right away, and other times, it doesn’t. It’s not clear how pervasive this problem is. But I am working on a longer-term solution that I will post later.

Those with access to large datasets — OpenAPS, Nightscout, Sugarmate, Gluroo, etc. — are encouraged to use the associated API packages (fully documented) to run large analyses to get a sense of broad sensor health performance.

For individual users, to understand your own CGM’s health, you need to upload your CGM data, so to do that, you go to the website associated with your product and download your data. Dexcom’s Clarity patient portal is shown below. After you login, select a time span (I suggest 90 days), and choose the Export button—not the download button. You don’t want a PDF report, you want the raw data in CSV format.

Once you have your CGM data, open a browser tab to your preferred AI agent and upload both files—the SID distribution and your CGM data. The AI assistant will read the documentation and immediately know what to do. You can then ask it questions. If you’re lost, ask what to do. If you want new ideas, just ask. If you don’t even understand what any of this is about, ask. Those things are pretty smart that way. You can also point the AI to this article if you want to ask questions about the details.

Sample Reports

This section will show some sample reports that the SID package will produce.

The first sample is a daily report generated for March 3, 2023, the first day of the first G7 sensor I ever wore. This data comes from my 2023 article. Red boxes mark Critical clusters and orange boxes mark Elevated clusters.

All reports highlight two key datasets: The clusters themselves, and the number of hypos that happened after a cluster. The black numbered symbols represent nocturnal hypos that occur during or shortly after a cluster. These are guideposts to look for the insulin doses that may have led to the event. CGM data from Dexcom and Abbott do not contain insulin doses unless users manually add that information. And they rarely do, and AID systems don’t export their dosing data to anything.

The table at the bottom lists the time the cluster ended, how many minutes after the cluster it took before glucose levels dropped below 70 mg/dL, and the lowest BG value recorded while glucose levels remained below 70. (BG units will show mmol/L if that’s what’s used in the CGM data report.)

Now let’s look at a clean report: Below is a G6 chart for the same day.

As we can see, there are no clusters of PIGRs in the G6. But you can also see that the overall glucose readings are roughly similar to the G7. That’s what makes the G7’s “accuracy” claims feel plausible. We can see that by overlaying the charts. (This is also the leading image from my 2023 article.)

At a high level, the G6 and G7 run mostly in parity. The G7’s jumpy readings look odd, but still relatively close to the G6. True, but that’s not how dosing decisions are made. They are made, not just based on fixed glucose levels, but trajectory and rate of change. This is why the jumpiness is problematic.

If a cluster of readings breaches a threshold where they are now physiologically implausible, this could give the illusion of rapid glucose movements. If we zoom into the 4pm window, we can see this in stark detail, which brings us back to the original image at the beginning of this article.

When zoomed in like this, we can now see that these wild glucose readings are highly unreliable, and nowhere near where the G6 was—the “reliable” readings. That’s why I made my own dosing error and caused my glucose levels to drop to 49. You can imagine an AID system algorithm making the same decision. And once this becomes apparent, it’s much easier to see them.

And yet, Dexcom promoted the G7 as being “the most accurate CGM”. Technically, they were right. But that was based on easily manipulable metrics like MARD that the CGM industry has adopted and the FDA permitted. If the standard were based on sensor integrity, the CGM market would look very different, and manufacturers would have different incentives to aim for.

Now that we have an algorithm that detects clusters, let’s run it on the entire dataset where I wore both the G6 and G7 to get a dashboard of the whole month. In total, there were 19 Critical clusters, and 90 Elevated clusters. Each bar in the chart represents the number of elevated and critical clusters over the full day of readings. We start with the chart for the G7 and notice that there were 27 hypo events that succeeded a cluster.

Even for me, a particularly well-controlled T1D who’s pretty adept at dosing (multiple daily injections, or “MDI”), I can also be swayed by CGM readings that look like they require dosing.

Of course, that was in 2023 when the G7 first came out. I had no idea what was going on. The G6 was so reliable, and with the G7’s claim of being more accurate, I assumed the G7 was somehow seeing nuanced data that I’d never considered before. I thought I could get better control still. Turned out, these were entirely unreliable readings, and my experience confirmed it.

And we can see in the aggregate time-in-range (TIR) chart from 2023, just how different the outcomes were. When I used the G6 to make decisions, I achieved a TIR of >90%. When I used the G7, my TIR dropped to the ~70% range.

Let’s now focus on another part of that report: The sensor’s overall “health” as indicated by the purple bars that have the sensor numbers: S1, S2, and S3. This color is one of four that represents a scoring formula to determine how reliable the sensor is overall.

For you math nerds, I add up all the amount of time the sensor was in elevated and critical clusters, along with the amount of time the sensor produced clean data:

For comparison, below is the dashboard for the G6 that I wore at the same time: A total of 7 elevated clusters and only one critical one.

There are no hypos shown here because, even though I had them, none were associated with the G6 sensors I was wearing.

My sensor integrity detection algorithm can produce a variety of reports, including situations like my experiment wearing multiple sensors, but it can also produce reports from large datasets, indefinite time frames, and so on. Here’s a multi-sensor report showing both the G6 and G7 combined.

OpenAPS, Nightscout, Tidepool

If you use OpenAPS, Nightscout or Tidepool, your insulin dosing data is there, and my reports will graph it. Below is an example of an anonymous donor using an unknown CGM because this data is often not included in many people’s uploads. We can see this is a pretty noisy sensor—therefore, probably highly unreliable most of the time. The insulin dosing data includes both large doses as well as SMBs (super micro boluses) and are represented at the bottom of the CGM graph.

This particular user had three hypos that are directly associated with insulin dosing that appears inconsistent with the CGM readings at the time. But of course, there are a lot of unknowns here, such as which doses were automated versus user-initiated, nor whether the person ate food and bolused for it. This is why daytime data is hard to interpret—lots of confounding factors.

By contrast, nighttime data is easier because we can generally assume no manual bolusing or eating, so any insulin delivery is likely algorithm-driven.

Notice there’s one nocturnal post-cluster hypo, labeled “4”. That cluster started before midnight on Dec 15, but hypo nadir falls just after midnight on Dec 16, so the table correctly reports it (with the +1d marker), but the chart can’t render it because the scatter plot is bounded to the Dec 15 24-hour window.

The new Dexcom G7-15day Sensor

In December, 2025, Dexcom updated their G7 algorithm to smooth out some of the jumpiness in readings. The new G7-15day sensor inherits this new algorithm. To test it out, I wore the G6 and the G7-15day sensors at the same time, just as I did in 2023, but for 70 days. Below is a graph of the new G7-15day sensor for January 6, 2026. While the overall data are far better than those of the old G7 algorithm, the new sensor itself is not quite there yet.

Here’s a dashboard report for six sensors worn over the period. Here, we find there were 19 Critical level PIGR clusters throughout the period. In other words, the new G7 algorithm is clearly improved, but it is not yet as generally clean as would be ultimately needed.

It’s very important to notice one more thing in sensors 4 and 5: the number and severity of the clusters increases as the G7-15day progresses towards the end of its life cycle. This suggests that the hardware begins to degrade progressively, not all at once. This is the vulnerability users would need to be concerned about when I mentioned earlier that 26% of 15-day sensors won’t make it to the end. This gradual degradation is what happens as it approaches that endpoint, and this raises risk during those periods.

Now let’s talk about the G6.

Dexcom G6 can have bad data, but….

In my 2023 data, the G6 was almost entirely clean. Indeed, that’s almost always been the case for me and most others. The G6 is a well-established and reliable CGM. My analysis across years worth of G6 data rarely finds a problem.

But this doesn’t mean the G6 won’t have issues. It can, but this is where things are different from the G7.

The G7 is a self-contained unit — the sensor and transmitter are built together as one piece. In the G6, the transmitter is a separate unit that clips onto each new sensor. One transmitter typically lasts three months, during which you cycle through roughly nine 10-day sensors, attaching the same transmitter each time.

That design difference matters. Both the G6 and G7 transmitters use sealed batteries that can’t be replaced. As those batteries age, they don’t fail cleanly — they degrade unevenly. When that happens, the electrical signals the transmitter reads from the sensor become inconsistent, and the glucose values it reports start to drift and spike in ways that look a lot like bad sensor data. In the G6, this is easier to spot because the transmitter is separate: when one goes bad, every sensor you attach to it will produce unreliable data. In the G7, the transmitter and sensor are fused together, so when a unit goes bad, there’s no way to know whether the problem is the sensor, the transmitter, or both.

What we can say is that my algorithm detects the same signatures in both cases.

Below is a report of my G6 data from September through December 2025, covering four different G6 Transmitters. That’s a lot for a three month period, but you’ll understand why in a moment. Let’s examine the dashboard:

Notice the concentration of bad sensors (S1 - S3) in transmitter 89PKFK. The number and severity of these bad clusters made me acutely aware that the transmitter was failing. In the G6, when a series of sensors are bad, the problem is the transmitter, not the sensors.

So, I got a new transmitter (89W2NK), which started fine, but at the end of S2, again, the number of clusters were increasing, all bumped up against the end. Knowing the transmitter was failing again, I got yet another transmitter, 8QXYWL, which was largely clean. That is, there were minor clusters (that if you look at each individually, are comparatively small), but they were also not increasing in frequency the way the old G6 transmitters were.

This is very much the pattern Dexcom’s patents describe: as transmitters begin to fail, the data become progressively unreliable.

The problem with G6 transmitters is that they tend to fail pretty reliably as they get to the end of their 90-day period OR the end of the use-by date on the box. And, for some reason, whenever I get a new G6 transmitter from Dexcom or my pharmacy, that use-by date on the box is pretty close to the current date. If I don’t use it right away, that transmitter won’t last its entire 90-day period.

Now that we’re talking about bad transmitters, let’s return to Jane Doe.

Jane Doe: Mystery Solved

Jane was using a G6. And her problem wasn’t her sensors — it was her transmitter. One bad transmitter caused every sensor she used during that period to produce faulty data. This is not something generally known.

You can see in her dashboard that she kept swapping sensors, over and over, well before their normal expiration. She thought she was getting a run of bad sensors. The transmitter was the source, and it was affecting every sensor it worked with. (I changed the transmitter ID to protect her identity.)

Her acute hypoglycemic event happened on December 5th, but she had suffered 83 hypos tied to bad clusters during the entire 90-day period. Any one of those nocturnal events could have been lethal.

After her coma, she was told by her endo to change sensors. Again. It didn’t solve the problem.

Next Steps

With all we’ve covered here, restating my earlier warning may have a different resonance now: If these signatures are as detectable as the data suggest, then this begins to look less like unavoidable noise and more like a class of preventable harm. The saddest part is that this has been known for over 20 years when the first patents on detecting these patterns were filed.

Reasonable people can debate exactly where to draw the line between ‘noisy but usable’ and ‘don’t trust this data.’ That is the policy debate this kind of detector forces into the open. One could reasonably ask what the commercial consequences would be of deploying this detection more aggressively. That question is worth sitting with, while also understanding that this article is not the first to deliberate on it.

CGM and pump companies are aware that clusters of data can be unreliable, so they’ve had to debate the “noisy-but-usable” consequences long before now. A system that’s constantly bothering the user is unusable at best, and frightening at worst. That puts everyone in the ecosystem in a very uncomfortable position. The G7’s behavior caught everyone flat-footed.

And let’s not forget the Russian Roulette analogy. The likelihood that a cluster is still within the scope of a person’s real glucose levels is unknown, but likely. The fact that things work out OK anyway gives the false illusion that this is an acceptable problem.

But let’s pull the lens back and realize that this class of recurrent, transient, self-contained signal incoherence should never exist in the first place. It should not be the new normal. Before the G7, this problem was so rare that we didn’t think we needed it. And hopefully, the G7 will become noise-free. As the company works towards that, it would be wonderful to delay retiring the G6 until the new G7’s performance is as clean as the G6 with a good transmitter.

And we should also use this as a learning opportunity to make things safer throughout the industry.

One thing we need to be alert to is the industry response. The easy and dangerous way around this problem is not to solve it, but to smooth it away — to do exactly what current pump algorithms often do, averaging unreliable data until it merely looks usable. That would calcify the problem rather than fix it, much as CGM trials eventually learned how to optimize for flattering MARD values.

The article Limits to the Evaluation of the Accuracy of Continuous Glucose Monitoring Systems by Clinical Trials is a step in the right direction: it explains how MARD can be manipulated or misinterpreted by trial design, and it recommends better reference methods, weighted accuracy measures, and more transparent reporting across glucose ranges and wear periods.

But even that is not enough. What also needs to be measured is local sensor integrity — whether the trace itself becomes briefly incoherent in ways that can be clinically dangerous even when the average performance still looks respectable. To address that, my proposal is for trials to include using independent reference CGMs alongside the sensors being tested. This would catch attempts to conceal transient incoherent traces by averaging numbers together because those averages would be far out of sync with the reference sensors.

As for what those sensor-integrity standards should look like, this is where movements like #WeAreNotWaiting can help. The group has long pushed open interoperability across hardware and software platforms in much the same way open standards helped stabilize many early internet-era technologies. That same ethos could now help define practical standards for sensor-integrity analytics, using my reference platform as a working model. Working with industry, the open-source community could propose a formal standard for inclusion in future trial design and FDA review. At that point, “accuracy” in the MARD sense would no longer stand alone.

Until then, the broader ecosystem can help monitor sensor integrity even if manufacturers do not move fast enough. OpenAPS Commons, Nightscout, Tidepool, and other data-rich platforms are in a position to surface population-level performance patterns and make it harder for signal-quality problems to hide behind aggregate metrics.

Most urgently, downstream systems that act on CGM data need to begin checking its integrity for themselves. That includes apps, dosing calculators, hospitals, and closed-loop systems. If the data are incoherent, then the system should know it is acting under degraded conditions. And in some cases—especially where insulin dosing is involved—it should refuse to act at all. This is both for patient safety and for their own liability protection.

This is not as hard of an ask as it may sound because the code could be licensed or developed in-house. For example, the screenshot below are mockups showing how Gluroo and Sugarmate, two of the most popular T1D management apps, might represent unreliable CGM data.

AID systems software can monitor for sensor degradation and switch into manual mode until the data is clean again.

Dosing calculators can simply say that they can’t recommend dosing while the CGM’s data is unreliable. (As it happens, many insulin dosing calculators don’t even factor in current glucose readings in their formulas. They simply calculate dosing based on the person’s carb-to-insulin ratio and the number of carbs they’re entering into the calculator. This is notoriously dangerous, and is a separate matter entirely.)

Hospital systems that integrate CGM data into inpatient care — increasingly common in ICU settings — carry perhaps the highest duty of care of all, given the acuity of their patients and the directness of clinical action on that data.

Clinics and healthcare providers can identify when sensors or transmitters are suspect, so when patients call with problems, the HCP can be prepared to offer better advice. This could have been helpful to Jane Doe.

And, of course, there’s the CGM companies themselves. They could immediately deploy certain processes that require no FDA submission, no firmware update, and no action from any user at all. Their backend systems already aggregate data from every sensor in the field; running coherence detection centrally on that incoming data stream is a deployment that can be done within months. When a signature is detected, the system flags it. As they accumulate, the condition escalates automatically in the system. What happens next is not a technical mystery. It is a policy choice.

One option is to send automated messages to users’ phones, emails, care teams, and emergency contacts. Internal support systems would also be aware. All service agents identify the patient when they call. Imagine if Jane Doe called Dexcom to ask about her CGM: whoever answers that call would have their computer screen flash large red, all-capital letters: USER’S SENSOR SHOULD BE REPLACED IMMEDIATELY. Or a transmitter for the G6.

At this point, with what we all now know, pump manufacturers deserve much closer attention. When a closed-loop system receives incoherent sensor data and administers insulin anyway, the question is no longer just whether the system failed. It is whether that failure was tolerated as a matter of policy.

The technology exists. The methodology works. It’s time to deploy it.