The Changelog: Software Development, Open Source - Building an artificial Pancreas with Elixir and Nerves (Interview)

Episode Date: August 11, 2017

We talked with Tim Mecklem about building an artificial Pancreas with Elixir and Nerves to help those with Type 1 Diabetes who want to "loop" — a process which involves monitoring glucose levels, predicting where a person's glucose levels are heading, then delivering insulin based on that prediction. Tim is a Developer at Gaslight in Cincinnati where he builds software solutions with Ruby and Elixir, and he's a member of the Nerves Core team.

Bandwidth for ChangeLog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash ChangeLog. This episode is brought to you by ElixirConf 2017, held September 5th through 8th in Bellevue, Washington, just across the lake from Seattle in the home of Microsoft, as well as Amazon. It's two days of training on September 5th and 6th

and two days of conference and community on September 7th and 8th. Get face-to-face time with core developers of Elixir, Phoenix, Ecto, Nerves, and more. Learn from over 40 speakers and keynotes about how top companies and developers are getting performance gains from Elixir and surpassing their competition. There is no better place to discuss, collaborate, and socialize with other Elixir professionals and enthusiasts. And the ElixirConf organizers have been generous enough to give us a $40 discount. This is exclusive to us. You can't get this anywhere else.

In fact, early bird pricing ends August 18th, so you've got limited time. Head to ElixirConf.com to learn more, and use our special URL, ElixirConf.com slash changelog, to get that $40 discount. And now onto the show. From Changelog Media, you're listening to The Changelog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, Editor-in-Chief of ChangeLog. On today's show, Jared and I talk with Tim Mecklum about building an artificial pancreas with Elixir and NERV to solve the problem of looping for those with type 1 diabetes.

Tim is a developer at Gaslight in Cincinnati, Ohio, where he builds software solutions with Ruby and Elixir. And Tim is also a member of the Nervescore team. So Tim, you're giving a talk at ElixirConf coming up. And it's kind of gotten some interesting responses to this problem. And we've covered something similar to this on an episode of Spotlight, which we'll link up. But people with type 1 diabetes, they have to monitor their insulin. covered something similar to this on episode of spotlight which we'll link up but uh you know people type 1 diabetes they have they have to monitor insulin there's devices involved and you've kind of tackled this problem of like of combining your technical prowess and in software

to to kind of mitigate this problem can you kind of open that problem up for us help us understand what the problem is and how you're helping solve it. Sure. So a little over a decade ago, my wife was diagnosed with type 1 diabetes. It's a misunderstood disease, partly because there's two kinds. There's type 1 and type 2. Type 1 in particular is an autoimmune disease. It means that your body is fighting against its own production of insulin. And insulin is the thing that your blood needs and that your body needs in order to absorb sugar and energy out of your bloodstream.

And so people with diabetes are often, I mean, there's a lot of jokes about diabetes cat and things like that. Those don't go over very well with people with diabetes. So really, ultimately, what got me into this was my wife. She wasn't really well informed at the beginning of this disease about what it was that we needed to do to monitor her blood sugar. It's been a journey and it's been pretty fantastic for us because we've been able to grow closer as a result of it. But type 1 diabetes is kind of a monster. Nobody fully

really understands why it happens. But once you have it, it's essentially there for life. And you have to be able to figure out how to adapt and monitor and control your diabetes as well as you can. And up until recently, that hasn't even really been a concept. Like you haven't really been able to manage it well. So that's really what the background of this whole story for me is. Managing it involves obviously monitoring it. So you have to have something in today's age, you know, whether I think it was, you know,

blood on a strip and the device would read it and you do that several times a day, you have to prick your finger. Is that what you're talking about? Yeah. So, I mean, insulin was discovered a long time ago, but how to manage diabetes has come about much more recently. There's some really cool technology that's come out since my generation, which is like continuous glucose monitoring and insulin pumps that can deliver insulin automatically through a little motor. There's just really neat technology, but at the end of the day, most of it still requires for you to draw blood in order to measure and to calibrate the devices that you're using to do this stuff. I actually have a little bit of a personal context with that now because I'm actually wearing a continuous glucose monitor myself.

And I'm going through a lot of the first-person empathy, I guess you could call it, that my wife has been going through for years. Just waking up in the middle of the night to something telling you check your blood sugar, you know, that kind of thing is, it's distracting, but it also wrecks a lot of other parts of your life. If you don't get a good night of sleep, it can affect everything. And so ultimately, yeah, the technology is coming around and there's a lot of really cool things out there. But at the end of the day, you're monitoring through a finger prick most of the time. You know, some doctors will suggest to anybody, you know, whether you have been diagnosed with diabetes or not to monitor and be aware of your glucose levels, because it plays such a role in thyroid and metabolism. It's such a key component to overall body health and

not to be morbid, but I've got some history with this, some personal history. And people often end up dying because of, not directly because of diabetes, but because of the things it causes. They may die of a heart attack. They may die of something else. But it's ultimately, it was diabetes is where it began. Yeah. I mean, so there's two kinds of trouble that could come up as a result of having, especially type 1, and that is if you go too high and you maintain that high blood glucose for too long,

then you have all kinds of health complications. It affects your heart. It affects your vision. It affects your blood vessels. It affects a lot of your body. And so in the long term, it's very bad to have high blood sugar. On the short term, though, if you go too low for too long, then you have the problem where you could pass out.

You could not be able to address that by taking some form of glucose. And so the short-term impact of being really low is actually much more acute than the long-term effects of being high for too long. So it's really a game of playing the balancing game in the middle of this highs and lows and trying to keep your sanity while you're doing it. So the type of scenario you're talking about is like constantly monitoring so you don't go too low for those short-term scenarios. Yeah. I mean, in the past with my wife having a CGM and having an insulin pump, so having something that is monitoring her every five minutes and also is able to deliver insulin, we still had many nights where her pump would alarm and wake me up and also is able to deliver insulin. We still had many nights where her pump would alarm and wake me up and I would have to roll over and kind of touch her and say,

hey, hey, you're going low. I can hear your pump beeping. And, you know, she got so accustomed to it, she would just sleep right through it sometimes. It's dangerous even when you have technology helping you. So I don't understand in terms of the blood draw. Is that happening at intervals or continuously? I haven't had experience with modern tooling around this. Explain exactly when the blood is being drawn and what continuous monitoring means. So it depends on which CGM you use. As far as I know, there's still only two that are FDA approved in the United States. One of them is the Medtronic one. The other one is one called Dexcom. Medtronic has a pretty hard limit. Every 12 hours, you prick your finger and you tell it what your blood sugar is, and it uses that to calibrate. It's not actually measuring blood

