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.
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.
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.
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.
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:
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.
Coming soon: once this code rolls out to master, there will be additions to the OpenAPS documentation to reflect more about this feature and how to enable it
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!
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.
General tips for water activities when living with diabetes:
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.
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.
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).
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.
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.
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 ;)).
(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:
You don’t need to know everything.
You really don’t particularly need to have any technical “ability” or experience.
You DO need to know that you don’t know it all, even if you already know a thing or two about computers.
(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.)
You only need to be willing to TRY, try, and try again.
It might not always work on the first try of a particular thing…
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.
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?
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.
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!
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:
If you’re using Sleep Cycle, enable it to write sleep analysis data to Apple HealthKit.
Download the Hipbone app for iPhone, connect it with your Dropbox, and allow Hipbone to read sleep data from HealthKit.
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.
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!
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.
#OpenAPS balanced BGs during a stomache bug flawlessly. Never low, never high. Even w no boluses for sips of Gatorade and the like. Amazing.
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.
3 days of hardly any food when dealing w/ norovirus. Mind blowing for daily avg BG ranges to be 108-113 with 92-97% time in range. #OpenAPS
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.)
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.
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.
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!).
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.)
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.
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!
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.)
This post was written months ago for Prescribe Design, and will also be posted/made available there as a collection of their stories by and about patients who design, but I am also posting here for anyone new to #DIYPS and/or wondering about how #OpenAPS came into existence.
About the author: Dana Lewis is the creator of #DIYPS, the Do-It-Yourself Pancreas System, and a founder of the #OpenAPS movement. (Learn more about the open source artificial pancreas movement at OpenAPS.org.) Dana can be found online at @DanaMLewis, #DIYPS, and #OpenAPS on Twitter, and also on LinkedIn.
Diabetes is an invisible illness that’s not often noticeable, and may be considered to be “easy” compared to other diseases. After all, how hard can it be to track everything you eat, check your blood glucose levels, and give yourself insulin throughout the day?
What most people don’t realize is that managing diabetes is an extremely complex task; numerous variables influence your blood glucose levels throughout the day, from food to activity to sleep to your hormones. Some of these things are easier to measure than others, and some are easier to influence than others, as I’ve learned over the past 13 years of living with type 1 diabetes.
Diabetes technology certainly helps – and those of us with access to insulin pumps and continuous glucose monitors are thankful that we have this technology to better help us manage our disease. But this technology is still not a cure. After I run a marathon, my blood sugar is likely to run low overnight for the next few nights. And the devices I use to help me manage still have major flaws.
For example, my continuous glucose monitor (CGM) gives me a reading of my blood glucose every 5 minutes – but I have to pay attention to it in order to see what is going on (pulling the device from my pocket and pressing a button to see my numbers). And what happens when I go to sleep? I am sleeping, rather than paying attention to my blood sugar.
Sure, you can set alarms, and if your blood glucose (BG) goes above or below your personal threshold, an alarm will sound. That’s great, unless you’re a sound sleeper like me who doesn’t always hear these sounds in my sleep – and unfortunately there’s no way on the device to make the alarms louder.
For years, I worried every night when I went to sleep that I would have a low blood sugar, not hear the alarm, and not wake up in the morning. And since I moved across the country for work, and lived by myself, it could potentially be hours before someone realized I didn’t show up for work, and days before someone decided to check on me inside my apartment.
I was worried about “going low” overnight, and I kept asking the device manufacturers for louder alarms. The manufacturers usually responded, “the alarms are loud enough, most people wake up to them!” This was frustrating, because clearly I’m not one of those people.
I realized that if only I could get my CGM data off my device in real-time, I could make a louder alarm by using my phone or my laptop instead of having to rely on the existing medical device volume settings. It would be as easy as using a basic service like IFTTT or an app like “Pushover” that allows you to customize alerts on an iPhone.
However, for the longest time, I couldn’t get my data off of my device. (In fact, for years I had NO access to my own medical device data, because the FDA-approved software only ran on Windows computers, and I had a Mac.) But in November 2013, I by chance found someone who tweeted about how had managed to get his son’s data off the CGM in real-time, and he was willing to share his code with me. And this changed everything.
(At the time, my continuous glucose monitor only had FDA-approved software that could be used on a Windows computer. Since I had a Mac, when my endocrinologist asked for diabetes data, I took a picture with my iPhone and pasted the images into Excel, and printed it out for him. Data access is an ongoing struggle.)
My design “ah-ha” became a series of “wow, what if” statements. At every stage, it was very easy to see what I wanted to do next and how to iterate, despite the fact that I am not a designer and I am not a traditional engineer. I had no idea that within a year I would progress from making those louder alarms to building a full hybrid closed loop artificial pancreas (one that would auto-adjust the levels on my insulin pump overnight).
Once I had my CGM data, I originally wanted to be able to send my data to Scott (my then-boyfriend and now husband, who lived 20 miles away at the time) to see, but I didn’t want him to get alarms any time I was merely one point above or below my target threshold. What was important for him to know was if I wasn’t responding to alarms. We set up the system so that Scott could see whether or not I was taking action on a low reading, which I signaled by pressing a button. If the system alerted to Scott that I was not responding to a low reading, he could call and check on me, drive 20 miles to see me, or call 911 if necessary. (Luckily, he never needed to call 911 or come over, but within a week of building the first version of the system, he called me when my blood sugar was below 60 and I hadn’t woken up yet to the alarms.)
I realized next that if I was already pushing a button on the web interface (pictured), I might as well add three buttons and show him what action I was taking (more insulin, less insulin, or eating carbohydrates) in case I accidentally did the wrong thing in my sleep. I also customized the system so that I could log exactly how much insulin I was taking or how much I was eating.
Because I was entering every action I took (insulin given, any food eaten), we realized that this data could fuel real-time predictions and give precise estimates of where my blood sugar would be 30, 60, or 90 minutes in the future. As a result, I could see where my blood glucose level would be if I didn’t take action, and make sure I didn’t overcorrect when I did decide to take action. This was helpful during the day, too. The CGM has alarm thresholds that notify you if you cross the line; but #DIYPS will predict ahead of time that I am likely to go out of range, and will recommend action to help prevent me from crossing the threshold.
The system worked great and generated many alarms that woke me up at night. (Ironically, we generated so many alarms that Scott would periodically change the sound of the alarm without telling me, because my body would get used to ignoring the same sound over time!) The next step was deciding to get a smart watch (in my case, a Pebble) so I could see my data on my watch, and reduce the amount of time I spent pulling my CGM receiver out of my pocket and pressing the button to turn the screen on. With a watch, it was also easier to see real-time push alerts that the system would send me to tell me to take action. As a result, I was able to begin to spend less time throughout the day worrying about my blood sugar, and more time living my life while the system ran in the background, updating every few minutes and alerting me as to when I needed to pay attention when something changed.
People often ask what my health care provider thinks. He didn’t appear very interested in hearing about this system when I first mentioned it, but he was glad to hear I was having positive outcomes with it.
More significantly, I had a lot of other people with diabetes interested in it and wanting to know how they could get it.
As a patient, I can only design tools and technology for myself; but because it would be seen by the FDA as a class III medical device (and making dosing recommendations from a CGM rather than a blood glucose meter, which the CGM is not approved for), I can not distribute it to other people to use as it would have to first be reviewed and regulated by the FDA.
We also kept iterating on #DIYPS and the algorithms I use to predict when my blood sugar is going to end up high or low. By the time we made it to November of 2014, we realized that we had a well-tested system that did an excellent job giving precise recommendations of adjusting insulin levels. If only we had a way to talk to my insulin pump, we theorized that we could turn it into a fully closed loop artificial pancreas – meaning that instead of only allowing my insulin pump to give me a pre-determined amount of insulin throughout the night, a closed loop system would instead take into account my blood sugar and make the automatic needed adjustments to give me more or less insulin as needed to keep me in range.
With the help of Ben West, another developer we met while working on Nightscout, who has spent years working on tools to communicate with diabetes devices, we were able to take a carelink USB stick and use it to communicate with my insulin pump. Plugged into a raspberry pi (a small, pocket sized computer), the carelink USB stick could pull from our algorithms, read from the pump, write commands (in the form of temporary basal rates for 30 minutes), read back the results, update the algorithm and generate new predictions and action items, and then do the same process over and over again.
And so, with the help of various community members, we had closed the loop with our artificial pancreas. And once I had it turned on, testing, and working, it was hard to convince me to take it off. This was December of 2014. More than a year and a half later, I’m still wearing and using it every day and night.
There are definitely challenges to having self-designed a device. There are usability issues, such as the burden of keeping it powered and extra supplies to haul around. But as a patient, and as the designer, I can constantly iterate and make improvements to algorithms or the device setup itself and make it better as I go, all while having the benefit of this lifesaving technology (and more importantly, having the peace of mind to be able to go to sleep safely at night).
And, I have the ability to communicate and spread the word that this type of DIY technology is possible. I frequently talk with others who are interested in building their own artificial pancreas system as part of the OpenAPS movement. Like #DIYPS, I can’t give away an #OpenAPS implementation or build someone else an artificial pancreas. But through #OpenAPS, the community has collectively published a reference design, documentation and code, and established a community to support those who are choosing to do an n=1 implementation, following the reference design we have shared. As of the beginning of May 2016, there have been a total of 56+ people who have decided to close the loop by building individual OpenAPS implementations, with more in progress. You can read more here about the risks and how it is a personal decision to decide to build your own system; each person has to decide if the work to DIY and the risk is worth the potential reward.
For me, this definitely has been and is worth the time and effort. It’s worth noting that I am glad there are traditionally designed devices going into clinical trials and are in the pipeline to be made available to more people. But the timeline for this is years away (2017-2018), so I am also glad that the technology (including social media to enable our community to connect and design new tools together) is where it is today.
You don’t have to be an engineer, or formally trained, to spot a problem with disease management or quality of life and build a solution that works for you. Who knows – the solution that works for you may also work for other people. We can design the very tools we need to make our lives with diabetes, and other diseases, so much better – and we shouldn’t wait to do so.