Category Archives: Data-betes

Insulin Concentration Redux

I figured out the right way to average the insulin concentration in my blood at different times of the day. The chart is below. The red curve is the average for weekend days, while the blue curve averages weekdays. (The scale on the Y axis doesn’t mean anything, and I should probably get rid of it.)


You can see that I don’t eat a regular breakfast on most weekends. Instead, I go for a long bike ride or head to the track for a run, and when I’m done it’s time for a snack or lunch. I guess that’s why my insulin concentration starts rising steadily after 10 AM. (Remember we’re looking at an average of many weekends.) The weekday curve is much smoother and more clearly defined, as shown below:


The chart above shows my average insulin concentration for each day of the week. (It pays to click through to the full-size image.) Once again, red is the weekend, and blue tracks weekdays. I’ve repeated the “weekdays vs. weekend” plot to make it easier to see the big picture and to highlight the curve that’s going to be repeated on each of the following days as the dashed line. Most individual weekdays are like their average, as are the weekend days. I am a creature of habit, I guess.

If you look closely, you can see that my IOB/active insulin is higher on Monday afternoons because I take it off from training and am not so worried about having extra insulin around. You can also see that the free Wednesday breakfast at the office leads to higher insulin concentrations all the way through to lunchtime. I also want to believe that I can see a higher lunch peak on Tuesdays, when Gourmet India makes its biweekly appearance in the cafe at work, and a delayed peak at lunch on Friday because of an extra bolus for weekly cookies. (It’s no wonder some people call us “The FatWorks.”)

Surely there are more stories to be told from the data, but those are for me to figure out another day. For now, it’s time to move on to looking at carbs. Until next time. . . .

Posted in Data-betes, Diabetes, Fodder for Techno-weenies | Leave a comment

The Quantified Self

I’m getting ready to dive deep into this site and the places it links to: QuantifiedSelf.com.

Posted in Data-betes, Diabetes, Fodder for Techno-weenies | 1 Comment

Insulin Concentration

The following plot shows three day’s worth of insulin boluses. (What’s a bolus? It’s the insulin dose given at mealtime or as a correction to bring down blood sugar. It differs from the continuously delivered background insulin by being a much larger dose and being manually delivered.)


The spikes are the “normal” boluses, and there are about a dozen per day. (The one rectangular box on the 9th is a “square bolus” delivered over an extended period.) It’s kind of amazing how quickly insulin gets from where it’s delivered subcutaneously to the blood stream, but it isn’t instantaneous. And several hours pass between when the insulin enters the blood stream and when it is fully cleared through metabolism or by the liver. (Yay, liver!)

In signal processing terms, the normal boluses are essentially impulse signals that yield a response. (You can see the response curve in a previous post.) Here are the impulse responses for the normal boluses.


But this isn’t exactly how insulin works. All of those curves build on top of each other. Figuring out how to add all of those contributions into one “signal” is my project for the evening. When I asked a coworker about a good way to do this today, he suggested convolution, and then we prototyped a couple things. Now I’m working on doing that. It’s supposed to look a bit like this . . .


. . . but it isn’t quite right, since it seems shifted earlier in time relative to the boluses:


I will provide an update when we figure it out.

Updated a few minutes later: Of course! Because the convolution operation acts symmetrically about the impulse, the kernel needs to be pre-padded with an equal number of zeros. That shifts the result appropriately.


And some code. . . .

timelineAll = load('database_all.mat');
timelineSubset = findByDate(timelineAll, '2013-06-09', '2013-06-12');
timeStamps = [timelineSubset.bolusEvents{:,1}];
bolusAmts = [timelineSubset.bolusEvents{:,3}];

% Create a linearly spaced timeline.
resolution = 10;
spacing = resolution/60/24;

inputTime = floor(min(timeStamps)):spacing:ceil(max(timeStamps));
inputSignal = zeros(size(inputTime));

% Put the normal boluses into the signal.
for p = 1:numel(bolusAmts)
    % Find closest inputTime location to this time.
    absoluteTime = timeStamps(p);
    fractionalPart = absoluteTime - floor(absoluteTime);
    fractionalPart = round(fractionalPart * 24 * 6) / 6 / 24;
    roundedTime = floor(absoluteTime) + fractionalPart;

    % Assign the bolus.
    inputSignal(inputTime == roundedTime) = bolusAmts(p);
end

% Resample the insulin action curve.
scaleFactors = [0.0, 0.73, 1.0, 0.93, 0.67, 0.47, 0.27, 0.22, 0.18, 0.13, 0.07];
curveTimes = 0:0.5:5;
resampledCurveTimes = 0:(resolution/60):5;
resampledScaleFactors = interp1(curveTimes, scaleFactors, resampledCurveTimes, 'cubic');
resampledScaleFactors = [zeros(size(resampledScaleFactors)) resampledScaleFactors];

%concentration = conv(inputSignal, resampledScaleFactors, 'same') * 0.37;
concentration = conv(inputSignal, resampledScaleFactors, 'same');

figure;
stem(inputTime(inputSignal~=0), inputSignal(inputSignal~=0)); datetick
hold on
plot(inputTime, concentration, 'r'); datetick;
title('Cumulative insulin concentration')
Posted in Data-betes, Diabetes, Fodder for Techno-weenies, MATLAB | 3 Comments

Motor Error


In March I got a new pump, since my older Minimed Paradigm 522 was very out of warranty. The differences between the 522 and the 523 are slight and barely noteworthy, but I would miss them if they went away.

Unfortunately, this new pump also came with some problems. “What kind?” you ask. “Motor errors,” I reply. Take a look at my pump’s own diagnostics—as parsed by the little app I’m writing—if you don’t believe me:

>> displayAllEvents(timelineAll, 'major alarms')
15-Apr-2013 17:29:31 - Alarm - No Delivery (4)
15-Apr-2013 17:30:17 - Alarm - No Delivery (4)
19-Apr-2013 09:19:53 - Alarm - Motor Error (43)
19-Apr-2013 11:48:37 - Alarm - No Delivery (4)
19-Apr-2013 11:49:23 - Alarm - No Delivery (4)
19-Apr-2013 11:50:27 - Alarm - No Delivery (4)
25-Apr-2013 18:20:45 - Alarm - No Delivery (4)
25-Apr-2013 18:22:18 - Alarm - No Delivery (4)
25-Apr-2013 18:24:22 - Alarm - No Delivery (4)
06-May-2013 07:27:35 - Alarm - Device Alarm (55)
09-May-2013 17:21:01 - Alarm - No Delivery (4)
09-May-2013 17:22:39 - Alarm - No Delivery (4)
09-May-2013 17:25:15 - Alarm - No Delivery (4)
17-May-2013 06:59:19 - Alarm - No Delivery (4)
17-May-2013 07:00:00 - Alarm - No Delivery (4)
17-May-2013 07:01:52 - Alarm - No Delivery (4)
17-May-2013 07:03:45 - Alarm - No Delivery (4)
18-May-2013 08:49:24 - Alarm - Motor Error (43)
24-May-2013 07:15:58 - Alarm - No Delivery (4)
24-May-2013 07:17:54 - Alarm - No Delivery (4)
24-May-2013 08:29:27 - Alarm - No Delivery (4)
27-May-2013 17:40:46 - Alarm - No Delivery (4)
27-May-2013 17:41:29 - Alarm - No Delivery (4)
07-Jun-2013 12:11:21 - Alarm - Motor Error (43)
10-Jun-2013 08:23:11 - Alarm - Motor Error (43)

The “No Delivery” alarms were mostly my fault. (Running a reservoir to completely empty will lead to that . . . along with the possibility of high BGs, so I don’t recommend it. I’m trying to pay more attention to how long it’s been since the previous “Low Reservoir” notice.) Those four “Motor Error (43)” messages, however, are definitely a problem with the pump and always appeared in the middle of a bolus.

Minimed’s customer service is great, and they delivered a new pump to me next day. The “next day” happened to be a Saturday, and the UPS man arrived mid-morning shortly after I got back from the track, where I had run ridiculously fast 30-second repeats—like 4:20/mile fast—in my last speed workout during the taper before this weekend’s 70.3. (Sorry, I’m getting distracted.) Sadly, technology will fail, but I’m glad that the manufacturers realize that these devices keep us living and go to extraordinary lengths to make things right.

Tomorrow, after transferring all of my settings into 523 #2, I’m sending 523 #1 back to the mothership. Godspeed little pump. May your refurbished motor be error-free in the future.

Posted in Data-betes, Diabetes | 2 Comments

Pharmacokinetics

Now on this evening’s reading list: Bioavailability and bioeffectiveness of subcutaneous human insulin and two of its analogs—LysB28ProB29-human insulin and AspB10LysB28ProB29-human insulin—assessed in a conscious pig model. (“LysB28ProB29,” or insulin lispro, is better known as Humalog.) Along with the “Pharmacokinetics” section of the Humalog FDA drug insert, it’s helping me better understand insulin absorption, metabolism, and elimination. My goal is to have a better model of “active insulin” than just insulin on board (IOB) and to look at how insulinized I am at different parts of the day.

The main question I hope to answer is whether having twice as much serum (i.e., blood) insulin concentration means twice as much BG lowering effect. I suspect it does, but as we all know, “Assumption, my dear Mitz, is the mother of all fuck-ups.” [IMDB]

Yesterday evening I estimated some of the information from one of the charts in the Humalog insert, put it into MATLAB, used one of our more awkwardly named functions (cumtrapz), and generated this table:


Those tiny numbers (hopefully) tonight will become a set of overlaid curves that show how much insulin is in my blood throughout the day. Yay, math!

Posted in Data-betes, Diabetes, Fodder for Techno-weenies | 2 Comments

Box Plot

Based on Sara‘s comment on yesterday’s post, I decided to use MATLAB’s boxplot function to show the statistical complexity in the data.


So what is this? The boxes show the 25th and 75th percentiles of the data, and the red line is the median (which is the middle value—not the average—in the data). The “whiskers” extend to the extremes of the statistically significant data, and the red “+” symbols are the outliers (which figure into the median and average but are statistically outside the normal distribution). I’ve added a couple of extras to the regular box plot; the first is a red-and-green dashed line that shows the average of all readings, while the curve with the “x” markers shows the average of each bin.

What does this say to me? Most of the medians are below the daily average, which means that most of the time my BG is pretty good, but I have a lot of “outlier” highs that I should work on. Also, the time right around lunch is the low time of my day, while the late afternoon (from about 3:00-6:00PM) tends to be my highest. I seem to be most consistent—statistically speaking—in the evenings.


What next? While I was walking off a hypo during today’s long run, I started thinking about how to extract “interesting” things from the data I’ve aggregated. I need to figure out how to programmatically request to “show me all of the data five hours before a long run in the afternoon” or “show me what happened on days that I exercised after bolusing two to three hours before starting.” I can think of “good” ways that are quite complicated, but I need to consider whether there’s a way to do some natural-language processing so that I can actually write something “human” instead of forcing people/myself to chain lots of conditionals and requests together. (Of course, the complicated way might be the first step.)

Figuring that out is going to take a while. In the meantime, I need to get to work on adding the currently unrecorded data to the mix and figuring out how to display just a day-or-so of data.

More soon!

Posted in Data-betes, Diabetes, Fodder for Techno-weenies | 3 Comments

A “Typical” Day’s Blood Sugars

I always wondered what an “average” day’s blood glucose looked like. Now I know.

Posted in Data-betes, Diabetes, MATLAB | 2 Comments

Diabetes Flight Data Recorder

Lisa and I took a quick trip to Iowa over the weekend for our college class reunion. I took advantage of the time in airports and airplanes to work on the diabetes app. Because I’m using MATLAB—which I know very well and which makes programming complicated tasks very easy—I was able to get a lot done. In my mind, development of version 1 of this app has five phases:

  1. Import data from CareLink and .fit files into MATLAB. — DONE!
  2. Create a data structure (“the timeline”) that can hold all of this data and import the CareLink data into it, taking care to prevent repetition when importing data that’s already present. — DONE!
  3. Import exercise data from .fit files into the timeline.
  4. Make a MATLAB GUI to enter other events that aren’t currently captured by any device, and put these events into the timeline.
  5. Create some MATLAB tools to visualize the data and search for patterns in it.