sugar through the continuous glucose monitor. It's actually just measuring a proxy variable, so it needs calibration periodically. Dexcom works similarly. I believe you can go longer, and it'll still give you readings if you don't calibrate, but I'm not as familiar with the Dexcom. And there's been, I mean, there's obviously a lot of people are working on making this something more integrated or smooth in people's life. I know there's people who've been trying to do this kind of monitoring through eyes and, you know, there's been rumors that Apple's working on something with the watch and blah, blah, blah. Is there anything that's heartening with regard to maybe research and development that you know about where perhaps it becomes, in the next couple of years, a little less, what's the word, intrusive?

Yeah, there's a few things going on. They're actually growing, I believe they're called islet cells, and they're embedding them under people's skin. They're doing some really interesting things where basically they're giving people the function of a pancreas without necessarily having to try to do a transplant or something like that. That's really exciting. I know Amanda's following that really closely.

I think there's really nothing more that I would like as an end result to all of this work that I've done to be able to just throw it away and say, you know what? Diabetes is a thing of the past. We don't need any of this technology anymore. People's bodies can function the way they were supposed to. But ultimately, right now, on the horizon, Medtronic has a new FDA-approved closed-loop pump, and they're doing some really cool research with embedding or implanting these cells into people. So back to Jared's question of the constant monitoring, you're not actually pricking several times a day. It's like maybe twice.

Yeah, two times a day for the Medtronic one and about the same for Dex, if I remember correctly. You're supposed to prick it every time that you eat for the Medtronic one. You're supposed to do that every time you bolus, which is when you deliver a large amount of insulin for a meal. Whereas the Dexcom, I believe has been approved for, for treatment without having to finger prick and calibrate at every meal. So before you get to your dream of getting to just throw all this stuff away, in the meantime, you've done a lot of work and perhaps you have some more work ahead of you with solutions around the monitoring, the predicting and the controlling,

which these are things that our computers are very good at. Tell us the story about what finally prompted you to start breaking out your editor and writing some code and what you're building in order to help address some of these issues. My wife actually is the one who discovered the OpenAPS project. I believe it still stands for Open Artificial Pancreas System. And she asked me if I would look into it,

and I said no. I would have really basically nothing to do with something that would control insulin delivery to her body. That just kind of scared me. And for good reason. I think everybody who does something like this should pause and think about

whether or not it's really the right thing for them. But I said no. You mean the responsibility, right? Yeah, there's a huge amount of responsibility. I mean, not ultimately for me, but for the person who has diabetes and is really thinking about closing the loop, as people within the community call it, closing the loop. What's closing the loop? It's when you take that monitoring and the predicting and you turn that into control.

So you can have an open loop which monitors and predicts, sorry, predicts. You can have an open loop that monitors and predicts but doesn't control. It will just give you guidance as to what to do and you can choose to, based on your own experience, ignore it or heed its advice. A closed loop is when a computer is actually sending a signal to the pump to say, okay, you're starting to go low

so I'm going to cut off your insulin supply or vice versa. Well, especially with what you said earlier with how important it is to control it short term, low, high, how severe it could be affecting that person to trust the person writing the code and or the computer doing all the work, basically. That part of it takes a lot of trust. Yeah. Yeah, yeah. Yeah, so OpenAPS itself actually has built into it some safeguards, one of which is that it never issues a bolus.

Now, that's kind of not true anymore. They're doing some work with the next revision of it or the next iteration. But up until very recently, the only thing that it would do was to change the basal rate, which is more like a background drip that you have just to keep the sugar being absorbed into your body. So there are safeguards, and that's really the only reason that I was okay moving forward. So back to Jared's question, which was what got you to get out your editor and take the first step? Yeah, because you said no at first. I said no, and I said, okay, think about this for a month, Amanda.

If you really want me to go forward with this, I want you to be purposeful about it. I want you to come back and tell me without any reservation this is something you want me to look at. Knowing that I'm just in a support role and she's the one who has to deal with the consequences of whatever's happening there. At the end of about a month or so, she said, yes, I want you to look into this. So I began a journey, a journey of learning specifically around OpenAPS. It has many strengths. Its community is one of them. One of its weaknesses, I would say, is that you have to essentially be a Linux system

administrator to set it up. You are installing a Linux operating system on what I like to call tiny computers, just an embedded device like a Raspberry Pi. And then you are going through many, many steps to get to the end. They've done a lot of work to improve that. But when I started out with it, it took about two weeks just to wrap my head around what the loop would even look like. So how long ago was this when you first started digging into it? I think we were headed into fall of last year. That may not be true. I think she's been looping

for about a year now. So it was a little bit before then. But I didn't crack open my editor at that point. I like how there's a term for looping. Yeah, year now so it was a little bit before then but i didn't crack open my editor at that point i'm like there's a term for looping yeah it sounds like science fiction the thing that people use to loop is their rig it's just the tiny computer and the battery and everything but they call them their rigs so um amanda has a few rigs and they're all of different sizes and varying technologies and things but yeah the loopers use rigs. Wow. Has she bumped into Bruce Willis? No, not yet. I mean, how about you though? Like how did, how did you gain the confidence? I mean, I, we don't know much of your technical background or where you came from to, to, to even feel comfortable with you being responsible, let alone her trusting you to do it.

How did you get there? Um, so I, I like to solve problems. I like to tinker with things. I like to understand how things work. And I remember early on when Amanda would download all of the glucose information and everything else from her pump and upload it to the internet, that process was really, really difficult. I mean, it was just a pain. They had to use this special USB stick and everything. And I just remember thinking, man, somebody should really fix that and make it better. Ultimately, that's what OpenAPS did. Ben West is somebody who worked on it very early on and has done a lot of things to contribute to the community. And he ended up reverse engineering some of the communications of the insulin device, of the insulin pump, and determined how to send

commands to it and get responses and what those responses should look like. So he was really, along with Dana Lewis and Scott Libran, they're really like the triangle of people who started all of this, I think like seven years ago or something like that. So what was your initial goal? You said you took two weeks of just studying OpenAPS. Was it to get Amanda looping on OpenAPS? Was that like the initial, we're going to do that? Or was it just to dip your toe in the water, so to speak? What were you guys thinking at the outset

