What is #DIYPS (Do-It-Yourself Pancreas System)?

#DIYPS (the Do-It-Yourself Pancreas System) was created by Dana Lewis and Scott Leibrand in the fall of 2013.

#DIYPS was developed with the goal of solving a well-known problem with an existing FDA-approved medical device. As recounted here (from Scott) and here (from Dana), we set out to figure out a way to augment continuous glucose monitor (CGM) alerts, which aren’t loud enough to wake heavy sleepers, and to alert a loved one if the patient is not responding.

We were able to solve those problems and include additional features such as:

  •  Real-time processing of blood glucose (BG), insulin on board, and carbohydrate decay
  •  Customizable alerts based on CGM data and trends
  •  Real-time predictive alerts for future high or low BG states (hours in advance)
  •  Continually updated recommendations for required insulin or carbs
  • ..and as of December 2014, we ‘closed the loop’ and have #DIYPS running as a closed loop artificial pancreas.

You can read this post for more details about how the system works.

While #DIYPS was invented for purposes of better using a continuous glucose monitor (CGM) and initially tailored for use with an insulin pump, what we discovered is that #DIYPS can actually be used with many types of diabetes technology. It can be utilized by those with:

  • CGM and insulin pump
  • CGM and multiple daily injections (MDI) of insulin
  • no CGM (fingerstick testing with BG meter) and insulin pump
  • no CGM (fingerstick testing with BG meter) and multiple daily injections (MDI) of insulin

