All Together Now: Integrating the Diabetes App

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.

This entry was posted in Data-betes, Diabetes, Software Engineering. Bookmark the permalink.

7 Responses to All Together Now: Integrating the Diabetes App

  1. Marcus says:

    Very very cool… Can’t wait ’til you’re ready to share… I’m impressed!

  2. StephenS says:

    Jeff, I’m finding all of this very interesting and I’m hanging on every word (or line of code). Good luck with the continued research.

  3. Nice work Jeff. What devices are you using and how are you exporting/manipulating data?

  4. Jeff Mather says:

    Bernard, I’ll write a longer post about the import workflow (and it’s several pains) soon, but here it is in a nutshell. I use these devices:

    • Three OneTouch meters (UltraLink, UltraMini, and Ultra2), which I can download via a serial-to-USB cable.
    • A Garmin Edge 500 bike GPS, which I sync via USB cable.
    • A Garmin FR-60 non-GPS watch, which I can sync via ANT+ USB stick.
    • Medtronic Minimed Paradigm Revel (523) pump with CGM that I sync via the Bayer Contour USB BG meter.

    I have to manually download the BG meters, pump, and CGM through Medtronic’s CareLink site. It’s a pain—especially since I had to hack together a (mostly reliable) solution to read my OneTouch meters on my Mac—and that pain is the main reason that I only upload data to it about once a week. Then I have to manually download the data from CareLink via a CSV file. I sync from the Garmin devices much more frequently because it’s easier and because I want to keep my Strava account up-to-date. The data files from my Garmins are automatically saved to my hard drive, which makes importing them much, much easier. I’ve written parsers to import the Medtronic CareLink CSV files as well as the Garmin .fit files.

    All of the data processing, visualization, and analysis happens within MATLAB.

    I guess I should add that I just borrowed a FitBit device and have been collecting data for, say, an hour or two. I will be hacking around with that soon. If I can replicate in MATLAB some of the FitBit/ANT+ hacks that I’ve seen recently and gain access to the minute-by-minute “how active am I right now?” data in the near future, I will (probably) incorporate that into the analysis at a very coarse, qualitative level.

    Based on what I learn about hacking USB devices, I’ll probably try getting as much of the data from my OneTouch and Medtronic devices as I possibly can without using CareLink. The “wait until I’m at a computer, connect, acquire, upload, download, import and parse” workflow is very time-consuming.

  5. scully says:

    C.O.M.P.L.I.C.A.T.E.D!!
    You are a master, my friend. A master.

  6. Julie says:

    Really excited by this! Can’t wait until we can integrate all our proprietary D devices in an easy-to-use interface!

  7. matt smith says:

    Love the work you are doing and hope for your success. I’m a non-techie trying to link my fitbit, pump, garmin and meters. Hard to believe in this connected world, it is so hard to connect.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>