200+ People With Diabetes Injured After Software Drained Insulin Pump Batteries
cnn.com
cnn.com
I'm guessing the pump was already coded defensively to guard against whatever some shoddily coded app may try to do, but trying to anticipate every way in which the typical app developer is negligent is not easy. Constant reconnects draining your own battery is one tricky defect to deal with.
So if you're able to, you're going to go get another job. Because unless you're in the executive suite, the money isn't really worth the headache. Which leaves those who can't get another job. Which produces a Dead Sea effect.
From the other side, you may have people who really want to be in medical technology, but don't have the technical chops to do so. Which is its own problem.
So you have those who could do the task, but aren't interested in doing it.
Then you have those who are interested in doing the task, but can't do it.
Dang, I do not like Doctors as much as the next person (ok, Medical doctors, I am a doctor of engineering, I suppose, according to some piece of paper)... but you are just _jaded_.
I have met Doctors who understand full well that they do not know it all. Sure I have met conceited, full of themselves doctors who think they play god too. For the most part, people are people, and IMHO, on average, someone who went to get a terminal degree and did so with good teachers was taught good and well that they surely did not and do not know it all. I sure as hell know that I know nothing about life, the universe and everything, even though I have three letters after my name.
I agree with this statement, however:
>> Medical software often sits at a sad intersection.
Not sure what a good solution is.
And I've worked with various industries over the course of my career. Doctors, especially surgeons, on average, are a special breed of arrogant. Outside of working with them, they're fine. Just be prepared to fight for every decision, have to do it their way, have it fail, then have to do the thing you should have done in the first place, then convince them it was their decision in the first place.
As to the solution, I don't know it either. I think there needs to be that first person who can come in with that unique combination of desire, skill, and determination to do something. And that person will either be the person who figures out the solution or at least puts us on the path to finding one.
"FDA approved" should require an external verification process for every update.
It should also imply waterflow-like software development processes and safety engineering.
At the division between consumer and medical, no smartphone nor any malicious radio shall be able to induce denial-of-service or any sort of dangerous failure in any medical device in ordinary circumstances.
Integrating with 3rd party hardware (phones) is hard. I commend them for trying it, heck their new smaller insulin pump is 100% dependent on a phone for most uses.
Perhaps smart phone integration is convenient or allows for interactions that aren't possible otherwise, but devices like smart phones are not reliable - they run out of batteries, they get lost or stolen, they change frequently, and they can be compromised. If anything of any consequence - especially a life-saving device - is dependent on a smart phone or other consumer-level product, that is a serious risk.
Medical and other life-critical devices are held to very high standards with special development methodologies and testing criteria. Elsewhere, it's the wild West. Normally, general purpose software is poorly tested, riddled with known issues that were decided are not worth fixing, and has little to no security provisions.
When a commercial-grade application controls a life-critical device, it defeats all of the effort put into ensuring the safety of the device itself. Safety is only as good as its weakest link.