diabetes

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

by Dana Lewis

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!

Autosensitivity (automatically adjusting insulin sensitivity factor for insulin dosing with #OpenAPS)

by Dana Lewis

There’s a secret behind why #OpenAPS was able to deal so well with my BGs during norovirus. Namely, “autosensitivity”.

Autosensitivity (or “autosens”, for short hand) is an advanced feature that can optionally be enabled in OpenAPS.

We know how hard it is for a PWD (person with diabetes) to pay attention to all the numbers and all the things and realize when something is “off”. This could be a bad pump site, a pump site going bad, hormones from growth, hormones from menstrual cycles, sensitivity from exercise the day before, etc. So at the beginning of the year, Scott and I started brainstorming with the community about automatically detecting when the PWD is more or less sensitive to insulin than normal, and adjusting accordingly. Building on the success we’d had in DIYPS with fixed “sensitivity” and “resistance” modes, we built the feature to assess how sensitive or resistant the body is (compared to normal), rather than just a binary mode that sets a predefined response.

How OpenAPS calculates autosensitivity/how it works

It looks at each BG data point for the last 24 hours and calculates the delta (actual observed change) over the last 5 minutes. It then compares it to “BGI” (blood glucose impact, which is how much BG *should* be dropping from insulin alone), and assesses the “deviations” (differences between the delta and BGI).

When sensitivity is normal and basals are well tuned, we expect somewhere between 45-50% of non-meal deviations to be negative, and the remaining 50-55% of deviations should be positive. (To exclude meal-related deviations, we exclude overly large deviations from the sample.) So if you’re outside of that range, you are probably running sensitive or resistant, and we want to adjust accordingly. The output of the detect-sensitivity code is a single ratio number, which is then used to adjust both the baseline basal rate as well as the insulin sensitivity factor (and, optionally, BG targets).

Autosens is designed to detect to food-free downward drift, due to basal rates being too high for the current state of the body, and will adjust basals downward to compensate. The other meal-assist related portion of the algorithms do a pretty good job of dealing with larger than expected post-meal spikes due to resistance: auto-sensitivity mostly comes into play for resistance when you’re sick or otherwise riding high even without food.

Does this calculate basals?

No. Similar to everything else in OpenAPS, this works from your established basals – meaning the baseline basal rates in your pump are what the sensitivity calculations are adjusting from. If you run a marathon and your sensitivity is normally 40, it might adjust your sensitivity to 60 (meaning 1u of insulin would drop your BG an expected 60mg/dl instead of 40 mg/dl) and temporarily adjust your baseline basal rate of 1u to .6u/hour, for example.

This algorithm is simply saying “there’s something going on, let’s adjust proportionately to deal with the lower-than-usual or higher-than-usual sensitivity, regardless of cause”. It easily detects “your basals are too high and/or your ISF is too low” or “your basals are too low and/or your ISF is too high”, but actually differentiating between the effect of basal and ISF is a bit more difficult to do with a simple algorithm like this, so we’re working on a number of new algorithms and tools (see “oref0 issue 99” for our brainstorming on basal tuning and the subsequent issues linked from there) to tackle this in the future.

#OpenAPS’s autosensitivity adjustments during norovirus

After I got over the worst of the norovirus, I started looking at what OpenAPS was calculating for my sensitivity during this time. I was especially curious what would happen during the 2-3 days when I was eating very little.

My normal ISF is 40, but OpenAPS gradually calculated the shift in my sensitivity all the way to 50. That’s really sensitive, and in fact I don’t remember ever seeing a sensitivity adjustment that dramatic – but makes sense given that I usually don’t go so long without eating. (Usually when I notice I’m a little sensitive, I’ll check and see that autosens has been adjusting based on an estimated 43 or so sensitivity.)

And in later days, as expected when sick, I shifted to being more resistant. So autosens continued to assess the data and began adjusting to an estimated sensitivity of 38 as my body continued fighting the virus.

—

It is so nice to have the tools to automatically make these assessments and adjustments, rather than having to manually deal with them on top of being sick!

 

Half life

by Dana Lewis

I have now lived with diabetes for more than half of my life.

That also means I have now lived less than half of my life without diabetes.

This somehow makes the passing of another year living with diabetes seem much more impactful to me. Maybe not to you, or to someone else with a different experience of living with diabetes and a different timeline of life before and after diagnosis…but to me this is a big one.

I’m happy to have context, though, to help me keep things in perspective. For example, I’ve now lived with a closed loop artificial pancreas (or automated insulin delivery) system for almost two full years.

(That’s almost as significant a marker of a “with” vs. “without” comparison as living “with” vs. “without” diabetes.)

And because I ended up with type 1 diabetes, I found out that doing things for other people and the communities you’re a part of is a powerful way to help yourself, both in the short term and the long term. That’s what drove me to figure out a way to take #DIYPS closed loop and make it something open source. And by doing that, I learned so much more about open source, and have been able to partner with incredible people innovating in hardware and software. These collaborations have resulted in an incredibly rich community of passionate people I like to call #OpenAPS-ers.

While #OpenAPS is by no means a cure, and no artificial pancreas will be a cure, they provide an immeasurably improved quality of life that a lot of us didn’t realize was possible with diabetes. Someone told me he can get the same results for his child living with diabetes, but with #OpenAPS it requires about 85% less work. And given the enormous time and cognitive burden of diabetes, this is a HUGE reduction.

And now doors are opening for us collectively to make even more of a significant impact on the diabetes community, and our fellow patient communities. Yesterday, while at the White House Frontiers conference, NIH Director Dr. Francis Collins was in the audience during my panel. At the end of the day, he stopped me to ask questions about my experiences and perspective on the FDA and what we need from the government. I was able to talk with him about the need for FDA & other parts of the government to help foster and support open source innovation. We talked about the importance of data access for patients, and the need for data visibility on commercially approved medical devices.

Showing former NIH Director Francis Collins my OpenAPS rig and talking about data interoperability.

This is not just a need of people with diabetes (although it’s certainly very applicable for all of the manufacturers with pipelines full of artificial pancreas products): these are universal needs of people dealing with serious health conditions.

Given what I heard yesterday, it’s working. The #WeAreNotWaiting spirit is infusing our partners in these other areas. We are planting seeds, building relationships, and working in collaboration with those at the FDA, NIH, HHS in addition to those in industry and academia. I know they were working toward these same goals before, but social media has helped raise up our collective voices about the burning need to make things better, sooner, for more people.

So if I have to live the rest of my life at a ratio where more than half of it has been spent living with diabetes, I look forward to continuing to work to get to an 85% reduction in the burden of daily life with diabetes for everyone.

 

What a FDA approved commercial hybrid closed loop artificial pancreas system (670G) means for #OpenAPS

by Dana Lewis

You probably heard that a commercial hybrid closed loop (the 670G) has been approved by the U.S. FDA and, like everyone else, are wondering what that means for #OpenAPS.

First commercial AID finally became available in 2016

First, here’s our initial reaction:

Thoughts-on-commercial-AID-DanaMLewis

And here are some longer form thoughts:

  • Yes, this is exciting. FDA moved months more quickly then expected (hmm, we are sensing a theme when the #WeAreNotWaiting community is involved ;)) to get this tech approved. And as we’ve experienced (check out this self-reported outcomes study with better outcomes than the pivotal trial for this new device), the results of using a hybrid closed loop are outstanding. It’s disappointing that they won’t be ready to ship until Spring 2017, but…
  • …This means the company has time to work on user guides and usability. As we’ve told every device company we’ve encountered, we (the #OpenAPS community) are happy to share everything we’ve learned. And we have learned a lot, including what it takes to trust a system, how much info is needed to help determine if additional human action is needed, what to do in all kinds of real-world situations, and more. We hope the companies continue to work with people with diabetes who have experience with this technology from both clinical trials and the DIY world, where we’ve racked up 350,000+ hours with this type of technology. Because setting expectations with users for this technology will be key for successful and sustained adoption.

This doesn’t really mean anything for #OpenAPS, though. The first generation of AP technology is similar to #OpenAPS in that it’s a hybrid closed loop that still requires the human to input carbs into the system, but it unfortunately has a set point that can not be adjusted below 120mg/dl.  For many people, this is not a big deal. But for others, this will be a deal breaker. For DIYers, that lack of customization will likely be frustrating. And for many families, the lack of remote data visualization may be another deal breaker. And, like with all new technology and devices, getting this stuff covered by insurance may be an uphill battle. So while optimistically this enables many people in the U.S. to finally access this technology (yay) without having to DIY, it won’t necessarily be truly available to everyone from a cost or access perspective for many years to come. So #OpenAPS and other DIY technology may still be needed from a cost/access perspective to continue to help fill gaps compared to current status quo with basic, non-connected diabetes devices (i.e. standalone pump and CGMs).

I also know that many of the parents of kids with T1D are disappointed, because the initial approval is for kids 14+, and it even notes that the system is not recommended for kids <7 or those taking less than 8u of insulin every day (usually young kids). I asked, suspecting it was related to occlusion, but it sounds more like they just don’t have enough data to say for sure that the system is safe with that small amount of insulin, and they’re working on additional studies to get data in that area.

Ditto, too, for more studies allowing different set points. They stuck with a 120mg/dl set point in order to speed to approval, but fingers crossed they get other studies done and new approvals from FDA before this device ships in the spring – that would be awesome. And I was glad to hear that they do have an “exercise” target of 150. That’s a bit of good…but I’m still hesitant that it is enough. From my personal experience knowing net IOB (here’s why net IOB matters) an hour before and when starting exercise is required information to help me decided whether or not I will need carbs to prevent lows during exercise. I don’t think this device will report on net IOB, but I admittedly haven’t seen the device and hopefully I’ll be proved wrong and the data available will be good enough for this purpose!

So in summary: this is good news. But we still need more FDA approved commercial options, and even with a single “commercial approved option”, it’s still ~6+ months away from reaching the hands of people with diabetes…so we as a #WeAreNotWaiting movement continue to have work to do to help speed up the processes for getting enhanced diabetes technology approved and available on the market, with access to view data the ways we need it.

—

*(Yes, in the title of the post I called it a commercial hybrid closed loop artificial pancreas system. It’s a hybrid closed loop, as is #OpenAPS, but it’s also on the road/part of the suite of more complex artificial pancreas technology. I realize to many PWDs “artificial pancreas” means a lot of different things. Quite certainly, regardless of definition, an artificial pancreas or hybrid closed loop still requires a lot of work. It’s not a cure by any stretch of the imagination. But it’s easy for the media to describe it as an AP, and I also find it a lot easier to describe the small device accompanying my pump when strangers ask as an “artificial pancreas” followed by an explanation rather than saying “hybrid closed loop”.

If anything, I think having the media broadly categorize it as an AP will encourage the diabetes community to ask more questions about what exactly this tech does, leading to greater understanding and better expectations about what the device will/won’t be able to do. So this may result in a good thing.)

Old news alert: FDA is monitoring the DIY community

by Dana Lewis
There was a news article today that got a lot of people to react strongly. In that sense, the article did it’s job, to get people talking. But that doesn’t mean it got all the details right, as an insider to the DIY community would know.

What am I talking about?

There was an article posted today in “Clinical Endocrinology News” with the titillating headline of “FDA Official: We’re monitoring DIY artificial pancreas boom”.

Guess what, though? This is NOT news. We’ve been talking to the FDA, and they’ve in fact been “monitoring” us (especially if monitoring includes reading this blog, DIYPS.org ;)) since the summer of 2014, before we even turned our eyes toward closing the loop. Definitely since we, while they were in the room at a D-Data in 2015, announced we would close the loop. And even more so after we closed the loop and then decided to go the #OpenAPS route and find a way to make closed loop technology open source. And others from the community, like Ben West, have been talking with the FDA for even longer than we have.

What the article got right:

Recently at AADE, Courtney Lias from FDA (who gave a similar presentation at D-Data a month ago) gave a presentation talking about AP technology. She addressed both how the FDA is looking at the DIY community (they believe that they have enforcement discretion, even though no one in the DIY community is distributing a medical device, which is legally where FDA has it’s jurisdiction) and how it’s looking at the commercial vendors with products in the pipeline.

Courtney highlighted questions for CDE’s to ask patients of theirs who may be bringing up (or bringing in) DIY closed loops. They are good questions – they’re questions we also recommend people ask themselves and are a critical part of the safety-first approach the DIY community advocates every day.

(It was not mentioned in this article, but Aaron Kowalski’s presentation at AADE also highlighted some critical truths that I think are key about setting and managing expectations regarding closed looping. I often talk about these in addition to pointing out that it should be a personal, informed choice in choosing to closed loop. I hope these points about setting expectations and our points about the stages of switching from standard diabetes tool to closed looping becomes a bigger part of the conversation about closed loop safety and usability in the future.)

Where the article linked together some sentences that caused friction today:

The end of the article had a statement along the lines of an FDA concern about what happens if an AP breaks and you have a newly diagnosed person who doesn’t have old school, manual diabetes methods to fall back on. The implication appeared to be that these concerns were solely about the DIY looping “boom”. However, we know from previous presentations that Courtney/FDA usually brings this up as a concern for commercial/all AP technology – this isn’t a “concern” unique to DIY loops.

And that’s the catch – all of the concerns and questions FDA has, the DIY community has, too!

In fact, we want FDA to ask the same questions of commercial vendors, and we are going to be reaching out to the FDA to ask how they will ensure that we, as patients, can ask and get answers to these questions as end users when the FDA is approving this technology.

Because that’s the missing piece.
Right now, with the current technology on the market, we don’t get answers or insight into how these systems and devices work. This is even MORE critical when we’re talking about devices that automate insulin delivery, as the #OpenAPS community has learned from our experiences with looping. Getting the right level of data access and visibility is key to successful looping, and we expect the same from the commercial products that will be coming to market – so the FDA has a role to play here.

What we can do as a result
And we have a role, too. We’ll play our part by communicating our concerns and questions directly to the FDA, which is the only way they can officially respond or react or adjust what they’re doing. They unfortunately can’t respond to tweets. So I’m drafting an email to send to FDA, which will include a compilation of many of the questions and concerns the community has voiced today (and previously) on this topic.

Moving forward, I hope to see others do the same when concerns and questions come up. You don’t need to work for a commercial manufacturer, or be a part of a formal initiative, in order to talk to the FDA. Anyone can communicate with them! You can do that by sending an email, submitting a pre-submission, responding to draft guidances, and more. And we can all, in our informal or formal interactions, ask for clarity and push for transparency and set expectations about the features and products we want to see coming from commercial manufacturers.

Why you should post that in Gitter

by Dana Lewis

“You should post that question in Gitter.” –something @DanaMLewis says a lot

I realize it’s not always obvious to those who are newer to #WeAreNotWaiting or #OpenAPS why I am often pointing people to ask their questions in Gitter.

Let me explain:

There is a Gitter chat channel where most of the #OpenAPS and other DIY development conversations happens. (There are several other channels, so if you pop onto the main OpenAPS one, we’re happy to point you to another if there’s another one already built for another or related project.)

Gitter connects with Github, so you can use the same username to log in and ask a question. And very importantly, it’s public, so *anyone* can see the conversations in channel – even if you decide not to log in. See for yourself – click here to view the chat channel. This is very key for an open source project: anyone can jump in and check things out.

Transparency & archiving community knowledge
It also means that questions can be asked – and answered – openly, so that when someone has the same question, they can often find an existing answer with a little bit of searching.

(Tip: there’s a Gitter app for your phone, and for your desktop, both of which I use on the go – but for searching back in the channel, the web Gitter interface has a better search experience, or you can also use Google to search through the archives.)

Faster responses from a smarter, broader, worldwide community
There’s another key reason why asking a question in an open channel is helpful for Q&A. Two words: time zones. There are now (n=1)*104+ people around the world with DIY closed loops, and a lot of them pay it forward and provide guidance and also help answer questions.

If you send one individual a question in a private channel, you have to cross your fingers and hope they’re a) awake b) not working and c) otherwise available to respond.