That seems like a reasonable first version. It will have the tools necessary to aggregate data from various sources and do something useful with it. My main goal when starting this project was to create something that can help me improve my BG self-management by revealing trends and adding context. This should make that possible. Later I would like to make it more portable, but I’m not sure how easy (or even how) to integrate this MATLAB-based processing and I/O with a mobile device. I have some ideas that involve iCloud. A first step in the next version will likely involve an iOS app to gather the “self-reporting” data, but even that is a ways down the road.

In the meantime here’s what I can currently do. This isn’t how I imagine working with the data in the future, but it shows a bit of what it is possible to do with a very little bit of work.

>> fname = 'CareLink-Export-2013-03-30-to-2013-05-01.csv';
>> importCarelink(fname, 'database.mat')
>> timeline = load('database.mat')

timeline = 

        alarmEvents: {1221x3 cell}
        basalEvents: {480x3 cell}
           bgEvents: {821x3 cell}
        bolusEvents: {1282x6 cell}
        calibEvents: {1300x3 cell}
     sensorBGEvents: {35586x4 cell}
    setChangeEvents: {184x5 cell}
      suspendEvents: {41x3 cell}
    tempBasalEvents: {108x5 cell}
       wizardEvents: {1160x8 cell}
          uploadIDs: {9x2 cell}

>> wizardEvents = timeline.wizardEvents;
>> wizardEvents(end-20:end,:)

ans = 

    [7.3538e+05]    [     4]    [40]    [  0]    [     0]    [     4]    [     0]    '10777573309'
    [7.3538e+05]    [0.8000]    [ 8]    [  0]    [     0]    [0.8000]    [     0]    '10777573301'
    [7.3538e+05]    [7.5000]    [75]    [127]    [0.5000]    [7.5000]    [1.3000]    '10777573290'
    [7.3538e+05]    [     4]    [40]    [  0]    [     0]    [     4]    [     0]    '10777573282'
    [7.3538e+05]    [8.5000]    [75]    [120]    [0.4000]    [8.3000]    [0.2000]    '10777573267'
    [7.3538e+05]    [4.4000]    [40]    [ 99]    [     0]    [4.4000]    [4.1000]    '10777573259'
    [7.3538e+05]    [0.5000]    [ 0]    [138]    [0.5000]    [     0]    [     0]    '10777573241'
    [7.3538e+05]    [     6]    [60]    [103]    [     0]    [     6]    [0.4000]    '10777573237'
    [7.3538e+05]    [2.5000]    [25]    [228]    [1.9000]    [2.5000]    [     3]    '10777573230'
    [7.3538e+05]    [7.5000]    [75]    [238]    [2.7000]    [7.5000]    [2.7000]    '10777573221'
    [7.3538e+05]    [5.2000]    [ 0]    [361]    [5.2000]    [     0]    [     0]    '10777573205'
    [7.3538e+05]    [6.6000]    [60]    [361]    [5.2000]    [6.6000]    [5.5000]    '10777573200'
    [7.3538e+05]    [     0]    [ 0]    [182]    [1.6000]    [     0]    [7.2000]    '10777573186'
    [7.3538e+05]    [0.9000]    [ 0]    [313]    [3.8000]    [     0]    [2.9000]    '10777573177'
    [7.3538e+05]    [3.5000]    [ 0]    [390]    [5.4000]    [     0]    [1.9000]    '10777573168'
    [7.3538e+05]    [0.6000]    [ 0]    [257]    [2.4000]    [     0]    [1.8000]    '10777573156'
    [7.3538e+05]    [3.4000]    [ 0]    [330]    [3.5000]    [     0]    [0.1000]    '10777573143'
    [7.3538e+05]    [     6]    [60]    [256]    [2.4000]    [     6]    [3.5000]    '10777573133'
    [7.3538e+05]    [8.5000]    [85]    [126]    [0.5000]    [8.5000]    [0.5000]    '10777573122'
    [7.3538e+05]    [     6]    [50]    [153]    [     1]    [     5]    [     0]    '10777573115'
    [7.3538e+05]    [7.2000]    [65]    [151]    [     1]    [7.2000]    [2.4000]    '10777573108'

I can’t remember what those wizard event columns mean, but it’s basically all of the data from the bolus wizard. (Updated: The columns are time in MATLAB datenum values, bolused insulin units, grams of carb, BG in mg/dL, correction calculation, food calculation, active insulin, and CareLink unique upload ID.) Let me distract you with a picture of CGM sensor data, smoothed over two hours.

>> sensorBGEvents = timeline.sensorBGEvents;
>> dates2013 = [sensorBGEvents{:,1}] > datenum(2013,1,1);
>> sensorBGEvents(~dates2013,:) = [];
>> figure; plot([sensorBGEvents{:,1}], medfilt2([sensorBGEvents{:,2}], [1 100])); datetick

Posted in Data-betes, Diabetes, Fodder for Techno-weenies, MATLAB | 4 Comments

Siri, Tell Me about the Ultimate Diabetes Device


Diabetes Blog Week is technically over, but I still want to write about one of the topics: my dream diabetes device.

I — In the past I’ve written about wanting an application that integrates all my current diabetes paraphernalia, my Carelink account, and my mobile phone iPod. The goal was to have total diabetes awareness by tagging “interesting” events so that I can go back to the historical record the next time that thing occurs. “When I was sick how much extra insulin did I need to give?” “When I ate Indian food, what was an appropriate amount of insulin and how did I deliver it?” “What basal rates and carb amounts worked well for a triathlon?” Ask one of these questions, and see the BG values, bolus wizard details, and CGM traces for all of the events tagged with those keywords. It wouldn’t be a perfect solution to preventing all lows and highs, but it would surely be better than my own faulty memory.

I actually started writing the application and got all of the data into a MacOS application, but I got frustrated that I wasn’t going to be able to easily get the data from my computer onto my mobile device. So, as usual, I set it aside and got distracted by something else. That was a couple years ago. Since then iCloud came along and makes sharing this kind of data between devices much easier. Maybe someday—after I win the PowerBall lottery, perhaps—when I have limitless time and ambition, I will pick it back up. Or (better yet) I’ll become a venture capitalist whose first project is to fund the development of such an app. That way I can travel the world while other people do most of the coding for me. I’ll show up for design reviews to give insightful commentary and gather information for my TED talks.

