I've been a Type 1 Diabetic now for nearly 25 years. The first thing that every techie does once they've been diagnosed with Diabetes is they try to solve the problem with software or hardware. Whatever tool they have, they use that too to "solve their Diabetes." Sometimes it's Excel, sometimes it's writing a whole new system. We can't help ourselves. We see the charts and graphs, we start to understand that this is a solvable problem.
However, innovation in Diabetes technology has two sides. There's the "what can we do within the medical establishment" side, and there's the "what components do I, the actual diabetic, have to work with" side. We are given insulin pumps, glucose meters, and drugs but we aren't involved in the development, which makes sense to a point.
Fifteen years ago (yes, really, 15) I went on a trip with a PalmPilot, OmniSky wireless modem, Blood sugar meter, and insulin pump and quasi-continuously sent my blood glucose numbers back to a server and my doctor. Many many years later I demonstrated on stage at a Microsoft conference (video) how a remote management system like NightScout along with other innovations in IoT are taking these concepts so much further. It's through the work of hundreds of innovators and tinkerers that I think we're on the cusp.
Aside: If you are wholly unfamiliar with how Type 1 Diabetes works, please take a moment and read Diabetes Explanation: The Airplane Analogy. This post pretty clearly explains how blood sugar rises and falls and why fixing this isn't a simple problem.
Four years ago - four years ago this week in fact - I wrote a post called The Sad State of Diabetes Technology in 2012, largely in frustration. It became one of my most popular posts. For some it was a turning point and was called "seminal." For most Diabetics, though, the post said what everyone already thought and already knew. Diabetes sucks deeply, the technology we are given to manage it sucks deeply, and we are pretty much tired of waiting. We've been told a "cure" (or at least, a mostly fool-proof way to manage it) is just 5 years out. I've been told this, personally, every year for the last 25.
Here we are four years after I wrote my angry post and I'm actually feeling like we are on the edge of something big.
I believe that now we are inside a 5 year window of time where we WILL make Type 1 Diabetes MUCH MUCH easier to deal with.
Using this generation diagram from the JDRF, it's totally clear that the open source diabetes community is making Stage 4 happen today.
Let's stop and level set for a moment. Here's a generalization of your day if you're not diabetic.
Here's what a Type 1 diabetic (like me) does:
What we need is for the "loop to be closed."
Is a Closed-Loop System for Diabetes Management like a Self-driving Car?
You know how the press just loves to call the Tesla a "Self-driving car?" It's not. I've driven one for over 15 thousand miles. It has two main features and they are both effectively cruise-control. There's the cruise control that slows down when there's a car in front of you, and then there's the "Tesla Auto-Pilot" feature. Amazing, sure, but realistically it's effectively "side to side cruise control." It will keep you in the lanes, usually, to a limit. You can't go to sleep, you shouldn't be texting. You are in charge. This isn't to minimize the amazing work that Tesla has done, but using a closed-loop insulin stages above as a parallel, a Tesla is barely stage 3 or 4.
However, this is still a fantastic innovation and for a diabetic like myself, I *would* like to take my hand off the diabetic wheel as it were, at least for the easy stuff like staying in the lanes on the freeway while going straight. Automatic basal insulin dosing (background insulin dosing) would free my mind up a LOT.
It's possible and it's happening.
What's required for a closed loop?
In order to close the loop, what are the components we need? For this simple exercise please assume that "safely and securely" applies to all of these statements.
The ability to tell an insulin pump to deliver insulin
The ability to read data from the insulin pump.
The ability to read current blood sugar from a continuous glucose meter
Some CPU or "brain" where an algorithm or controller lives to coordinate all this.
Storage, cloud or otherwise, to keep all this historical data
There are a number of issues to think about, though, if the open source community wants to solve this before the commercial companies do.
Most pump manufacturers don't like the idea of remotely controlling them after a series of insulin pump proof of concept "attacks."
This means that some systems require the use of an older pump to allow remote control. We, the community, need to encourage pump manufacturers to create pumps that allow secure remote control.
Most CGM manufacturers don't publish their specifications or like 3rd party apps or systems talking to their stuff.
We, the community, need to encourage manufacturers to create glucose meters that allow secure access to our sugar data. 'Cause it's our data.
Universal concern that someone will accidentally hurt or kill themselves or someone else.
Where should the "closed loop brain/algorithm" live? The cloud? Your phone? Another CPU in your pocket?
What happened in the Diabetes Technology Ecosystem in the last 4 years to make this possible?
The interesting part about this problem is that there are many ways to solve this. In fact, there are multiple closed loop OSS systems available now. Lots of things have made this possible.
Here's a rough timeline of the Open Diabetes Ecosystem.
Insulaudit - Ben West starts an open source driver to audit medical devices
Decoding CareLink - Driving an insulin pump with Python, Oct 2012
Decoding Dexcom - Pulling data off a Dexcom CGM 3 years ago!
CGM-Simple-Reader - Using Windows 8 DLLs from Dexcom Studio to get CGM data. Next step was uploading it somewhere!
Pebble - Being able to remotely view Nightscout Data on your wrist on a pebble.
Nightscout - Remote viewing of glucose data by pulling from a CGM and uploading to a web app. The addition of a REST API (Web API) was the killer that kick started other apps.
Parakeet Google App Engine - Gets data from The Parakeet Unit and talks to xDrip over the cell network. "OnStar for diabetes"
Nightscout Share Bridge - Takes Dexcom G5 data and copies it over to Nightscout.
xDrip - Talk to a CGM without a Receiver. Pulling the signal off the air itself. Can we improve their algorithm ourselves?
PingRF - Talking to the Animas Ping Pump via RF
OpenAPS - Open Artificial Pancreas System. A platform for building a closed-loop with open tools. There are almost 100 people running their own closed loops, today.
Watch Dana Lewis talk about OpenAPS at OSCON this year!
RileyLink - A bridge that can talk a Medtronic Pump. Make a the pump's RF programmatically available via Bluetooth
Loop - iPhone-based closed loop that uses RileyLink
xDripG5 - iOS Framework for talking to Dexcom CGMs over Bluetooth
OmniAPS - Talking to an OmniPod Pump
I realize this isn't comprehensive, but the point here is to understand there are dozens of ways to solve this problem. And there are dozens (hundreds?) of excited and capable people ready to make it happen.
Here's the systems that I have. This is my Dexcom G5 on my iPhone showing my blood sugar in near-realtime. Here I can see my sugar, but I have to make my own decisions about dosing.
Here is a Raspberry Pi running OpenAPS. This is the brain. The algorithm runs here. It's talking to my Dexcom, to Nightscout in the cloud, and to my Medtronic Pump via RF via a USB device called a CareLink.
Here is OpenAPS again, this time running on an Intel Edison sitting on a SparkFun Block with a battery and a TI C1111 RF transmitter. The Edison is the brain and has Bluetooth. The TI transmitter can replace the CareLink.
As an alternative to OpenAPS, here is a RileyLink custom board that can also talk to the pump, but doesn't have a brain. There is no algorithm here. Instead, this is a bridge with RF in one hand and Bluetooth in the other. It makes a pump controllable and readable. The brain lives elsewhere.
Here's the RileyLink in a 3D printed case. I can keep it all in my pocket and it will run all day.
Here is a build of Loop from Nathan Racklyeft that uses Bluetooth to talk to both my CGM (Glucose Meter) and the Pump via the Riley Link. In this example, the phone is the brain. This is good and bad. You can't really trust your phone to keep stuff running if it also runs Candy Crush AND has a crappy battery. However, if both my Pump AND CGM spoke Bluetooth, we can imagine a world where the brain of my "artificial pancreas" is just an app on my phone. No additional hardware.
The most important point here is that a LOT of stress could have been avoided if the manufacturers had just created open APIs in the first place.
There's also amazing work happening in the non-profit space. Howard shared this common on my original "Sad State" Diabetes Post:
Since then, Howard created Tidepool and recently spoke at the White House! On the commercial side, there are lots of players rushing to market. Medtronic may '>'>'>have a hybrid closed loop called the 670g by spring next year although trials move slowly so I'm thinking later or possibly 2018. Lane Desborough from Bigfoot Biomedical has also closed the loop and they are bringing it to market...soon we hope!
For more information, go watch Mark Wilson's talk at D-Data Exchange 2016. It is an excellent 30 minute overview of the ecosystem and a call to action to everyone involved.
Check out this visualization of 6 years of Hacking Diabetes. These are all the projects and commits as folks dump into Open Diabetes Hacking Community.
What's the take away? It's an exciting time. It's happening. It can't be stopped.
More Diabetes Reading
Bridging Dexcom Share CGM Receivers and Nightscout
Hacking Diabetes
Diabetes Technology: Dexcom G5 CGM Review
Introducing Web Tiles for Microsoft Band - My diabetes data on a Band!
Diabetics: It's fun to say Bionic Pancreas but how about a reality check
It's WAY too early to call this Insulin Pump an Artificial Pancreas
Sponsor: Big thanks to Redgate for sponsoring the feed this week. How do you find & fix your slowest .NET code? Boost the performance of your .NET application with ANTS Performance Profiler. Find your bottleneck fast with performance data for code & queries. Try it free!
© 2016 Scott Hanselman. All rights reserved.