But if you ask your question openly in a public channel, anyone out of the large community with the answer can jump in and answer more quickly. Given that we have a worldwide community and people across many time zones, this means faster answers and more “ah-ha’s” as people collaboratively work through new and already-documented-sticky-points in the build process.

So if you ask an individual a question in a private channel, you might get a “You should ask that in Gitter!” response. And this is why. :) You’re welcome as always to ping me across any channel, but often when there’s a good question, I’m going to want you to re-post in Gitter, anyway, so people can benefit from having the knowledge (including any answers from the community) archived for the next person who has the same or similar question.
4 reasons to post OpenAPS questions in Gitter

Our take on how to DIY closed loop, safely

by Dana Lewis
You will often see similar growth and evolution cycles across any type of online community, and the closed loop community is following this growth cycle as expected. Much like how Nightscout went from one very hard way to setup to get your CGM data in the cloud, to ultimately having dozens of DIY options and now more recently, multiple commercial options, closed looping is following similar trends. OpenAPS was the first open source option for people who wanted to DIY loop, and now there are a growing number of ways to build or run closed loops! And next year, there should be at least one commercial option publicly available in the U.S. followed by several more options in 2018 on the commercial market. Awesome! This is exactly the progress we were hoping to see, and facilitate happening more quickly, by making our work & encouraging others to make their work open source.