II — Recently I’ve started working on another diabetes data project. Now that I have a newer Mac, I can run MATLAB again. Yay! It occurred to me, after reading a coworker’s at-work blog about telling stories with MATLAB, that it should be possible to integrate a lot of the disparate sources of data into one application (MATLAB) and try to reconstruct a day with diabetes and try to figure out a partial model for some of the stuff that currently requires a lot of trial and error. It’s not a perfect solution, but it’s a start.

The thing that makes this all possible is the fact that so many of the devices I use every day record and export data. My cycling GPS and Garmin running watch tell when I exercise, for how long, and at what intensity. My CGM records my blood sugar patterns, while my BG meters record the ground truth. My insulin pump tracks my basal insulin usage and all of my bolus wizard details, along with a host of other details. There’s a lot of data there that I can potentially synthesize and display in one view. And, because it’s MATLAB, I can define every last little thing about how I want the information displayed, what details I want to filter out, and what I want to try to highlight or search for.

III — But even with all of this data there are missing parts of the picture. Diabetes is a difficult disease to manage, in large part, because it’s integrated with almost every other part of life. Unfortunately, daily life is messy. There’s a lot of it that just isn’t easily tracked by devices—well, not yet. I’ve toyed with the idea of getting a FitBit device to keep track of some additional things, such as overall activity and sleep, but that still leaves a lot of things untracked, especially food: food that I don’t bolus for, such as glucose tablets, food during exercise, “just in case” snacks, the things that seem too small to worry about, etc. And then there’s swimming, stress, pain, illness, hydration, weight, and so on. I wish there were a way to keep track of all of that. (At least for a few days or a couple weeks while trying to figure out appropriate baselines or when changing my training load. Paying attention to all of that data every day could be a bit overwhelming.)

So I asked one of my bildr/maker-type friends if there were good hardware or software solutions for keeping track of any of this stuff, especially the food-related bits. There are hundred (if not thousands) of nutrition apps, but all of them I’ve seen are much more heavyweight than I want. Don’t make me select something that says which food I ate in order to give me all of the nutrition info or calorie count when all I really want to record is “At 11:25AM (give or take) I ate 15 grams of carbs that I didn’t bolus for.” The best that we could come up with at the time is a small notepad and pen to record stuff before transferring it manually into whatever computerized, MATLAB-based system that holds all of the other diabetes events.

Thinking about it on a bike ride a couple days later, it seems like it should be possible to have a little nanny app that pops up a few times a day asking questions. How is everything going? What time did you wake up this morning? How much sleep did you get? Feeling stressed? Eaten anything you didn’t bolus for in the last day that we haven’t already talked about? Do any swimming or yard work? How active have you been this afternoon? Any pain? Illness? Have you been drinking water?

Just a few judgment-free yes/no questions and easy-to-answer questions involving time and quantity, and voilà! instant context. I could probably make an iOS app to do that in a weekend (if I didn’t mind it looking crappy). But really that’s all of the data that my devices don’t give me now that I want to capture. Oh, and it should have a one-touch switch that turns it off so that I’m not bothered during the 95% of the year that I don’t want to keep track of all that stuff.

IV — As an aside, wouldn’t it be awesome if someday there were a Siri-like interface for diabetes?

“Hey, Siri. Remind what I did those times that I had barbecue at the office and everything went pretty well?”

“You estimated you ate 100 grams of carbs. You delivered ten units of insulin in a dual-wave pattern with two-thirds up-front and the remaining third over an hour. Here’s what your CGM trace looked like for the next six hours.”

“Thanks, Siri. I love you.”

“Hey, let’s keep things professional. I’m not that kind of robot.”

“Sorry, girl.”

“It’s cool.”

V — But all of this “Total Diabetes Awareness” and data fusion and mindfulness/memory apps got me thinking that the ideal diabetes device system is one that wraps all of this up. It automatically keeps track of activity and food and active insulin and BG/CGM values and all of the other emotional intangibles.

But then I thought, keeping track of all that data in order to make better insulin dosing decisions is 20th century thinking. What I really want is a system that automatically regulates BG levels using two hormones, one that lowers blood glucose (via insulin) and one that raises it (via glucagon). Then the system can reach homeostasis all on its own.

Of course, an artificial pancreas that integrates everything together in a closed loop system needs believable inputs. BG meters and (especially) CGM sensors need to be much more accurate so that the system is given the right data to make the right decisions. It’s a bad thing when my CGM says I’m 40 mg/dL (2.2 mmol/L) when I’m really 140 (7.8) or, worse, vice versa. So obviously, an artificial pancreas that’s actually implanted and uses a semi-permeable membrane that lets more insulin seep out when it’s needed is the way to go.

And that’s when I realized the basic truth of diabetes technology: The ultimate diabetes device is a new pancreas.

Posted in Data-betes, Diabetes, Diabetes Blog Week, Fodder for Techno-weenies, Life Lessons | 1 Comment

Diabetes Math

After getting basal rates that I believe, I’m up to the part of my on-going “Let’s finally figure out the right pump settings!” project where I check my bolus amounts. I have long suspected that I am over-insulinized in the morning, since I frequently need a snack between 10AM and noon to prevent a hypo. Now that I know my basal rates are correct—I can plank pretty well if I don’t eat—the fiery finger of blame points at my bolus ratios.

Last week, after my awesome endocrinologist “ooh-ed and ahh-ed” over my much improved A1c, I asked her my burning question about active insulin (a.k.a., insulin on board or IOB). “When I’m bolus stacking, when do I consider active insulin and when don’t I?” I frequently eat multiple times during any given five hour period, which means that I have multiple doses of insulin working on their respective meals. I’ve noticed that sometimes I have to take that insulin into account, since its “long tail” will continue to lower my blood glucose for a bit longer. Other times, if I subtract out that IOB, I see high blood sugars later because that insulin was still needed for the previous meal/snack. What to do?

Her advice to me (and this supposes that my pump’s “active insulin” setting is correct) was to subtract out the active insulin if the bolus was three or more hours ago, since digestion should have finished by that point. This is when I’m already near my BG target and have IOB.

