4 ms·

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?

aftbit 5y ago
OpenAPS oref0 works pretty hard to avoid overdosing. More details in the reference design doc. https://openaps.org/reference-design/ https://openaps.org/reference-design/
jimrandomh 5y ago
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.

aftbit 5y ago

OpenAPS oref0 works pretty hard to avoid overdosing. More details in the reference design doc. https://openaps.org/reference-design/ https://openaps.org/reference-design/

jimrandomh 5y ago

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.