Sensor compression and the 640g

"Sensor compression" is a well-known issue with current Continuous Glucose Monitoring (CGM) tech. In a nutshell, the theory is that local blood flow is restricted in the immediate vicinity of the CGM sensor. That restricts the availability of glucose in the interstitial fluid compartment that the sensor's sitting in and you can then get a rapid drop in reported Sensor Glucose (SG).

You can read much more about the theory in Brentt Mench's paper here and numerous other publications available online.

So how does the 640g deal with this?
In our experience, the vast majority of the time it will continue to report a SG value. From what I've seen and read, almost all systems seem to suffer with this phenomenon, so this isn't a criticism of the 640g.

It may raise (silently) a data error. For example, on some occasions it maybe that as our little PWD rolls on to or off the sensor, the ISIG data acquired during the five minute averaging period varying just too much for it to confidently report a SG value. In these cases, you'll see a gap in the SG trace. The ISIG value is still reported and is still available on the ISIG history screen, but the value will be in brackets () and the SG value will be null ('---').

The SG value usually changes more slowly than the ISIG value (due to the filtering of the SG data between data points - see this post here if you're interested how it might be doing that). In this case, this can be helpful, as it means a transient roll on to a sensor, which could lead to a massive drop in ISIG (see the example screen shot below for example) may not trigger an alert or alarm. The SG will be held closer to recent values by the filtering and if the compression is relieved (she rolls off the sensor, with or without a parent assist...) ISIG will return back to the previous ISIG to glucose ratio and the SG trace will return to normal.

If our daughter continues to compress this sensor, the SG value will eventually catch up with the ISIG drop and - for us - that often triggers an alert or alarm. When you BG and see a significant difference, the temptation is to calibrate. However, we certainly would want to wait to ensure a valid (uncompressed) ISIG value was going to be used and that a calibration was really necessary. So I tend to roll my daughter off the sensor and watch for an ISIG value to recover (using the ISIG History screen). At that point (~10 minutes later) if I think a calibration is required and my daughter is sound asleep I'll do another BG. In many cases, it's not required. More calibration details here.

One final thing I've noticed is that the trend arrows on the 640g appear to be driven by the ISIG data, including those values that are not used to generate a SG value (those data gaps in the SG trace). An example is below from the other night:

So you can see a correction bolus at around 01:30. SG trundles down as expected.

Two hours later, SmartGuard triggers. Not ideal, but not a big problem. We're coasting down towards a roll out at around 5 mmol/L.

And then, at around 03:50, Janki rolls onto the sensor. In this instance, the very low (~6 nA) ISIG isn't believed by the pump (good) and we then get a data gap on the SG trace.

I then roll Janki off her sensor in time for the 04:07 reading (ISIG back up to ~20 nA).

At 04:12 normal service is resumed.
Except I have three arrows up on the screen - you could argue technically 'incorrect'.
(Remember those arrows track 'SG' over the past 20 minutes according to the User Guide).

By the way, SmartGuard is (correctly) still in suspend.

So, in my opinion, with the exception of the trend arrows, the 640g appears to be behaving sensibly.
I just wish four year old's didn't roll around at night so much :-)


Compression has been raised by a couple of people, both 1-1 and in the 640g support forums in recent days and we've also had a couple of particularly compression-sensitive sensors recently so I thought it was worth a quick post - it is a quick post, so please forgive the rough edges! Usual rules apply - this could well be plain wrong. Please feel free to get in touch via Facebook. Thanks.