when you first started getting involved? The end goal was to loop. I had no idea how to get there. I started very slowly, just trying to wrap my head around all the different components. There's a lot of moving pieces to an OpenAPS install. And so it really just depended on me ramping up my understanding of how to do a Linux install on top of how to install some Python packages, some Node packages, and set

up some Cron jobs. I mean, there was a lot to it. And so there were documents upon documents that I was reading through, and ultimately trying to understand how does this work. So OpenAPS, if you had to describe the system at a high level, the architecture, you said it's a Linux-based thing. I'm sure there's a bunch of tooling and programs. What's it comprised of? What is it? That's kind of a hard question to answer because it's really hard to pin down exactly what OpenAPS is.

It's clearly not a product. I mean, they're very, very forthcoming with that because products have commercial responsibilities and are usually monitored and regulated by the FDA and things like that. Each OpenAPS install is essentially a custom thing. You may buy some hardware that gets you there faster, but ultimately at the end of the day, you're pulling down packages and repos and you're building something and trying to understand algorithms while you're going. It's not an easy process. Wow. It seems like it has a small window of a goal though, where it's mainly about the safe ranges when you're sleeping or right after meals, not so much like a all-day, 24-hour duration constant? Well, some of the early adopters of OpenAPS were actually parents. Their kids were going off to school.

They had no ability to control what their kids were eating, what kind of gym classes they were taking, what they were experiencing in terms of all that. And I don't think a lot of people realize that there's a lot more that goes into blood sugar levels than just food. It's food, it's activity, it's hormones. There's, there's just stressful will cause problems for you. If you, if you have that actually public speaking is interesting because it affects your blood sugar. I heard also that if you just imagine, if you just put a piece of candy in your mouth, you took it right back out, it would do the same effect as if you ate it. I don't know.

I'm not a doctor either, but I've heard that just the mental... Well, mostly that your brain is so powerful that it knows, like, I've gotten an induction of sugar. I should respond accordingly. And it doesn't know that you took it back out. It just gets that neuron sensor. How could your brain not know that it

didn't? I mean, if your brain's smart enough, it should know your brain is the one that took it back out. Tim, you mentioned that OpenAPS is not a product, and I have hard evidence of that on the homepage, openaps.org. It says, how do I get started? It says, the documentation and reference design implementation code is available on GitHub. Take a look at the FAQs, reference design and links

to open source repository documents. So I mean, basically, it's okay, look, you're gonna spend two weeks reading. If you want to get started with this. There's no handholding whatsoever. That's exactly right. So what has your work been with OpenAPS after maybe take us a little bit down the road a little bit, and then tell us, you know, where you're at now, roughly a year or so later, you're giving this talk at ElixirConf all about it. What's been your progress through OpenAPS and getting involved,

and where have you ended up with Amanda and using this stuff? My path through the OpenAPS community has been kind of meandering. There's actually another project called Loop. It's an iOS application that has an Apple Watch app and some really cool other stuff. Amanda really wanted to try it. And so I got everything that we needed hardware-wise. There's a great guy named Pete Schwamm.

He created the hardware called Riley Link. His daughter's name is Riley. His daughter's name is Riley. And he built this hardware and he built the integration and the iOS application to monitor her blood sugar. Another guy named Nate Rackley, I think he went to work at Apple, ended up actually building the loop application with Pete. And they have essentially what's open APS on the iOS phone and on the Apple Watch. So it didn't support a particular feature, the CGM on an insulin pump that my friend was using. And I thought, this is a great opportunity for me to dig in and really understand and feel more secure in

my knowledge of how these insulin pumps work. So I started there. I actually started, I learned Swift. I didn't do anything with that. I had been an iOS developer before, but it was pre-Swift. And so I learned how to implement the pump communication stuff in Swift and release that. And then I kind of went back to the OpenAPS community and said, hey, I learned some things about the CGM decoding of these binary chunks of data that come from the insulin pump. And I think we're kind of doing it wrong a little bit here. And so I contributed back to that project. But as I was doing those things, I kept thinking, man, this is supposed to be what Elixir is really good at. It's supposed to be able to decode binary chunks like this and

split them out and make them meaningful data very quickly and very easily. And it should be handling like all of the problems that you get with insulin pump communication. It's wireless. So there's just wireless interference. There's multiple pumps in the same room. People's looping rigs can like interfere with each other. This is something that Elixir should do really well at. So as I was building up my understanding of how the insulin pump works, I was implementing a reference implementation for myself. I was learning how to do this in Elixir. So I was picking up the language at the same time that I was really understanding a problem domain that was new to me. So it was fun. I got to build it with tests. I got to really drive through some examples. And then what I took from that,

I contributed back to the loop application on the iOS side and then back to OpenAPS on the tiny computer side. Coming up after the break, we talk with Tim about the OpenAPS project, which stands for Open Artificial Pancreas System. This allows those who are willing to build their own system to loop. Looping is a process which involves monitoring glucose levels, predicting where a person's glucose levels are heading, and then delivering insulin based on that prediction. Needless to say, it's a complex problem to solve. We also talked to Tim about Elixir and Phoenix, how he's learning it, and how it's fitting into the solution he's building. All this and more after the break.

This episode is brought to you by Datadog. Datadog is cloud-scale monitoring that lets you track your dynamic infrastructure and applications. It brings you visibility into every part of your infrastructure, plus APM for monitoring your application's performance, dashboarding, collaboration tools, and alerts that let you develop your own workflow for observability and incident response. Datadog integrates seamlessly with all of your apps and systems from Amazon Web Services, Slack, to Docker, so you can get visibility in minutes. Go to changelog.com slash datadog to get started for free. Also, our listeners get a free Datadog

t-shirt when you start your trial and create your first dashboard. Once again, teamslaw.com slash Datadog and get started for free. So, Tim, you said that you contributed back the things that you were doing in Elixir back to the OpenAPS project. What does that contribution look like in terms of technical logistics? You have some Elixir code and you're trying to get it back to them. Is it another implementation of their reference? What's the actual contribution and what does it look like?

So the code that drives pump communications for the reference OpenAPS implementation is in Python. And so what I did actually was I just went back and ported the code over to Python. So I had my reference implementation

