Open source medical devices! Is this a first? There is potential for some genuine health concerns where QA and security are involved.
What is new is that the tools and technology (think dirt-cheap microcontrollers that you can easily (re)program, 3D printers etc) are getting to the point where it's becoming more realistic for more people to be successful with less effort/risk along with a means (i.e. the web) for people to collaborate and share information.
That said: yeah, one better do their homework as they are definitely taking their own health (or even life) into their hands.
The key is: "Well Maintained". For these insulin closed loop community, I bet they are. They bet their own life on it.
> You spent 1 day developing, 1 day testing and 5 days documenting.
If you change the configuration, you encounter the possibility of finding new bugs. When someone's life is tethered to the device, this will make engineers (and lawyers) properly twitchy.
For a perfect example of this, have a look at the the Ariane 5 [1]. Existing software was used in a new configuration and when it encountered an untested condition the software crashed, resulting in the rocket self-destructing.
Now, consider, you're adding bluetooth to a safety critical device - this is a protocol stack where people can't get their phone to connect to their car, and my Android phone occasionally needs to be rebooted before it will connect to my headphones.
[1] https://en.wikipedia.org/wiki/Cluster_(spacecraft)#Launch_fa...
For all the issues in medical device engineering, the bar is higher than most people (particularly in software industry) have worked in. Obviously there are other areas too (e.g. aerospace), with similar or higher bars.
Your project will benefit by finding people with experience in hazard analysis and risk mitigation, testing, SDLC management etc. They either have to be motivated to do this on their own or payed, or a mix. Hopefully you'll find people familiar with ISO13489, IEC60601, IEC62304, etc. - not because you'll want to audit to these standards, but because the people will also be familiar with what's needed.
Basically, to have the quality where you want it to be, you need to do the work. The flexibility of such a system is great, but in terms of verification and validation, the amount of work could become exponential with the configurabilty - so you are probably going to want to concentrate on some specific configurations pretty rigorously and encourage them for "real" use.
"The patient died when the hospital was locked out of the pacemaker due to a bug in the license code parser in the patient's device."
You still need to have security for remote control safety, but a device maker cannot afford even a single bug in the "I have my hands physically on the device and I require access" pathway, or else deaths will eventually occur.