I use, and have contributed code to, one of these (OpenAPS/oref0). There's actually a pretty shocking amount of spaghetti code, shell scripts, and cobbled together components in different languages. The key thing that makes it work is that, safety-wise, it fails more gracefully than you might think; if it stops working it falls back to what would be the no-automation standard of care anyways, and there are high- and low-glucose audible alarms from the CGM going through an entirely separate path that has no DIY in it.
My concern with safety is strictly around accidental over-dosing. If I understand correctly this fallback mechanism wouldn't help with that case—is that right?
The rate of accidental over-dosing is not zero, and pretty fundamentally can't be zero, in both automated and non-automated setups. First, users are manually entering estimates of how many carbs they're eating, and if they overestimate carbs, they'll get too much insulin. This is true regardless of whether there's any automation or not. So in practice, getting a bit too much insulin is a well-tested scenario which every T1 diabetic knows how to deal with; we all carry glucose tablets around everywhere for exactly this purpose. It's still a hazard, but it's not a new hazard. Managing this without automation is pretty hard, so there's a lot of room for automation to be imperfect while still being an improvement.
The second issue is that the continuous glucose monitoring sensors are themselves unreliable, for biology reasons. If a CGM reports high blood sugar when blood sugar isn't actually high, then the system will deliver insulin to try to correct the high, leading to a low. To my knowledge there's been exactly one publicly reported death among DIY loopers, and this is what happened to him. A similar scenario can happen without automation, though: users are supposed to confirm high blood sugars with a fingerstick before dosing insulin to correct, but they often don't.
OpenAPS has a lot of maximum-insulin-amount limits that are, basically, to ensure that it never delivers so much insulin that you can't correct it with glucose tablets alone. I am not aware of these safety limits having ever failed to work as designed (though they are configurable, and the user can set them high if they want).
I did once get a double-bolus due to a bug introduced by another developer on the dev branch, while doing development myself. It was fine; at least two additional things would have had to go wrong for it to have been seriously dangerous.
I imagine reviewing a pull request for a repo like this and shudder in horror. I've never understood a significant piece of software in my life to the degree that I'd be confident having it control the contents of someone's bloodstream. I know many programmer's don't have the luxury of having only bugs that can't kill people. I'm just glad I'm not one of them. With the best of my intentions and skills, every app I've written has ultimately been a house of cards, supportable only by extensive testing, that can and does fall over at a stern thought. I'd like to write truly robust software but it doesn't look like one of my practical options at the moment.
Standards must be followed and testing can add a great deal of safety. And for an individual contributor, there could be potential liability if standards weren't followed. Even so, I think in terms of social value per line of code, you'd feel much better spending your time on a project like this.
We should understand that the alternative is very imprecise: poking yourself and trying to time the right delivery of insulin doses, based on your current blood sugar, exercise levels, meals, etc. It's a guessing game with diabetics, so this is a giant leap forward in making them healthier, even if the tech wasn't 100% perfect.
My dad had been lethargic as he ages, the doctors just told him that the level he was maintaining his blood sugar at was much lower than he should be at for his age. They also gave him an in-arm blood sugar reader. The difference from these small changes has been enormous. He seems more alert and healthier than he has in the last couple of years and he keeps more on top of the sugar levels with the new reader. My point here is that people risk their own lives trying to manage their own blood sugar, and even the smallest tech add, like a device that suggests the right insulin dose can be life altering. Diabetics who fail to manage their blood sugar properly can lose limbs and go blind. Given the choice of going it alone or using a technology used by many others, I know what I'd choose.
Sure, but a tired/hungry/drunk/distracted human failure mode is "fuck it, it was 22 units 12 this morning, 22 units yesterday evening, 22 units yesterday morning, I'll just do 22 units." A tired/drunk/hungry/distracted human isn't going to calculate a dose of -1 units of insulin and inject 4,294,967,295 units.
Yes, it's possibly true that failure modes could be more extreme.
Practically, in the discussed system the pumps themselves have built-in maximum boluses so the control-loop is limited in how badly it can fuck up. Of course, you have to trust the pump firmware...
That said, I've done some pretty stupid shit. Like the time I injected a huge bolus of novorapid, thinking I was doing my Lantus shot. Ugh.
Exactly, a human won't won't dose 4,294,967,295 units, but dosing 4 units instead of 2 units is still a thing can drop you to 30mg/dl, as has happened with my SO.
I think one of the considerations with open source medical software like this is price-- for many who can't afford anything better its a suitable risk, perhaps with excess monitoring by the user. The ideal situation is for everyone to have easy access to the best equipment, but in some countries that just isn't possible. Not to 'shoo' away your concerns, I do think the still need to be accounted for, but I don't think they represent a roadblock for such an initiative
Also there is nothing comparable to AndroidAPS available in the market that allows you to keep crazy good balance. The price is the learning curve, but the documentation is good.
Theres also the possibility to verify things, which is at least as much effort as to write it in the first place but then you know it wont kill anyone.
As an adult, I use a GCM manufactured by Abbott, which allows for scanning and recording data, charts etc. I inject appropriate insulin dosage after reading the GCM scan. The software and hardware are proprietary for use with IOS. The package is very effective and accurate, and very expensive if you consider how much insulin, needles and the consumable GCM cost together. It works and I have been able to get very good, tight control using their system. Until OS software and hardware catch-up, this might be a good intermediate step for those who can afford it. Pumps are always going to be problematic until they are simple enough for youth to understand and maintain them, since most Type 1s start out at a young age being insulin dependant.
I also use one. The software is available on Android too and as long as your phone has NFC it will work.
I was surprised that this method of reading blood sugar wasn't mentioned in the article. It removes the stressful and painful need for constant finger prick tests.
I've been using another similar system called AndroidAPS for three years now. With Dexcom G6 and DanaRS pump it means I never need to measure my glucose from my fingertips, be afraid of hypos and wake up every morning with a 5.5 mmol/l glucose. My A1c has been 6.0% the whole time and all I need is a bluetooth capable Android phone.
A night and day difference to the hell I was living with my T1 before I found this system...
Their repo has like 300 open issues today...
I have type 1 diabetes, and use open source tech for getting the glucose readings from my sensor and pushing it to a Pebble, but insulin dosing is a way more complex story.
An interesting question to ask one’s self: how many open issues exist in the private repo of the various commercial insulin dosing providers? How would one judge, at any given moment, whether Company A or Company B has the more robust software? And whether Company C’s recent v2.0 release has increased or decreased the reliability of their software?
I use Dexcom G6 CGMS with Nightscout and xDrip+.
xDrip+ runs on Android, gets the data from the Dexcom transmitter, and sends it to a Pebble watch and also to a mongodb database.
xDrip itself supports a lot of CGMS systems, I've been using it since G4, which was not Bluetooth ready initially, so you had to build a bridge that read the data from the transmitter and sent it to the phone. Way easier nowadays,as the transmitter is using BLE.
Glad to see more folks supporting efforts like this. I've been using a similar DIY approach[1] to manage my diabetes for four+ years, and it's been surprisingly effective and impactful.
Happy to take any questions about how closed loop works, technologies+processes, comparison to other therapies, etc.
Background: SW Dev + Type 1 diabetic for 47 years;
The headline is a little misleading. “Approval” is not really possible as these are unregulated devices. This is just a group of experts providing guidance on their use.
It doesn't look like hackers are necessarily the intended audience, but it would have been interesting to read about some of the failsafes preventing this system from causing overdoses or other dangerous conditions.
One of the failsafes is the conservative amounts of insulin the software is allowed to dose on its own. In my case, it is set to never deliver more than 1.2 units of insulin per hour. If it wants to deliver that amount, it will instruct the pump to raise the continous supply of insulin for half an hour. In contrast, I will routinely instruct the pump to deliver 8 units at once for a meal.
So if say the blood glucose sensor delivers faulty measurements (that happens frequently in my case) it may gradually try to kill me, but it takes hours to get me into a dangerous zone. This is a lot of time for me to notice and correct. I mainly like the system for correcting while I sleep. I wake up less to a low sugar thanks to the software suspending insulin delivery, and high sugar at night is often corrected by the time I wake up.
I don't know about failsafes on the lower levels. I kind of trust it after a year on OpenAps :-)
The reference design document was both an interesting read, and gave a lot of detail on how the system aims to be as safe as possible: https://openaps.org/reference-design/