for myself in Elixir. I used that to help drive the Swift code and drive the Python code and then just basically wrote the tests for those things separately, pushed those back into their own repos and kind of moved on from that.

So you're keeping your own Elixir implementation and then you're porting for them the results of that into things that they can use directly. Is the reason for the Elixir version beyond that you wanted

to have a project and learn things about Elixir version beyond that you wanted to have a project and learn things about Elixir and all that is to have another fully working implementation of OpenAPS that's Elixir only or is it something that I'm missing? So at the beginning of it, it was really I won't say it was a toy, it was a learning experience for me

I wanted to just understand how the promises that people make about Elixir and how it can do binary decoding and do all these things really well, whether or not those things measured up. What I found was pretty overwhelming evidence that it's an amazing language for this kind of thing. But Elixir also lends itself to philosophies like let it crash. And if you're allowing parts of the loop to crash, but you're resilient to those things, you're fault tolerant to those things, then, I mean, that's great.

The pumps are going to be unreliable. You're going to walk away from your pump when you leave the restroom one day, and then you're going to come back 30 minutes later. Your loop can't start making really poor decisions because it couldn't talk to the pump. And so what I wanted to see is how well Elixir would fit the problem space. What I ended up with was essentially a dream at the end of that experience. I said, wow, wouldn't it be really cool if we could take Elixir and its abilities to handle these problems and my outside knowledge at the time of the NURSE

project and start building a system where people don't have to know Linux system administration. They don't have to know how to schedule cron jobs. They don't have to pull down a certain Python repository here and a Node repository there. What if they could just pull down one set of code, one project, and build it into a firmware that burns onto an SD card in less than a minute, and they're booting up in less than seven seconds and into a loop? I mean, how cool would that be? And if it had Phoenix running a configuration screen, so when they're plugged into their computer, it gets power over the line, but it also serves up a website. And you can just go there and say, this is my pump serial number. This is my Dexcom.

And I'm looping. I need to understand the algorithm. I need to understand the pieces behind it. Because if I can't do those things, then I'm doing a disservice to myself and I'm taking a risk. But ultimately, I don't see where Linux system administration or cron jobs fit into the problem space. I shouldn't have to know those things in order to be able to loop. Yeah.

When you were describing your first steps, I was thinking this sounds like something that Docker or similar would help address all of this configuration and dependency installation and all that kind of stuff that those of us who've done Linux network administration, like myself, setting up mail servers back in the day, install this and then that, and then configure this and configure that, and you're like, this is really...

So nuanced. It's so nuanced and so easy to just get stuck for hours or days on like obscure spam assassin configuration or yeah, absolutely. So limits the reach, right? Limits the reach for people like Tim or like us who can, you know, plumb those depths. So bringing that, I thought maybe like a Docker thing would be good,

but it sounds like the Elixir would be a great fit if you can have it on an embedded device, which you've mentioned the Nervous project a couple of times. Give us the high level of Nervous for those who aren't familiar with the project. So Nervous, I think the tagline is something about building bulletproof firmware. I should probably know this better because I'm on the core team, but ultimately what drew me to Nervous is that I had a Raspberry Pi. I bought it literally the day they came out, like 2.30 in the morning, and I thought, this is going to be great. And I had no idea what to do with it.

I put Linux on it. It sat on a shelf. Nothing happened. Nervs Project actually takes custom Linux kernels built off of a thing called BuildRoot and takes those kernels, puts your application, your Elixir OTP application on top of it, and runs it. There's no init script outside of just booting up the Elixir application and running it. So you have essentially full control of all the hardware and all the software. And in some ways, the OS is a commodity at that point for your firmware.

You've got a packaged application and an operating system on an SD card booting up in about seven, under 20 seconds, let's just say under 20 seconds. And so that, you know, Docker fits well on like the laptop or server space. NERS fits great in really tight spaces on small computers that don't necessarily have the hardware

available to them to run like containers and things like that. So by the way, when you were describing your dream, you had me all excited as well. So I feel like you're like, wouldn't it be cool? And I'm over here thinking, yeah,

that would be really cool. I was right there with you. So your dream, it translates pretty well. Hopefully it translates into some people willing to help you out and maybe break out their editors as well. So how far are you down the road on this dream and what you've been putting together on the Elixir side of things? So I really wanted to put together something that was compelling. The first thing that I wanted to do, I didn't want to go too far

and like try to really just accomplish everything because I can't do this by myself. I also didn't want to aim too low and just have people look at it and say, okay, whatever, and then move on. What I decided on was an open CGM monitoring loop. And that's actually why I'm wearing a sensor right now. I'm gathering the data from it. So every five minutes, these pumps or whatever CGM you're using will store a new blood glucose number and you can pull those things

off of there and push them up to a website there's a project called night scout which is just amazing it's the thing that i think most parents use with their kids to be able to monitor remotely so they know what's happening with their child more than even the school administrators or wherever they're at but it pushes up this data to night scout and then on Night Scout you can basically see what my blood sugar is every five minutes and be able to, if I go low, get an alarm and call me and say, hey, are you doing okay? Or if I go really high, you can say, hey, look, it looks like you need to deliver some insulin.

So my first goal, and I basically accomplished that as of a couple of weeks ago, is to push up CGM data every five minutes to Night Scout so that it acts and behaves like OpenAPS does in that sense. It just gets deeper. Night Scout. Yeah, NightScout.info.

I mean, this is the second website I've been on that has the hashtag, we are not waiting. Is that like the rallying call around parents and people? I think that really, ultimately, it was born out of frustration over more than a decade of promises, right? Like we're on the cusp of being able to close the loop, and it just never happened. Like nothing ever came out through the FEA's approval system that closed the loop for people, and they were finally just fed up with it. As of right now, I believe there's about 360 plus people looping. So it seems like maybe a small number because there's a lot of setup. But also, I don't know that a lot of people are necessarily self-reporting that they're

doing this out of concern or they want privacy or things like that. But I mean, still a pretty significant number of people willing to go through all of that setup to close the loop. Yeah, considering how hard it is, I guess 360 is kind of a success number. When I heard it, I thought, really, I mean, because how many people with type 1 diabetes are there? That's probably a statistic

that you at least can estimate for us. You know that one? I have no idea. Oh, gosh. Come on, Tim. No, let's let Google do that one. About 86 million Americans Americans at least. Is that with type 1?

