Hey, y’all. Sorry I’ve been mostly absent recently. I’ve been making stuff, and it feels pretty good. I don’t get to code quite as much as I used to at work, and this (*ahem*) little project has been giving me the outlet I need.
I started building an app to integrate all of my diabetes and exercise data right after my last endocrinology appointment, when I decided I finally wanted to do something about (1) the abysmal lack of context in the data I share with my doctor, despite having so much of it automatically logged for me, and (2) the highs and lows that I see associated with exercise. I’ve had a bad track record with personal software development projects, but I was able to get some good traction with this one. After some early brainstorming and design sessions, a couple of productive plane rides, numerous conversations with a few coworkers, one Boston Quantified Self meet-up, and many evenings of hacking/coding/fixing/designing/refactoring/playing—including not a few where I stayed up way past “pumpkin time”—I feel like I have something I can actually use to start making real conclusions. Of course I’ve been using the data throughout the project, leading to a few “Ah ha!” moments, but the last bit of integration makes it so easy to really see what’s going on.
Here’s what I’ve got. (Click for a larger image.)
You’re looking at four windows in my app. There will probably be more, but this is all I can really wrangle now. Soon I will figure out how to use the awesome, undocumented stuff under development at work and put these parts into a more polished application. (This project is really helping me know more about the bleeding-edge parts of MATLAB. While I’ve worked with it more or less every day for the last fifteen years, I never really had the chance of use many of its newer features.) Here’s are description of the four parts.
(1) The upper left-hand window is a data browser, focusing on the highest level details for each day. This should look pretty familiar to most of us with diabetes. This part and the next one are the most quantitative, and I’m trying to work more contextual, qualitative information into the other pieces of the app. Clicking on any cell in the table changes what is shown in the other windows, and it’s possible to compare multiple days at once.
(2) The lower left window presents more details for the selected days: minimum, maximum, average, and standard deviation for both blood glucose readings and CGM data; the estimated number of carbs I ate (including the ones, like glucose tablets and food during exercise, that I didn’t bolus for) and the amount of insulin I dosed; and the amount of exercise. I have also thrown in a couple of computed values: my average blood glucose divided by the number of carbs and my effective carb:insulin ratio for the day. They might be useful as I look through the data. Or maybe they won’t. We shall see.
(3) The graphs in the upper right are the big picture view of the data. If you’re a visual person (like me) and want to see how the parts fit together, this is it. It’s all there: sensor and BG data, carbs, insulin, temporary and regular basal rates, . . . even the estimated amount of insulin concentration in my bloodstream waiting to be used. The bright blue boxes are exercise. They’re not the most beautiful graphs (yet), but I’ve already managed to see some trends in them.
(4) While looking for these trends, I found myself always going back to the raw data to see exactly what that number was or exactly when that other thing happened. So I made the fourth window—the one in the lower right—which contains the actual events logged by all of my devices. It’s the rawest form of the data that I’ve exposed in the app. (There’s even more “raw” data stored in what I’m calling “the timeline,” or database, but it’s so hard to use as-is. That’s why I wrote the app, eh?)
And that’s the big picture of what I’ve made.
Oh, I guess there’s also this other stuff, just in case you think I’ve been slacking:
- There’s a nice box plot tool that can be configured to show averages, distributions, and other statistical goodies for different times of day. When I threw enough data at it, it became pretty clear where the most challenging part of my day are (blood sugar wise, at least).
- It integrates with Dropbox, so I can use it wherever I have both MATLAB and Dropbox installed. The data is always sync’ed up.
- It has one of the fastest .fit file parsers around.
- There’s a good deal of date-oriented subsetting functionality. Maybe I want to look at what happened in the last 90 days since my endo appointment. Perhaps I just want to examine weekdays . . . or weekends. I might only be interested in seeing the five hours before and two hours after exercise. Easy peasy.
- It’s possible to look for and report specific kinds of events. Only want to see CGM or pump alarms? Okay. Want to see all the details about swims lasting longer than 30 minutes. No problem.
- I liked the free-form nature of Microsoft Outlook’s date/time entry so much that I implemented the same thing for myself. I like saying “yesterday” or “tomorrow” when talking to MATLAB’s datenum function.
There’s more stuff, but they are mostly building blocks.
Now the really exciting work begins to automate the search for trends. . . . finding those insulin needles in the haystack, if you will. I hope to be able to answer questions like these soon: What is happening on days when I climb wicked high in the afternoon? What happens on days when I don’t? How much does my blood glucose typically drop when I ride my bike in the afternoon? What did I do on afternoons when my blood sugar was really stable while I was out running or cycling? What is my actual carb:insulin ratio on days where my blood glucose is well-managed? How does my overnight basal rate look?
I’ll let you know how the data mining turns out!
p.s. — Yes, I’m thinking about how to share this functionality with the whole world (or at the very least the MATLAB-speaking part). But before I do that, I need to ruminate much, much, much more about what it means to provide the building blocks for medical analytics to people (like me) who have to make most/all of our medical decisions without much decision-support tooling and yet are expected to get it right most of the time. It’s not something I take lightly.