data

#DIYPS and the wedding

by Dana Lewis

“Diabetes wasn’t in the picture during the wedding, and that was exactly how it should be.”

Dana Lewis and Scott Leibrand said "I do!"

 

If you’re not familiar with Scott & me (Dana), and how we ended up building #DIYPS and later #OpenAPS, you might be interested to read this great article in Business Insider. (And I’ve been told it’s guaranteed to make you go “awww” even if you already sort-of know us!)

I love that it also highlights how #DIYPS played into our wedding, which was exactly how I wanted it: I hardly thought about diabetes at all. I didn’t have to cut into the lining of my wedding dress to carry d-supplies. In fact, up until the last minute, I wasn’t sure if I was going to carry the closed loop during the wedding itself, because I had decided not to put pockets in my dress and I wasn’t sure Scott’s suit had big enough pockets to hold everything.

But just like all things in this #DIYPS and #OpenAPS journey, a couple of serendipitous events gave us our solution.

First, we were in Alabama for the week before the wedding, and I was working a few days remotely there. But I like to move while I work, and so I’d move around the house (and go outside) with my laptop while I was on calls. This led to Scott getting no data alerts and no-loop-running alerts, and randomly chasing me down to re-plunk the loop down into range. Finally, he asked if I would consider a fanny pack. I laughed, and told him no way, and that HE should wear a fanny pack. Then I remembered hearing about flip belts and thinking about getting one at one point to try for running. So, we made a quick Amazon purchase (where all great artificial pancreas parts come from ;)).

Scott probably thought he’d get me to wear the flip belt around the house (it is purple, after all), and maybe at the wedding, but when it arrived two days before the wedding and I was busy working, he actually put it on, placed all the loop parts inside, and then decided to try putting his tux coat on over it.

It didn’t show.

And this is how *Scott* ended up wearing the belt and the AP parts during the wedding (he’s wearing it above and you can’t see it!). I obviously was stilling wearing my pump and my CGM sensor under my dress where it wasn’t showing. We also gave my second CGM receiver to Tim ( Scott’s brother and best-man-extraordinaire), who also wore Scott’s watch for much of the day and helped give me updates on my BGs when Scott & the loop were out of range prior to our “first look”.

As a result of having #DIYPS/#OpenAPS, my BGs had been picture perfect the night before the wedding, and were within range all afternoon leading up to the wedding. (They were fine during and after the wedding, too, so much so that it never occurred to me to take more pictures of my graph, which shows how perfect it was to have diabetes not on my mind!)

This may have been (one of) the first wedding(s) with an artificial pancreas in it, but we bet it won’t be the last – one of our friends in the Seattle area who is now up and running on #OpenAPS is also getting married next month, and he may wear his loop during his wedding, too!

We like this trend.

What we’ve been up to – mostly offline #OpenAPS

by Dana Lewis

It’s probably time for an update around here – especially since we’re nearing the “deadline” we set for closing the loop – August 1, 2015!

August 1 is our wedding date, which is part of the reason it’s been quiet around here as we are off busy preparing for that.