(Since I’m often back into the lower part of the “happy” range 2-3 hours after a bolus and/or I didn’t see much of a rise at all, this is probably another indicator that I’ve been taking in too much insulin. That and the fact that bolusing frequently comprised more than 70% of my total daily dose, which is higher than the 40-60% that most recommend. As a result I was eating a lot of “defensive” carbs to prevent lows, which seems to be leading to highs later in the day.)

I had been trying less aggressive bolus ratios over the weekend with some success, but acting on hunches and suspicions is bad form, so today I decided to be a bit more rigorous. Armed with my endo’s advice, a measuring cup, notebook, and pen, I set out to figure out what my bolus ratios need to be. Here is the data through lunch:

05:03 - 164 -       - Wake up... yawn.
05:45 -     -       - Swim 1000 yards in 20 minutes. Disconnected for 35 minutes.
06:21 - 121 - 2.9 u - Granola bar (24g) = 2.6u + 0.3u correction (using 1:9 ratio)
07:34 - 149 - 6.5 u - Cereal, milk, eggs, sausage (64g) = 7.1u (but I know this is too much)
10:18 - 104 -       - There was a bit of walking around in the previous hour
11:15 - 104 - 1.0 u - 1/2 donut from the box next to the printer (19g) = 2.3u - 1.3u IOB
12:00 - 120 - 8.3 u - Sandwich (35g), Yogurt (18g), Apple (~20g) = 75g = 8.3 (using a 1:9)

This morning looks pretty successful. Let’s try to reverse engineer a possibly correct bolus ratio. I ate 24+64=88 grams of carbohydrates for breakfast, and delivered 9.4 units of insulin. That yields, let’s see here, 1 unit for 9.4 grams, or about 1:9. But we know that’s too much from past experience (including this morning).

The 9.4 units of total insulin includes whatever insulin was needed to make up for the 35 minutes that I was disconnected from my pump while swimming and a correction of 0.3 units, which may or may not be the same. Let’s run the numbers again a few different ways.

Not taking correction into account: (24 + 64 g) / (2.9 + 6.5 units) = 9.4 g/unit

Just using the correction: (24 + 64 g) / (2.9 + 6.5 – 0.3 units) = 9.7 g/unit

Using the time off pump: (24 + 64 g) / (2.9 + 6.5 – 0.9*(35/60) units) = 9.9 g/unit — 0.9 units/hour is my basal rate at that time in the morning.

What’s the lesson here? What ratio should I use? 9.4? 9.7? 9.9? Since my pump only works in whole units for the ratio, it’s a choice between 1:9, 1:10, or carrying a calculator/MATLAB everywhere with me. (The pump version one generation after mine does allow fractional ratios.) The 1:9 ratio is clearly too aggressive given what’s been happening to me, so I’m going for 1:10, which has a certain easiness to it, too.

Let’s see what tomorrow brings.

Posted in Data-betes, Diabetes, Life Lessons | 4 Comments

Ready for Winter… Almost

Winter is coming. Labor Day has passed, and in typical New England fashion the days are suddenly shorter and cooler. It’s almost as if Mother Nature flipped a switch. Soon it will be too dark to ride or run outside after work, and I will be banished to the basement. I will still get out on the weekends, and I’ve ridden outside in Massachusetts in every month of the year, but I definitely prefer the beautiful weather better.

While it’s cooler here now, it’s still going to be hot next month in Death Valley. Tomorrow’s predicted high is 113ºF (45ºC). The JDRF ride is definitely going to be the last gasp of summer for me. I’ve been practicing drinking more and refining my insulin/nutrition plan for the ride. At this point of the season, I feel really confident, so I took a little ride last weekend to see how my body felt.

The best route I could think of to test myself was one that was similar to Death Valley—minus the whole desert thing—and a ride that I had been looking forward to for the last couple of weeks: Mount Wachusett. You might remember that it’s one of my favorite loops and the one I did just before going to the Midwest to ride the Tour de Cure with Scotty J, Heather, and Scully.

There are about 40 miles of rolling hills from my house to the foot of Mount Wachusett, and it was a chilly 45ºF (7ºC) when I left my house just before 7:00AM. I was happy that I decided to wear arm warmers and a wind breaker, although it warmed up quickly enough, and I already had my jacket off a couple hours in. It’s gently uphill from my house to the start of the climb, which is about 600 feet higher than where I started, but then it just gets right down to business. The first road on the climb is Mile Hill Road, which goes uphill for—you guessed it!—a mile before it crosses into Princeton from Westminster, where it becomes Mountain Road.

The climb is pretty steep there (between 9-11% for the most part), and I was starting to get rather warm. I still had my arm warmers on, but they were rolled all the way down to my wrists. (I think it’s kind of a stupid look, but it’s better than the other choices of stopping or overheating.) When I turned into the state park to start the actual climb, I took that extra layer off and stuffed them down the back of my jersey where they joined my jacket. (I pretty much carry everything that’s not for bike maintenance on my back.) The previous 1.7 miles was just a warmup for the next 2.4. Even though the first part has more than half of the vertical gain and is quite tough, there are places near the summit where the road gains almost one foot for every five it goes forward. That’s right, we’re talking about an 18-20% grade.

I will confess to like mountain climbing. Yes, it’s hard, but it’s all just a matter of perspective. If you can dissociate the thinking, whining part of your brain—the part that says, “Hey! This is really difficult!”—from the part that keeps the map and sees the big picture and knows that it’s just a half-hour of difficulty with really great rewards at the top, then it’s really not that bad. Of course, it helps if you see value in those rewards. You have to want to see the view from the top. It also helps to cultivate a sense of self-satisfaction in doing difficult things for their own sake or to hold the somewhat stoic, archaic belief that suffering is in some way redemptive or transcendent.

And if those rewards don’t work for you, there’s always the downhill. What goes up must come down. Oh yes it must!

I’m not young enough anymore to be completely fearless on a descent, but I really, really love going fast on a bike. I’m still building up trust with this bike, but I’ve learned over the last two months of riding my Cervélo R3 that it will pay back any trust you give it with an insane amount of responsive and agility in the corners. “Go on! Lean into the corner!! DO IT!!” it seems to be saying. And I’ve generally been listening and having more fun on a bike than at any other point in my life. I carved the most beautiful, amazing curve around a blind corner at slightly more than 40 miles per hour (65 km/h). Yes, I spent twenty-five minutes to climb the mountain and was done with the fun part in just five. It was over too soon!

