Mind The Gap(s) - The Enhanced Enlite Sensor

Lots has been written about data drops on the Enlite CGM, both before and after the 640g's arrival. But several seasoned pump users, such as Lewis, were sure that they had less issues and better tracking with the same Enhanced Enlite sensors on previous gen pumps (such as the Veo).

I wrote a little about sensor errors earlier this year in the blog - we (I, other users and some Medtronic reps) thought RF interference might have been to blame for what was being seen, since one of the changes from the Veo to the 640g was the switch in bands to the even more crowded 2.4GHz band.

But that didn't explain why some users were able to bathe their 640g system in WiFi, Bluetooth and all sorts of other 'nasty' RF producers and get nice, clean CGM most of the time and why others found their sensors conking out almost as soon as they'd gone in...And it didn't chime with the RF protocol used, with its built-in error checking.

So what is going on?

Here's part of the story (I hope I can find the time to get these posts out as I won't try to cover it all here :-) )...

Disclaimer - My inner-scientist has inflated this post, so if you don't want to read through the semi-technical stuff please don't, but please do take a look at the YouTube videos below and scroll down to the graphs near the end... And I certainly haven't answered all the questions in this post (or on this blog). There's also a reasonable chance I'm plain wrong about some of this - feel free to educate me via the comments or get in touch via Facebook.

The Sensor
I touched briefly on the Enhanced Enlite Sensor in some earlier posts, for example, here, but for this post I want to look again at
- Insertion
- Stability
- Raw Data (ISIG)

Insertion
I've heard and read lots of chatter online about 'correctly' inserting the sensor and how messing this up will adversely affect sensor lifetime (possibly to zero). Of more immediate concern to me has been causing Janki more trauma by muddling anything up...

I imagine most (all) users will have had the training on how to insert, focusing on using the inserter tool, pressing the button twice (press and release to insert; wait; then press again to release) and how to remove the needle assembly.

I thought I had it cracked - and the vast majority of Janki's sensors have been good - but then I came across this video from Medtronic ANZ. It goes into a level of detail that the UK / US videos just don't touch on. Well worth a look. It may well be that in the haze that is now our first few hours of 640g + CGM use we were told all of this 1-1, but it's handy to have this video as a reminder.

Taping
The Enhanced Enlite Sensor is smaller than it's predecessor and so potentially, more sensitive to insertion technique and securing. The first step in securing the sensor is taping the sensor down correctly. Again, we've probably all be shown this on day one, but here's Medtronic ANZ again to rescue any fuzzy brain cells:

We were initially guided to use another over-tape over the transmitter to further secure the whole assembly on our (then) three year old. However, we found that made removal and cleaning considerably harder and have been using a single tape and the transmitter adhesive flap without any issues. [This also makes extending a good sensor beyond six days infinitely easier].

Connecting

There are a few comments on the forums out there suggesting sensors get better by allowing them to 'bed' or 'wet' in , by leaving them inserted but not connected to the transmitter. We've not tried that and so I can't comment from experience. However, Medtronic appear to be clear that the transmitter should be connected as soon as possible after Enlite sensor insertion. (It may be that the 'delay' advice was valid for the earlier Sof sensors). Why? Because as soon as those Enlite electrodes (I believe there are three on the Enlite, with one acting as a reference electrode) are in the tissue the chemical reaction begins...

Like other current generation CGM systems, the Enlite works by measuring the current flowing between an oxidation reaction on one electrode (which is coated with GOx - Glucose-Oxidase and catalysts) and a reduction reaction on another. Hydrogen Peroxide is produced as part of this process and any build up of Hydrogen Peroxide will damage the sensor. According to Wang [Electrochemical glucose biosensors. Chem. Rev. 2008, 108, 814-825 if you want to see the detail] the Enlite is not as efficient as the Dexcom in controlling this level, which may help to explain the significantly longer lifespan of the Dexcom product.

Over to the transmitter...

The Guardian 2 Link Transmitter
The G2L transmitter has several jobs, but these can be split into dealing with the raw data (the ISIG current) from the Enlite sensor and then transmitting that successfully to the pump. The transmission bit I've covered in an earlier posts on connectivity, so let's focus on the ISIG value.