Sorry. I read the first headline. I'll read it since it's context here. About 86 million Americans had pre-diabetes that year. Type 2 diabetes represents about 90-95% of all diabetes cases. So if the other 5% to 10%

is... I have a direct quote as many as three million americans have type 1 diabetes according to the juvenile diabetes research foundation it's a lot of people blah blah blah yeah so less than 400 looping out of i mean we're talking about three million. 0.001%. Yeah. But in absolute terms, right? Yeah. I mean, I guess if you look at it like a percentage, it might seem low. But if you look at it as individuals, like individuals have value, right?

Like there's intrinsic value that every person has and we're making their lives better. We're doing. So I gave a talk and at the end of my talk, I mean, it was totally right in line with the things that I'm saying today. And I thought, okay, this is cool. I get an audience. People are listening to me. After it was over, I couldn't believe the response of people who came up and said, you know, my parents, you know, my father and my mother had type two and died because of complications. Like some of the solutions that are being done here, some of the monitoring that's coming to the market and being able to be distributed to people

through the commercial means, as well as the things that the community is doing, are amazing. This wasn't available 10 years ago, and people are willing to pay a lot of money for it, and now we have a community of people who are just developing it and giving it away for free, and that's just amazing to me.

That's an interesting perspective there is like, you know, as a society up until maybe, I don't know, like, I don't know if open source has done this, but where technology seems more tangible to everyday human beings, I guess, is the perspective is like, we've, we've been a society that has trusted some sort of for-profit company to create some magic device that we use to save our lives every day. That's the society we've been. And over the last five to ten years or more, we've become more of a grassroots like this. Night Scout and the tagline there, which is we are not waiting. We're taking it on our own. We're demanding, in many cases, that it be open.

Seems like maybe, I don't know, I'm missing something or a failure of capitalism or something that so many people, because everybody who has this problem would want this and would pay money for the solution, for looping, for the closed loop of the ability to let it feed back in and manage it um but 360 people have set it up themselves or you know like you said that's just a number that could be bigger when without the people weren't reporting but why aren't there for-profit companies that are providing this as a product?

Why is OpenAPS? I'm not saying that the open source side is bad or anything. I'm just trying to think of why there's this huge gap and maybe it's regulation. I don't know. Tim, what are your thoughts on that? That's a pretty constant conversation that my wife and I have around the dinner table.

We're just trying to figure out why did it take so long for us to get here? You know, like, so Medtronic has a closed-loop pump that they are approved with. It doesn't have exactly the same kind of level of control that you have with OpenAPS, but at the same time, it's better than nothing. I think one of the issues is cost. You know, people can't just go and trade their insulin pump in and get a new one. They have to wait for the process through their health insurance and do a lot of things there. So

even though it's come to market, it may be a while before people can even use this. Not everybody who's type two actually is insulin dependent. In fact, I think there's quite a few that aren't. I'm not sure exactly the differences here. Like, I don't really understand what it is about type 1 and type 2 that that would really cause such a huge shift between like there's there's the people with type 1 it's an autoimmune right type 2 I'm not really I don't know as much about that space I have noticed that there are a good number of people who come up to Amanda and ask her questions about what she's doing and she walks away and says they're not managing this disease at all like they're not they're not aware of even the basics of like

what it means to test your blood sugar and what it means when you're 200 or 400 like she's just baffled by these things and so I mean you say that everybody would want this if they could have it I'm not sure that's true but at the same time it would be great if it was available to more people. Well, just generically everyone. I'm sure there's people that wouldn't want it, but given opportunity and education, right, it seems like a straightforward win. Maybe the better way to say it might be everybody who needs it would want it.

Right? Because if you needed something and you didn't have it and it would solve a huge problem, you'd probably want it. Yeah, I think what definitely matters in all of this, even when you go to the commercial solutions that are coming out, is that people really have to take ownership of their own disease management. You can't just assume that an insulin pump is going to go and solve all of your problems for you. That's not how that works. Disease management, especially with type 1, is a constant process. You may be able to delegate some of your responsibility to technology, but at the end of the day, you're responsible for your own body and your outcome. And I think that that is a potential shift in mentality for some people who would really benefit from the technology but don't really understand it well. I could see how, like you said, delegating the responsibility.

I could see how looping for some might be too much trust. That's why I said earlier, your wife must really have to trust you because you've got food, you've got exercise, you've got various things that affect your blood sugar. So not just simply a medication curbing it medication, you know, curbing it, it's a holistic approach to the disease for you. Right. So before we started this whole process, it was a pretty regular event for me to wake up in the middle of the night and in a very rude way.

But of course, I didn't think about it at the time. I would just kind of smack her and say, hey, your pump's going off. Something's bad. You need to fix it. I would just kind of smack her and say, hey, your pump's going off. Something's bad. You need to fix it. I'm too tired to deal with it. And she would either take more insulin or take some kind of glucose tablet or something to regulate that. We actually had a couple of other more scary things happen because when you go low and

there's nothing cutting off the insulin supply, your pump doesn't do it, right? So it's just you're continually going a little bit lower, a little bit lower, and then you have to come out of that and the the roller coaster ride of coming out of it going too high coming down and then crashing and all of that was really really painful for us as trying to just get a good night of sleep um since amanda has started doing these things uh we've been sleeping pretty well i don't get i don't get alarms from her anymore. And ironic. I can say that, I don't know about you, Jared, but I've been politely, as Tim had said it,

smacked by my wife in sleep. So, I mean, I can imagine the version of her. Who hasn't, right? Snoring, whatever. For whatever reason, I'm getting it. Absolutely. Tim, one thing we haven't cleared specifically on the air is the the project that you're working on the elixir and nerves code your wife is not yet using that she's using she's looping but not with your code correct that's correct yes okay you guys have like a countdown

timer on the wall or like a zero days since last no that, that's the opposite kind of thing. Do you have a goal in mind when that might be the case? I have a long-term goal of that happening. One of the things that's going to cause a little bit of difficulty is that she uses a different CGM technology than the one that the pump uses. And I have specifically chosen the pump first because it's a lot easier to get the comprehensive data. Like the pump has all the CGM and also has all of the history of like boluses and basal rates and

