OpenAPS does not implement an infusion pump, just an infusion pump controller and interface to the continuous glucose monitor. While it manages a pump using its hybrid closed-loop algorithm, doses are still delivered by a commercial infusion pump. In order to interface to the infusion pump, OpenAPS users have to commit to one of several older pump models, usually a Medtronic, with a vulnerable RF control implementation that allows ANYTHING to write dose instructions to it.
I’d love to use a hybrid closed-loop system. I love open source. I cannot use OpenAPS until the RF integration with the infusion pump is securable. I’d love to see this take the form of an open source hardware infusion pump but would also settle for pump manufacturers implementing an RF interface as an open standard with mechanisms for endpoint mutual authentication.
This is pretty great, that someone can hack on their pump and GCM systems - but at the same time it makes me a little nervous. People should be able to do this, but I’m not sure they should do this. Because although commercial systems are expensive, we assume they come with at least some testing behind them. A large company has a lot to lose if their system is proven buggy, so they would (at least theoretically) spend some time and effort testing it.
I’d be very reluctant to have my own new code, that’s only running in my own device, give me insulin. If a bug causes too much insulin to be delivered, I could die. That exact code would have been “tested” in only one device: mine.
Not that open source can’t be used to make these devices better. What should happen is that Medtronic should put their code on Github and accept pull requests. Changes should be slow, careful and well tested and people should only load official releases into their devices, so that many people are running the same code. Because it’s also scary that the code currently running on these devices (though it may have been well tested) - doesn’t have many eyes on it.
The thing here is that medical device manufacturers have financial incentives to be closed-source, even if we’re assuming they wanted to help people get their own changes through the regulatory process. Specifically, for any device that can be offered on a rental basis, health insurance providers like to have sole control of the data it generates, and manufacturers have been happy to oblige. I’m sure there are a variety of reasons that insurers like this, but at least one reason is that they like to stop paying for people’s machines if the machine doesn’t get used every day.
A friend of mine puts up with this for a CPAP, and has had to deal with threats to take the machine (which could endanger their life) because technical issues prevented the upload from working. Anecdotally, this is a widespread practice and well-known within the disability community.
Unfortunately we don’t live in a world where medical technology companies want to be nice. I can absolutely understand why people are trying to go outside this system, regardless of the risks. I personally hope they don’t run into legal barriers.
That’s pretty awesome. I think this might make a nice target for hobbyists or CompSci folks wanting to prototype high-assurance systems. The documentation and algorithm I skimmed look like a great start on it. First step I’d say is putting it on a MCU board on older node whose components are known to run long time without screwups. They tend to be really cheap, too. Next version might be high-availability setup of a few of them in small package. Might be a fun project.
This article misses a huge detail!
OpenAPS does not implement an infusion pump, just an infusion pump controller and interface to the continuous glucose monitor. While it manages a pump using its hybrid closed-loop algorithm, doses are still delivered by a commercial infusion pump. In order to interface to the infusion pump, OpenAPS users have to commit to one of several older pump models, usually a Medtronic, with a vulnerable RF control implementation that allows ANYTHING to write dose instructions to it.
I’d love to use a hybrid closed-loop system. I love open source. I cannot use OpenAPS until the RF integration with the infusion pump is securable. I’d love to see this take the form of an open source hardware infusion pump but would also settle for pump manufacturers implementing an RF interface as an open standard with mechanisms for endpoint mutual authentication.
This is pretty great, that someone can hack on their pump and GCM systems - but at the same time it makes me a little nervous. People should be able to do this, but I’m not sure they should do this. Because although commercial systems are expensive, we assume they come with at least some testing behind them. A large company has a lot to lose if their system is proven buggy, so they would (at least theoretically) spend some time and effort testing it.
I’d be very reluctant to have my own new code, that’s only running in my own device, give me insulin. If a bug causes too much insulin to be delivered, I could die. That exact code would have been “tested” in only one device: mine.
Not that open source can’t be used to make these devices better. What should happen is that Medtronic should put their code on Github and accept pull requests. Changes should be slow, careful and well tested and people should only load official releases into their devices, so that many people are running the same code. Because it’s also scary that the code currently running on these devices (though it may have been well tested) - doesn’t have many eyes on it.
The thing here is that medical device manufacturers have financial incentives to be closed-source, even if we’re assuming they wanted to help people get their own changes through the regulatory process. Specifically, for any device that can be offered on a rental basis, health insurance providers like to have sole control of the data it generates, and manufacturers have been happy to oblige. I’m sure there are a variety of reasons that insurers like this, but at least one reason is that they like to stop paying for people’s machines if the machine doesn’t get used every day.
A friend of mine puts up with this for a CPAP, and has had to deal with threats to take the machine (which could endanger their life) because technical issues prevented the upload from working. Anecdotally, this is a widespread practice and well-known within the disability community.
Unfortunately we don’t live in a world where medical technology companies want to be nice. I can absolutely understand why people are trying to go outside this system, regardless of the risks. I personally hope they don’t run into legal barriers.
That’s pretty awesome. I think this might make a nice target for hobbyists or CompSci folks wanting to prototype high-assurance systems. The documentation and algorithm I skimmed look like a great start on it. First step I’d say is putting it on a MCU board on older node whose components are known to run long time without screwups. They tend to be really cheap, too. Next version might be high-availability setup of a few of them in small package. Might be a fun project.