Pages

Monday, 18 May 2015

Big Data - Little D


My instinct right from the start of Janki's T1D was to hoover up as much knowledge and data as possible. I'm still in First Grade when it comes to understanding T1D: it's huge and complex, far more than I ever imagined prior to diagnosis. And there's the small matter of keeping the Day Jobs going (being a Dad and a Medical Physicist) on top of trying to squeeze all this new information into my head... :-)

When it came to the data, whilst on the pens, Sonal starting keeping a very detailed diary of carbohydrate intake and we quickly migrated to the excellent mySugr app to record as much electronically as possible. The theory was that if it's in a database, it's searchable and can be mined for patterns.

The mySugr Logbook and Junior apps were a fantastic addition to our T1D kit - Janki really enjoyed using the Junior app and would type in her Novorapid and Levemir injections and record how she was feeling. I highly recommend both apps and paying the one off fee for mySugr Pro was well worth it (another "Go Pro" recommendation!)

Moving over on to the 640g System, including the Enlite CGM, unleashed a whole new level of data.
Each week, you have over 2,000 CGM datapoints to look at, plus 10s of bolus events for carb intake and corrections.

We signed up for a Medtronic CareLink Personal account and started scrolling through PDF report after PDF report. But I wasn't convinced we were presenting the data as clearly (or completely) as it could be... I was missing that reassuring "got it" feeling from the overview display. I'm not a diabetes professional, merely the parent of a little girl with T1D, but I do have a background in clinical image analysis and reporting and we spend a lot of time distilling 100s and sometimes 1,000s images down into a processing and reporting package that will enable a radiologist to report complex data in a handful of minutes.

I wanted to see what else might be in the data. I'm certainly not the first, nor will I be the last curious T1D parent to do this...

So the starting point was the CSV (Comma Separated Values) file via the CareLink Report page.
You get an Aladdin's Cave of data, which can be opened and viewed in MS Excel (or any other spreadsheet programme). Here are the key data ranges covered in the data:-

Blood Glucose - each BG reading from your linked meter.

Temp Basal Changes - amount and duration recorded

Bolus events - type, volume (units) and duration recorded, Bolus Wizard details, including target BG, sensitivity, carbs, correction and active insulin at time of bolus

Alarms - Suspend events, Highs, Lows, Sensor Calibration, Battery status, Reservoir changes

Enlite Sensor data - calculated SG (Sensor Glucose), Calibration events, ISIG (nA)

Most of this data (minus the SmartGuard suspend events) has been available to Veo users for sometime. However, the 640g's data file includes significant additional data, in the Raw Data column. This contains the info I used to extract the sensor error conditions for example.

Armed with this data I put together a straightforward Excel spreadsheet to look at data that, well, I thought was of interest. Is MS Excel the best choice to develop these tools? No. I'd usually prototype in IDL (Interactive Data Language) but with the CSV data sat there in Excel it was too tempting to plough on!

Here's a brief overview of the 'wins' that I think looking at this data has given us as a T1D family:-

Daily Overview
Similar to the Medtronic CareLink output but with each bolus event marked and markers showing when SmartGuard was active. For me this was an absolutely essential combination in order to attempt to influence Janki's control. A difficult "Sick Day" week below (colours are easier to see on the actual Excel output - sorry about that):-




The other crucial change I made was adding the ability to selectively analyse any combination of days within a set time period (e.g. every pre-school day, or every weekend). That data selection cascades through all of the analysis, unlike the Medtronic CareLink Pro selection, which I think just selects out those chosen days at the end of the report.


SmartGuard 
SmartGuard has been overwhelmingly positive for us in our experience.

However, lots of SmartGuard action indicates something's not right with either the basal or bolus regime (or both) at that time of the day and putting all of that on one graph was helpful for us. More detail posted here. Below is the chart showing our early SmartGuard distribution (for March) and a reduction by the middle of April (week of 9th - 15th April). More work was still to be done :-) Being able to extract clear data on the number and duration of SmartGuard events (and infer from them the likely frequency of hypo events avoided) over time has also been valuable when talking with Janki's excellent clinical team.




Insulin Sensitivity and Lifetime
Various formulae are out there suggesting Insulin Sensitivity factors (mmol reduction per Unit of insulin administered) and, we had good guidance from our DSN to guide this one. But there's nothing like actually looking at real data - what happened after each correction bolus? 

Now, of course, you could do this manually and if you only have to administer a handful of correction boluses you might choose that route. We haven't been in that boat - first due to dialing in the correct basal and bolus schedules and also due to sickness. So automatically extracting suitable bolus events is relatively straightforward. I selected out correction bolus events that occurred between 23:00 and 04:00, that were at least 4 hours from the last recorded carbohydrate intake (to avoid active insulin and also delayed carbs). The minimum bolus was also set (to 0.25 units below) to limit the impact of the extremely noisy data that would generate.

There's quite a variation (some of it due to basal changes, some due to very late, complex carbs), but it was reassuring to see the average come in very close to our DSN's initial estimate (10 mmol/L  per Unit).



The same data can be used to estimate your IOB (or Active Insulin) lifetime. The Medtronic 640g uses a curvilinear fit to estimate the decrease in active (available) insulin after each bolus and the lifetime is a single figure used to control the shape of that graph. It will directly impact on the IOB figure in the bottom right-hand side of the pump display and (even more importantly) in the Bolus Wizard. John Walsh has written extensively on this subject and on the impact of the different bolus wizard calculators out there - I highly recommend his material for bedtime reading if you're on a 640g (or any pump). His team's Pumping Insulin book or either of these links (here and here) are a good starting point.


Enlite Performance
I posted before about our generally good experience with the Enlites (see e.g. here). Not only does the CSV data highlight any general performance issues, but it's been useful to look at the SG/ISIG trend (ISIG being the raw output) and MARD (on a daily basis) to take a view as to whether a 'problematic' sensor is likely to come good or just needs to come out.

I won't attempt to add to the mountain of opinion and theory on-line about the Enlites issues for some users in this post, but if I could email Janki's sad, sad face to the Enlite development team when we tell her a sensor's got to come out early I would... please don't post any Medtronic email addresses in the comments ;-) 

Conversely a well behaved, stable sensor can be pushed beyond its official six day life - I'd have to email Janki's smiling face on those days too, for balance...

On that happy note, that's a wrap for this one. Hopefully its helped show some of the additional data you can easily extract and discuss with your clinical team.




No comments:

Post a Comment