“Continuous” glucose monitors (CGMs) aren’t actually continual. Most take a reading every 5 minutes. But it’s easy to forget that.
In any moment we see a number on our CGM display, and it feels like that’s our current BG. But it was calculated by the CGM up to 5 minutes ago, and will usually be updated 5 minutes later. We get used to seeing our data displayed as smooth curves, but in reality what we’re seeing is stepped.
A good CGM display will show you all of:
- the number
- a trend arrow
- an indicator of how old the number is.
Effects on CGM calibration
Quite apart from the issues of the ISF glucose being measured by the CGM “lagging behind” (being buffered from) the blood glucose (and thus needing calibrations to be done when your levels are changing as slowly as possible) the 5-minute delays have other effects.
Depending on the particular CGM system you’re using, it can take up to 15 minutes for a calibration to have an effect on the reported numbers. The calibration could be delayed by 4.9 minutes before it’s sent to a transmitter, which with a Dexcom will then at the earliest return a re-calibrated result after another 5 minutes. Sometimes the transmitters (especially Medtronic transmitters) have to think about it even longer.
On the whole it’s fast enough
People get used to the 5-minute cycle time fairly quickly. It’s just short enough that we’re usually prepared to wait and see the next result if we think it’s changing, and it’s just long enough that the power and battery consumption makes the engineer’s lives easier.
288 samples per day produces data and graphs that give us and our medical teams great insights into what our our bodies and diabetes have been doing.
Using my 5-minute Dexcom CGM (which also has the BG-to-ISF lag to deal with) my OpenAPS-based loop systems have been able to keep my BG levels within range even without me bolusing or even announcing meals. That’s even with the relatively long action time of Humalog insulin (starting in minutes but taking over an hour to reach peak activity and then tailing off over hours).
Some people have come to accept the 5-minute cycle time as an unchangeable characteristic of the technology. But it doesn’t have to be.
Can we get faster?
Some CGM sensors monitor more frequently than every 5 minutes. For example the Libre internally does a measurement every minute. However it does get summarised further up the software chain into 5-minute and 15-minute samples.
In 2017 I experimented with a CGM that used a Libre sensor at its core, sampling every 2 minutes. This did manage to track glucose changes more closely, but it did have a few drawbacks:
- The frequent scanning and calculations made a big dent in the battery life of the system.
- The closed-loop controller I was feeding the CGM data into wasn’t able to complete a whole set of calculations (“one loop”) within those 2 minutes, so wasn’t really able to take advantage of the extra data.
However the loop system (OpenAPS) I was using in 2017 has improved in efficiency since then.
- The software is more efficient (even though it’s got more features).
- Processing power has improved (which has the promise of reducing both battery consumption and “loop time”).
- The Bluetooth LE protocols used with newer pumps also have significantly lower latency than the simple radio protocol used to communicate with the Medtronic 554 pump I was using at the time.
- Faster insulins are coming. Fiasp is one example, although I’m not comfortable with the safety risks of using that particular insulin as a basal insulin. There will be other fast insulins eventually.
Should we get faster?
Most of the CGM systems we know of have stuck to 5-minute cycles. Luckily the Libre 2 still uses 1-minute samples (and apparently does BLE transmissions every minute) so we may be able to find out this year what we can do.
As I mentioned, my loop systems have been able to keep my BG at what some people would regard as “non-diabetic” levels even with Humalog insulin and a 5-minute CGM. But I know that reducing the latency of any part of the system holds a promise of improving the overall performance even further (reducing the frequency of “out of range” events).
This is backed up by my experience with designing and working with computer communication protocols where what seem like insignificant changes in latency for low-level building blocks can end up having huge impacts on the overall throughput of the system. The impact sometimes seems non-intuitive, but it’s real.
Especially when combined with the use of faster-acting insulins, I’m keen to see what we can achieve with future CGMs with lower latency!