For a long moment I thought about doing the climb again, but my ride wasn’t finished at the foot of the mountain. I still had around 35 miles to go before I was home. They were mostly downhill; I had a rare tailwind out of the north; and my muscles and body felt great. My BGs stayed very stable—between 90 and 110 mg/dL (5.0-6.1 mmol/L)—almost the whole ride, and I stayed very well hydrated.* Riding home wasn’t no thang. On a few occasions I found myself thinking, “Is that a hill? Let’s attack it!” It wasn’t the perfect ride, but if I’d had friends with fresh legs along with me, it probably would have been.

Yes, friends, winter is coming and I’ll be missing riding outside several times a week. If only I could bottle everything that was fantastic about Sunday’s ride, I would take little sips from it all winter long and have no problem waiting for springtime. I’m going to be surviving thriving off the memory of that ride for quite a while.


* — For the curious, here’s what happened with my nutrition and diabetes. I started the ride a little higher than I wanted (about 240 mg/dL) due to a miscalculation the night before, so I took a tiny bit of extra insulin with the small bolus for my pre-ride ClifBar and used a slightly less aggressive temporary basal rate of 70%. An hour into the ride, I tested—I’m getting good at doing that while riding—and saw a 94. Worried that I was going to overshoot and go low, I doubled up my first snack (40g of carbs) and then continued to eat 20g in gels or chews every half hour, which was my plan. At the top of the mountain, my BG check read 108, and I celebrated with a Pay Day candy bar. (It’s a poor substitute for a Peterson’s Salted Nut Roll, but it’s still yummy and the closest you can find round these parts. I don’t know what the Peterson folks put in the white center of their candy, but I suspect it’s some kind of opium product.)

At that point I also started drinking a bottle of Skratch Lab’s drink mix along with my every-thirty-minute snack, since I wanted to buoy my BGs every few minutes. The mix is the super secret stuff Derek Lim and friends whipped up for Lance Armstrong and Team RadioShack and then started selling on the down-low to a bunch of devotees before realizing they could probably make real money off the stuff. It, my friends, is the real deal. It has 20g of carbs for 20 oz./500 mL. It doesn’t really have a flavor, so it’s as refreshing as drinking water. And it works! Oh, yes. It absorbs well and gives the right amount of electrolytes. Check it out! My reading at the end of the ride: 97.

So let’s recap: one ClifBar, one pack of ClifShot Blocks, six energy gels, one Pay Day bar, and one bottle of Skratch Lab’s drink (all together = 250 carbs) plus one high BG reading, 1.0 units of bolused insulin, and 70% of my normal basal insulin yields five hours of cycling, four of which were in the “non-diabetic” range. I want that to be part of what’s in the bottle that I sip from over the long, cold, New England winter.

Posted in Cycling, Data-betes, Diabetes | 3 Comments

What I’ve Learned about my CGM

I’ve been using a Medtronic Minimed continuous glucose monitor (CGM) for a little more than a year and a half now, and here’s what I’ve learned about it.

  • Having CGM is the greatest thing. It’s a decision-support tool, a dashboard, and a security blanket. I’ve learned so much about my diabetes from it, and it’s provided the data I needed to make some important changes to my self-management. I wish everyone had it.
  • The BG values it reports are delayed by 15 minutes. This is a fact of life. The CGM looks at “interstitial glucose” between cells (ISIG) instead of blood glucose, and there’s a lag time between the two. Don’t expect the BG numbers from your meter and your CGM match unless your having very stable BGs.
  • The most important factor in getting believable CGM readings is calibration. Wait until your interstitial glucose (ISIG) is the most stable before calibrating.
  • If my BG is on the move but the system says I need to calibrate it, I’ll let it go past the “Meter BG Now” deadline and look at the “Sensor ISIG” values on the CGM information screen. When this value isn’t changing much, that’s when I’ll calibrate.
  • Lots of things affect ISIG values and therefore CGM accuracy: the rate of change of BGs, the level of hydration, and the wetness of the sensor (both too wet and not wet enough).
  • I find that if I keep my sensor and transmitter covered, I get a longer sensor life and better readings.
  • Tegaderm film works the best for me. Unlike IV-3000, it doesn’t come off when I’m swimming or sweating a lot from exercise; it doesn’t leave behind a lot of residue; and it’s stretchy enough to cling nicely and create a good barrier.
  • Hydration matters a whole lot to accuracy. If you’re dehydrated, the sensor will read incorrectly, or perhaps not at all.
  • Don’t calibrate first thing in the morning. There’s too much going on. Almost everyone is slightly dehydrated when they wake up, and I’ve noticed that the very act of waking up and getting moving causes my CGM sensor to give inaccurate readings for about a half hour.
  • Don’t calibrate right before or after exercise. For me, my blood sugar usually is on the move during the first bit of a workout and immediately after it. Plus, the chance of BG swings is greater while exercising, which is bad news for calibration.
  • I find that sometimes I can count on my CGM values when I exercise, and other times I can’t. The lag is a little less during exercise, but my hydration is also different so it’s less accurate. Sometimes it catches big BG swings, and sometimes it doesn’t.
  • Swimming: I find that I can swim for at least an hour without affecting the sensor or transmitter. But I also find when I swim three or more times in a week, the off-label lifespan of each sensor is noticeably shorter.
  • Sensor life: The longest-lasting sensor I’ve used that produced reliable BG estimates is 12 days, which is not too bad for something that’s only supposed to work for three. (Just tell the CGM that you’re starting a “new” sensor when it says “Sensor End,” even though it’s the same one and not new at all.) Because my transmitter battery requires a quick recharge after 6 days, I have to very carefully peel off the Tegaderm I put over the sensor and transmitter, give the transmitter a charge for 15-30 minutes, and then reattach it and apply more Tegaderm.
  • Occasionally, the sensor values will just drop out after the three days; they might come back to match my BG, and they might not.
  • When the CGM graph gets really noisy, the sensor is dying.
  • Sensor freshness matters. A sensor getting close to its expiration date won’t last as long and seems to give less accurate readings.
  • Treat the number after finding a “Lost Sensor” with some skepticism. I find I often need to recalibrate 30-60 minutes after reacquiring the sensor.
  • To avoid “CAL ERROR” messages, I don’t calibrate if the CGM and BG meter values are very different.
  • The Medtronic CGM does some curve fitting, so it often doesn’t “snap” the CGM values to the calibration value when they’re very different. I hate that. Entering another, new BG value usually gets them closer, though.
  • Post meal, a period of flat BG values followed by a rise 1.5-2 hours later almost always means that the meal bolus was too small. (There are a lot of other trends you can spot, but this one was the most consistent.)

