I think it may help to have some specifics about what, exactly, the regulations are screwing up here.
Every type 1 diabetic has some parameters that they use to determine how much insulin they need: an insulin to carb ratio, an insulin sensitivity factor, and a basal rate (or several basal rates for different times of day). The way these parameters are traditionally managed is that your devices collect data about your carbohydrate intake and glucose at various times of day, and every 3 or 6 months you bring those devices to an endocrinologist's office where they print them out, a doctor looks at the printouts, and the doctor suggests tweaks to the parameters. This process works very poorly, first of all because 3-6 months is too infrequent, and second because calculating the correct parameter tweak requires a whole lot of math, not just looking at a printout.
The way it works in OpenAPS is that a program runs nightly, looks at historical data, figures out the correct parameter tweak, and applies it for the next day. This works much better. Much better long term health, much better quality of life, much lower short-term risk of death. But if someone dies, there's no doctor to pin it on. So device makers don't include that feature.
(This is the clearest example, but there are others as well. There are also things like where alert thresholds are set; too few alerts and you're at risk of failing to alert the user to something important, too many alerts and you cause alert fatigue and impact quality of life.)
When you say OpenAPS "works much better", while I believe that in general is probably true, how exactly do you know? Is somebody monitoring the OpenAPS fleet and its users? If something did go wrong, would you be able to recover the decision process that led to the incorrect dosing?
Deep understanding of the system, plus personal experience. There is a repository of OpenAPS users' logs, accessible to a small pool of researchers, but (for medical privacy reasons) there isn't any central fleet monitoring. Each user has detailed logs of what their own install saw and did and why, and is expected to monitor it closely. (And we do in fact monitor them--not just as a precaution, but as a necessary part of the remaining decision-making we still do ourselves. The monitoring requirement is much more manageable and less time-sensitive than it would be in the alternative, without a closed-loop system.)
I have, in fact, had incorrect dosing happen, including the worst-case scenario of an incorrect large bolus at night. (That happened because of a bug on the git head branch, not a release version, which is much riskier. As a developer of the system that's a risk I knowingly accept.)
And that's not actually that bad. The important thing to realize is that the point of comparison isn't a zero error rate, it's the error rate a human would make. The worst-case scenario is quite well understood: excess insulin, up to a configured dosage limit. And that's an error which humans definitely make--it's not even a rare mistake, it's a mistake that a human doing everything manually will make multiple times per year, every year.
When you say The worst-case scenario is quite well understood: excess insulin, up to a configured dosage limit.
Is the configuration software controlled? IE, if you had a bug in your configuration or in your microcontroller, could that bug lead to exceeding the configured dosage limit? Or is there a hard limiter (fixed amount of insulin, a physical limit switch, etc) that prevents that.
There's a software limit, selected by the user, in the microcontroller. There's a per-bolus limit, selected by the user, in the pump. There's a physical limit, in the amount of insulin that is loaded into the pump at a time (typically 2-5 days worth).
OK. Based on what you said, I see numerous situations in which a user could receive very large doses simply due to software errors. Have you had external auditors test your design from an adversarial point of view?
Well, the bloomberg article mentions that Medtronic has accepted this new uprising (which is great), but there's nothing mentioned about if the new relationship has meant the DIYers have a clear path to controlling pumps that doesn't rely on hacks.
The chances are this is unlikely, for legal reasons: Medtronic creates regulated medical devices. I wonder whether it would be possible to add something along the lines of "push this (software/hardware) button to allow non-regulated 3rd-party hardware and software to begin controlling your medical device, but doing so will bind you to <insert waiver here>" and get such functionality to pass FDA approval. I somehow suspect not, although I would be very happy to hear otherwise.
As things stand now, though, it sounds like (as the article suggests, with the picture of a "hacked pump") people are still relying on methods and techniques that it sounds like anyone can use. So yes, unfortunately everyone's in a situation where any adversary within Bluetooth range could probably take the device over, and (depending on the severity of the vulnerability being used) perhaps modify the pump itself to pump too much or too little regardless of inputs, or similar.
Quite an uncomfortable situation from a security perspective. :/
Every type 1 diabetic has some parameters that they use to determine how much insulin they need: an insulin to carb ratio, an insulin sensitivity factor, and a basal rate (or several basal rates for different times of day). The way these parameters are traditionally managed is that your devices collect data about your carbohydrate intake and glucose at various times of day, and every 3 or 6 months you bring those devices to an endocrinologist's office where they print them out, a doctor looks at the printouts, and the doctor suggests tweaks to the parameters. This process works very poorly, first of all because 3-6 months is too infrequent, and second because calculating the correct parameter tweak requires a whole lot of math, not just looking at a printout.
The way it works in OpenAPS is that a program runs nightly, looks at historical data, figures out the correct parameter tweak, and applies it for the next day. This works much better. Much better long term health, much better quality of life, much lower short-term risk of death. But if someone dies, there's no doctor to pin it on. So device makers don't include that feature.
(This is the clearest example, but there are others as well. There are also things like where alert thresholds are set; too few alerts and you're at risk of failing to alert the user to something important, too many alerts and you cause alert fatigue and impact quality of life.)