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. :/

Chiming in to say that some data is available to the public as well, as these Open Humans users have shared their Nightscout data publicly: https://www.openhumans.org/api/public-data/?source=direct-sh...