Do you use CGM? What have you noticed?

Posted in Data-betes, Diabetes, Life Lessons | 9 Comments

Trials – Monday, 5:45AM

I. Monday morning swims are always the hardest. Technically, Monday is a rest day on my plan, but the pool is only open three days a week during the summer, so I find myself getting up at 5:00 on my rest day to get ready to go to the pool—which I admit has been a little harder to do recently than normal. I’m usually a bit worn out after the previous day’s long bike ride, and Monday reminds me that swimming, while mostly upper-body, really is an activity that uses each of the major muscle groups: arms, legs, and core.

The first swim of the week is often a speed workout, which involves lots of short, all-out sprints. Just like track workouts, the idea is to tax the body’s anaerobic system so that the fast-twitch muscle fibers strengthen, resulting in greater speed the rest of the time. The rest is just short enough to clear out the lactic acid and “reset” the anaerobic system. (“You get faster by going faster” is one of the basic rules of endurance training.) For example, today called for two sets of 5×100 yards with 30 seconds of rest between each 100. Those thirty seconds are just long enough to catch my breath before starting the next sprint. The two minutes of rest between each set is heaven. I lean back against the wall with the water up to my chin, letting it cool me down while I come back to myself. Eventually I resume noticing what’s going on at the pool around me, since I usually get very focused during these intense efforts. Then it’s time to start the intense effort all over again.

I’ve slowly been getting a bit stronger and faster during these speed sessions. Each 100 is a little bit faster than at the beginning of the season—maybe 5-10 seconds—and my 50s are much faster than before. It’s nice to see everything coming together. Now I just need a little more slipperiness and efficiency in the water, and I’ll be keeping up with the cool kids at the pool . . . or at least watching them lap me fewer times.

I don’t think a lot during these speed sessions. Unlike the endurance swims, where my body follows the line on the bottom of the pool while my mind drifts all over the place—trying to remember what lap I’m on, looking around at the people and noticing what they’re wearing and how well they’re swimming, thinking about Lisa and my friends, visualizing my next race, computing fractions and percentages of the swim that I’ve done, being mindful of my form and stroke efficiency, singing along to inappropriate lines from hip hop songs that stick in my head—when I’m doing strength and speed workouts, I’m mostly fixated on pushing as much water past me as I can and trying to remember how many times I’ve touched the wall in the deep end since I started this part of the set. It’s nice to be so single-minded.

This morning while I was warming up and then as I recovered between sets, I thought about the U.S. Olympic trials that Lisa and I have been watching nightly for the last week. I love watching the swimmers, runners, and field athletes doing what they do so well. (I’ve also watched a bit of the gymnastics trials, but I have to admit that it’s hard for me to get into it. I respect the difficulty of what they’re doing and how they make it look effortless, but with the exception of doing a plank or two in my day I don’t feel a lot of connection with the sport. I do like the drama of the events, although NBC could dial it back just a smidge.)

It occurred to me the other day that, while I’ve always had a good understanding of how hard it is for the track athletes to do what they do, this is the first Olympiad where I can really appreciate the swimmers’ technique and times and not just the drama of who is going to win. I’ve never run under 5:00 for a whole mile, but I ran 800m back in the day near 2:15 and some 2-mile track races around 11:00. It was never fast enough to win, but it was fast enough to know what it’s like to run really fast. I know what air moving past me at 4:30 pace feels like, and it’s great. I’ve only done a handful of bike races, but I know what it feels like to descend at 50 MPH and to make that face when riding. That look is the 5 MPH difference between what I do for part of a workout and what they do for hours.

As I was leaning against the wall having done five 100-yard sprints at between 1:40 and 1:45 for each, I was thinking of the women and men I watched at the Olympic trials on TV the night before who swam 200m of freestyle in the same amount of time that I took for my 90-ish meters. The fact is, I have no idea what it feels like to swim fast. (Don’t get me wrong; I’m not complaining. I’m so much faster and stronger than I was just a year ago.) While I do well versus my peers, there’s another group of swimmers out there that have more than just the skills and speed that I lack; they have also had swimming experiences that I’ve only dreamt of.

I’ll never swim as fast as Ryan Lochte or Missy Franklin—or run as fast as Galen Rupp or Allyson Felix or ride as fast Jens Voigt or Kristin Armstrong—but it’s fun to think about maybe getting halfway there. It certainly makes those 100 yard sprints feel better.


II. Each trip to the pool is also an opportunity to fine-tune my insulin for the swim. Based on a few weeks of data, I can definitively say that if I don’t eat, lower my basal rate, or bolus any insulin before speed or strength workouts, my blood glucose will go up. But if I go to the pool or lake and do an endurance swim of a half-mile or more, it will go down. How much insulin do I need on a speed day to prevent going up? How much food (and possibly insulin) do I need on an endurance day not to drop very much? These are questions I’m asking myself and trying to answer three times a week. With NYC coming up on Sunday, finding the answer is a bit more urgent, which is another good reason not to sleep in on Monday.

This morning was a perfect opportunity to search for answers and gain extra confidence.

My BG at 4:30 this morning was 120 mg/dL (6.7 mmol). An hour later before my swim it was 108 (6.0). Those are pretty close to perfect for me for fasting readings. That perfection made “doing the right thing” more critical. I didn’t want to waste an opportunity to gather good, usable data by changing too many things at once, and I didn’t want to act too aggressively and possibly go low in the pool. Choices, choices, choices.

I was hungry, I didn’t have a lot of headroom for going low, and I had an energetic swim ahead. What to do? I decided to simulate this weekend . . . minus the endurance aspect, which I hope to account for on Wednesday or Friday. I set a 0% temp basal rate 40-45 minutes before I knew that I would start swimming, I ate an energy gel (20g of carbs) 10 minutes before the swim, and I delivered an almost insignificant 0.3 units of insulin to “cover” the food and the swim. (This follows the same ratio of roughly 65:1 that I’ve been using when I bike in the morning. It hardly seems like it should matter, but it does. And no, I don’t divide by 65. I say, “ClifBar = 0.6u, and a gel is half a ClifBar, so 0.3u.”)

