How I made my #OpenAPS code shirt (and new pancreas case!)

“Wait, what does your shirt say?”

When we talk about the ability and right to self-experiment and to DIY, a common theme that comes up is about freedom of speech and the freedom to self-experiment. And there’s a well-known example of someone who put their code on a t-shirt. In the back of my mind, I always thought one day I would do that (create #OpenAPS shirts with code on them), but didn’t really get around to it, because we’re a little busy doing other things 😉 for the most part.

However, a few months ago I was itching to do something crafty, but I’m not a really crafty person. So, I decided to hack the process and use technology to facilitate my craftiness.

The design process

I’m not a designer, just like I’m not a traditional programmer/engineer/whatever. But what I learned from pancreas building applies to other DIY areas, too! I knew Spoonflower enables you to custom print cool fabric, but I didn’t realize anyone (like, you know, me) could upload a design and have it printed in your fabric of choice. You don’t need fancy design software, either – I used PowerPoint to create the design, exported as an image, and uploaded to Spoonflower.

(The one limitation is that before ordering any of the fabric in a traditional order, they require you to print a sample of it first. But if you do that, it’s a $12 sampler and you might as well do a couple of designs. You can iterate on your one design, or do multiples. And I like hashtags, so I designed some hashtag patterns, too. But don’t worry – since I already printed my oref0 code as a sampler, it doesn’t need to be re-sampler’ed – you can order away now if you so choose. )

Once I got my sampler, I went over to the Sprout Patterns website, which is connected to Spoonflower. I had my eye on this shirt, but there’s dresses and shirt patterns of all kinds. (You can also just get the fabric printed and do any kind of shirt pattern you want.) But the other reason I did Sprout? Because I have talented sisters- and cousins-in-law who were willing to sew the shirt for me, but they’re super busy. So I decided to pay the $25 to have someone from Sprout sew my shirt.

The finished shirt:
Dana Lewis oref0-determine-basal code shirt

How to get your own shirt (or the fabric for whatever you want)

Because I marked my design as “public”, you can go to Spoonflower today and order prints in any size and any of the fabric that you want with that design. (I used “modern jersey” for my shirt). As the “designer”, I do get 10% of the cost of any yard printed with one of my designs on it in SpoonFlowerCash, which means I’ll probably use any of that to design more patterns and order another set of samplers so there are more colors/code options/font sizes to choose from in the future.

However, if you want the shirt to come made for you, go start on Sprout. Pick the pattern you like, pick your size, and then you can “design” your shirt using any of the Spoonflower designs, including the #OpenAPS oref0-determine-basal code. You can find it by searching OpenAPS, oref0, determine-basal, my username (danamlewis), etc.

You can move the design around and figure out where you want it to go. You can make any piece of the panels/sides of the shirt in different patterns or colors, so you can pick an accent color for a sleeve or cuff or belt, etc.

Pro tip: If you’re doing the Sprout route with the White Glove Service (where they sew the shirt/garment for you), in the comment area, tell them you want the extra “scrap” fabric!

#OpenAPS code cases

I have a pile of scrap fabric that I sent pictures of to the wonderful Tallygear team, and talked Donna into trying it out to make me a pancreas case. 😀 (Like this idea for a case design? Let her know! She (or anyone else) can order this fabric on Spoonflower, too, to make cases. The fabric isn’t quite the same as the neoprene we’ve been using, but it’s still got some stretch and I’m incredibly biased but I think they’re awesome!)

So, that’s how I ended up wearing a shirt that makes you do a double take and say hey, that code sure does look familiar….

If you end up printing the fabric or designing your own pattern or shirt or pancreas case after hearing about this, I’d love to hear about it, please do share pictures!

This. Matters. (Why I continue to work on #OpenAPS, for myself and for others)

If you give a mouse a cookie or give a patient their data, great things will happen.

First, it was louder CGM alarms and predictive alerts (#DIYPS).

Next, it was a basic hybrid closed loop artificial pancreas that we open sourced so other people could build one if they wanted to (#OpenAPS, with the oref0 basic algorithm).

Then, it was all kinds of nifty lessons learned about timing insulin activity optimally (do eating soon mode around an hour before a meal) and how to use things like IFTTT integration to squash even the tiniest (like from 100mg/dL to 140mg/dL) predictable rises.

It was also things like displays, button, widgets on the devices of my choice – ranging from being able to “text” my pancreas, to a swipe and button tap on my phone, to a button press on my watch – not to mention tinier sized pancreases that fit in or clip easily to a pocket.

Then it was autosensitivity that enabled the system to adjust to my changing circumstances (like getting a norovirus), plus autotune to make sure my baseline pump settings were where they needed to be.

And now, it’s oref1 features that enable me to make different choices at every meal depending on the social situation and what I feel like doing, while still getting good outcomes. Actually, not good outcomes. GREAT outcomes.

With oref0 and OpenAPS, I’d been getting good or really good outcomes for 2 years. But it wasn’t perfect – I wasn’t routinely getting 100% time in range with lower end of the range BG for a 24hour average. ~90% time in range was more common. (Note – this time in range is generally calculated with 80-160mg/dL. I could easily “get” higher time in range with an 80-180 mg/dL target, or a lot higher also with a 70-170mg/dL target, but 80-160mg/dL was what I was actually shooting for, so that’s what I calculate for me personally). I was fairly happy with my average BGs, but they could have been slightly better.

I wrote from a general perspective this week about being able to “choose one” thing to give up. And oref1 is a definite game changer for this.

  • It’s being able to put in a carb estimate and do a single, partial bolus, and see your BG go from 90 to peaking out at 130 mg/dL despite a large carb (and pure ballpark estimate) meal. And no later rise or drop, either.
  • It’s now seeing multiple days a week with 24 hour average BGs a full ~10 or so points lower than you’re used to regularly seeing – and multiple days in a week with full 100% time in range (for 80-160mg/dL), and otherwise being really darn close to 100% way more often than I’ve been before.

But I have to tell you – seeing is believing, even more than the numbers show.

I remember in the early days of #DIYPS and #OpenAPS, there were a lot of people saying “well, that’s you”. But it’s not just me. See Tim’s take on “changing the habits of a lifetime“. See Katie’s parent perspective on how much her interactions/interventions have lessened on a daily basis when testing SMB.

See this quote from Matthias, an early tester of oref1:

I was pretty happy with my 5.8% from a couple months of SMB, which has included the 2 worst months of eating habits in years.  It almost feels like a break from diabetes, even though I’m still checking hourly to make sure everything is connected and working etc and periodically glancing to see if I need to do anything.  So much of the burden of tight control has been lifted, and I can’t even do a decent job explaining the feeling to family.

And another note from Katie, who started testing SMB and oref1:

We used to battle 220s at this time of day (showing a picture flat at 109). Four basal rates in morning. Extra bolus while leaving house. Several text messages before second class of day would be over. Crazy amount of work [in the morning]. Now I just have to brush my teeth.

And this, too:

I don’t know if I’ve ever gone 24 hours without ANY mention of something that was because of diabetes to (my child).

Ya’ll. This stuff matters. Diabetes is SO much more than the math – it’s the countless seconds that add up and subtract from our focus on school/work/life. And diabetes is taking away this time not just from a person with diabetes, but from our parents/spouses/siblings/children/loved ones. It’s a burden, it’s stressful…and everything we can do matters for improving quality of life. It brings me to tears every time someone posts about these types of transformative experiences, because it’s yet another reminder that this work makes a real difference in the real lives of real people. (And, it’s helpful for Scott to hear this type of feedback, too – since he doesn’t have diabetes himself, it’s powerful for him to see the impact of how his code contributions and the features we’re designing and building are making a difference not just to BG outcomes.)

Thank you to everyone who keeps paying it forward to help others, and to all of you who share your stories and feedback to help and encourage us to keep making things better for everyone.

 

Introducing oref1 and super-microboluses (SMB) (and what it means compared to oref0, the original #OpenAPS algorithm)

For a while, I’ve been mentioning “next-generation” algorithms in passing when talking about some of the work that Scott and I have been doing as it relates to OpenAPS development. After we created autotune to help people (even non-loopers) tune underlying pump basal rates, ISF, and CSF, we revisited one of our regular threads of conversations about how it might be possible to further reduce the burden of life with diabetes with algorithm improvements related to meal-time insulin dosing.

This is why we first created meal-assist and then “advanced meal-assist” (AMA), because we learned that most people have trouble with estimating carbs and figuring out optimal timing of meal-related insulin dosing. AMA, if enabled and informed about the number of carbs, is a stronger aid for OpenAPS users who want extra help during and following mealtimes.

Since creating AMA, Scott and I had another idea of a way that we could do even more for meal-time outcomes. Given the time constraints and reality of currently available mealtime insulins (that peak in 60-90 minutes; they’re not instantaneous), we started talking about how to leverage the idea of a “super bolus” for closed loopers.

A super bolus is an approach you can take to give more insulin up front at a meal, beyond what the carb count would call for, by “borrowing” from basal insulin that would be delivered over the next few hours. By adding insulin to the bolus and then low temping for a few hours after that, it essentially “front shifts” some of the insulin activity.

Like a lot of things done manually, it’s hard to do safely and achieve optimal outcomes. But, like a lot of things, we’ve learned that by letting computers do more precise math than we humans are wont to do, OpenAPS can actually do really well with this concept.

Introducing oref1

Those of you who are familiar with the original OpenAPS reference design know that ONLY setting temporary basal rates was a big safety constraint. Why? Because it’s less of an issue if a temporary basal rate is issued over and over again; and if the system stops communicating, the temp basal eventually expires and resume normal pump activity. That was a core part of oref0. So to distinguish this new set of algorithm features that depart from that aspect of the oref0 approach, we are introducing it as “oref1”. Most OpenAPS users will only use oref0, like they have been doing. oref1 should only be enabled specifically by any advanced users who want to test or use these features.

The notable difference between the oref0 and oref1 algorithms is that, when enabled, oref1 makes use of small “supermicroboluses” (SMB) of insulin at mealtimes to more quickly (but safely) administer the insulin required to respond to blood sugar rises due to carb absorption.

Introducing SuperMicroBoluses (or “SMB”)

The microboluses administered by oref1 are called “super” because they use a miniature version of the “super bolus” technique described above.  They allow oref1 to safely dose mealtime insulin more rapidly, while at the same time setting a temp basal rate of zero of sufficient duration to ensure that BG levels will return to a safe range with no further action even if carb absorption slows suddenly (for example, due to post-meal activity or GI upset) or stops completely (for example due to an interrupted meal or a carb estimate that turns out to be too high). Where oref0 AMA might decide that 1 U of extra insulin is likely to be required, and will set a 2U/hr higher-than-normal temporary basal rate to deliver that insulin over 30 minutes, oref1 with SMB might deliver that same 1U of insulin as 0.4U, 0.3U, 0.2U, and 0.1U boluses, at 5 minute intervals, along with a 60 minute zero temp (from a normal basal of 1U/hr) in case the extra insulin proves unnecessary.

As with oref0, the oref1 algorithm continuously recalculates the insulin required every 5 minutes based on CGM data and previous dosing, which means that oref1 will continually issue new SMBs every 5 minutes, increasing or reducing their size as needed as long as CGM data indicates that blood glucose levels are rising (or not falling) relative to what would be expected from insulin alone.  If BG levels start falling, there is generally already a long zero temp basal running, which means that excess IOB is quickly reduced as needed, until BG levels stabilize and more insulin is warranted.

Safety constraints and safety design for SMB and oref1

Automatically administering boluses safely is of course the key challenge with such an algorithm, as we must find another way to avoid the issues highlighted in the oref0 design constraints.  In oref1, this is accomplished by using several new safety checks (as outlined here), and verifying all output, before the system can administer a SMB.

At the core of the oref1 SMB safety checks is the concept that OpenAPS must verify, via multiple redundant methods, that it knows about all insulin that has been delivered by the pump, and that the pump is not currently in the process of delivering a bolus, before it can safely do so.  In addition, it must calculate the length of zero temp required to eventually bring BG levels back in range even with no further carb absorption, set that temporary basal rate if needed, and verify that the correct temporary basal rate is running for the proper duration before administering a SMB.

To verify that it knows about all recent insulin dosing and that no bolus is currently being administered, oref1 first checks the pump’s reservoir level, then performs a full query of the pump’s treatment history, calculates the required insulin dose (noting the reservoir level the pump should be at when the dose is administered) and then checks the pump’s bolusing status and reservoir level again immediately before dosing.  These checks guard against dosing based on a stale recommendation that might otherwise be administered more than once, or the possibility that one OpenAPS rig might administer a bolus just as another rig is about to do so.  In addition, all SMBs are limited to 1/3 of the insulin known to be required based on current information, such that even in the race condition where two rigs nearly simultaneously issue boluses, no more than 2/3 of the required insulin is delivered, and future SMBs can be adjusted to ensure that oref1 never delivers more insulin than it can safely withhold via a zero temp basal.

In some situations, a lack of BG or intermittent pump communications can prevent SMBs from being delivered promptly.  In such cases, oref1 attempts to fall back to oref0 + AMA behavior and set an appropriate high temp basal.  However, if it is unable to do so, manual boluses are sometimes required to finish dosing for the recently consumed meal and prevent BG from rising too high.  As a result, oref1’s SMB features are only enabled as long as carb impact is still present: after a few hours (after carbs all decay), all such features are disabled, and oref1-enabled OpenAPS instances return to oref0 behavior while the user is asleep or otherwise not engaging with the system.

In addition to these safety status checks, the oref1 algorithm’s design helps ensure safety.  As already noted, setting a long-duration temporary basal rate of zero while super-microbolusing provides good protection against hypoglycemia, and very strong protection against severe hypoglycemia, by ensuring that insulin delivery is zero when BG levels start to drop, even if the OpenAPS rig loses communication with the pump, and that such a suspension is long enough to eventually bring BG levels back up to the target range, even if no manual corrective action is taken (for example, during sleep).  Because of these design features, oref1 may even represent an improvement over oref0 w/ AMA in terms of avoiding post-meal hypoglycemia.

In real world testing, oref1 has thus far proven at least as safe as oref0 w/ AMA with regard to hypoglycemia, and better able to prevent post-meal hyperglycemia when SMB is ongoing.

What does SMB “look” like?

Here is what SMB activity currently looks like when displayed on Nightscout, and my Pebble watch:

First oref1 SMB OpenAPS test by @DanaMLewisFirst oref1 SMB OpenAPS test as seen on @DanaMLewis pebble watch

How do features like this get developed and tested?

SMB, like any other advanced feature, goes through extensive testing. First, we talk about it. Then, it becomes written up in plain language as an issue for us to track discussion and development. Then we begin to develop the feature, and Scott and I test it on a spare pump and rig. When it gets to the point of being ready to test it in the real world, I test it during a time period when I can focus on observing and monitoring what it is doing. Throughout all of this, we continue to make tweaks and changes to improve what we’re developing. After several days (or for something this different, weeks) of Dana-testing, we then have a few other volunteers begin to test it on spare rigs. They follow the same process of monitoring it on spare rigs and giving feedback and helping us develop it before choosing to run it on a rig and a pump connected to their body. More feedback, discussion, and observation. Eventually, it gets to a point where it is ready to go to the “dev” branch of OpenAPS code, which is where this code is now heading. Several people will review the code and approve it to be added to the “dev” branch. We will then have others test the “dev” branch with this and any other features or code changes – both by people who want to enable this code feature, as well as people who don’t want this feature (to make sure we don’t break existing setups). Eventually, after numerous thumbs up from multiple members of the community who have helped us test different use cases, that code from the “dev” branch will be “approved” and will go to the “master” branch of code where it is available to a more typical user of OpenAPS.

However, not everyone automatically gets this code or will use it. People already running on the master branch won’t get this code or be able to use it until they update their rig. Even then, unless they were to specifically enable this feature (or any other advanced feature), they would not have this particular segment of code drive any of their rig’s behavior.

Where to find out more about oref1, SMB, etc.:

  • We have updated the OpenAPS Reference Design to reflect the differences between oref0 and the oref1 features.
  • OpenAPS documentation about oref1, which as of July 13, 2017 is now part of the master branch of oref0 code.
  • Ask questions! Like all things developed in the OpenAPS community, SMB and oref1-related features will evolve over time. We encourage you to hop into Gitter and ask questions about these features & whether they’re right for you (if you’re DIY closed looping).

Special note of thanks to several people who have contributed to ongoing discussions about SMB, plus the very early testers who have been running this on spare rigs and pumps. Plus always, ongoing thanks to everyone who is contributing and has contributed to OpenAPS development!

Scuba diving, snorkeling, and swimming with diabetes (and #OpenAPS)

tl;dr – yes, you can scuba dive with diabetes, snorkel with diabetes, and swim with diabetes! Here’s what you need to know.

I meant to write this post before I left for a two-week Hawaii trip, and since I answered about a question a day on various platforms as I posted pictures from the trip, I really wish I had done it ahead of time. Oh well. :) I especially wish someone had written this post for me 2 years ago, before my first scuba dive, because I couldn’t find a lot of good information on the practicalities of good approaches for dealing with all the details of scuba diving with diabetes and an insulin pump and CGM and now closed loops. Scuba diving, snorkeling, and swimming with diabetes are actually pretty common, so here are a few things to keep in mind/tips from me, before diving (pun intended) into some explanations of what I think about for each activity diabetes-wise.

scuba_diving_with_diabetes_tips_water_activities_by_Dana_M_Lewis

General tips for water activities when living with diabetes:

  1. Most important: be aware of your netIOB going into the activity. Positive netIOB plus activity of any kind = expedited low BG. This is the biggest thing I do to avoid lows while scuba diving or snorkeling – trying to time breakfast or the previous meal to be a few hours prior so I don’t have insulin peaking and accelerated by the activity when I’m out in the water and untethered from my usual devices.
  2. Second most important: CGM sensor and transmitter on your body can get wet (shower, pools, hot tubs, oceans, etc.), but keep in mind it can’t read underwater. And sometimes it gets waterlogged from short or long exposure to the water, so it may take a while to read even after you get it above water or dry off. And, historically I’ve had sensors come back and the CGM will sometimes read falsely high (100-200 points higher than actual BG), so exercise extreme caution and I highly recommend fingerstick testing before dosing insulin after prolonged water exposure.
  3. Know which of your devices are waterproof, watertight, etc. Tip: most pumps are not waterproof. Some are watertight*. The * is because with usual wear and tear and banging into things, small surface cracks start showing up and make your pump no longer even watertight, so even a light splash can kill it. Be aware of the state of your pump and protect it accordingly, especially if you have a limited edition super special super rare DIY-loopable pump. I generally take a baggie full of different sized baggies to put pump/CGM/OpenAPS rig into, and I also have a supposedly waterproof bag that seals that I sometimes put my bagged devices into. (More on that below).
    1. And in general, it’s always wise to have a backup pump (even if it’s non-loopable) on long/tropical/far away trips, and many of the pump companies have a loaner program for overseas/cruise/tropical travel.
  4. Apply sunscreen around your sites/sensors because sunburn and applying or removing them hurts. However, as I learned on this trip, don’t do TOO much/any sunscreen directly on top of the adhesive, as it may loosen the adhesive (just surrounding the edges is fine). I usually use a rub sunscreen around the edges of my pump site and CGM sensor, and do the rest of my body with a spray sunscreen. And pack extra sites and sensors on top of your extras.

Why extras on top of your extras? Because you don’t want to have a vacation like I did where I managed to go through 5 pump site catastrophes in 72 hours and run out of pump sites and worry about that instead of enjoying your vacation. Here’s what happened on my last vacation pump-site wise:

  • Planned to change my site the next morning instead of at night, because then I would properly use up all the insulin in my reservoir. So I woke up, put in a new pump site (B) on my back hip, and promptly went off to walk to brunch with Scott.
  • Sitting down and waiting for food, I noticed my BG was rocketing high. I first guessed that I forgot to exit the prime screen on the pump, which means it wasn’t delivering any insulin (even basal). Wrong. As I pulled my pump off my waist band, I could finally hear the “loud siren escalating alarm” that is “supposed” to be really audible to anyone…but wasn’t audible to me outside on a busy street. Scott didn’t hear it, either. That nice “siren” alarm was “no delivery”, which meant there was something wrong with the pump site and I hadn’t been getting any insulin for the last hour and a half. Luckily, I have gotten into the habit of keeping the “old” pump site (A) on in case of problems like this, so I swapped the tubing to connect to the “old” site A and an hour or so later as insulin started peaking, felt better. I pulled site B out, and it was bent (that’s why it was no delivery-ing). I waited until that afternoon to put in the next pump site (C) into my leg. It was working well into dinner, so I removed site A.
  • However, that night when I changed clothes after dinner, site C ripped out. ARGHHHH. And I had removed site A, so I  had to put on another site (D). Bah, humbug. Throw in someone bumping a mostly-full insulin vial off the counter and it shattering, and I was in one of my least-pleased-because-of-diabetes moods, ever. It was a good reminder of how much a closed loop is not a cure, because we still have to deal with bonked sites and sites in general and all this hoopla.
  • Site D lasted the next day, while we went hiking at Haleakala (a 12.2 mile hike, which was amazing that neither my site or my sensor acted up!). However, on the third day in this adventure, I put on sunscreen to go to the beach with the whole family. When we came back from the beach, I went to remove my cover up to shower off sand before getting into the pool. As my shirt came over my head, I saw something white fly by – which turned out to be 4th pump site, flying around on the end of the pump tube, rather than being connected to my body. There went Site D. In went my fifth site (E), which I tackled down onto my body with extra flexifix tape that I usually use for CGM sensors because I. Was. Fed. Up. With. Pump. Sites!
  • Thankfully, site E lasted a normal life and lasted til I got home and did my next normal site change, and all is back to normal.

Lessons learned about pump sites: I repeat, don’t sunscreen too much on the adhesive, just sunscreen AROUND the adhesive. And pack extras, because I went through ~2 weeks of pump sites in 3 days, which I did not expect – luckily I had plenty of extra and extras behind those!

Now on to the fun stuff.

Scuba Diving with diabetes:

  • 2 years ago was my “Discovery” dive, where you aren’t certified but they teach you the basics and do all the equipment for you so you just do some safety tutorials and go down with a guide who keeps you safe. For that dive, I couldn’t find a lot of good info about scuba diving with diabetes, other than logical advice about the CGM sensor not transmitting under water, the receiver not being waterproof, and the pump not being waterproof. I decided to try to target my BG in advance to be around 180 mg/dl to avoid lows during the dive, and for extra safety eat some skittles before I went down – plus I suspended and removed my pump. Heh. That worked too well, and I was high in the mid-200s in between my two dives, so I found myself struggling to peel my wetsuit off in between dives to connect my pump and give a small bolus. The resulting high feeling after the second dive when my BG hadn’t re-normalized yet plus the really choppy waves made me sea-sick. Not fun. But actually diving was awesome and I didn’t have any lows.
    • Pro tip #1 for scuba diving with diabetes: If you can, have your pump site on your abdomen, arm, or other as-easy-as-possible location to reconnect your pump for between-dive boluses so you don’t have to try to get your arm down the leg of your wetsuit to re- and disconnect.
  • I decided I wanted to get PADI certified to scuba dive. I decided to do the lessons (video watching and test taking) and pool certification and 2/4 of my open water dives while on a cruise trip last February. Before getting in the pool, I didn’t do anything special other than avoid having too much (for me that’s >.5u) of netIOB. For the open water dives at cruise ports, I did the same thing. However, due to the excitement/exertion of the first long dive, along with having to do some open water safety training after the first dive but before getting out (and doing my swim test in choppy open water), I got out of the water after that to find that I was low. I had to take a little bit longer (although maybe only 10 extra minutes) than the instructor wanted to finish waiting for my BG to come up before we headed out to the second dive. I was fine during and after the second dive, other than being exhausted.
    • Pro tip #2 for scuba diving with diabetes: Some instructors or guides get freaked out about the idea of having someone diving with diabetes. Get your medical questionnaire signed by a doctor in advance, and photocopy a bunch so you can take one on every trip to hand to people so they can cover themselves legally. Mostly, it helps for you to be confident and explain the safety precautions you have in place to take care of yourself. It also helps if you are diving with a buddy/loved one who understands diabetes and is square on your safety plan (what do you do if you feel low? how will you signal that? how will they help you if you need help in the water vs. on the boat, etc.?). For my training dives, because Scott was not with me, I made sure my instructor knew what my plan was (I would point to my arm where my sensor was if I felt low and wanted to pause/stop/head to the surface, compared to the other usual safety signals).
  • This past trip in Hawaii I was finishing off a cold at the beginning, so at the end of the trip I started with a shore dive so I could go slow and make sure it was safe for me to descend. I was worried about going low on this one, since we had to lug our gear a hundred feet or so down to the beach and then into the water (and I’ve never done a shore dive prior to this). I did my usual prep: temp basal to 0 on my pump for a few hours (so it can track IOB properly) and suspend; place it and CGM and OpenAPS rigs in baggies in my backpack; and confirming that my BG was flat at a good place without IOB, I didn’t eat anything extra. We went out slowly, had a great dive (yay, turtles), and I was actually a little high coming back up after the dive rather than low. My CGM didn’t come back right away, so I tested with a fingerstick and hooked my pump back up right away and gave a bolus to make up for the missed insulin during the dive. I did that before we headed off the beach and up to clean off our gear.
    • Pro tip #3 for scuba diving with diabetes: Don’t forget that insulin takes 60-90 minutes to peak, so if you’ve been off your pump and diving for a while, even if you are low or fine in that moment, that missing basal will impact you later on. Often if I am doing two dives, even with normal BG levels I will do a small bolus in between to be active by the time I am done with my second dive, rather than going 3+ hours with absolutely no insulin. You need some baseline insulin even if you are very active.
  • While in Hawaii, we also got up before the crack of dawn to head out and do a boat dive at Molokini. It was almost worth the 5am wakeup (I’m not a morning person :)). As soon as I woke up at 5am, I did an “eating soon” and bolused fully for my breakfast, knowing that we’d be getting on the boat at 6:30amish (peak insulin time), but it’d take a while to get out to the dive site (closer to 7:30am), so it was better to get the breakfast bolus in and let it finish counteracting the carbs. I did, but still ran a little higher than I would have liked while heading out, so I did another small correction bolus about half an hour before I temped to zero, suspended, and disconnected and baggied/bagged/placed the bag up in the no-water-shelf on the boat. I then did the first dive, which was neat because Molokini is a cool location, and it was also my first “deep” dive where we went down to about ~75 feet. (My previous dives have all been no deeper than about ~45 feet.) Coming back onto the boat, I did my usual of getting the gear off, then finding a towel to dry my hands and do a fingerstick BG test to see what I was. In this case, 133 mg/dl. Perfect! It would take us almost an hour for everyone to get back on the boat and then move to dive spot #2, so I peeled down my wetsuit and reconnected my pump to get normal basal during this time and also do a small bolus for the bites of pineapple I was eating. (Given the uncertainties of accuracy of CGM coming out of prolonged water exposure, since they sometimes run 100+ points high for me, I chose not to have the loop running during this dive and just manually adjust as needed). We got to spot #2 and went down for the dive, where we saw sharks, eels, and some neat purple-tailed fish. By the end of the dive, I started to feel tired, and also felt hungry. Those are the two signs I feel underwater that probably translate to being low, so I was the first from our group to come up when we got back from the boat. I got on the boat, removed gear, dried hands, tested, and…yep. 73 mg/dl. Not a bad low, but I’m glad I stopped when I did, because it’s always better to be sure and safe than not know. I had a few skittles while reconnecting my pump, and otherwise was fine and enjoyed the rest of the experience including some epic dolphin and whale watching on the return boat ride back to the harbor!
    • Pro tip #4 for scuba diving with diabetes: You may or may not be able to feel lows underwater; but listening to your body and using your brain to pay attention to changes, about low or not, is always a really good idea when scuba diving. I haven’t dived enough  (7 dives total now?) or had enough lows while diving to know for sure what my underwater low symptoms are, but fatigue + hunger are very obvious to me underwater. Again, you may want to dive with a buddy and have a signal (like pointing to the part of your body that has the CGM) if you want to go up and check things out. Some things I read years ago talked about consuming glucose under water, but that seems above my skill level so I don’t think I’ll be the type of diver who does that – I’d rather come to the surface and have someone hand me from the boat something to eat, or shorten the dive and get back on the boat/on shore to take care of things.

All things considered, scuba diving with diabetes is just like anything else with diabetes – it mostly just takes planning ahead, extra snacks (and extra baggies) to have on hand, and you can do it just like anyone else. (The real pain and suffering of scuba diving in my opinion comes not from high or low BGs; but rather pulling hair out of your mask when you take it off after a dive! Every time = ouch.)

Snorkeling with diabetes:

  • Most of my snorkeling experiences/tips sound very similar to the scuba diving ones, so read the above if you haven’t. Remember:
    • Don’t go into a snorkel with tons of positive IOB.
    • Have easy-access glucose supplies in the outer pockets of your bag – you don’t want to have to be digging into the bottom of your beach bag to get skittles out when you’re low!
    • Sunscreen your back well 😉 but don’t over-sunscreen the adhesive on sites and sensors!
    • Make sure your pump doesn’t get too hot while you’re out snorkeling if you leave it on the beach (cover it with something).
    • You could possibly do baggies inside a waterproof bag and take your pump/cgm/phone out into the water with you. I did that two years ago when I didn’t trust leaving my pump/receiver/phone on shore, but even with a certified waterproof bag I spent more time worrying about that than I did enjoying the snorkel. Stash your pump/gear in a backpack and cover it with a towel, or stick it in the trunk/glove compartment of your car, etc.
    • Remember CGMs may not read right away, or may read falsely high, so fingerstick before correcting for any highs or otherwise dosing if needed.

Swimming with diabetes:

  • Same deal as the above described activities, but with less equipment/worries. Biggest things to think about are keeping your gear protected from splashes which seem more common poolside than oceanside…and remember to take your pump off, phone or receiver out of your pocket, etc. before getting in the water!

Wait, all of this has been about pump/CGM. What about closed looping? Can you #OpenAPS in the water?

    • If you don’t have your pump on (in the water), and you don’t have CGM data (in the water, because it can’t transmit there), you can’t loop. So for the most part, you don’t closed loop DURING these activities, but it can be incredibly helpful (especially afterward to make up for the missing basal insulin) to have once you get your pump back on.

However, if your CGM is reading falsely high because it’s waterlogged, you may want to set a high temporary target or turn your rig off during that time until it normalizes. And follow all the same precautions about baggies/waterproofing your rig, because unlike the pump, it’s not designed for even getting the lightest of splashes on it, so treat it like you treat your laptop. For my Hawaii trip, I often had my #OpenAPS rig in a baggie inside of my bag, so that when my pump was on and un-suspended and I had CGM data, it would loop – however, I kept a closer eye on my BGs in general, including how the loop was behaving, in the hour following water activities since I know CGM is questionable during this time.

I’m really glad I didn’t let diabetes stop me from trying scuba diving, and I hope blog posts like this help you figure out how you need to plan ahead for trying new water activites. I’m thankful for technology of pumps and CGMs and tools like #OpenAPS that make it even easier for us to go climb mountains and scuba dive while living with diabetes (although not in the same day ;)).

The only thing to fear is fear itself

(Things I didn’t realize were involved in open-sourcing a DIY artificial pancreas: writing “yes you can” style self-help blog posts to encourage people to take the first step to TRY and use the open source code and instructions that are freely available….for those who are willing to try.)

You are the only thing holding yourself back from trying. Maybe it’s trying to DIY closed loop at all. Maybe it’s trying to make a change to your existing rig that was set up a long time ago.  Maybe it’s doing something your spouse/partner/parent has previously done for you. Maybe it’s trying to think about changing the way you deal with diabetes at all.

Trying is hard. Learning is hard. But even harder (I think) is listening to the negative self-talk that says “I can’t do this” and perhaps going without something that could make a big difference in your daily life.

99% of the time, you CAN do the thing. But it primarily starts with being willing to try, and being ok with not being perfect right out of the gate.

I blogged last year (wow, almost two years ago actually) about making and doing and how I’ve learned to do so many new things as part of my OpenAPS journey that I never thought possible. I am not a traditional programmer, developer, engineer, or anything like that. Yes, I can code (some)…because I taught myself as I went and continue to teach myself as I go. It’s because I keep trying, and failing, then trying, and succeeding, and trying some more and asking lots of questions along the way.

Here’s what I’ve learned in 3+ years of doing DIY, technical diabetes things that I never thought I’d be able to accomplish:

  1. You don’t need to know everything.
  2. You really don’t particularly need to have any technical “ability” or experience.
  3. You DO need to know that you don’t know it all, even if you already know a thing or two about computers.
  4. (People who come into this process thinking they know everything tend to struggle even more than people who come in humble and ready to learn.)
  5. You only need to be willing to TRY, try, and try again.
  6. It might not always work on the first try of a particular thing…
  7. …but there’s help from the community to help you learn what you need to know.
  8. The learning is a big piece of this, because we’re completely changing the way we treat our diabetes when we go from manual interventions to a hybrid closed loop (and we learned some things to help do it safely).
  9. You can do this – as long as you think you can.
  10. If you think you can’t, you’re right – but it’s not that you can’t, it’s that you’re not willing to even try.

This list of things gets proved out to me on a weekly basis.

I see many people look at the #OpenAPS docs and think “I can’t do that” (and tell me this) and not even attempt to try.

What’s been interesting, though, is how many non-technical people jumped in and gave autotune a try. Even with the same level of no technical ability, several people jumped in, followed the instructions, asked questions, and were able to spin up a Linux virtual machine and run beta-level (brand new, not by any means perfect) code and get output and results. It was amazing, and really proved all those points above. People were deeply interested in getting the computer to help them, and it did. It sometimes took some work, but they were able to accomplish it.

OpenAPS, or anything else involving computers, is the same way. (And OpenAPS is even easier than most anything else that requires coding, in my opinion.) Someone recently estimated that setting up OpenAPS takes only 20 mouse clicks; 29 copy and paste lines of code; 10 entries of passwords or logins; and probably about 15-20 random small entries at prompts (like your NS site address or your email address or wifi addresses). There’s a reference guide, documentation that walks you through exactly what to do, and a supportive community.

You can do it. You can do this. You just have to be willing to try.

Autotune (automatically assessing basal rates, ISF, and carb ratio with #OpenAPS – and even without it!)

What if, instead of guessing needed changes (the current most used method) basal rates, ISF, and carb ratios…we could use data to empirically determine how these ratios should be adjusted?

Meet autotune.

What if we could use data to determine basal rates, ISF and carb ratio? Meet autotune

Historically, most people have guessed basal rates, ISF, and carb ratios. Their doctors may use things like the “rule of 1500” or “1800” or body weight. But, that’s all a general starting place. Over time, people have to manually tweak these underlying basals and ratios in order to best live life with type 1 diabetes. It’s hard to do this manually, and know if you’re overcompensating with meal boluses (aka an incorrect carb ratio) for basal, or over-basaling to compensate for meal times or an incorrect ISF.

And why do these values matter?

It’s not just about manually dosing with this information. But importantly, for most DIY closed loops (like #OpenAPS), dose adjustments are made based on the underlying basals, ISF, and carb ratio. For someone with reasonably tuned basals and ratios, that’s works great. But for someone with values that are way off, it means the system can’t help them adjust as much as someone with well-tuned values. It’ll still help, but it’ll be a fraction as powerful as it could be for that person.

There wasn’t much we could do about that…at first. We designed OpenAPS to fall back to whatever values people had in their pumps, because that’s what the person/their doctor had decided was best. However, we know some people’s aren’t that great, for a variety of reasons. (Growth, activity changes, hormonal cycles, diet and lifestyle changes – to name a few. Aka, life.)

With autosensitivity, we were able to start to assess when actual BG deltas were off compared to what the system predicted should be happening. And with that assessment, it would dynamically adjust ISF, basals, and targets to adjust. However, a common reaction was people seeing the autosens result (based on 24 hours data) and assume that mean that their underlying ISF/basal should be changed. But that’s not the case for two reasons. First, a 24 hour period shouldn’t be what determines those changes. Second, with autosens we cannot tell apart the effects of basals vs. the effect of ISF.

Autotune, by contrast, is designed to iteratively adjust basals, ISF, and carb ratio over the course of weeks – based on a longer stretch of data. Because it makes changes more slowly than autosens, autotune ends up drawing on a larger pool of data, and is therefore able to differentiate whether and how basals and/or ISF need to be adjusted, and also whether carb ratio needs to be changed. Whereas we don’t recommend changing basals or ISF based on the output of autosens (because it’s only looking at 24h of data, and can’t tell apart the effects of basals vs. the effect of ISF), autotune is intended to be used to help guide basal, ISF, and carb ratio changes because it’s tracking trends over a large period of time.

Ideally, for those of us using DIY closed loops like OpenAPS, you can run autotune iteratively inside the closed loop, and let it tune basals, ISF, and carb ratio nightly and use those updated settings automatically. Like autosens, and everything else in OpenAPS, there are safety caps. Therefore, none of these parameters can be tuned beyond 20-30% from the underlying pump values. If someone’s autotune keeps recommending the maximum (20% more resistant, or 30% more sensitive) change over time, then it’s worth a conversation with their doctor about whether your underlying values need changing on the pump – and the person can take this report in to start the discussion.

Not everyone will want to let it run iteratively, though – not to mention, we want it to be useful to anyone, regardless of which DIY closed loop they choose to use – or not! Ideally, this can be run one-off by anyone with Nightscout data of BG and insulin treatments. (Note – I wrote this blog post on a Friday night saying “There’s still some more work that needs to be done to make it easier to run as a one-off (and test it with people who aren’t looping but have the right data)…but this is the goal of autotune!” And as by Saturday morning, we had volunteers who sat down with us and within 1-2 hours had it figured out and documented! True #WeAreNotWaiting. :))

And from what we know, this may be the first tool to help actually make data-driven recommendations on how to change basal rates, ISF, and carb ratios.

How autotune works:

Step 1: Autotune-prep

  • Autotune-prep takes three things initially: glucose data; treatments data; and starting profile (originally from pump; afterwards autotune will set a profile)
  • It calculates BGI and deviation for each glucose value based on treatments
  • Then, it categorizes each glucose value as attributable to either carb sensitivity factor (CSF), ISF, or basals
  • To determine if a “datum” is attributable to CSF, carbs on board (COB) are calculated and decayed over time based on observed BGI deviations, using the same algorithm used by Advanced Meal Asssit. Glucose values after carb entry are attributed to CSF until COB = 0 and BGI deviation <= 0. Subsequent data is attributed as ISF or basals.
  • If BGI is positive (meaning insulin activity is negative), BGI is smaller than 1/4 of basal BGI, or average delta is positive, that data is attributed to basals.
  • Otherwise, the data is attributed to ISF.
  • All this data is output to a single file with 3 sections: ISF, CSF, and basals.

Step 2: Autotune-core

  • Autotune-core reads the prepped glucose file with 3 sections. It calculates what adjustments should be made to ISF, CSF, and basals accordingly.
  • For basals, it divides the day into hour long increments. It calculates the total deviations for that hour increment and calculates what change in basal would be required to adjust those deviations to 0. It then applies 20% of that change needed to the three hours prior (because of insulin impact time). If increasing basal, it increases each of the 3 hour increments by the same amount. If decreasing basal, it does so proportionally, so the biggest basal is reduced the most.
  • For ISF, it calculates the 50th percentile deviation for the entire day and determines how much ISF would need to change to get that deviation to 0. It applies 10% of that as an adjustment to ISF.
  • For CSF, it calculates the total deviations over all of the day’s mealtimes and compares to the deviations that are expected based on existing CSF and the known amount of carbs entered, and applies 10% of that adjustment to CSF.
  • Autotune applies a 20% limit on how much a given basal, or ISF or CSF, can vary from what is in the existing pump profile, so that if it’s running as part of your loop, autotune can’t get too far off without a chance for a human to review the changes.

(See more about how to run autotune here in the OpenAPS docs.)

What autotune output looks like:

Here’s an example of autotune output.

OpenAPS autotune example by @DanaMLewis

Autotune is one of the things Scott and I spent time on over the holidays (and hinted about at the end of my development review of 2016 for OpenAPS). As always with #OpenAPS, it’s awesome to take an idea, get it coded up, get it tested with some early adopters/other developers within days, and continue to improve it!

A big thank you to those who’ve been testing and helping iterate on autotune (and of course, all other things OpenAPS). It’s currently in the dev branch of oref0 for anyone who wants to try it out, either one-off or for part of their dev loop. Documentation is currently here, and this is the issue in Github for logging feedback/input, along with sharing and asking questions as always in Gitter!

 

 

Automating “wake up” mode with IFTTT and #OpenAPS to blunt morning hormonal rises

tl;dr – automate a trigger to your #OpenAPS rig to start “wake up” mode (or “eating soon”, assuming you eat breakfast) without you having to remember to do it.

Yesterday morning, I woke up and headed to my desk to start working. Because I’m getting some amazing flat line overnights now, thanks to my DIY closed loop (#OpenAPS), I’m more attuned to the fact that after I wake up and start moving around, my hormones kick in to help wake me up (I guess), and I have a small BG rise that’s not otherwise explained by anything else. (It’s not a baseline basal problem, because it happens after I wake up regardless of it being 6am or 8am or even 10:30am if I sleep in on a weekend. It’s also more pronounced when I feel sleep deprived, like my body is working even harder to wake me up.)

Later in the morning, I took a break to jot down my thoughts in response to a question about normal meal rises on #OpenAPS and strategies to optimize mealtimes. It occurred to me later, after being hyper attuned to my lunch results, that my morning wake-up rise up from 1oo perfectly flat to ~140 was higher than the 131 peak I hit after my lunchtime bowl of potato soup.

Hmm, I thought. I wish there was something I could do to help with those morning rises. I often do a temporary target down to 80 mg/dL (a la “eating soon” mode) once I spot the rise, but that’s after it’s already started and very dependent on me paying attention/noticing the rise.

I also have a widely varied schedule (and travel a lot), so I don’t like the idea of scheduling the temp target, or having recurring calendar events that is yet another thing to babysit and change constantly.

What I want is something that is automatically triggered when I wake up, so whether I pop out of the bed or read for 15 minutes first, it kicks in automatically and I (the non-morning person) don’t have to remember to do one more thing. And the best trigger that I could think of is when I end Sleep Cycle, the sleep tracking app I use.

I started looking online to see if there was an easy IFTTT integration with Sleep Cycle. (There’s not. Boo.) So I started looking to see if I could stick my Sleep Cycle data elsewhere that could be used with IFTTT. I stumbled across this blog post describing Sleep Cycle -> iOS Apple HealthKit -> UP -> Google Spreadsheet -> Zapier -> Add to Google Calendar. And then I thought I would add another IFTTT trigger for when the calendar entry was added, to then send “waking up” mode to #OpenAPS. But I don’t need all of the calendar steps. The ideal recipe for me then might be Sleep Cycle ->  iOS Health Kit -> UP -> IFTTT sends “waking up mode” -> Nightscout -> my rig. However, I then learned that UP doesn’t necessarily automatically sync the data from HealthKit, unless the app is open. Hmm. More rabbit holing. Thanks to the tweet-a-friend option, I talked to Ernesto Ramirez (long time QS guru and now at Fitabase), who found the same blog post I did (above) and when I described the constraints, then pointed me to Hipbone to grab Healthkit sleep data and stuff it into Dropbox.

(Why Sleep Cycle? It is my main sleep tracker, but there’s IFTTT integration with Fitbit, Jawbone Up, and a bunch of other stuff, so if you’re interested in this, figure out how to plug your data into IFTTT, otherwise follow the OpenAPS docs for using IFTTT to get data into Nightscout for OpenAPS, and you’ll be all set. I’m trying to avoid having to go back to my Fitbit as the sleep tracker, since I’m wearing my Pebble and I was tired of wearing 2 things. And for some reason my Pebble is inconsistent and slow about showing the sleep data in the morning, so that’s not reliable for this purpose. )

Here’s how I have enabled this “wake up” mode trigger for now:

  1. If you’re using Sleep Cycle, enable it to write sleep analysis data to Apple HealthKit.
  2. Download the Hipbone app for iPhone, connect it with your Dropbox, and allow Hipbone to read sleep data from HealthKit.
  3. Log in or create an account in IFTTT.com and create a recipe using Dropbox as the trigger, and Maker as the action to send a web request to Nightscout. (Again, see the OpenAPS docs for using IFTTT triggers to post to Nightscout, there’s all kinds of great things you can do with your Pebble, Alexa, etc. thanks to IFTTT.) To start, I made “waking up” soon a temporary target to 80 for 30 minutes.

Guess what? This morning, I woke up, ended sleep cycle, and ~10-11 minutes later got notifications that I had new data in Dropbox and checked and found “waking up” mode showing in Nightscout! Woohoo. And it worked well for not having a hormone-driven BG rise after I started moving around.

First "waking up" mode in #OpenAPS automation success

Ideally, this would run immediately, and not take 10-11 minutes, but it went automatically without me having to open Hipbone (or any other app), so this is a great interim solution for me until we find an app that will run more quickly to get the sleep data from HealthKit.

We keep finding great ways to use IFTTT triggers, so if you have any other cool ones you’ve added to your DIY closed loop ecosystem, please let me know!

Sick days solved with a DIY closed loop #OpenAPS

Ask me about the time I got a norovirus over Thanksgiving.

As expected, it was TERRIBLE. Even though the source of the norovirus was cute, the symptoms aren’t. (You can read about the symptoms from the CDC if you’ve never heard of it before.)

But, unexpectedly, it was only terrible on the norovirus symptoms front. My BGs were astoundingly perfect. So much so that I didn’t think about diabetes for 3 days.

Let me explain.

Since I use an OpenAPS DIY closed loop “artificial pancreas”, I have a small computer rig that automatically reads my CGM and pump and automatically adjusts the insulin dosing on my pump.

OpenAPS temp basal adjustments during day 2 norovirus November 2016
Showing the net basal adjustments made on day 2 of my norovirus – the dotted line is what my basals usually are, so anything higher than that dotted line is a “high” temp and anything lower is a “low” temp of various sorts.
  • When I first started throwing up over the first 8 hours, as is pretty normal for norovirus, I first worried about going low, because obviously my stomach was empty.

Nope. I never went lower than about 85 mg/dl. Even when I didn’t eat at all for > 24 hours and very little over the course of 5 days.

  • After that, I worried about going high as my body was fighting off the virus.

Nope. I never went much higher than a few minutes in the 160s. Even when I sipped Gatorade or gasp, ate two full crackers at the end of day two and didn’t bolus for the carbs.

  • The closed loop (as designed – read the OpenAPS reference design for more details) observed the rising or dropping BGs and adjusted insulin delivery (using temporary basal rates) up or down as needed. I sometimes would slowly rise to 150s and then slowly head back down to the 100s. I only once started dropping slowly toward the 80s, but leveled off and then slowly rose back up to the 110s.

None of this (\/\/\/\/\) crazy spiking and dropping fast that causes me to overreact.

No fear for having to force myself to drink sugar while in the midst of the worst of the norovirus.

No worries, diabetes-wise, at all. In fact, it didn’t even OCCUR to me to test or think about ketones (I’m actually super sensitive and can usually feel them well before they’ll register otherwise on a blood test) until someone asked on Twitter.

Why this matters

I was talking with my father-in-law (an ER doc) and listening to him explain how anti-nausea medications (like Zofran) has reduced ER visits. And I think closed loop technology will similarly dramatically reduce ER visits for people with diabetes when sick with things like norovirus and flu and that sort of thing. Because instead of the first instance of vomiting causing a serious spiral and roller coaster of BGs, the closed loop can respond to the BG fluctuations in a safe way and prevent human overreaction in either direction.

This isn’t what you hear about when you look at various reports and articles (like hey, OpenAPS mentioned in The Lancet this week!) about this type of technology – it’s either general outcome reports or traditional clinical trial results. But we need to show the full power of these systems, which is what I experienced over the past week.

I’m reassured now for the future that norovirus, flu, or anything else I may get will likely be not as hard to deal with as it was for the first 12 years of living with diabetes when getting sick. That’s more peace of mind (in addition to what I get just being able to safely sleep every night) that I never expected to have, and I’m incredibly thankful for it.

(I’m also thankful for the numerous wonderful people who share their stories about how this technology impacts their lives – check out this wonderful video featuring the Mazaheri family to see what a difference this is making in other people’s lives. I’m so happy that the benefits I see from using DIY technology are available to so many other people, too. At latest count, there are (n=1)*174 other people worldwide using DIY closed loop technology, and we collectively have over half a million real-world hours using closed loop technology.)

What we heard and saw at #DData16 and #2016ADA

As mentioned in the previous post, we had the privilege of coming to New Orleans this past weekend for two events – #DData16 and the American Diabetes Association Scientific Sessions (#2016ADA). A few things stuck out, which I wanted to highlight here.

At #DData16:

  • The focus was on artificial pancreas, and there was a great panel moderated by Howard Look with several of the AP makers. I was struck by how many of them referenced or made mention of #OpenAPS or the DIY/#WeAreNotWaiting movement, and the need for industry to collaborate with the DIY community (yes).
  • I was also floored when someone from Dexcom referenced having read one of my older blog posts that mentioned a question of why ??? was displayed to me instead of the information about what was actually going on with my sensor. It was a great reminder to me of how important it is for us to speak up and keep sharing our experiences and help device manufacturers know what we need for current and future products, the ones we use every day to help keep us alive.
  • Mark Wilson gave a PHENOMENAL presentation, using a great analogy about driving and accessing the dashboard to help people understand why people with diabetes might choose to DIY. He also talked about his experiences with #OpenAPS, and I highly recommend watching it. (Kudos to Wes for livestreaming it and making it broadly available to all – watch it here!) I’ve mentioned Mark & his DIY-ing here before, especially because one of his creations (the Urchin watchface) is one of my favorite ways to help me view my data, my way.
  • Howard DM’ed me in the middle of the day to ask if I minded going up as part of the patient panel of people with AP experiences. I wasn’t sure what the topic was, but the questions allowed us to talk about our experiences with AP (and in my case, I’ve been using a hybrid closed loop for something like 557 or so days at this point). I made several points about the need for a “plug n play” system, with modularity so I can choose the best pump, sensor, and algorithm for me – which may or may not be made all by the same company. (This is also FDA’s vision for the future, and Dr. Courtney Lias both gave a good presentation on this topic and was engaged in the event’s conversation all day!).

At #2016ADA:

  • There needs to be a patient research access program developed (not just by the American Diabetes Association for their future Scientific Sessions meetings, but at all scientific and academic conferences). Technology has enabled patients to make significant contributions to the medical and scientific fields, and cost and access are huge barriers to preventing this knowledge from scaling. At #2016ADA, “patient” is not even an option on the back of the registration form. Scott and I are privileged that we could potentially pay for this, but we don’t think we should have to pay ($410 for a day pass or $900 for a weekend pass) so much when we are not backed by industry or an academic organization of any sort. (As a side note, a big thank you to the many people who have a) engaged in discussion around this topic b) helped reach out to contacts at ADA to discuss this topic and c) asked about ways to contribute to the cost of us presenting this research this weekend.)
  • We presented research from 18 of the first 40 users of #OpenAPS. You can find the FULL CONTENT of our findings and the research poster content in this post on OpenAPS.org. We specifically posted our content online (and tweeted it out – see this thread) for a few reasons:
    • First, everything about #OpenAPS is open source. The content of our poster or any presentation is similarly open source.
    • Not everyone had time to come by the poster.
    • Not everyone has the privilege or funds to attend #2016ADA, and there’s no reason not to share this content online, especially when we will likely get more knowledge sharing as a result of doing so.
  • With the above in mind, we encouraged people stopping by to take whatever photos of our poster that they wanted, and told them about the content being posted online. (And in fact, in addition to the blog post about the poster, that information is now on the “Outcomes” page on OpenAPS.org.)
  • Frustratingly, some people were asked to take down posted photos of our poster. If anyone received such a note, please feel free to pass on my tweet that you have authorization by the authors to have taken/used the photo. This is another area (like the need to develop patient research access programs) that needs to be figured out by scientific/academic conferences – presenters/authors should be able to specifically allow sharing and dissemination of information that they are presenting.
  • Speaking of photos, I was surprised that around half a dozen clinicians (HCPs) stopped by and made mention of having used the picture of the #OpenAPS rig and the story of #OpenAPS in one of their presentations! I am thrilled this story is spreading, and being spread even by people we haven’t had direct contact with previously! (Feel free to use this photo in presentations, too, although I’d love to hear about your presentation and see a copy of it!)
  • We had many amazing conversations during the poster session on Sunday. It was scheduled for two hours (12-2pm), but we ended up being there around four hours and had hundreds of fantastic dialogues. Here were some of the most common themes of conversation:
    • Why are patients doing this?
      • Here’s my why: I originally needed louder alarms, built a smart alarm system that had predictive alerts and turned into an open loop system, and ultimately realized I could close the loop.
    • What can we learn from the people who are DIY-ing?
    • How can we further study the DIY closed loop community?
      • This is my second favorite topic, which touches on a few things – 1) the plan to do a follow up study of the larger cohort (since we now have (n=1)*84 loopers) with a full retrospective analysis of the data rather than just self-reported outcomes, as this study used; 2) ideas around doing a comparison study between one or more of the #OpenAPS algorithms and some of the commercial or academic algorithms; 3) ideas to use some of the #OpenAPS-developed tools (like a basal tuning tool that we are planning to build) in a clinical trial to help HCPs help patients adjust more quickly and easily to pump therapy.
    • What other pumps will work with this? How can there be more access to this type of DIY technology?
      • We utilize older pumps that allow us to send temp basal commands; we would love to use a more modern pump that’s able to be purchased on the market today, and had several conversations with device manufacturers about how that might be possible;  we’ll continue to have these conversations until it becomes a reality.
  • There is some great coverage coming of the poster & the #OpenAPS community, and I’ll post links here as I see them come out. For starters, Dave deBronkart did a 22 minute interview with Scott & I, which you can see here. DiabetesMine also included mention of the #OpenAPS poster in their conference roundup. And diaTribe wrote up the the poster as a “new now next”! Plus, WebMD wrote an article on #OpenAPS and the poster as well.

Scott and I walked away from this weekend with energy for new collaborations (and new contacts for clinical trial and retrospective analysis partnerships) and several ideas for the next phase of studies that we want to plan in partnership with the #OpenAPS community. (We were blown away to discover that OpenAPS advanced meal assist algorithm is considered by some experts to be one of the most advanced and aggressive algorithms in existence for managing post-meal BG, and may be more advanced than anything that has yet been tested in clinical trials.) Stay tuned for more!

Research studies and usability thoughts

It’s been a busy couple (ok, more than couple) of months since we last blogged here related to developments from #DIYPS and #OpenAPS. (For context, #DIYPS is Dana’s personal system that started as a louder alarms system and evolved into an open loop and then closed loop (background here). #OpenAPS is the open source reference design that enables anyone to build their own DIY closed loop artificial pancreas. See www.OpenAPS.org for more about that specifically.)

We’ve instead spent time spreading the word about OpenAPS in other channels (in the Wall Street Journal; on WNYC’s Only Human podcast; in a keynote at OSCON, and many other places like at the White House), further developing OpenAPS algorithms (incorporating “eating soon mode” and temporary targets in addition to building in auto-sensitivity and meal assist features), working our day jobs, traveling, and more of all of the above.

Some of the biggest improvements we’ve made to OpenAPS recently have been usability improvements. In February, someone kindly did the soldering of an Edison/Rileylink “rig” for me. This was just after I did a livestream Q&A with the TuDiabetes community, saying that I didn’t mind the size of my Raspberry Pi rig. I don’t. It works, it’s an artificial pancreas, the size doesn’t matter.

That being said… Wow! Having a small rig that clips to my pocket does wonders for being able to just run out the door and go to dinner, run an errand, go on an actual run, and more. I could do all those things before, but downsizing the rig makes it even easier, and it’s a fantastic addition to the already awesome experience of having a closed loop for the past 18 months (and >11,000 hours of looping). I’m so thankful for all of the people (Pete on Rileylink, Oscar on mmeowlink, Toby for soldering my first Edison rig for me, and many many others) who have been hard at work enabling more hardware options for OpenAPS, in addition to everyone who’s been contributing to algorithm improvements, assisting with improving the documentation, helping other people navigate the setup process, and more!

That leads me to today. I just finished participating in a month-long usability study focused on OpenAPS users. (One of the cool parts was that several OpenAPS users contributed heavily to the design of the study, too!) We tracked every day (for up to 30 days) any time we interacted with the loop/system, and it was fascinating.

At one point, for a stretch of 3 days, we counted how many times we looked at our BGs. Between my watch, 3 phone apps/ways to view my data, the CGM receivers, Scott’s watch, the iPad by the bed, etc: dozens and dozens of glances. I wasn’t too surprised at how many times I glance/notice my BGs or what the loop is doing, but I bet other people are. Even with a closed loop, I still have diabetes and it still requires me to pay attention to it. I don’t *have* to pay attention as often as I would without a closed loop, and the outcomes are significantly better, but it’s still important to note that the human is still ultimately in control and responsible for keeping an eye on their system.

That’s one of the things I’ve been thinking about lately: the need to set expectations when a loop comes out on the commercial market and is more widely available. A closed loop is a tool, but it’s not a cure. Managing type 1 diabetes will still require a lot of work, even with a polished commercial APS: you’ll still need to deal with BG checks, CGM calibrations, site changes, dealing with sites and sensors that fall out or get ripped out…  And of course there will still be days where you’re sensitive or resistant and BGs are not perfect for whatever reason. In addition, it will take time to transition from the standard of care as we have it today (pump, CGM, but no algorithms and no connected devices) to open and/or closed loops.

This is one of the things among many that we are hoping to help the diabetes community with as a result of the many (80+ as of June 8, 2016!) users with #OpenAPS. We have learned a lot about trusting a closed loop system, about what it takes to transition, how to deal if the system you trust breaks, and how to use more data than you’re used to getting in order to improve diabetes care.

As a step to helping the healthcare provider community start thinking about some of these things, the #OpenAPS community submitted a poster that was accepted and will be presented this weekend at the 2016 American Diabetes Association Scientific Sessions meeting. This will be the first data published from the community, and it’s significant because it’s a study BY the community itself. We’re also working with other clinical research partners on various studies (in addition to the usability study, other studies to more thoroughly examine data from the community) for the future, but this study was a completely volunteer DIY effort, just like the entire OpenAPS movement has been.

Our hope is that clinicians walk away this weekend with insight into how engaged patients are and can be with their care, and a new way of having conversations with patients about the tools they are choosing to use and/or build. (And hopefully we’ll help many of them develop a deeper understanding of how artificial pancreas technology works: #OpenAPS is a great learning tool not only for patients, but also for all the physicians who have not had any patients on artificial pancreas systems yet.)

Stay tuned: the poster is embargoed until Saturday morning, but we’ll be sharing our results online beginning this weekend once the embargo lifts! (The hashtag for the conference is #2016ADA, and we’ll of course be posting via @OpenAPS and to #OpenAPS with the data and any insights coming out of the conference.)