everything like that. So I already have to talk to the pump to pull the CGM down is not much more work. But for people who use Dexcom, which is a different CGM, there's no support for that yet in Elixir. My real goal is that Elixir becomes the communications platform it becomes the thing that talks to the devices and at the inner core is the the initial open aps reference implementation i'd like to as much as possible leave that part unmodified you mentioned different cg cgm is that right yeah what does that stand for by by the way? Continuous glucose monitor. Okay, so she uses a different CGM than you're producing with your nerves and elixir code. Can you give us kind of a breakdown of the architecture? You've got maybe a pump, you've got an algorithm that decides based on information.

What are all the components involved in looping with this kind of technology? On the monitoring side, there's communication with the pump. You need to know what the current basal rate is, how much insulin you have on board, which is like how much is in your body that's still waiting to be absorbed or is absorbing. And there's just general information from the pump, like you got to make sure the timestamps are right. So there's monitoring the pump side. Then there's monitoring the CGM, which may be on the pump and it may be something separate. From that, you pull every five minutes a trend, essentially. You're pulling in what's my current blood glucose value, what's maybe one or two previous to that, and where am I headed? Am I

going high? Am I going low? Am I staying where I'm at? Once you have all that information, that's where the prediction and the control come in. And that's where I would like to leave most of what is in OpenAPS unmodified. So the prediction side is take all these variables into account, guess about 30 minutes out into the future where you're headed, plot you along a curve, and then if you're going to head outside of the boundaries, if you're going to head outside of the boundaries,

then apply more insulin or remove some of it on the basal rate. Does your project have a name or a website or a place to go for the people who are interested the way they can contact you? I have a few GitHub repos. I mean, ultimately, it's very bare bones right now. I didn't really decide until ElixirConf call for proposals that I was actually going to push forward with this idea. I was really excited about it.

I had the dream. I sat there and I would talk to my wife about it and say, wouldn't it be cool if we could do this? And eventually I decided it's going to be cool. We're going to do this. And so, I mean, I'm basically in the infancy of this project. I understand a lot of things about the other communities. I like to believe that we can build one around this and really improve the experience for people who are trying to get into this looping community but don't have the desire or maybe just the ability to learn about Linux system administration and all those things that make it difficult.

If someone was listening to this show, you mentioned you've given some talks around this and you were surprised by the reaction. Crowds came up, said parents, friends, loved ones were, had diabetes and what a great mission to be on. You know, if someone's listening to the show and they're like, dang, Tim, I could totally help you or I want to help you. Are you open to like doing this kind of thing? Is this a mission to do it full time or is it simply, you know, in quotes, a pet project for your wife and your, the passions you've already shared during this show? Like, is this something you would like to do on a full-time basis or is this a mission for you on the longterm? If the open APS community really embraced the work that I'm doing and we

could push it forward from there, that would make me ecstatic. If it grew its own, similar to how Loop, the iOS side, kind of grew their own community as well, that would also make me really excited. The question of do I want to do this full-time is no, the answer to that is no. I really love, first of all, working at Gaslight and doing the consulting work that I do. Second of all, this was sort of a mission that thrust itself upon me. It wasn't something that I sought out. But I don't really want this to be a solution forever. I want to see everybody, including the community, including the FDA,

I want to see the device manufacturers forge ahead and solve this problem for everybody. And I mean, as long as people have to do this for themselves, by themselves, without commercial solutions, then, you know, it's a little bit harder for me to see the end vision. So my end goal is really for my work to go away. That's long, long term. I would love to see adoption. I would, if anybody has any interest in helping with this project at this point, I would absolutely love it. I've had people here at Gaslight offer to do some things. I hadn't really felt like it had moved along enough for

me to be able to pull more people on. I'm getting close to the point where I feel like I have the vision that I can present to somebody and we could start working on things in parallel and really, really knock some of these really hard features out. I would love to see that, but I don't have any interest in working on it full time. Coming up after the break, we talk with Tim about elixir and nerves and why they're a great fit for this project. We talk about pattern matching elixir, how his work applies to other CGMs, continuous glucose monitoring, and how his work can scale to allow for water adoption. We also talk about the human equation. You know, all of you out there listening to the show right now. How can you get involved with this project? How can you help Tim solve this problem? To find out, stay tuned. Thank you. via Slack. You can see diagnostic information on the air. You can identify the developer who committed the code.

And Bugsnag's integration with Trello, Jira, GitHub, and many other collaboration tools makes it easy to assign and track bugs as they're being fixed. We have a special offer for our listeners. Head to bugsnag.com slash changelog. Try out all the features completely free for 60 days. Once again, bugsnag.com slash changelog. All right, Tim. Well, earlier on, you were talking about Elixir

and how it got you all excited when you began to dive in and solve this problem and write some tests and see them pass. That's always a good feeling. We didn't really dive into why that was a good fit. And you mentioned binary matching, and I've been doing some work with Elixir and parsing ID3 tags and the bit string syntax and pattern matching. And I can see where in that case, it's definitely a good fit. And I'm thinking it's probably very similar.

So open that up for us and tell us why Elixir and then as a follow-up NERVs when we get to there fit so well into the kind of work that you're doing? So underneath the covers, when you're talking to one of these insulin pumps, it uses relatively proprietary protocol, but it's running on packet radio. So you're getting these packets of data, you're sending commands to the pump, getting things back, and it's giving you frames of data that you have to peel away and do CRC checks on and make sure that

everything looks right. And then you can add that to the bundle of things that you've already received. And once you get enough of those things together, then you have this page. It's 1024 bytes full of stuff and you have to figure out what to do with it. That's the way both the history and the continuous glucose monitor data comes from the pump. And so these pages of information have various kinds of events encoded in them. At the simplest, it's a single byte that tells you what your blood sugar is. At its most complicated, it's, hey, I changed the date and time on the pump. The old one was this, the new one is this, and it's like 20 bytes or something like that. So there's just lots of different varying lengths and varying types of data that are stored in these pages. And you have to be able to walk through multiple pages

sometimes to get to where you want. If I just flipped a page on the CGM, if I just filled up the last byte of the previous page and I'm on a new one, then if I need 20 minutes worth of CGM data, I got to go fetch two pages. I got to fetch the one I'm on, turn around, make another request, get all these packets back, reassemble them, and then get another page and then walk through that. And so like, there's just a lot of manipulation of data and streams and binary that when you look at it in the Python code, or you look at it in the Swift code, they handle it reasonably, but you're going a bunch of different places to try to figure out how it works. And in Elixir, I mean, it's right there in the function head.