Here are some frequently asked questions about #DIYPS:

  1. Q:I love it. How can I get it?A: Right now, #DIYPS is n=1, and because it is making recommendations based on CGM data, we can’t publicly post the code to enable someone else to utilize #DIYPS.But, you can get Nightscout, which includes all of the publicly-available components of #DIYPS, including the ability to upload Dexcom CGM data, view it on any web browser and on a Pebble watch, and get basic alarms for high and low BG. We’re working to further develop #DIYPS, and also to break out specific features and make them available in Nightscout as soon as possible.
  2. Q: “Does #DIYPS really work?”A: Yes! For N=1, we’ve seen some great results. Click here to read a post about the results from #DIYPS after the first 100 days – it’s comparable to the bionic pancreas trial results. Or, click here to read our results after using #DIYPS for a full year.
  3. Q: “Why do you think #DIYPS works?”A: There could be some correlation with increased timed/energy spent thinking about diabetes compared to normal. (We’d love to do some small scale trials comparing people who use CGMs with easy access to time-in-range metrics and/or eAG data, to compare this effect). And, #DIYPS has also taught us some key lessons related to pre-bolusing for meals and the importance of having insulin activity in the body before a meal begins. You should read 1) this post that talks about our lessons learned from #DIYPS; 2) this post that gives a great example of how someone can eat 120 grams of carbohydrates of gluten-free pizza with minimal impact to blood glucose levels with the help of #DIYPS; and 3) this post that will enable you to find out your own carbohydrate absorption rate that you can start using to help you decide when and how you bolus/inject insulin to handle large meals. And of course, the key reason #DIYPS works is because it reduces the cognitive load for a person with diabetes by constantly providing push notifications and real time alerts and predictions about what actions a person with diabetes might need to consider taking. (Read more detail from this post about the background of the system.)
  4. Q:Awesome!  What’s next?A: We’re working on new features for DIYPS, of course.  Those include:
    • better real-time BG readings using raw unfiltered sensor values
    • calculation of insulin activity and carb absorption curves (and from there, ISF & IC ratios, etc.) from historical data
    • better-calibrated BG predictions using those calculated absorption curves (with appropriate error bars representing predictive uncertainty)
    • recommendations for when to change basal rates, based on observed vs. predicted BG outcomes
    • integration with activity tracking and calendar data
    • closing the loop – done as of December 2014! :)

    We also are starting to collaborate with medical technology and device companies, the FDA, and other projects and organizations like Tidepool, to make sure that the ideas, insights, and features in #DIYPS get integrated as widely as possible. Stay tuned (follow the #DIYPS hashtagDana Lewis & Scott Leibrand on Twitter, and keep an eye on this blog) for more details about what we’re up to.

  5. Q: “I love it. What can I do to help the #DIYPS project?”A: We’d love to know if you’re interested in helping! First and foremost, if you have any ability to code (or a desire to learn), we need contributors to the Nightscout project.  There are many things to work on, including implementing the most broadly applicable #DIYPS features into Nightscout, so we need as many volunteers, with as many different types of skills, as we can get.  For those who are less technical, the CGM in the Cloud Facebook group is a great place to start. Click here to see the Nightscout project roadmap; it shows what developers are currently working on, what each of our priority focus areas are (as of 11/26/14), and the ‘backlog’ of projects we know we want (and the community wants), but no one has started on yet (jump on in!).
    If you want to contact us directly, you can reach out to us on Twitter (@DanaMLewis @ScottLeibrand and #DIYPS) or email us ([email protected] and [email protected]). We’d also love to know if you’re working on a similar project or if you’ve heard of something else that you think we should look into for a potential #DIYPS feature or collaboration.

Dana Lewis & Scott Leibrand

The power of visualizing your data, your way

Sometimes, it’s the little things that make a big difference – even little glimpses of data, or little improvements to ways that you can control the way you access and view your data (and generate alarms).

For example, I recently had a conversation with a few people in the #WeAreNotWaiting community about the different watch faces that exist for displaying CGM data; and about how much I like my #DIYPS watch face. A few reasons why:

  • It’s a little more discreet than some watch faces showing BG data, so the average person won’t glance at my watch and see a large number.
  • It pulls from the #DIYPS interface, so I can see what I’m predicted to be, and any current recommendations (such as carbs, temp basal, or bolus needed).

It’s data-heavy, but I like having all this information without having to pull my CGM out and run calculations in my head; or pull out my phone and pull up a web page to #DIYPS; etc.

One of the many cool things about the #WeAreNotWaiting community is how together we have learned and created so many new ways to visualize our data, on various devices (tablets, phones, smart watches) and various size screens. And so when I hear that someone’s not wanting a smart watch, or isn’t using it for diabetes related things, sometimes I think it’s a matter of them finding the right tools to build their own display that works for them. Several times a week I hear about various people working on new, interesting DIY diabetes projects, and it’s awesome that we have tech to improve the tools we have – and excellent social media channels to communicate about these projects.

Related to that, I wanted to share an update – recently Milos, Jason, and others have done some really amazing work to visualize basal rates in Nightscout. (If you use Nightscout, you can get this in the 0.8.2 release – see here for more details.) This means it also can pull in temporary basal rates that are used in #OpenAPS, so you can get a nice visual showing the adjusted basal rate compared to normal scheduled basal rates – and see why it might be needed – on top of display of BG data and everything else that Nightscout offers.

In this example, it also shows how OpenAPS deals with compression drops, or how it might react to other flukey data. Remember, we designed OpenAPS to only enact 30 minute temporary basal rates in a way that is the safest possible thing to do, even if it loses communication. But if it keeps communication, and the system sees a drop and a return to the normal pattern from before (see visual), it can counteract a low temp with higher temp, or vice versa.

The visualization of temp basals in Nightscout (another example here) is an excellent improvement over how I previously used to check and see what OpenAPS had been doing. I have a watchface (similar to the above #DIYPS one) that shows me what the loop is doing currently, but when I wake up in the morning, I was mostly using a basic screen like the below to see the positive, negative, and net temp basal rates on an hourly basis and comparing that to my CGM graph to get an understanding of what happened.

Visualizing basal rates in Nightscout is a seemingly minor change, but every time we make a change like this that allows me to contextualize all of my data in one place (on a single glanceable watchface; or on the Nightscout screen); it saves a few seconds or minutes that add up to a lot of time saved every day, week, month, and additional year that I’m dealing with diabetes – a big win.

Building diabetes technology is like building a mountain bike

I’ve had the opportunity to meet some fantastic people through our work with #DIYPS and #OpenAPS, one of whom is Eric Von Hippel, an MIT professor and researcher who work on user innovation. He shared a great example of user innovation that I was previously unfamiliar with, but is an awesome parallel for what we in the diabetes community are doing.

History: bike manufacturers used to make bikes for riding on flat surfaces. Some people wanted to ride their bikes down mountains, but existing bikes weren’t too comfortable (they didn’t have spring-based seats – ouch!). So, bikers started customizing and modifying the bikes they had. Eventually, bike manufacturers saw the demand and started building mountain bikes with the same features that the original mountain bikers had used. (And if you don’t like my paraphrased version of this story, Wikipedia is always your friend!)

The parallels:

We in the diabetes community have seen a series of needs that are not being met with our existing, FDA approved medical devices that are out on the market. From not-loud-enough alarms to not enabling us to track critical information like temporary basal rate history on the pump itself, these are the needs that drove me (and Scott) to first build #DIYPS and then to close the loop. At the same time, the need for remote data access is what drove John Costik and then the other Nightscout founders and developers to build an amazing, community-based open source tool to enable real-time remote data sharing.

Are there commercial products coming to market or are in the market that meet some of these needs now? Sure. But remember, I’ve had diabetes since 2002. In 2013, when Scott and I first started working to solve my need for louder alarms, there was NO commercial solution available for either remote data access or alarm customization. Thus the need for #DIYPS, which we built in 2013, and Nightscout, which blossomed in early 2014. And even though tools like Dexcom SHARE and MiniMed Connect have come to market (and in some cases, more quickly with help from the community communicating to the FDA about the critical importance of these tools), they came in 2015, which is a long time to wait for new tools when you’re dealing with diabetes 24/7/365. And when we managed to close the loop, again with help from the amazing #wearenotwaiting community, in December of 2014? Well, it’s now nearing the end of a year (and with amazing continued results from #OpenAPS not just for me, but for 13 additional people and potentially more to come soon), and we are AT LEAST a year and a half, if not more, away from any commercial device to reach the market. Not to mention: I’m not sure that the first generation of closed loops commercially available will be good enough for me.

The commercial entities are getting there. And, I always want to give them credit – I have a closed loop, but I can’t have one without a solidly working insulin pump and an excellent CGM system. They are, for the most part (with the exception of some missing features), making good, solid safe products for me to use.

The manufacturers are also starting to be open to more conversations. Not just “listening”, which they’ve sort-of/maybe done in drips over the past, but actual two-way conversations where we can share the needs that we know of in the community, and discuss what can be incorporated into their commercial product pipeline more quickly. This is progress starting to be made, and I’m excited to see more of it. It seems like there is a refreshed mindset and energy in the industry, as well as an understanding that we all care deeply about safety and that we’re all in this together to make life with diabetes less of a burden – like riding downhill on a mountain bike rather than a road bike.

“Should I build an artificial pancreas?” (It’s a personal question)

Given that many (7 almost 8!) of us have closed the loop with OpenAPS, and sometimes show pictures of great overnights like the below, and given the fact that diabetes is a complicated, annoying, unfair disease, there is a lot of interest in closing the loop. Scott and I definitely get that, which is why we started the #OpenAPS movement.

I have been asked more and more lately, “Are you going to make this available to less tech-savvy people?” and “Should I build one?”.

The answer to the first question is emotionally hard, because a DIY build of a medical device that auto-adjusts insulin will always involve some technical knowledge – or at the very least, a growth mindset and willing to learn many new things to build a technical knowledge in order to proceed through the murky process of building a not-100%-documented artificial pancreas. You don’t have to be a programmer or an engineer; but you do have to have time and energy to spend learning as well as doing. I say this every day: the DIY part is important.

(And, I know people always want to hear “yes! It’ll be out on X date, and just as easy as installing Nightscout.” But it’s not as easy as installing something like Nightscout and never will be.)

That leads into the second question as an explanation of why it’s not as easy as we would wish:

Even if you have a very technical background, you’ll still spend time learning new languages, new pieces of software, and building pieces of your own. Things will break, things will need to be improved, and you need to have the knowledge of what’s going on and understand the logic of what you’re trying to achieve at each stage in order to be able to troubleshoot both the code part of things and the diabetes part of things.

It is hard. And it is a lot of work.

What you don’t see when someone says they’ve (DIY) closed the loop:

For every “I had such a great night” picture someone posts, that probably represents at least (10?+) hours of working on building or troubleshooting their system. Scott and I have each spent hundreds of hours working with my system, from trouble shooting, to building in new features, to reaffirming that things are all working as planned, etc. That figure should be a bit lower for new people as a result of our efforts, but it will never be as easy as just plugging something in, giving it your weight, and letting it take over. The system only does what you program it to do.

I often say this is “not a set-and-forget” system. And this is also true in the wearability of it. Right now, I use a Raspberry Pi and Carelink USB stick to communicate with my pump. They’re great, but the separate power source I also have to keep charged, plus keeping the USB in range of my pump, plus making sure it’s all working, can be a headache sometimes. (Which is why I’m so glad we made an offline mode, to reduce one of the biggest headaches of using the system.) When I’m on the go during the day, sometimes I don’t take it with me, or I choose to stop and un-power it and resume it when I get home. At this point, I wouldn’t be surprised if most people use it for nighttime use only (at least for the most part). But even with nighttime use only, there’s still constant changing of the code (in some cases daily), tweaking, altering, fixing, breaking, and un-breaking various parts.

Did I mention it was a lot of work?

And does a closed loop prevent all lows and highs? No.

It’s important to realize this is not a cure. I work really hard to do eating soon mode before meals to prevent spikes from the amount of carbs I choose to eat. I still have to test my blood sugar and calibrate my CGMs multiple times a day. I still have to change out my pump site every 2-3 days, and deal with the normal hassles of wonky pump sites, etc. I still have some highs – although the loop helps me handle them and I spend less time above range. And I still have some lows – although usually they’re from human error related to bolusing, the loop helps prevent them from always being a true low and/or blunting the drop so I don’t require as much correction. But diabetes is still a good amount of work, even with a closed loop.

Is it worth it to self-build an artificial pancreas?

This is a personal question. It’s a lot of work, with risk involved.

For me, I have decided and continue to decide that it’s worth it.

But only you can decide if the work and the risk are worth the potential rewards for you.

Does the FDA care more about safety than people with diabetes do?

Today my inbox was suddenly flooded with links to a video with some commentary about artificial pancreas technology at a conference by a representative of the U.S. FDA. The implication many people are getting after watching the video clip is that this FDA representative is implying that people are being unsafe by building their own artificial pancreas. He mentions it is consumer prerogative to build an artificial pancreas – which is correct. The implication of his analogy is that changing your car and killing yourself is similar to a DIY artificial pancreas effort.

The scary takeaway from the video, in my opinion, as well as other public comments in the past, is the implication that the FDA cares more about the potential harms of taking action than the almost certain harms of inaction. And it’s increasingly frustrating that the FDA appears to imply publicly that those of us in the #wearenotwaiting community are doing things unsafely as a result of taking action.

Safety is what drives the #wearenotwaiting movement. In my case, I refuse to sleep another night with the fear that I won’t wake up in the morning because there’s not an FDA-approved system on the market that will wake me up if my life is in danger, let alone a system that can take action and change the situation to be more safe. So I built my own (#DIYPS), because the current FDA-approved CGM devices were not (and still are not) loud enough to wake me up at night, putting me at risk of dying in my sleep. And yes, it ultimately turned into an artificial pancreas – with the same goal of ensuring I wake up every morning, safely (alive). That is my prerogative for sure.

But I fail to see why the FDA, which collectively has no particular knowledge of these systems (especially as they have no jurisdiction, acknowledged on all fronts, over what I do myself – it’s my prerogative), is making public statements implying that these types of systems are categorically unsafe.

As a matter of fact, every DIY system I’ve seen is safer than the FDA-approved standard of care available for people with diabetes. The thousands of people using Nightscout, which is currently a DIY remote view-only monitoring system? Provides more safety and security for people with diabetes, not to mention it is helping achieve better outcomes for people with diabetes than they were able to achieve before with the standard of diabetes care as it exists today. (This was originally for the most part because of restricted access to data, although while that has improved there’s still interoperability issues getting access to real-time data in the same place from the 3+ average devices a person with diabetes uses…unless they have Nightscout or another DIY tool running.) The dozens of people working on their DIY version of an artificial pancreas system (many of whom are collaborating and sharing data in the #OpenAPS community)? These systems are safer than the standard of care, which is to let an insulin pump continue to overdose you if you are dangerously low while you sleep.

(You can see some of my personal data from #DIYPS, before we closed the loop, here and more about outcomes after we closed the loop and had #OpenAPS here. My closed loop artificial pancreas system continues to work excellently nine plus months in, and you can continue to watch my outcomes as I post them to Twitter regularly using the #DIYPS and #OpenAPS hashtags. I’ve also shared the other powerful lessons that DIY tech has helped me learn about diabetes care that helps all people with diabetes, regardless of technology.)

Are there risks to DIY efforts? Yes. But there’s risks to living with diabetes regardless. And as a person with diabetes, I am well aware of the risks that I choose to take. Diabetes is a disease in which you carry around large amounts of a lethal drug in your pocket that you are supposed to inject daily in order to save your life. As a person with diabetes, we are nothing but aware of the multitude of risks of living with this chronic disease 24/7/365.

In fact, even without a DIY artificial pancreas system, I am at risk every day simply from using my FDA-approved insulin pump that does not accurately track how much insulin I am given. (Read more here about how most insulin pumps on the market calculate IOB only from boluses, and often do not provide a record let alone incorporate any temporary adjustments to your basal rates and do not in any case track the impact of suspending your pump completely.)

And as someone who has founded the #OpenAPS movement, with the goal of an open and transparent effort to make safe and effective basic Artificial Pancreas System (APS) technology widely available to more quickly improve and save as many lives as possible and reduce the burden of type 1 diabetes…..we approach it with safety first in mind, and is a big part of why the DIY part is critical and is a part of our number one priority of safety.

Not everyone will choose to go the DIY route. In fact, most people do not and I am told all the time “Oh, I would never do that.” And that’s fine! Everyone can choose what they want for themselves.

But technology has made it increasingly feasible for those of us who want to improve our own safety to do so, because the industry and the FDA are not moving quickly enough to meet our needs.

That, indeed, is our prerogative – to increase our own safety.

#DIYPS and the wedding

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





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

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

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

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

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

It didn’t show.


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

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

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

We like this trend.

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

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

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

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

It’s all working well.

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

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

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

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

Context – give me my data (on my device)

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

My initial reaction:

Additional context:

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

None, at all.

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

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

No record at all.

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

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

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

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


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

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

This is backwards.

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

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

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


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

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

This is not ok.

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

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

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

“Making” and “DIY”ing – continued

I had a conversation this week with someone in the CGM in the Cloud Facebook group, after they indicated they wouldn’t be (or maybe weren’t interested in) joining the “dev” group for #OpenAPS – and it’s a conversation I find myself having often. Here’s what I usually end up saying, when someone says they’re not a “dev” or “not an engineer” or something similar:

“I’m not a formally trained developer/coder/engineer, either… but I keep telling people, many people in this project aren’t- it’s a passion project where we learn what we need to learn to do the things we want to do. It’s fine if someone chooses not to do something, but I encourage everyone to not let labels or perceptions of traditional roles stop them from jumping in and giving it a try to see what they can learn and thus do! Especially with this awesome supportive community of people willing to help you as you go.”

This also came up when we were discussing what it takes to be a “maker” on TEDMED’s #GreatChallenges live panel today. One of my excellent fellow panelists (Cole) pointed out that pretty much everyone is a maker – whether you tweak a recipe, work with wood, or find any kind of workaround of any sort to make things work. (Which in my mind makes every single person with diabetes a “maker” and probably anyone with any disease or health care condition that they live with.)

I previously wrote about what it takes to DIY from a DIYPS and #OpenAPS perspective (and why that’s important), but I think it holds true across any aspect of diabetes or any other disease state – and definitely beyond healthcare:

So please, don’t let labels stop you from DOING. You can learn whatever tech skills you set your mind to. You can find numerous ways to solve a problem, whether it’s on your own or by partnering with someone else – and there’s plenty of people with the skills who are willing to help you learn, too.Remember, we started building #DIYPS to make louder CGM alarms. Scott and I have both learned numerous new things and new programming languages and skills along the way as we went from alarms to an alert and recommendation system to a closed loop artificial pancreas (and now people who own 4 Raspberry Pis). We didn’t come to the table with knowledge of everything we needed to know to do what we first wanted to do – and we’re definitely still learning a dozen or more things (programming languages, new software, etc.) along the way as we continue with #OpenAPS. We also didn’t know anything previously about working directly with the FDA – and now we are, on a number of projects, in order to help scale from n=1 of a DIY artificial pancreas to many n=1s around the world.

You can do this. Bring your passion, and go do great things!

#WeAreNotWaiting, are you?

Why the DIY part of OpenAPS is important

I had the chance to talk about DIYPS and OpenAPS during a demo session in DC last week. (Thank you to Gary from Quantified Self and Marty from the National Academy of Sciences for making this possible!)

I walked away with several insights:

  1. Many people don’t know about diabetes; fewer have a realization of current diabetes tech. In several cases as I was describing the closed loop artificial pancreas, people stopped me and were wowed – but not by the closed loop. They were impressed by the CGM.
  2. Others think that this type of technology is already out on the market.

So, I believe we have a long way to go in communicating and advocating for this type of technology. We know it’s behind where it should be – and we want it to catch up. That’s a big part of the OpenAPS goals to help the FDA, device companies, and everyone involved move a little faster than they might otherwise, because #WeAreNotWaiting.

But here’s the other question I was often asked: “How many people have you given this to?”

I frequently embarked on an explanation of how we can’t “give” away #DIYPS or the OpenAPS implementation – in fact, we can’t and won’t give away the code, either. Some of that is because the FDA says no – and some of it is common sense and principles that both Scott and I hold.

Here’s why I think it is so important to keep the DIY in DIYPS and each OpenAPS implementation that is in progress:

  • You need to have a deep understanding of the system before even considering using it on yourself. You need to know what it’s trying to do in all situations, including the fringe cases (the “this is unlikely to happen but if it does…”), so that you know when it’s working – and when it’s not – whether it’s 3pm in the afternoon at work, or 3am and you wake up and find something is not right and the system is not working.
  • You need to go step by step and test and ensure at each stage that it is working as expected – both in a “this is what it should be doing” and “it is giving out the correct amount of insulin”. Remember, insulin is a lethal drug. It’s also a lifesaving drug. It’s important to remember both of these things and balance the risks accordingly.

From the conversations I’ve had with people interested in learning more or getting a DIYPS-type system for themselves, they fall into two categories:

  1. “How can I buy it from you?”
  2. “What do I need to do to make one?”

Given my above reasoning, the second question is my favorite. The first one scares me, if someone does not then switch to the #2 question. Many people do go from #1 to #2, which is great.

DIYPS, for me, and OpenAPS implementations, for others, are works in progress. They’re not perfect. They’re better than what’s out there (like sleeping through alarms when you’re low at night), but they also have big risks. And it’s important to know, and respect these risks, and understand the limitations of the system, before being able to take advantage of this type of system – and to build the system with appropriate safeguards. (This is one of the reason we have OpenAPS, for example, designed to accept multiple failure points – like walking out of range, loss of connectivity, etc.)

The ability to buy a “black box” type system where you don’t know exactly how it works, but you trust that it works? That will be coming from the major device manufacturers in several years – hopefully sooner rather than later, and that’s something that OpenAPS will hopefully help make happen more quickly.

So to answer the #2 question, what do you need to make a DIYPS or OpenAPS of your own?

I’ll answer the technical aspects of this question in another post, but the first thing I always say is: “The willingness to build and test and test and test some more before ever considering using it on yourself.”

How to do “eating soon” mode – #DIYPS lessons learned

“Do you prebolus for meals with #DIYPS?”

The answer to this question is complicated for me. I don’t “prebolus” like most people do (meaning “take some or all of your meal insulin about 15 minutes before you eat”).

I do take insulin before a meal. In fact, I do it up to an hour before the meal starts, by setting my correction target BG from it’s usual range (usually 100-120) to 80. This usually means I’m usually doing anywhere from .5-1u or more of insulin prior to a meal. But the amount of insulin has no direct relationship with the total amount of carbs I’ll end up eating during the meal.

Does it work? Yes. Do I go low? No, because it is unlikely that I would get anywhere near 80 by the time my carbs kick in for a meal (15 minutes after I eat), and therefore the initial carbs are handled by that initial amount of insulin from the eating soon-bolus. (Last year, I wrote a post about “eating soon mode” under the guise of lessons learned about meal time with #DIYPS – if you want to read the reason behind WHY eating soon mode is key in more detail, you can definitely read the longer version of the post. It also links another key concept I’ve learned about called carbohydrate absorption rate.)

So, how can you manually do “eating soon” mode?

1. If you know you’re going to eat anywhere in the next hour, manually calculate a correction bolus with a target BG of 80. (Example – if your correction ratio is 1:40, and you are currently 120, that means you would give yourself 1u of insulin.) An hour, 45 minutes, 30 minutes – whatever you make work is better than not doing it!

2. Eat your meal and bolus normally, but use your IOB as part of your meal calculation so you don’t forget about that insulin you already have going. (Helpful if your pump tracks IOB and you use a bolus calculator feature, but if you take injections, keep in mind about the insulin you’ve already given for the meal – just subtract that amount (1u in above example) from what you’d otherwise inject for the meal.

Note: if you use eating soon mode, you might want to delay the last unit or two of your meal insulin until after you see BGs rise, since sometimes you need less total insulin for the meal if you get insulin active early. (Often, we PWDs may overcompensate with more insulin than we need because it’s not timed correctly compared to the carb absorption rate.)


  • 5pm – You’re planning to eat around 5:30 or 6pm. Your BG is 120 and your correction ratio is 1:40. Setting your correction target to 80, that means you take 1u of insulin.
  • 6pm – You sit down to eat. Looking at your meal, you see 45 carbs and decide, with a carb ratio of 1:10, that you would take 4.5 units for the meal. Keeping in mind your earlier bolus of 1u, you end up taking 3.5 units for the meal. (4.5 total – 1u prebolus = 3.5 more units needed to cover the meal, see above note about considering delaying a unit or two of that bolus until you see your BGs impacted by carbs).

Result? You should have less of a spike from your carbs kicking in 15 minutes after you eat. It won’t always completely eliminate a spike, but it will provide a flattening effect. This is part of how I’m able to eat large (like 120g of gluten free pizza) meals and have flat or mostly flat BGs, and this is also one of the reasons I think using #DIYPS has dramatically improved my eAG and a1cs.