We’ve learned a lot (from building our own closed loop and watching others do so through OpenAPS) that we think is relevant to anyone who pursues DIY closed looping, regardless of the technology option they choose. This thought process and approach will likely also be relevant to those who switch to a closed loop commercial option in the future, so we wanted to document some of the thought process that may be involved.

Approaching closed looping safely

Before considering closed looping, people should know:

  • A (hybrid or even full) closed loop is not a cure. There will be a learning curve, much like switching to a pump for the first time.
  • Even after you get comfortable with a closed loop, there will still sometimes be high or low BGs, because we are still dealing with insulin that peaks in 60-90 minutes; we’ll still get kinked pump sites or pooled insulin; and we’ll still have hormones that drive our BGs up and down very rapidly in ways we can’t predict, but must react to. Closed looping helps a lot, but there’s still a lot that goes into managing diabetes.

Before using a DIY closed loop, people should consider:

  • Identifying or creating the method to visualize their data in a way they are comfortable with, both for real-time monitoring of loop activity and retrospective monitoring. This is a key component of DIY looping.
  • Running in “open loop” mode, where the system provides recommendations and you spend days or weeks analyzing and comparing those recommendations to how you would calculate and choose to take action manually.
  • Based on watching the “open loop” suggestions, decide your safety limits: you should set max basal and bolus rates, as well as max net IOB limits where relevant. Start conservative, knowing you can change them over time as you watch and validate how a particular DIY loop works with your body and your lifestyle.