What happened? My post-swim was 112 (6.2), basically unchanged from before the swim. That sounds like something very promising to try again. Later this week, I’ll try a longer, aerobic swim with similar fueling and see what changes I need to make.

Things might finally be starting to come together.

Disclaimer: Obviously, this is something that worked for me . . . once. Take a big ole grain of salt, don’t consider this as personal advice or copy it outright, and talk to your diabetes peeps before making any changes. Yadda yadda yadda.

Posted in Data-betes, Diabetes, Life Lessons, Reluctant Triathlete, Swimming | 1 Comment

Girl, You’ll Be a Woman Soon

I’ve always said that triathlon is more than three disciplines. Beyond swimming, cycling, and running, you have to be good at transitions, nutrition, and recovery. And for some of us, there’s also diabetes.

I have a training plan with very exact instructions of what to do for the three athletic events, and I’ve been practicing my nutrition and transition strategies. Recovery is a little harder to actively manage, but I take lower-intensity rest weeks, use a foam roller, stretch, and try to stick to my plan. Diabetes has been much more ad hoc for me, though.

I was thinking on my way back from Minnesota after the big ride about insulin and exercise. This was not the first time where I’ve needed to give myself insulin during the event, despite my best efforts to avoid doing so. It’s also about the millionth time that I have not eaten (much) before some serious exertion because I didn’t know how much insulin to give to prevent low or high blood sugar.

Basically, I’m a big baby, but I have grown tired of being afraid of insulin and not knowing how to harness its power to prevent lows. And I want to figure out how to use it so that I can eat enough beforehand to prevent hitting the wall during my races, training outings, and long rides.

In order to gain the mental toughness to use insulin effectively—to no longer be afraid of it—I explicitly need to work insulin into my training plan and make it just as rigorous as the swim, bike, or run parts. This involves setting myself some goals and giving myself some concrete tasks to do.

Over the last couple weeks, I have taken some premeditated steps to experiment actively with diabetes before my swim, testing whether it was still right to turn my basal rate off 45-60 minutes before swimming, which I had been doing for most of the last year. I had noticed my BGs going up during my intense “strength” and “speed” workouts—which happens to many people—so I wanted to see if it was my basal rate or the anaerobic nature of the training. I also wanted to see what would happen if I ate something and took some insulin before my long Sunday ride (scary). And I set out to look very carefully at (a) what I need to do to get my BGs down before my afternoon workouts and (b) what happens during those workouts. Each workout at the pool is a chance to make a small change in a safe environment (cloudiness notwithstanding) before I try it at the lake.

It’s been interesting. I’ve done one long ride, three swims, a ride and a run. And, of course, I’ve kept notes the whole time.

Swim #1 — The plan: Swim 1800 yards without reducing my basal rate beforehand (i.e., use my normal, pre-dawn 0.9 u/hr rate). Food: Nope. Insulin on board: A bit (I wrote it down somewhere). The result: Down from 221 to 81.

Swim #2 — The plan: Swim 2 sets of 4×50 sprints (plus 10:00 of warmup and cool-down) without using a temp basal rate. Food: Nope. Insulin on board: Nope. The result: 5:00=123. Before @ 5:45=124. After @ 6:20=115.

Swim #3 — The plan: Swim 1000 yards without using a temp basal rate. Food: Nope. Insulin on board: Nope. The result: 5:10=165. Before @ 5:45=157. After @ 6:20 = 111.

Next up on the plan: another high-intensity workout without a temp basal rate reduction. Let’s see if the endurance workouts need a reduction and the strength/speed workouts don’t. And then, work on finding the right basal reduction for the long, aerobic swims.

50-Mile Bike Ride + 20-Minute Run — The plan: Eat something before starting a ride and take a small fraction of the recommended insulin. See what happens. Temp basal: 70%. Insulin on board: 0.5u @ 4:30. Food before: Clif Bar (39g). Insulin: 0.6u (not very much). Other food during the ride: 3 gels (25g each), 1 pack of Clif Bloks (40g), 60 oz of water. The result: 4:30=215. Before @ 6:50=171. 7:50=159. 8:40=130. 9:10=146. 9:45=172. Start of run @ 10:15=158. After @ 10:45=146.

Well, that could work. Next time, we’ll see what happens when the insulin on board is different.

There’s more data, but I’ll stop there. I’m off to figure out what diabetes experiments to do during the next few workouts. Stay tuned!

Posted in Cycling, Data-betes, Diabetes, Life Lessons, Reluctant Triathlete, Swimming | 2 Comments

Diabetes Mind Palace


“Stuff” is one of the evergreen topics of diabetes. What we use, the features we would like from pharma, and why we don’t have the amazing toys yet—we never seem to get tired of discussing it. Today in Diabetes Blog Week is the day that we talk tech, in particular our “fantasy diabetes devices.”

I think you can divide fantasy devices into (at least) two broad categories: (1) things like what we have now, and (2) things that act like an endocrine system. I’d love the latter, with its promise of a system or implant that behaves like a pancreas and gives us back normal glycemic response without any work. It’s going to take a while before we have replacement beta cells that don’t die . . . or CGM sensors that are accurate enough to make life and death decisions without our input . . . or control system algorithms that can handle all of the crazy variables that go into blood glucose.

So I think we’re on our own for a while longer, and we will need devices that help us make better decisions. I’ve said it before: we generate so much data that never gets used, and I’m sure that device manufacturers could build more decision-support, trend-spotting, and CDE-like functionality into our devices. And these devices should all talk to each other using standard, open protocols (like ANT+) so that they can integrate with all kinds of other devices—like my Garmin bike computer or running watch—and third-party software, which I would totally write if it were easier to get at the data.

Ideally, these decision-support systems would remember what’s happened over a long, ever-growing history, know what’s happened earlier in the day, and give suggestions about what to do next. The less work that I have to do the better.

Posted in Data-betes, Diabetes, Diabetes Blog Week | 3 Comments