Does anyone know if it's possible to get the FDA to certify a snapshot of source code, along with a complete test suite - instead of an executable binary - for use in medical devices?
From my limited experience with this, it seems that all existing medical device software is closed source and are certified as executables - but I'm not sure if this is a limitation of the FDA processes, or the fact that they're intended to be closed source?
That's not quite how it works with the FDA. One thing you have to be able to do is demonstrate reproducibility - so an exec + toolchain is easier, but there is no reason that you couldn't in principal do the same thing with source + toolchain + test. There is more to it, of course.
More importantly though, there isn't such a thing as "certification". You can go through a PMA or 510(k) to get "approval to market" for a restricted set of claims based on your filing, leading to "indications for use". This wouldn't really apply to an open source project unless someone were selling it an making claims on how it could be applied.
In the US, clinicians would have fairly broad power to use a product "off label" if they chose, and the FDA doesn't control anything around what you might choose to use on yourself.
Just to extend off the other replies, the license might also be a factor. GPLv3 has an anti-TiVo, "you must let your users apply their changes to hardware" clause. FDA might consider that too risky.
The anti-TiVo clause has some major exception since it is designed to address a very specific scenario; One where the the owner can update the device but only through the approval of the device manufacturer through signed updates.
That create two cases where GPL have no issue with DRM. The first case is when no one can update the device because there is no update mechanism.
The second case is when there is DRM, and the device can be updated, and the manufacturer give the owner the power to inject their own keys. Again this is allowed.
FDA should have no issue with the first case. It may have a issue with the second case if the update allows for changes which impact the medical safety of the device (but not technological security, as there is an exception for that by the fda).
It’s about auditing. Requiring an executable binary means they can pickup any device off any shelf in any store and verify the binary is the same as the one they approved.
I learnt a little a few years ago while setting up monitoring and building a "Parakeet" [0] for a relative. I think the Nightscout foundation [1][2] should be a good start. I believe they are very active in their Facebook group.
I was in an accelerator with Tidepool people, including Howard Look. They were head-and-shoulders above the rest of the groups. I'm not surprised that they are succeeding where others have failed to make an artificial pancreas work.
Exactly. A low end micro-controller would do the trick but a Raspberry Pi is much more accessible - almost anyone can get one fairly quickly and if they themselves don't have the knowledge to do the setup they most likely know someone who can help.
ATmega micro-controllers also have great community support and documentation because of their use in Arduinos. If I was relying on an electronic device to protect my health I'd trust a simple 8-bit device more than something as complex as a Raspberry Pi.
If I was relying on an electronic device to protect my health I‘d trust my garbage collected code on a 64 bit ARM CPU using real CPU timers way more than my own ability to not segfault or OOM myself to death (literally) with low-level embedded C code.
Segfaulting and OOM on MCU's is far more rare than on a device with an entire operating system on top.
In most cases, MCU IDE's like the classic Arduino one don't even give you an allocator, all data must be statically allocated beforehand.
IIRC it doesn't use the stack either. The main() and loop() functions initialize all their variables statically.
When you have 2KB of memory to share between code, data and stack, allocating and using stack for function calls is luxury that only introduces problems.
Hence, I've never ever ever seen an MCU crash from segfaults or OOMs.
On the plus side they will also use vastly less energy. 10 Milliamps is enough to drive a ESP8266 or ESP32, in deep sleep you start counting microamps. A single battery cell can easily last a month.
This diagram of an open source pancreas has about 3 devices and 3 cables too many. A coin cell can run the control loop forever.
I'm guessing industry hasn't produced this in a streamlined (reasonable) device because it will never be certified, and open source is just a codeword for subverting the regulatory process. Which, from a diabetes sufferer POV, is understandable.
The dark cloud on the horizon is that if the FCC throws a hissy fit because you can install new software on your wireless router, imagine what the FDA will do if you market your device as compatible with this open source software that claims to automagically control your insulin pump.
There are a few variants on how to do a closed loop system. OpenAPS is phone agnostic and everything runs on a RaspberryPi.
I myself use Loop. It's an iOS app that uses a RF-to-BT bridge to talk with the pump and intercepts the CGM reading from the official Dexcom app (there are forks that support different methods, being the Dexcom source the "official" one). The bridge is the size of a 9V battery, I never stopped to see which processor uses but it's probably 8 bit.
Each system support different pumps, sometimes people want to use one but are stuck with a different one to be able to use their pumps.
No, there was a story here about DIY CPAP about a month ago. None of this is new though efforts do appear to be gaining momentum.
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.
QA and Security for the patient? Difficult topic. Medical devices are expensive because they are released to a regulated market. You spent 1 day developing, 1 day testing and 5 days documenting. So an unregulated but well maintained open source product which spent 2 days in testing, has a better quality but cannot show it to the authorities.
The key is: "Well Maintained". For these insulin closed loop community, I bet they are. They bet their own life on it.
What is intrinsic in closed source products that makes them less concerning? Could a financially backed open source device have equal quality, safety and review?
There is no fundamental reason, the tricky part is (as always) cost and expertise.
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.
Systems, particularly safety-critical systems, are tested in specific configurations (inputs, users, integrations).
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.
DRM offers many bugs for an optional feature. I think they realized that the product testing requirements for DRM are so onerous that they'll never be willing to comply. Theoretical example:
"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.
My understanding is that they are partnering with those companies. For instance, Medtronic produces the 670g, the commercial closed loop system (what I have)
From the point of view of medical device development, one thing that is very cool about a community like this is the possibility for broad systematic testing.
Handled smartly with some centralized tools, they could have something really effective.
BTW. I don't doubt diabetes is a huge problem and there just is a reason I don't know but I'm actually curious: why not just go keto, what would you need insulin for if you just stopped eating carbs? Also can't R-lipoic acid do the job of push glucose into the cells?
For one thing you can (and will) generate blood sugar from protein, even with no supply of "carbs". I've heard that eventually after a few weeks the brain can use fat, but I don't know to which degree.
Also the lack of insulin means the glucose isn't going anywhere to be used.
Diabetic ketoacidosis will eventually lead to a Koma.
Sounds like you hardly know much more than I do. I wish scientifically-backed people could tell us exactly how much glucose does the body make out of proteins once it switches to ketosis and if lipoic acid supplementation can be enough to force the cells to consume it quickly enough.
To restate bayesian_horse's point: the lack of insulin means the glucose isn't going anywhere to be used. Insulin allows liver and muscle cells to take up glucose (the body's main energy source) from the bloodstream. No insulin -> cells can't absorb glucose from bloodstream -> high blood glucose + coma + wasting away.
Nobody can predict how much glucose you make from protein. Just too damn complicated.
I've never heard about Type-1 diabetics avoiding insulin through low-carb diets. From what I know about diabetes management (and I know a lot) that sounds incredibly dangerous.
Still, keto-genetic diets and even fasting, can be very beneficial, especially for Type-2, but patients need to keep track of their blood sugar. If you take insulin, you MUST check your blood sugar level, otherwise you may faint or go into a life threatening ketoacidosis.
But doesn't lack of data on glucose levels during ketosis with zero-glucose diets in type-1 diabetics seem weird to you too? As far as I know (obviously I may be wrong and I'm not an expert, just a curious person) once your body switches to ketosis it is fueled entirely by ketone bodies (which feels awesome according to my experience, but I'm not diabetic) and does not use glucose any more. I also thought it stops producing glucose from proteins too when in this mode. So this seems an obviously interesting area for research.
As I had Type 2 diabetes for a short time after a flu and because I studied veterinary medicine, I can assume to have a bit more data than you.
The assumption that there is no glucose used by your body when you are eliminating it from your diet is flatly wrong.
Firstly eliminating glucose and anything we can make glucose from (carbohydrates and protein) from a sustainable diet (= not using up your reserves) is next to impossible.
Secondly even when there is no protein and no carbohydrates in the diet, your body will claim the protein from your muscles and turn that into blood sugar.
Thirdly, some tissues in the body, especially the brain, just plainly need glucose. The body will make glucose, no matter what, even at the expense of destroying itself.
There is a lot of hype, marketing and simplification around ketogenic diets. Not all of that translates down to the actual physiology. Ketogenic diets are beneficial to diabetics, fasting will lower insulin tolerance, whether you are a diabetic or not. This is well known, and research is going on. There are even indications that fasting leads to more insulin production in Type-1 diabetic.
Can you reference any sources to confirm the body keeps producing glucose from protein once it has switched to ketososis (which you don't have to eliminate protein for, the diet just is to be lots of fats and some proteins) the brain always needs glucose and ketone bodies can't replace it completely? I don't mean you are wrong, you just are the first person I've met who tells there is glucose in ketosis (don't confuse it with diabetic ketoacidosis) and I'm curious to know for sure.
Note how both articles don't talk about fasting or ketogenic diets. Basic idea: even a low blood sugar level (let alone 0) is very very bad news. The metabolism will do its utmost to make glucose, even from amino acids. That's why even people who eat nothing don't have hypoglycemia all the time...
From my limited experience with this, it seems that all existing medical device software is closed source and are certified as executables - but I'm not sure if this is a limitation of the FDA processes, or the fact that they're intended to be closed source?