diabetes - January 14, 2017

Note: This post is about diabetes, and is less likely to be interesting to an average reader of this blog who just cares about technical topics. Still, feel free to read it!

Type 1 Diabetes.

97 years ago, it was a death sentence. A few days or weeks to say goodbye to your child, then they were gone.

Over time, we began to understand the mechanisms at work. And the scientists got to work, playing doctor Frankenstein - crushing up the insides of pigs, taking the pancreases of dogs. The miracle was that it worked - there was a "cure." Insulin. A few daily shots, and you could go on living a normal-ish life. Shorter of course - since the high blood sugars that are par for the course for diabetics are slowly killing us. On the other end, if you go to low, instead of a slow death, you get a fast one. But it was better - insulin offered not a cure, but a treatment.

Fast forward 97 years to 2017, and we have insulin pumps and blood glucose meters and CGMs and digital keytone meters and insulin pens. All of this technology - it's amazing. But it could be so much better. Here's my vision for the future of diabetes management:

First off, we need closed loop control. All of the technology for this exists - and it's even been created, by both researchers and hackers. It works, and it's amazing. But due to a combination of monopolies on diabetes care and stupid FDA regulations, slowing down progress in the name of safety as millions of people slowly die of high blood sugars and poor diabetes management, this isn't accessible to consumers.

The most compelling case for this is overnight use - set a target number, and even when you're sleeping, your devices are working to keep you at that target number. Not only could this offer near-perfect control for 8 hours of the day, but starting off the day at a good number makes controlling it so much easier. We don't want to stop at the overnight case though - throughout the day, that target number will still be set, algorithms still crunching away, working correct blood sugars far more vigilantly or accurately than any human could.

Next off, we need to get insulin pump technology out of the 90's - the shitty, pixilated, black-and-white LCD displays and AAA batteries are ridiculous. Additionally, we need to ditch the dinky custom RF protocols used to communicate with pumps currently. We should switch to bluetooth - this offers so many advantages - it's more universal, more secure, and easier to implement. Because we're adding bluetooth to our pump, we also need a new security model. All peripherals will need to enter a code to pair, and will be read-only by default. Write access would be provided by verifying a cryptographically signed key - making it difficult for untested or unauthorized peripherals to endanger people. I dream of a simple, open, secure world where you don't need to worry about which devices are compatible with which other devices. It all just works.

Another important factor in modernizing our devices is user interface. First off, an unconventional idea - kill off the idea of "units" of insulin. People shouldn't need training from a medical professional to be able to understand this device. Instead, the input should be carbs - that's it. It'll automatically determine the right amount of insulin to give based off of the user's body and past data, the amount of time that this set has been used for, the age of the insulin, the level of activity of the user, and any other factors that it can find. This will radically improve the effectiveness of bolusing, and any remaining slop can be picked up by the closed loop control. Once you've done this, the UI is simple - enter the number of carbs you're eating, and press go. Blood glucose will be automatically read from the CGM, and all other information will be gathered by the device.

Another important part of the UI is alerts. The device will monitor both the expected amount of insulin delivered and the actual amount. In the case that the actual exceeds the expected by a significant margin, the alert handling code will be called. This will determine if it's an alert that's worth notifying the user about (potentially blocked set or damage to the device), or if it's something that should be noted in weekly review (in the form of a digest sent to the user's phone). The digest will both include any events that happened (specific incidents where there was something unexpected - think eating a slice of cake and not bolusing, or taking off the set for a few hours while you go swimming.) as well as events that are repeated - for example, consistently forgetting to bolus for an afternoon snack.

Total integration of pumps and CGMs is not only possible, but it's the next step. This could be the future of diabetes management. We need a lot of work to be done before we get there though:

  • More research on closed-loop control of diabetes. We already have closed loop control far better than any human, but we need more research on what the best control strategies are.
  • More research on modeling the system of insulin and blood glucose - we need plug and play mathematical models that can tell us exactly what's going on in the body.
  • More open devices. I want to be able to copy-paste 100 lines of code to be able to read my CGM data. It has bluetooth, the fact that there's no API for it is disgusting.
  • We need to have glucagon that can last unrefrigerated long enough to be used as a component in a closed loop control system. This will allow for much more aggressive gains, allowing far tighter control.
  • We need research on faster acting insulin. This will allow us to go from only entering food information, to a complete, hands-off closed loop system.
  • We need the FDA to stop blocking progress. I understand that they are worried about safety issues, but there's far more damage being done by out of control blood sugars slowly killing people than there could be done by faulty closed-loop systems.

This is my dream. I hope that one day I'll have the resources to make it happen, but for now, all I can do is think and write.