The other reason it’s been quiet (unless you follow me on Twitter and see some of the #DIYPS examples there) is because we closed the loop back in December (read more about it here), and we haven’t made any significant updates to the #DIYPS system.

It’s all working well.

Showing a relatively flat CGM graph despite a 75 gram carbohydrate meal, thanks to OpenAPS.

What we’ve been focusing on most of the year is supporting the #OpenAPS community. In particular, we’re trying to help more people learn what they need to understand so that they can build their own loops. There’s a handful who have made or are making excellent progress, and hopefully we’ll have some OpenAPS data to share soon.

Most recently, spotty hotel internet in Portugal helped prompt us to finish the offline version of #OpenAPS, which I’ve been testing. (And will use the honeymoon, wherever that ends up being, as an opportunity for more testing!) #DIYPS has always required internet connectivity to get the recommendations from the cloud (which is where it stores the data I give it about boluses and carbs). The reliance on connectivity is always something to troubleshoot if the system appears to not be working, and also makes it burdensome to carry around all the time and make sure it has connectivity.

Getting offline looping of CGM data to OpenAPS.

Offline OpenAPS will likely solve a big part of the frustrations I experience with daytime use of the system. I already saw a big improvement in being able to use offline OpenAPS in Portugal – both at the conference and in the hotel, as well as walking the streets of London during a layover. It’s nice to drop the system (the same Raspberry Pi, battery, and carelink stick from DIYPS) in my bag and not have to constantly check to make sure the wifi hotspot is connected. The only difference in the setup is that one of my CGMs is plugged directly into the Raspberry Pi.

Showing my OpenAPS rig against the plane window to illustrate offline steam of BGs to OpenAPS is working

We still need to do more testing on our offline implementation of OpenAPS, but it’s going well and I’m excited that what we’ve learned from this progress will help us with better tools to enable the broader OpenAPS community since #WeAreNotWaiting!

Context – give me my data (on my device)

by Dana Lewis

Today I saw that Medtronic announced a partnership with IBM. You can read about it on Twitter, where I first saw it, or elsewhere online. There’s lots of news articles and PR about it, too, which I haven’t read yet in great detail.

My initial reaction:

Pointing out that I can't get temp basal histories on my insulin pump

Additional context:

When I reduce my insulin (either by “suspending” the pump’s activity altogether, or by reducing my basal rate with a “temp” or temporary basal rate), there’s no record of it visible on my insulin pump.

None, at all.

Suspended for 15 minutes while I’m in the shower? No record of it if I accidentally resume insulin activity before checking to see when I suspended it.

Same for if I go running and activate a reduce basal rate (again, a “temp”) of 0.3u/hour instead of my usual 1.3/hour. That’s 1u less of insulin than I normally get. If I cancel it, or if that hour ends without me noticing it?

No record at all.

Which means if my blood glucose skyrockets an hour later, it will take me much longer to catch up with insulin if I don’t realize that I’m -1u (negative one unit) below what my body is used to.

Suspending your pump for 3 hours to go swimming? Same deal. Your body has less insulin than it’s used to, but you have to manually and mentally keep track of it.

The reverse is true as well – if you are sick and your body is more resistant to insulin than usual, and you use a higher basal rate than your usual as a way to additionally correct for a high BG?

No record of the additional insulin you’re putting into your body above your baseline basal profile.

THIS IS DANGEROUS.

And yet this is the FDA approved medical device that everyone is happy that I’m using? Even with critical flaws that endanger my life every day?

And the world has a problem with patients “hacking” or otherwise finding ways to access this critical data since we can’t get it from our approved devices?

This is backwards.

Medtronic and other pump brands track how much “insulin on board” (aka IOB) you have…but this number is wrong, because it doesn’t calculate the lack of insulin if you adjust your basal rates (examples above).

This is something I’ve been doing with #DIYPS to compensate for the inaccessibility of data from my FDA-approved medical device. Instead, I have to calculate for myself the “net” IOB number that takes into account any ‘negative’ corrections from suspending or negative or positive temp basal rates. These make a huge difference in my diabetes care.

We’ve learned from talking to people about #DIYPS for a year and a half that many people don’t use temporary basal rates, even though they’re very effective to ward off future lows and highs.

Why?

For one thing, it’s because there’s no record in their pumps. It’s too hard, and too much guesswork when there’s no record.

I don’t understand why the pump companies seem to ignore this. (If someone has a pump that tracks net IOB and/or shows a history of temporary basal rates and suspension, let me know. I’m familiar mainly with Medtronic’s pumps.)

This is not ok.

So while I think there’s a lot of potential for Medtronic to do more things with diabetes data (like this or this) through this partnership with IBM’s Watson? In the meantime, I’d like them to start with something much more simple – and with guaranteed impact.

Give me, the patient, my data that I need – directly on my medical device – so I can safely take care of myself and better manage my diabetes.

(Note – I realize FDA approval cycles on pumps take a long time, and this is unlikely to get fixed in current pumps. But future pumps? This should be fixed across the industry. And in the meantime? Companies can and should make it much easier to access data from the pumps via their approved uploader methods and make it easier to read the data. Right now, it’s not even easy to see the data off your pump. Let’s change this.)