Getting started with a DIY closed loop, people should think about the following:

  • Understand how it works, so you know how to fix it. Remember, by pursuing a DIY closed loop, you are responsible for it and the operation of it. No one is forcing you to do this; it’s one of many choices you can and will make with regards to how you personally choose to manage your diabetes.
  • But even more importantly, you need to understand how it works so you can choose if you need to step in and take manual action. You should understand how it works so you can validate “this is what it should be doing” and “I am getting the output and outcomes that I would expect if I were doing this decision making manually”.
  • Often, people will get frustrated by diabetes and take actions that the loop then has to compensate for. Or they’ll get lax on when they meal bolus, or not enter carbs into the system, etc. You will get much better results by putting better data into the system, and also by having a better understanding of insulin timing in your body, especially at meal times. Using techniques like “eating soon mode” will dramatically help anyone, with or without a closed loop, reduce and limit severity of meal spikes. Ditto goes for having good CGM “calibration hygiene” (h/t to Pete for this phrase) and ensuring you have thought about the ramifications of automating insulin dosing based on CGM data, and how you may or may not want to loop if you doubt your CGM data. (Like “eating soon”, ‘soaking’ a CGM sensor may yield you better first day results.)
  • Start with higher targets for the loop than you might correct to manually.
  • Move first from an “open loop” mode to a “low glucose suspend” type mode first, where max net IOB is 0 and/or max basal is set at or just above your max daily scheduled basal, so it low temps to prevent and limit lows, but does not high temp above bringing net IOB back to 0.
  • Gradually increase max net IOB above 0 (and/or increase max basal) every few days after several days without low BGs; similarly, adjust targets down 10 points for every few days gone without experiencing low BGs.
  • Test basic algorithms and adjust targets and various max rates before moving on to testing advanced features. (It will be a lot easier to troubleshoot, and learn how a new feature works, if you’re not also adjusting to closed looping in its entirety).