You're just saying, okay, if it's this kind of an event based on that first byte, it's going to be 12 long, and then the first four are going to be the timestamp. Let's go decode those. It's just all right there. There's no indirection, and there's no, oh, this is scary because it's binary, so I have to treat it differently, and I have to have arrays and scary things like that.

It's just regular function head processing just like everything else in Elixir. So it's really exciting because you can see how it's processing the data without having to go jump around and jump through hoops. So because in Elixir you can pattern match inside your function signatures, inside your arguments. And it's treating these binaries as bit strings or as

a binary data type that also can be pattern matched. You can just pattern match on the first byte and call a different function based on what that is and pass the rest of the blob down into the function. And it's all right there, right? You just have your different functions that match

based on what that first byte is and then passes the rest on and you can slice and dice that as well. Yeah, I mean, like any project, like any software, there's edge cases, there's weird things that come along that look kind of like everything else but are slightly different. So, for instance, when I'm working with the history in the pump, it just reads like a book. You just go from byte to byte, and you figure out what's going on. The CGM, it's inverted.

Everything is timestamped backwards, so you have to flip the page around backwards before you process it because somebody had a bright idea, and they found a way to save some bytes and they can do that. But at the end, you know, some of the history, for instance, when you're talking to two different models of pump are different lengths. And so there's edge cases about, okay, am I dealing with a newer one or an older one? How do I actually decode all this information? With a lot of other previous experiences I've had that kind of breaks the that breaks assumptions in a way that makes you have to refactor a lot and what I found with the elixir work that I did on this it was just kind of like taking it in stride I don't know how else to better describe the experience that I had except that elixir was just ready for everything before

I was so would you have to redo that? I mean, is this work so specific to the CGM that you're working with? And then how do you know its particular protocol? Are you reverse engineering, like waiting to see what you get and then seeing what it is? Or do they have a specification like this is how you speak to this device? Most of what I do is based off of work from other people. I'm really standing on their shoulders. So at the very base of this pyramid, if you want to call it that,

has been West. He reverse engineered the pump protocol and the communications protocol. And the CGM sort of follows alongside that. So getting history and CGM is a little bit different than everything else, like give me your date and time or what's your battery level. Cause they give you this binary thing that you have to unpack. But ultimately it all came from those projects. I learned a little bit from those things. Well, I learned a ton from those things. And then I learned how some of it needed to be modified. And I went back and contributed back to those things. So I don't know if I answered your question there, but that's, that's ultimately where it came from, is somebody else's work and me learning and expanding on that.

So somebody else reverse engineered it, though? Yeah, no, I did not do the reverse engineering myself. But somebody reverse engineered it? Yes. I guess what I'm trying to get is, is this scalable? Or is it always going to be tied to a very specific product or device because that's the one that's been reverse engineered this one in particular is for a specific insulin pump or like various models but the specific kind but basically everybody uses that if they want to loop

so it's an understood anybody who wants to loop says you got to get this one because we know we know how to talk to it yes at the moment there are actually groups doing some of that work with other pumps on the market. I don't know much about their efforts, but I know they've had some recent breakthroughs. able to and like you said before a lot of it is well they got to switch pumps or something you know a lot of its cost or timing around health care and blah blah that holds them back and it seems like well if we had interfaces into more of these devices and we had a layer of abstraction where this product that you're thinking about uh had a layer where it could talk to not just this specific pump that you're coding against now but could work against these seven which cover you know 90 of the market or something like that you open it up to a lot more people without having to have them you know own specific

hardware yeah so so the community really understands there are only specific versions of the pump and they have to be older in order to loop um it's it's a definite drawback like you have to really understand what you're doing when you go into it again like you're saying building a product i'm not really looking to do that um i'm i'm looking to enhance what's out there and be able to support the community better but i'm not looking to like build something that i could sell here no when, when I say product, I just think about a holistic result. Yeah, I don't think about it as a commercial product. I think of it as a packaged thing

that more people could use than currently could. Because are you trying to get looping to more people if they want it or not? I guess is the distinction I'm trying to make. The end of the day for me is really how do I improve the experience of the people who are willing to do this? I'm not sure how much I'm really desiring to expand the outreach of this thing. I mean, I think that would naturally flow from a better onboarding experience for people,

I guess, if you want to call it that. But really, I see a lot of the difficulties and struggles that I had early on trying to support my wife with this. And I want to improve that experience for people. Is there any concerns at all about DRM or is there a terms of service when, you know, using those pumps or buying those pumps where it says I will not reverse engineer and be able to talk to it? Like, is there any of that concern whatsoever? So there's no encryption in the sense of like there's keys or anything like that, right? It's all, it's encoded, but I think you have to do that for any kind of data. I don't know of any terms of service for that.

I don't believe it. The only reason I ask that is because we talked to Corey Doctorow and he said when I use my printer, if I use the wrong printer driver or something like that, I could be in violation of it. So like without, you know, it's very different in terms of those two different things, but like, it just seems like they kind of make it easier for you to break the DRM, you know, or be in violation of it. It's almost like as if it's because then the one thing like Jared's asking

you like, Hey, is this thing you've done, you know, can it work with other pumps or other CGM models? And the answer is like, well, it's kind of tied to this one. Well one well you know wouldn't it make sense to create some sort of collective where these pump manufacturers are they understand what some of the technologists like you were trying to do and you know start speaking the same language or you know making the job a little easier to reverse engineer it yeah i think that that doesn't necessarily play well into the business model, I guess you could say, of the pump manufacturers. They are aware of some of the early efforts of OpenAPS.

I know that there were people who had conversations with developers within those companies, but I think at the end of the day, they never really could get publicly behind it, especially now they have a competing product, right? They want that to go to market. And ultimately I want to see that product get better. When people ask me what I'm doing, like, I'd love to be able to say, well, there's another adequate solution out there and let's, let's eventually move there. So it's kind of weird.

I have these competing tensions, but like, I really want to see this experience improve. I want to support the community. And at the same time, I'd love for it to all kind of go away and for us to solve diabetes diabetes a completely different way. Right. But one is real. One you can actually affect, and the other one is completely out of your hands. Right, absolutely. I wouldn't call it a pipe dream because that would be perhaps wrong.

But it's what you wish would happen in the world, and hopefully it will, hopefully sooner than later. But it's all just a hope. in the world, and hopefully it will, hopefully sooner than later, right? But it's all just a hope. Whereas here is like something tangible, something real, and something inside of your control and the control of other people who are, you know, hashtag not waiting. Or what's the one that we are not waiting? We're not waiting.