An "average" ISIG value is transmitted to the pump every five minutes.

Older Guardian transmitters used a simple algorithm to generate an 'average' value for transmission:

• Every 10 seconds, sample the ISIG current (in nA)
• Every 1 minute, discard the lowest and highest of those readings and average the 4 values left
• Every 5 minutes, discard the lowest and highest of those 1 minute readings and average the remaining 3 values

With that algorithm, the transmitter is filtering out some of the higher frequency changes in signal (i.e. probably not physiological) and clipping the data. Absolute (e.g. minimum nA accepted) or rate of change thresholds for rejecting ISIG data during this five minute period may also be set in order to filter out data that is unlikely to be real. 

If any of these filtering or clipping parameters have changed over the different Guardian transmitter versions (or even different batches of the same transmitter type) we'd expect to see a change in ISIG, a subsequent change in the Sensor Glucose output (mmol/L) and a change in the number of rejected (missing) ISIG integrations (those gaps on the SG graph that all of us see from time to time).

Q: So is the G2L ISIG algorithm different from the Guardian Link on the Veo? 

A: Probably... Argh! Sorry -  I don't have a long enough dataset to "prove" things for sure...

Here's a snapshot of the data from Lewis - thanks for this Lewis :-) 

Take a bow - actually, where are the sensors, careful not to upset them ;-) 

I think the older Guardian Link (on the Veo) is giving smoother ISIG output than the G2L (on the 640g). I'd need a longer data grab or the intra-sensor variability to say for sure (i.e. if Lewis had worn two G2Ls, what would the trace have looked like - would they have tracked identically..? Boyne and colleagues certainly found quite considerable sensor-sensor variability in their paper) 

So here's one of Janki's pesky sensors - CareLink output mirrors what we saw on the pump: lots of data gaps (and lots of alarms):

But if you drill into CSV output at around the same time and extract the ISIG data (it's recorded under the Raw Data column even if the ISIG column is blank for a time point, which it will be when no Sensor Glucose value is returned), you can see the sensor is still generating signal (ISIG - the purple line below). This graph covers ~1930 on the 24th to ~0930 on the 25th so you can see the transient ISIG drops.

The bright red spots (on the "100 mg/dl" line) are the sensor "errors" and will result in a gap on your display at these time points (as shown on the CareLink output above).

The blue line represents the glucose value that would be returned if  the system ignored the "errors" - clearly triggering suspend before / on low alerts in many cases. i.e. the pump is doing the right thing in ignoring the ISIG data returned at these time points by the G2L. The 640g is working in that regard.

We'll get to the other lines on the chart in another post :-)

The sensor errors are triggered by an ISIG rate of change and not an absolute ISIG rejection level.

So what's the story...?

Well how about something along the lines of 

Rapidly changing ISIG is rejected by the G2L and leads to data drops. 

It's almost certainly caused by the relative fragility of the Enhanced Enlite sensor and is amplified by changes in the filtering / clipping of the ISIG data in the G2L transmitter? 

Don't agree :-) - please leave me a comment below or on Facebook.

I appreciate that doesn't help restore those gaps or fix poor tracking (another post on that soon I hope when I get time, as part of that puzzle builds on this...) but I certainly feel slightly better having worked through so many of the possibilities over the last few weeks.

I'm certainly going to focus even more on insertion technique to try to reduce sensor issues even further. We'll carry on with the inserter and a single tape, but Lewis' blog is worth a read, especially if you have a little PWD.

Everyone's mileage will vary, and sensors definitely vary (I'm sure it takes precision manufacturing to make these, but I'd love to know if it's a Quality Control issue or a straight design limitation?)

And tonight at least, whilst I've be writing this, Janki's Enlite has been tracking well (on Day 7) and SmartGuard's Predictive Suspend has softened a hypo and allowed us to treat very gently (our basal rates are on the move again). The 640g, the Enlite, SmartGuard is not perfect, but when it works, its so nice to have.