Edge cases. Accounting for all the outlying scenarios that can result in the product malfunctioning, and then Q&A-ing it is what takes a huge chunk of an RnD budget. For normal software...
Edge cases. Accounting for all the outlying scenarios that can result in the product malfunctioning, and then Q&A-ing it is what takes a huge chunk of an RnD budget. For normal software development this can get kind of expensive. When you deal with a product that can affect a person's health, the standard goes way way up along with the expense of meeting that standard.
If 1 out of every 100,000 smartphones will crash when the user connects to WiFi, that's an annoyance. If 1 out of every 100,000 artificial pancreas crashes when the wearer lies down, and they die, is that acceptable? That's a really hard question to answer, which is why we have things like the FDA in the US and the EMA in Europe.
The folks doing DIY though (hopefully) have had to learn a bit about the thing they're building, how and why it can fail, what to watch for, and are willing to accept the risks.
A person who receives a medical device from say, a hospital, does not consider any of these things and they shouldn't have to. They should be able to trust that the device will work reliably, and has been proven to work to working a high degree of certainly. Achieving that level of certainly is what costs money, not the cost of the physical product.
Source: am a software developer who has worked on products that needed to clear FRA approval
In 2011 Medtronic, a major manufacturer of insulin pumps. was told by security researchers that their wireless link was insecure. Future devices closed that security hole, but the existing devices were never upgraded. This left thousands of pumps in circulation.
So why is it so difficult for there to be a professional system for this? Is it because the risks are high if it malfunctions?
You need to write code to handle timing that must work correctly 100% of the time.
Edge cases. Accounting for all the outlying scenarios that can result in the product malfunctioning, and then Q&A-ing it is what takes a huge chunk of an RnD budget. For normal software development this can get kind of expensive. When you deal with a product that can affect a person's health, the standard goes way way up along with the expense of meeting that standard.
If 1 out of every 100,000 smartphones will crash when the user connects to WiFi, that's an annoyance. If 1 out of every 100,000 artificial pancreas crashes when the wearer lies down, and they die, is that acceptable? That's a really hard question to answer, which is why we have things like the FDA in the US and the EMA in Europe.
The folks doing DIY though (hopefully) have had to learn a bit about the thing they're building, how and why it can fail, what to watch for, and are willing to accept the risks.
A person who receives a medical device from say, a hospital, does not consider any of these things and they shouldn't have to. They should be able to trust that the device will work reliably, and has been proven to work to working a high degree of certainly. Achieving that level of certainly is what costs money, not the cost of the physical product.
Source: am a software developer who has worked on products that needed to clear FRA approval
Via hackaday: https://hackaday.com/2018/08/09/homebrew-pancreas-gets-30-minutes-of-fame/
Oh, Hackaday, never change.
They're also helping to revolutionize data sharing: https://openaps.org/outcomes/data-commons/