Missing Data - A Tale of Two Systems: The Whole Picture

My recent post on the apparent differences between Janki's and Lewis' 640g connectivity threw up more questions than answers I think. If a student of mine had presented the piece, I would have paused, told them it's very interesting, definitely worth pursuing; but it needs more data. There's too much noise in the, um, noisy data to draw any firm conclusions. And, as they're leaving the office, wondering when they're going to get the time to get all the extra data together, I'd tell them, never, ever conclude a presentation with a quote from Bill and Ted's Excellent Adventure...

So with that sound advice in mind, I've crunched some more data. This time we have all of Lewis' data (thanks again to his Dad, Andy, for sharing) and all two weeks worth of data for Janki. As a bonus, I now also have data from the Tangerine Diabetic (aka Dave), who's recently embarked on a 64 day evaluation of the 640g. Thanks for sharing Dave! 

I've not filtered the data, so you're seeing worst case, as included are Enlite changes, swimming, baths, all things that we shouldn't expect the 640g to deal with without some data delay or loss.

In order to visualise the 50k+ lines of data that feed in here, I've created a composite histogram of Sensor Glucose Error, Noisy Data and Delayed delivery across each half hour of the days reviewed. So what you see is the sum total of all events, in 30 minute slots over all of the days evaluated. The stacked bars are a little misleading, because sometimes multiple flags relate to the same event, but hopefully you can gauge the level and distribution of potentially disruptive events from these.

I've used the same raw data flags as before.

I think I should take the opportunity to mention that transmission puzzles are a feature of both the Dexcom and Medtronic solutions for some T1Ds (see, for example, here).

First up, here's Lewis' data:

As with yesterday's snapshot, sensor errors dominate (0.75% of all SG readings), with an almost equal number of noise and delay flags raised (0.35% of all SG readings). Speculating / guessing, we may be either seeing a pump / transmitter fault / pressure issue (movement of the sensor-transmitter connection or the sensor itself causing data errors) or - judging by the lack of delayed re-transmission at some points of the day, perhaps there is a local source of RF interference that wipes out all five 802.15.11 channels? We've also split the data down day-by-day and also weekdays / weekends to help Lewis' folks get a handle on this one.

And here's Janki's:-

We're seeing fewer sensor errors, less noise warnings and more (successful) delayed data recovery. As mentioned in the earlier post, delayed data tops out at around 1% of the total SG readings in this unfiltered dataset. I'm pleased with that. Most of the data delay is associated with swimming (1530-1600 blocks), baths (1600 - 1730), and bedtime (1900 - 2030; if you're from a T1D household, you don't need to ask why things can get late...). 

So the first blocks are simply signal attenuation in water combined with the extra distance to the pump (we take it off before both swimming and bathing). Signal strength drops by ~ a quarter if you double the distance from pump to transmitter. 

Bedtime is a little puzzling. My guess (it is only that) is that this is due to our efforts to update a day's worth of pump history to MySugr, which allows more layers of useful information to be captured. This is done manually, from pump to MySugr's mobile app and so the phone is well within Medtronic's 1m guideline...

I should mention that, at home, Janki's pump has to contend with 2.4GHz 802.11g WiFi, Bluetooth and a microwave oven. Our DECT kit is on the 1880-1900 MHz band and so shouldn't interfere with the pump.

Dave's (the Tangerine Diabetic) first week of data (unfiltered) is shown below and shows a similar pattern of data interruption and resubmission that we've found with Janki's pump, with ~1% delayed data events and just one noisy data flag across the whole week:

So are we any closer to a robust conclusion? Well, I'm pleased that I think I can identify the majority of our data incidents and that, most of the time, Janki's 640g is finding a clear channel and then back-filling missing data. A one-percent delayed re-transmission figure is also also reassuring considering this is unfiltered data, and it's good to see this rate on Dave's data too.

Lewis' data is still puzzling and I know his parents have been very active in trying to resolve it and understand what's going on. As fellow 640g users, I'm keen to see this resolved, not only for the sake of Lewis and his folks, but - if specific kit is identified as causing transmission problems I think we'd all like to be aware.