FDA recalls defective iOS app that injured over 200 insulin pump users
theverge.com
theverge.com
It's kinda terrifying to be honest.
The hardware experience is indeed better. Bundling the transmitter with the patch and the 30 minute warmup are great, and part of the reason why I haven't got the energy to switch back.
It seems pretty obviously they are using a cross-platform framework, the buttons and the way alerts are displayed is non-standard. Given that I've never seen a native app struggle so much with it's notifications, I'm going to go out on a limb and say that not dealing with bog-standard native APIs because they are running through a framework might be the problem.
Honestly, I kinda think Apple has some responsibility here too. They should reject these apps, or help the companies figure out what is going wrong.
This is what the 15/30% Apple tax is supposed to be for. I simply don't understand why they drop the ball so much when they're making a mint from developers (and consumers!).
So it's on Apple to basically become a shadow FDA and maintain their own panel of experts to second-guess the whole FDA review process?
They want to have health as a major feature of their platforms. To do that, they have an interest in making sure the most important health apps aren’t garbage.
I'm fine with more stringent requirements on medical apps, but that should be part of the FDA's review process. Their stamp should actually mean something. If it doesn't, the onus to fix it falls on the FDA (and by extension, the body politic). Apple not so much: their responsibility with health apps has more to do with safeguarding the data's privacy than with the reliability of the device.
Furthermore, if you think Apple is asleep at the switch when it comes to quality control, why would you give them the oversight responsibility for life-and-death-critical software? They should take a package digitally signed by the FDA, do the additional testing that actually is in their wheelhouse (such as data security) then if it passes, publish it as-is. Otherwise, back to the FDA.
As I described, I got stacked alerts, sometimes as many as ten arriving in rapid succession with inconsistent readings (Alert: 10.5, Alert: 7.3, Alert: 12.2... etc). Sometimes the reading would actually change while I was looking at the alert. Alerts are particularly unreliable when the phone is in some sort of sleep? I'm not sure, but if the phone is inactive for a while alerts get really flakey.
Dexcom clearly knows about the problems, they continually update the app, and keep say "we're still testing it!"
I've used it on two phones, same problems.
I'm never used an app with such basic problems in its functionality. So the idea that the FDA or Apple are keeping software quality up in this space seems laughable to me.
The same reason why software developed by individuals or small teams can be very high quality, while "enterprise" software is universally horrible; the former work in more self-structured and effective ways, but the latter usually involves tons of bureaucracy. This tends to introduction a selection bias to the types of developers who work in those environments.
Or is your point that only lower quality devs have jobs at those places?
And you end up left with only mediocre devs who just want to take the salary and be home by 5pm because they care far more about their family/hobbies/life more than the quality of the app they're building at work.
If your company relies on no-lifers to be successful, you’re running a bad company. This is a management issue.
I think it's amazing that in your mind this is a negative thing.
The economic prosperity that affords us the opportunity to spend leisure time with our loved ones comes exclusively from great creations.
You don't iterate fast or slow when dealing with this shit. You do it at the exact speed you need to to fully understand the domain, failure modes, validation processes, etc. Similarly, you don't write "awesome software", you write exactly what is needed -- nothing more, nothing less, and what is there needs to go bang every time.
There is no reason to believe an enthusiastic day-tripper who starts getting bored when the grueling FMEA, design validation, etc. starts to kick in is a better choice than the salaryman who's prepared to do what needs to be done for the next 10+ years of the product lifecycle.
I say this as somebody that worked on an unreleased product that was on the cusp of safety critical and am glad that it didn't go to production in hindsight. It desperately needed less "awesome" software and a lot more "paperwork".
Let me put it this way: If you had a team of EE's and ME's who all made between $150k and $250k, you would basically have the cream of the crop. A team that could make mars rovers or infallible pacemakers.
But a team of SWEs making that much? You get buggy weight loss apps and serially broken web access portals.
Doesn’t mean that competent SWEs will be destitute but salaries will probably trend more towards other typical engineering salaries—solid middle class professional salaries.
Sure, when the market was hot this was most likely the case, but not everyone lives in the Bay Area and the choice of jobs that _aren't_ like this is much more slim.
Man, every second thread is something like this; "It's the MBAs! It's the managers!". As if every single employee doesn't affect "the environment".
What do you consider your responsibility, as a developer? Just following orders? Why not have a little accountability?
I’ve known many devs, myself included, who do speak up about user facing issues we’ve been keeping an eye on. We’re routinely ignored, moved to a different team, or, in the worst case, let go.
The best way to affect change is to keep your head down until you’re in a management position.
It’s as they say, “the fish rots from the head”
The real-world solution to those situations is the company falters and learns or fails and dies.
Which is why monopolies and TBTF are so toxic to our workplace - bad employers who leverage suppliers/customers in a bad way and institutionalized workers who then move to other organizations and bring their diseased ideology with them make things worse for everyone.
In my experience working in enterprise software, we as the devs are far removed from any customer problems.
Those problems, when reported, go through some or all the layers of support engineers, product owners, and engineering managers and eventually get put on some every growing list of stuff to do.
The devs, being so far removed from customers, choose to focus on what they can see, which is usually just whatever feature was prioritized because big customer A was promised it would be ready by some date.
A single dev has no such barriers, as you were saying.
They ultimately get incentivized to contribute to the maze of "safe" processes, rule making busywork, and google docs writing for the next layer of management above them.
I couldn’t stomach working in management at a big org, personally
A few months ago, an update to Roche's DiabetLoop (DBLG1) created a thousand problems with emails recommending temporary tricks, subsequent updates, etc.
It’s unclear how such a serious issue didn’t surface during QA testing for a system that is, ultimately, fully under the control of the manufacturer (hardware/software).
I see a lot of effort to ensure the ecosystem is increasingly closed, touting the need for security of devices that can be fatal, but, in reality, there's little attention given. (And I say this because bugs and issues that everyone reports are always present, they're known, and they’re not being addressed.)
Manufacturers should have to submit their devices and software for certification of the technology before itself. Bluetooth and coding standards are mature enough at this point, and it’s time customers start demanding this from their products.
[1] https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPCD/cla...
[2] https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res...
I think a "sacrificial device" is the right way to make reliable the unreliable parts. Big battery for running the pump, small battery for the smart device connection. If something happens and you drain the auxiliary device it's annoying but not life critical. Your phone and pump can both alert you indicator light/notification that the auxiliary device died.
Should all be about people and not profit. These aren't difficult problems to solve. Nightscout is great, as is xDrip+, but pairing your device with xDrip+ gets you locked out of the vendor app and invalidates your warranty, which is a big deal as sensor quality is hit-and-miss and may come out of your arm before the 15 day window is up, so you won't get a free replacement if that happens.
I would love to figure out DIYing CGMs, but the enzyme-dipped probe is the challenging part.
Also, I don't think smartphones should play an active role in this space. As a means of reading data and perhaps modifying routines on a dedicated device? Maybe. But these things should all function independently of phones.
My phone does an update or runs out of juice? I stop getting CGM data until I unlock with PIN and use the NFC to reconnect. Happened to me last night in my sleep, so missed going hypo in my sleep.
Complete junk in this space, IMO. It's very annoying.
Why is this surprising? No one is willing to spend any money on it.
A developer can make $400K+ at a FAANG and work remotely. Or they can work on-site for a quarter that salary in a medical enterprise company.
FAANGs may suck at hiring good developers, but good developers are excellent at leaving shitty companies.
Want better experiences on this stuff? Start paying embedded developers non-crap amounts of money.
In any case, I was responding to the notion that the FDA was quality-controlling these things. They aren't doing a very good job.
So? If you want better software, pay for it.
This infects all embedded development--not just medical.
Everybody refuses to pay people what they are worth and then wonders why all their software sucks.
> In any case, I was responding to the notion that the FDA was quality-controlling these things. They aren't doing a very good job.
The FDA doesn't exist to ensure something is "good". It exists to ensure that something "does what it says" and "doesn't actively do harm". That's all.
If you want something to be "good", you will somehow have to ensure that there is pressure or money to incentivize such behavior.
(Also it remains weird to me that Netflix is considered a tech company)
The reality is companies like this often use minimum cost contract companies to develop the software rather than actually employing developers directly. They seeing software engineers (or any non managerial position) as purely an expense not the source of value in their products so you only get penny pinching on development and QA.
Basically this device was cleared through a DAG of other devices that were "substantially equivalent". I made a website to visualize these relationships, and any recalls that occurred in the parent devices. If anyone is curious about this particular device, see here [2]
[1] https://wcedmisten.fyi/post/medical-device-analysis/
[2] https://www.510k.fyi/devices/?id=K232380 (click on "Predicate ancestry graph")
Its well known you can infer the safety of a specification by assessing a small subset of its features. Quod erat demonstrandum. /s
But seriously, this is how backdoors are trivially integrated.
- approvals for version N + 1 are basically skipped, as is safety testing
- manufacturers get a liability shield
- for many classes of devices, ladder pulling implies that no one will ever get another v1 approved. (The current rules for that are impossible to meet, but the incumbent company is grandfathered in under the old rules).
The device still has to go through testing, validation and verification. It is a very detailed process and follows IEC spec. The device also needs IEC 60601 testing by a third party lab. In this case at least 60601-2-24.
The 510(k) means it is not doing something new therapeutically therefore it doesn't need to go through PMA process which so much longer and more complex. In this instance they're saying a pump that uses electronics to monitor and deliver glucose already exists. Our device does the same thing therapeutically but we do it differently and here is all out docs showing the device is safe.
If they came up with a magical patch that used quantum chemtrail energy to align the shakras and thereby affect the patient's insulin levels, then they would need to go through PMA and show the therapy is safe and works in small clinical trials followed by larger trials before they can make a device that can be marketed.
to correct your points:
- No testing is skipped (just trials
- There is no liability shield.
I have no idea what you are talking about with ladder pulling. Do you have examples?
For the specific case of blood glucose monitors, the 510k submission will require testing to show that your monitor is safe, and provides "at least as good" blood glucose monitoring compared to predicate devices. This allows the device manufacturer to avoid having to prove that blood glucose monitoring will improve clinical outcomes for patients with diabetes. Testing to show performance typically requires some degree of real world (ie, with real operators and patients) testing.
There are certainly be some cases where this gets abused, but overall I think it's a logical system.
Trying to enact a policy that a limits the number/age of predicates in a 501(k) application is impossible if you have no way to find them!
Im not sure why you would think that. The answer would take 5 minutes to answer with the PDFs (which is where the parent post got the info).
Additionally, not having the data in a structured format prevents seeing overall trends in the data.
The FDA already has information on product codes. here is the one for this device [1]. What is the useful trend and data one gets from grouping an iPhone app with a physical test strip for measuring glucose.
I think there is a lot of confusion in the general public about the 510k process is and what substantial equivalence means. Product drift is an intentional feature of the process, not a bug. 510k filing is not intended to be a single point control for safety and efficacy, but is implemented in context of other controls like medical device reporting and quality management.
Devices are primarily regulated at the device level, sometimes at the group level, but never at the lineage level. Im not sure what it would mean to trend and regulate as a lineage. Would that mean recalling a safe and effective product because of bad ancestor?
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfTPLC/tp...
The app doesn't respect Android's Do Not Disturb override list which essentially means I can't use DND on my phone. It's been the same on two phones, there are loads of reports on the Play Store reviews and on Reddit, so it's definitely a bug and not just me.
They haven't even acknowledged it's a bug, every time I'm directed to reinstall the app, clear the cache, factory reset the phone etc.
Enabling DND makes LibreLink instantly flash up a warning saying "Alarms aren't available."
It's the preventative action that would be interesting, but we probably won't see that.
The specific recall action in the FDA database is here: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res...
It simply says "Software Design Change" as FDA determined root cause... so super vague.
EDIT: Although the root cause might be software, it's possible that they did detect the crashing during testing, but did not characterize it fully, and/or missed a step in their risk assessment analysis to determine that it may impact battery life and therefore have risk of harm to life.
for context, there are about 200,000 formally reported events per year for pumps with alternate controllers in the US.[1]
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfTPLC/tp...
https://www.fda.gov/medical-devices/medical-device-recalls/i...
At least the Tandem doesn't require using the phone app; it's not an option with the Omnipod, which has no other way of communicating with the device. (you either use an app on a small handful of approved Android phones, or use a stripped down Android device they provide you; iOS approval is in the works, but not here yet)
Their App Store rules are arbitrary and do not resemble local laws. There aren't that many regulations for software anyways, except for a) medical devices and b) privacy stuff, which all apps have to adhere to in most jurisdictions, but under different laws.
You can argue that it is simply not Apple's responsibility to check compliance with local laws for apps. Developers are responsible for local conmpliance, but Apple must remove law-breaking apps from countries in which these break local laws, upon request by authorities.
[1] https://developer.apple.com/app-store/review/guidelines/#phy...
Zero. It's not Apple's responsibility. Google Play Store just asked developers to provide more information on apps in the categories "Health" and "Medical" [1], which is more than Apple did so far.
[1]: https://support.google.com/googleplay/android-developer/answ...
Eventually the app developers fixed it but, for something that’s supposed to run 24/7/365 without fail it really rubbed me the wrong way.
On a slightly tangential note, I am interested in working on something better although not hardware inclined, so please reach out to me at my username @tutamail.com if you are interested.
I ended up realizing something was odd with the app and tried uninstalling/reinstalling the app to fix it. Which did in fact fix it (at least temporarily).
Is that not the case?
Unfortunately, like many people have already mentioned, the software coming out for these things is usually trash and who knows how well an autocall feature would even work. I actually ran into this exact bug and wound up disabling the phone connection to preserve the battery.
Edit to add: Utilizing a telephone is a significant quality of life upgrade from my (and many other) end-user experience. I'm guessing you are not Type 1 Diabetic (apologies if I am incorrect) in which case you have no idea the number of times in a day that one checks their blood sugar, boluses, etc. Frankly, it's exhausting. Being able to dial in a bolus or view my blood sugars from my phone, versus pulling out my insulin pump, has a significant impact and provides significant benefit.
Safety critical software wants to be simple and self-contained. I don't work on medical devices, but I have worked with safety-critical software before. While I know compromises are always made in practice, I would naively expect an insulin pump's remote control to be a few hundred lines of very-intensely-vetted C running on the bare metal of a microcontroller. I don't understand what a general purpose OS (!) connected to the internet (!!) is doing in a tech stack that someone notionally had to prove was safe under a wide range of circumstances.
It may be paranoia arising from my particular background. I just find it very surprising that the sheer number of layers in an app is considered responsible and appropriate engineering for the use case.
Bureaucratic capture ensures that any technology produced in a regulated environment requires a large organization to produce it, ensuring the extension of the bureaucracy into that organization as well and killing off any contribution from people who care. Institutionalized apathy is slowly destroying our world.