It's in the now. It's not in the future that you can affect these changes, what you're trying to say. So I can see where you have this confliction because you're not trying to turn this into a long-term. And when I say product, I'm referring to an end goal because you're hoping that it'll be all obsoleted soon enough.

I can see where that would be. I have multiple hearts there. And all this is going down. This podcast is a precursor to the bigger, potentially bigger, I guess, hour-long talk you'll give at ElixirConf. And this all kind of began with that proposal, which you were even surprised to me you mentioned before the call that it was accepted. Why was that? Yeah. So going into all of this, I've been very hesitant to really speak about this very publicly.

I mean, there's privacy concerns here. There's a lot of things going on. And ultimately what drove me over the edge was the ElixirConf call for proposals. I mean, people just kept asking me how my project was going, what's going on with it. And I thought, okay, fine, I'll put something together. And I think everybody in the office

here except me thought that I just knew that it was going to get accepted but I was I was a hold out I was like no this is I mean this is interesting but it's pretty niche like this this only affects certain people but at the end of the day I think everybody likes to understand when they're when there's somebody that's out there working hard to improve the lives of others they like to hear that story. They like to understand more about that. And the fact that it happens to use the technology that they are embracing, you know, that makes things even better for them.

So I see now in retrospect why the talk was accepted, but that's really what drove me over the edge to say, this could be a real project. Let's really go with this. People are excited about it. I can talk about it and move things forward. Well, I can definitely echo that sentiment i mean even from a person who like a lot of us spend our work hours you know writing crud apps for businesses that are you know not change not not like changing this improving the lives of other humans in like a health like it's such a basic foundational way of like people who live with this problem even though you know in america

there are three million of them of the 350 million i don't know how many people are in america anymore but anyways not very many of us a small percentage of people have this problem but the ones that do live with it day in and day out and unchecked you know it's something that they could die from tomorrow or the next day it's a very serious problem it's very serious and so like just the idea that our skill sets that we have that we use to lots of times you know keep be a cog in the machine of the capitalistic society that we live in, can do something for somebody else that you're trying to do, it's incredibly inspiring and exciting.

So I could see absolutely why your talk was selected, and I think it'll be a big hit. And I hear this is your first one as well, so there'll be lots of interesting times upcoming. Yeah, the anxiety and the nerves are already growing a little bit. You did say something that I wanted to touch on. One of the owners here, Doug, you mentioned him earlier. Doug likes to say something that we found to be true out of a book called User Story Mapping.

And what he says is you don't write software to build features. You write software to change the world. It's just a lot of times we lose sight of that. We don't catch on that the things that we're building impact people's lives. This is one of those things that for me, I could find a direct line to exactly where I wanted to go.

I can see exactly how this is going to impact people positively. I just latched on. That's exciting. Absolutely. That's the truth. We often lose touch with the fact there's human beings on the other side of our code, in pull requests, in the actual thing we deliver. And it's so easy to just,

to forget there's humans out there. I don't know why there's so many of them, right? But it's just like, we just forget why we're doing what we're doing, you know? It's easy to like remove the human equation for some reason i don't get that well you're just writing code all day you know there's and not interacting with too many other humans sometimes so i guess that's why it's easy to forget tim if you had uh the ear of the open source community to some degree and developers out there and getting

people excited uh you know with the vision you see where you're taking things even though it may not be a long-term thing for you you know if you were in a position like that like you might be right now what would you want to share about where you're going call to arms how can people step in and help you with your mission well there's a lot of things that still remain i already mentioned that you know there's only one of things that still remain. I already mentioned that there's only one of the two major CGMs that are supported here. I would love to see the integration with the OpenAPS

loop code become tight and become real. I want to see us be able to improve the battery life of these computers. I want to be able to add mobile data and GPS. Actually, it's kind of funny. James Smith here at Gaslight is also going to be talking at ElixirConf and he'll be talking about tracking buses, so like GPS devices and having cell technology.

I'd love to be able to integrate some of that. If you could imagine you go on a hike somewhere, and you start to go low, and you're not able to respond to it well, somebody remotely could get the data over the cell signal that here's your location, here's your current blood sugar, you look like you're dropping, not able to respond to it well somebody remotely could get the data over the cell signal that here's your location here's your current blood sugar you look like you're dropping and they could actually do something to help you remotely without you having to do anything there's a lot of really interesting things that i think could push forward the community and what we're doing

here and i would i would just love to see that i i know very very little phoenix so far which is kind of funny most people who get into Elixir go straight into Phoenix because Rails, Ruby, and the conversion there. I tend to take the weird path into new languages. And so here I am writing this thing and I need to be able to configure it and be friendly with that. I'd like to build a Phoenix configuration site

that you just load up when it boots, but I know very little Phoenix. I've done some just outside tinkering with it. So there's lots of really interesting ways that people could get involved with this i'd love to see a community just come behind me and and say hey what are the things that you need us to pick up because we know that you can't do it all yourself and i would i would really appreciate that i'd love it well we'll certainly link up to your github from the show notes so listeners know that so if you're thinking how can I see Tim's code? What's he doing? Tim mentioned he's putting what he

has there on GitHub, so that will be in the show notes, but it is also Team Mecklem at GitHub. So check that out. Tim, thanks so much for taking your time out, and especially with how touchy this is, how personal it is to you to take your

time and share this story with everybody else because we need more people like you, more Tims out there solving problems like this, and we appreciate your time. That's really kind of you. I appreciate those words. Thanks for tuning in to The Change Log this week, and special thanks to Jim Fries, the organizer of ElixirConf, for not only putting on a world-class event for the Elixir community, but also for supporting this podcast.

If you enjoyed this show, share it with a friend or two, rate us on Apple podcast. And thanks to our sponsors, Elixir conf data dog and bug snag. Also thanks to fastly our bandwidth partner at to Fastly.com to learn more. We host everything we do on Leno cloud servers. Head to Leno.com slash ChangeLog to learn more.

Check them out. Support the show. This show is hosted by myself, Adam Stachowiak, and Jared Santo. It's edited by Jonathan Youngblood. And the awesome music you've been hearing is produced by the mysterious Breakmaster Cylinder. You can find more shows just like this at changelog.com or by subscribing wherever you get your podcasts. Thanks for listening. We'll see you next week. Thank you.