Open-source automated insulin delivery system given approval by team of experts | Hacker News Reader

Open-source automated insulin delivery system given approval by team of experts

kcl.ac.uk

181 pointsgeox44 comments

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?

OpenAPS oref0 works pretty hard to avoid overdosing. More details in the reference design doc.

https://openaps.org/reference-design/

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.

If my life depended on a piece of software, I would choose the programmer who understood the impossibility of their task.

There are standards they likely have to follow, e.g. IEC 62304.

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.

Yes it's always worth remembering the alternative. In this case, the algorithm

    insulin_dose(blood_glucose, activity, carbohydrate, fat, protein, time_of_day, time_of_month, is_saturn_in_retrograde, **kwargs)

has to get run: Either a microcontroller does it or a person (tired? hungry? intoxicated? distracted?) has to do do it in their head.

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.

What would stop a tired/drunk/hungry/distracted human from overdosing as they sometimes do?

or underdosing.

Like, software can have failsafes and error handling, but at some point any healthcare product may require user intervention.

In this particular use case, overdosing is a far worse failure mode than underdosing.

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.

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.

Don't forget that if you miss an edge case lawyers will take your house and your life savings. Welcome to medicine = )

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.

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.

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.

> very expensive if you consider...

Do you mean "very inexpensive"?

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.

(Off topic but related to insulin hacking)

We (University of Maryland, Baltimore library) are hosting a Zoom talk by the Open Insulin Foundation next week, November 17, 12pm EST/UTC-5.

RSVP and details: https://umaryland.az1.qualtrics.com/jfe/form/SV_cHzZ72AJcosM...

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.

Would you please share which sensor and which open source tech you use?

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.

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?

>Their repo has like 300 open issues today...

that's a metric to compare only because that data is available.

how many issues are open on the tracker for the closed-source equivalent?

I have no idea, that's why I am not using an insulin pump either:)

Nobody considers a pump unless it is necessary.

Here you can choose between MDI and pump.

How would you know they have a tracker?

where is the repo at?

https://github.com/LoopKit/Loop

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;

[1] https://openaps.org/

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.

Its not at all misleading, you just have a strict view of what it means to give approval.

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/

Related: "Diabetics Are Hacking Their Own Insulin Pumps"

https://youtu.be/bouYRMItWnI

Here is a direct link to the Lancet review article "Open-source automated insulin delivery: international consensus statement and practical guidance for health-care professionals": https://www.thelancet.com/journals/landia/article/PIIS2213-8...

Article is paywalled and not sci-hubbale because it is recent. At least we can see the references though...

So grateful for the engine of capitalism/free market, that has people 3d printing insulin pumps for themselves.

Reply on news.ycombinator.com