As some of you may know, I’m a Network and Systems Engineering type who works in the Internet industry. I have a B.S. in Cell and Molecular Biology, but I have been working in computer networking and for Internet companies for the last decade and a half (since I was still in school), and have had the privilege of working on a number of different types of systems in that time. Nine months ago, I met a wonderful person who happens to have Type 1 Diabetes, and began learning just what was involved in managing the condition.
On the one hand, I was impressed at the level of data available from her CGM (glucose readings every 5 minutes), and the visibility that provided into what was going on. But I was also very surprised to find that the state-of-the-art medical technology she uses is, in many ways, stuck in the last century. Data is not shared between devices; her pump looks and acts like it came straight out of the early 1990s. (But at least it’s purple!) 😉
Most importantly, it is completely up to the person with diabetes (PWD) to collect all the relevant data on their current state, do a bunch of math in their head, and decide what to do based on the data, their experience, and how they’re feeling. And as a PWD, that’s not something you just do once in a while: it is a constant thing, every time you eat anything, every time your blood sugars go high or low (for dozens of reasons), every time you want to go exercise, etc. etc. etc. As a PWD, you’re dealing with life-and-death decisions multiple times a day: Too much insulin will put you into hypoglycemia and can kill you. No insulin for too long will put you into diabetic ketoacidosis and kill you. Overreacting to a high or low blood glucose (BG) situation and correcting too far in the other direction can completely incapacitate you. So as a PWD, you never get a break.
So, very early on, the obvious question was: why can’t we integrate all this data and make this easier? There were promising signs that it could be done: Artificial Pancreas Systems developed by various research groups and medical device companies are in clinical trials, and are showing promising results. In fact, she had just signed up for such a trial, and I was able to go with her to the clinic and watch just how a fully automated APS system works. But despite these brief hints of a better future, day to day we were (usually, she was) stuck doing everything manually.
It was very clear from the beginning that the primary bottleneck to doing something better was the ability to get blood glucose (BG) data off her CGM (a Dexcom G4) in real time. We knew it was possible to do so manually using Dexcom Studio, a Windows-only software package that is actually quite good for analyzing historical BG data, spotting trends, etc. But unless we were going to create a Windows macro to open up Dexcom Studio, import the data, export it to CSV, and then close Studio every 5 minutes, we couldn’t get our hands on the data to do anything in real time.
Then, we discovered that John Costik had figured out how to use the Dexcom USB driver’s API to get data off his young son’s CGM in real time, and display it remotely, even on his Pebble watch, and even when his son was at day care or kindergarten. This was the breakthrough we needed, so we contacted John, and he was able to provide us a copy of his script.
So now we were off to the races. I cobbled together a system using Dropbox for uploading the BG data from a Windows laptop (that ended up in a bedside drawer), and once I was able to get the data onto a VM server, got working on putting together something that would actually make a difference in her quality of life.
So we worked through a number of ideas. First off, we needed something that could wake her up at night when her BGs got too high or too low. The Dexcom G4 is supposed to do this, but even its loudest alerts are still not loud enough to wake a sound sleeper. People recommend sticking the G4 in a glass or in a pile of change, but that doesn’t work, either. She also had used Medtronic’s CGM system; but even its loudest, escalating “siren” alert isn’t all that loud, even if awake. We also needed something that would allow me to see the alerts remotely, and see whether she is awake and responding to them. This is a big deal for many people, like her, who live alone. So, I started coding, and she started testing. We ended up using my cracked-screen iPad (it got into a fight with Roomba) as a bedside display (it’s much easier to glance over and see BG values than to have to find the CGM and punch a button), and also to receive much louder push notification alerts.
After we got basic notifications working, we also started trying to enhance them. We ended up with a prototype system that allows the user to enter when they bolus insulin or take carbs, and snoozes alarms appropriately. (This enables a de facto remote alert monitoring system, especially handy for individuals living alone.) With that info, we are also able to do the calculations required to determine how much insulin is needed at any given point (the same calculations PWDs do in their head every time they eat or have to correct for high BG), and by doing those every 5 minutes as new data came in, we were able to provide early warning if she was likely to go low, or if she needed more insulin to correct a persistent high. Since getting all of that working, we have also developed a meal bolus feature, which takes advantage of an (as far as I know unique) ability to track how fast carbs are likely to be absorbed into the bloodstream to give the user better estimates of how much insulin is required now, vs. how much will likely be required later as the rest of the meal is digested.
Since she started began actively testing the #DIYPS (Do It Yourself Pancreas System), we have seen a decrease in average BG levels, with less time spent low, and less time spent high. It also enables her to execute “soft landings” after a high BG and prevents “rebounds” after a low BG. We are very encouraged by what we’ve seen so far, and are continuing to iterate and add additional alerts and features. But today, the #DIYPS is just a prototype system, and has only been development tested with a single user, so lots of additional development and testing are required. We are not yet ready to begin allowing (and helping) a large number of users to begin testing the system themselves, but hope to open it up in a manner that will allow as many people as possible to begin safely using the system as soon as possible. However, this is currently only a 2-person side project. We are looking to begin collaborating with anyone who has the skills and interest required to move the project forward, so if you think it’s worthwhile to move forward more quickly, I would encourage you to get involved (if you have technical or other skills that would be helpful) or pass along the word to others who might be interested and able to help.
If you’re interested, you can also read more about why a #DIYPS is needed now (and how it compares to true closed-loop automated Artificial Pancreas Device Systems). We’ll also be publishing a full description of how the #DIYPS prototype works shortly, so stay tuned.