This is our (Dana & Scott‘s) take on things to think about before and when pursuing a closed loop option. But there’s about a hundred others running around the world with closed loops, too, so if you have input to share with people that they should consider before looping, leave a comment below! :) And if you’re looking to DIY closed loop before a commercial solution is available, you might also be interested in checking out the OpenAPS Reference Design and some FAQs related to OpenAPS.

OpenAPS poster cited in Nature!

by Dana Lewis

I was thrilled to read a commentary by John Wilbanks and Eric Topol, out in Nature today, titled “Stop the privatization of health data“. (Click here to read a PDF version of the article.)

Tucked on the bottom of the second page of the (PDF version of the) article:

“For instance, in 2014, a woman with type 1 diabetes wired together a tiny processor, an insulin pump and a continuous glucose monitor to automate the regulation of her blood sugar levels. For a small community of patients, the collective use of such ‘home-made’ systems has resulted in improvements that are well ahead of those provided by devices and interventions emerging from conventional markets.1”

(The citation is to the poster that we presented on behalf of the #OpenAPS community at the American Diabetes Association Scientific Sessions meeting last month, with self-reported outcomes from 18 of the first 40 users and builders of DIY artificial pancreas systems)

OpenAPS (n=1)*98 as of July 19, 2016It’s worth noting that there are now (n=1)*98 users of #OpenAPS, so this “small community” is growing fast: doubling approximately every three months.

Wilbanks and Topol highlight some critical truths in their commentary, and call out another (frustrating) diabetes example to illustrate:

“Although patients can monitor their glucose levels at any instant, their aggregate records are not made accessible to them. And there is no mechanism by which patients or researchers outside the company can gain access to Medtronic’s tens of thousands of measurements.”

I’ve written about this specific example before, in fact: new ‘partnerships’ mean my personal health data is likely shared with IBM for Watson’s usage…but I don’t have access to this data or insights, and am in fact missing critical information and data visualization on my FDA-approved medical device that’s been on the market for years.

The call to action for device manufacturers, regulators, and the medical industry is simple: Give me, the patient, my data that I need so I can safely take care of myself and better manage my diabetes.

Wilbanks and Topol emphasize that this won’t happen “…unless each of us takes responsibility for our own health and disease, and for the information that we can generate about ourselves. When it comes to control over our own data, health data must be where we draw the line.”

This needs to happen everywhere, not just in diabetes. Will you join us in drawing the line?

Picture this: How to do “eating soon” mode

by Dana Lewis

How do you prevent or limit meal spikes? It doesn’t take a closed loop artificial pancreas; it takes an understanding of insulin timing and the impact on your body.

I’ve written before about why getting insulin going in your body before meal carbs kick in is so important. You can read that really long post here. And I’ve written a slightly shorter post explaining how to do “eating soon mode” to achieve insulin activity peaking when you eat, without causing lows. But recently, I quickly scratched together an illustration to show the difference in the timing and outcomes between the “eating soon mode” approach compared to a traditional “pre-bolus” approach, and after receiving feedback that these images were helpful, decided to post them here.

(Again, for more context, read this post on how to calculate your eating soon amount; and this post for more of the science behind it and how we discovered this method 2+ (!) years ago. And as always, your diabetes may vary; I’m not a doctor; etc. but this is something that when applied consistently smooths out meal spikes, even when eating high fat or high protein or high carb or any kind of meal.)

What often happens with a pre-bolus of the meal insulin 15 minutes before a meal
What often happens with a pre-bolus of the meal insulin 15 minutes before a meal

 

The type of meal spike (minimal) you can achieve by getting insulin activity going 1 hour before the meal with "eating soon" mode approach
The type of meal spike (minimal) you can achieve by getting insulin activity going 1 hour before the meal with “eating soon” mode approach.

*Note – the calculation of (TargetBG-80)/ISF is assuming that you have already corrected to your normal target, i.e. 100 or 120.

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

by Dana Lewis

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.
A picture of our #ADA2016 poster in the exhibit hall

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!