Sensor Glucose on the 640g Part 1: ISIG Data

I've been intrigued by a simple question for some time now: how come some people have had pretty good CGM performance with their Enhanced Enlites on their old Veo pump, but awful values (on the whole) when the same sensor is connected to the 640g? Others (and it would appear to be the majority - including us - have been doing just fine).

Simple problem, complex answer unfortunately.

First, the change is not just the pump, it's the Guardian Link transmitter, moving to the Guardian 2 Link (G2L) transmitter. In the UK at least, I believe both Veo and 640g users have the same Enhanced Enlite sensor.

Before we dive in, I want to stress again that this is a mixture of evidence, pondering and guess work - i.e. it might all be wrong. If it is, I'm fine with that, so long as someone else can tell me what really is going on :-) I don't have any "inside" information from Medtronic to share (I did ask for feedback on the sensor errors via the US, but no one ever got back to me, which isn't completely surprising but is still slightly disappointing. After all, with all the patents and journal papers flying around in the CGM arena, I'd be amazed if anything particularly sensitive was going to be revealed. Please do let me know via Facebook or below if you have any thoughts.

Ok, let's break this one down...

Black Box Number 1: the Guardian 2 Link transmitter

As far as I can tell, one of the very important tasks of this gizmo is to collate and process each 5 minute ISIG value (ISIG being the raw data from the Enlite glucose sensor - see here for example of a nice graphical breakdown of a CGM sensor). Whilst it could just hoover up values over the preceding 5 minutes and take an average, the chances are you'd be picking up a fair bit of noise too, as the signal itself is tiny, in the nA range (i.e. about a billionth of the current flowing to your laptop or PC power supply whilst you're reading this).

So what do we know about this black box? Well, there are some patents out there that give some clues as to the likely inner-workings. The majority of this information is included in Patent US 6895263. In this document ISIG is calculated along the following lines:-

- ISIG is sampled every 10 seconds
- Every minute, particularly low and high values (10 second samples) are clipped (discarded)
[various strategies for doing this are given - fixed, e.g. the lowest and highest values; and mobile, e.g. percentage of given ISIG]
- Every five minutes, the remaining one minute datasets are "averaged", producing the five minute ISIG value that's sent to the pump and the process is repeated for the next five minute sample...

The "averaging" method may vary - repeat arithmetic mean calculations (on the 10 second and then 1 minute samples) will produce a smoothing of the data, reducing noise, but also potentially masking a real change in ISIG during the five minute time period.

Other strategies, which are widely employed across signal processing to control noise and preserve data, including Bayesian filtering, linear Kalman filtering with various adaptive filters, appear to be considered in the patent. All I have access to are the final, 5 minute ISIG readings, so I'd be guessing as to which of the above "averaging" methods are used in either of the Guardian Link transmitters. From the snap-shot of dual data I had from Lewis, when he was running two Enhanced Enlite sensors with both the Guardian and Guardian 2 Link transmitters, they are appear to be slightly different, but there's not enough data-points to say what, precisely, is going on with each.

It's worth mentioning that, according to the patents, various events inside the G2L can trigger SG errors on the pump. Of particular interest to me:
- One or more clipping events at calibration may lead to a Calibration Cancelled event
i.e. If, during the calculation of the third reported ISIG reported value after the BG value is taken (at 10-15 minutes post BG), one or more of the 1 minute ISIG values are deemed to have failed you'll get a rejected calibration. As the failure criteria are based on absolute limits in signal and rates of change between each dataset, possible reasons for this include
- ISIG really is varying too quickly for the G2L to get a reasonable average (one reason not to calibrate on multiple SG arrows, although the key reason there is the error on the time-lag between BG and SG. Of course, sometimes, you get 'forced' to calibrate at the worst of times, unless you want to go without CGM for a while)
- the sensor moved internally / tissue interface changed during the five minutes causing a rapid change in ISIG (don't calibrate whilst bungy jumping...)

One more error type is one route (there are others...) to the dreaded "Replace Sensor" error: there appears to be a preset limit on a reasonable sensor sensitivity level - if this limit is breached three times in the a row, the system doesn't trust the sensor anymore... (I hope to get a post up shortly on all of the sensor errors)

Next up, on the sensor glucose journey - the calibration calculation.