Pages

Tuesday, 24 March 2015

New Generation Enlite - One Month On The 640g

I thought I'd quickly update our thoughts on the Enlite CGM, following my post on our first sensor.
I've compiled data from our first month's use.
I think it's overwhelmingly good news.

We're on our fifth sensor. We've not had any sensors fail within their six day recommended life-span. However, the last sensor did need a 'reboot' on day 4 by removing and then re-connecting the transmitter. As the failure happened overnight, we lost a night's worth of data and Janki lost some preschool time sorting it out in the morning...

Apart from the first sensor, we've not pushed any beyond six days yet...

Insertion
Not Janki's favourite, but she's tolerating the sensors. We get the occasional comment about the sensor once its in, but nothing to suggest it's causing anything other than a very occasional twinge of discomfort..

Whatever you do, don't show a little PWD the underside of a  'primed' CGM insertion device...


MARD
As SmartGuard is all about trusting your Sensor Glucose (SG) readings, particularly at the sharp, pointy, hypo- end of the range, a good MARD (Mean Absolute Relative Difference) value is critical. Overall MARD has been acceptable, at 14.3%.

However, the better news is that MARD in the hypoglycemic range (2.2- 4.0 mmol/l) has been very good. We've managed 11.0% (cf Medtronic's quoted range of 14.7%).

Sensor performance over the six days has been stable (both based on average MARD and SG/ISIG values) so I'm confident we can extend the sensor lifetime going forward. The first day performance is significantly worse than other days (average MARD on Day 1 is 19.6%), as expected, although varies widely between sensors. I think this is, at least in part, due to being forced to initially calibrate at times of poor BG stability.



I should mention that I've calculated "MARD" based on the SG reading that would be present on the screen when you're performing a BG test. i.e. I've not factored in the known BG-SG delay and so BG readings at periods of rapid change are not going to be well matched. These values are relative to the performance of the Bayer Contour Next Link 2.4 meter of course.

By definition, MARD gives an average performance figure - it doesn't mean that all SG readings are within 14% of the actual BG. We have had a few 'rogue' values, some of which we can spot (I'm thinking of rapid changes in SG without carbs or insulin on board), and some that catch you out. Digging through the data to try to identify what might cause these values is on my list of things to do. I can think of one - maybe two - 'bad' sensor days and your confidence in that sensor's SG values from then on takes a knock.

Connectivity and In the Cloud
Connectivity continues - for us - to be very good, with a low data error rate (0.3%), evidence of good data back-fill when expected (bathing, swimming) and just the odd, isolated data loss (a discarded data flag 0.3% of readings). The noise flag is also limited to 0.2%. I know others are not all as fortunate and I've now put together some spreadsheet tools to help unpick what might be going on and I'm waiting on Medtronc USA to confirm what each of the sensor data 'error' flags actually means.



Getting the 640g's SG data up in the cloud will be a huge bonus for us, particularly when Janki's at school. Whether Medtronic will produce an in-house solution is unclear, as far I know (see the end of this post for links on the Guardian Mobile application). I do know the Spanish developers behind the Medtronic (Veo) port of the Nightscout project now have a 640g and a compatible TI receiver, so let's see what they can unlock in the weeks ahead :-)

No comments:

Post a Comment