I use a Dexcom Continuous Blood Glucose Monitor that pairs with this pump (I don't use the pump). And honestly, this is not surprising. The software quality in this space seems really low. I don't understand why some single-developer Mastodon client app can absolutely reliably get notifications to my watch but Dexcom can't. Even on the phone, the app cannot get alerts right at all, sometimes stacking them over an hour or more, but getting the current value for the alert, so you can get like five in a row (ALERT YOUR BLOOD SUGAR IS IN RANGE).
I don't understand why some single-developer Mastodon client app can absolutely reliably get notifications to my watch but Dexcom can't.
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.
I’ve never met a dev who is pleased to be working on a shitty enterprise app.
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.
The two devs I know who worked on enterprise software both ended up getting an MBA on company time to move into management ASAP so they dont have to write code in the awful system and they get paid way more.
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.
Devs have little to no control over what work we do when on large enterprise projects.
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.
So you're asking devs to fight a dysfunctional and possibly aggressively punitive organization?
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.
smart devs who like to iterate fast and build awesome software will leave rapidly when bogged down with paperwork and compulsory training courses.
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.
> 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.
I think it's amazing that in your mind this is a negative thing.
You don’t necessarily have to disregard family/hobbies/life in order to make great creations at work. One can still do great things clocking in at 9AM and clocking out at 5PM. It’s a myth that all great progress comes from Code Ninjas grinding 100 hour weeks, a myth that benefits companies and VC investors only.
Yes I agree - I’m just saying that there’s good things to be done at home and at work and the two must be in balance over the course of a lifetime, or else society decays.
Maybe, I'm not sure though. The "because" part is pretty directly saying that caring more about your family/hobbies/life than the app you're building at work is what makes them mediocre developers.
> smart devs who like to iterate fast and build awesome software will leave rapidly when bogged down with paperwork and compulsory training courses
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.
Something about this makes me cringe. Not sure exactly what. I think it's the idea of "iterate fast and build awesome software" as it pertains to high integrity systems.
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".
I don't think anyone here wants to hear this or understand it, but SWE work needs a hard reality check. I think a lot has been lost in the swirl of easy six figure salaries and recruiters constantly nagging you to jump ship and come work on awesome xyz. A downpour of VC money doing billion dollar shotgun blasts hoping to find just one gem.
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.
There are a variety of factors, not all of which may upend things but some probably will at least for certain classes of SWEs. Remote opportunities in lower cost areas, AI, and a glut of people who jumped in because that’s where the dollars were are a few that come to mind.
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.
I was here to say exactly the same thing but about another insulin pump system.
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.)
I’d argue that the regulation for ‘alternative control enabled’ (ACE) pumps [1] is too vague. These devices should be ‘designed to reliably and securely communicate with external devices’. These incidents were caused by the app crashing, resulting in the connection re-establishing itself frequently enough to drain the batteries [2]. How reliable should it be? Shouldn’t it include some stability measures?
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.
Reliability to the degree that medical devices need to be when you're sharecropping on someone else's shifting-sand platform is a game I'm glad I'm not paid to play. It in no way excuses the bad behavior, they chose to go this route and committed to the work it would take, but the results of the such certification would be outdated by the time you finish it.
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.
It's because one app is made by an engineering enthusiast. The other app is made by a company whose primary field isn't software, the executives are most likely wholely inexperienced with software development and/or sometimes nepo hires who then proceed to hire yesman middle managers or even outsource app development.
What faang allows remote work? What faang has average devs making 400k?
(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.
People working in their spare time make better apps than these. I don't think you need great developers, just ones that follow specs and use native development tools would probably do.
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.
> People working in their spare time make better apps than these.
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.
I use a Freestyle Libre and think the software is junk too. Lot of proprietary lock-in and trying to push you towards certain vendors in this space.
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.
I moved to the 7 and have no issues with the (iOS) software whatsoever. What issues are you having? If I had one issue with the 7 it's that it appears much more impacted by bluetooth interference than the 6. I suspect that this is a hardware, not software issue.
For the first few months, the watch would be 20 minutes behind, maybe 60% of the time. About 20% of the time it wouldn't have any readings at all and tell me to check my phone. I almost gave up on the watch (now it pairs directly with the watch it's more reliable).
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.
Software aside, how do the accuracy/precision of the readings on the g7 compare to the g6? Not having to replace/order a transmitter every 3 months, and a 30-minute warmup, seem like significant improvements over the g6.
Regarding accuracy, I don't know, because I never compare it to anything. Seems pretty similar based on how I feel vs readings when I'm low.
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.
I know that paired pumps have been slow to move to the 7 (only the Tandem has AFAIK; I'm currently on the Omnipod) and I can understand why from what you're describing.
No, I think that is exactly what happened. They wanted to merge their Android and iOS teams. I described one major bug (the alert stacking).
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.
> 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!).
If the App Store is meant to have some sort of quality control to justify it’s existence, then yes, they should reject apps this buggy.
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.
From the app's perspective, it's working fine, it's just sending commands that crash the device (and even then, the device recovers, but then it gets sent into a boot loop that drains the battery). Does Apple then need to test the app with the actual device, and revalidate it every time the device is updated? Do they need to hire the expertise in medical devices for such review?
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.
I admit I was overly dramatic in that phrasing. But there's only so much one can expect the platform vendor to do when it comes to things like medical devices. I'd rather the certification were by an (ostensibly) accountable agency, not the corporation taking a cut of the profit.
I recently did a writeup [1] on the 510(k) FDA clearance process (which cleared this device for market).
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]
The “substantially equivalent” approval loophole is a textbook example of regulatory capture:
- 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 testing is NOT skipped. This is a misunderstanding of 510(k).
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.
It isnt capture. IT is the opposite. Capture is how first movers and established players raise the bar for others. the 510k process does the opposite. it means that the FDA has already reviewed devices of that nature for safety and efficacy, and you dont need to do a clinical trial, you just need to do the testing
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?
The testing to show "substantial equivalence" are not generally trivial. The "original" device needs to show safety, and effectiveness versus clinical endpoints. The follow up devices need to show safety and effectiveness versus appropriate measurements. Some degree of safety testing and/or analysis is generally always required for medical devices, regardless of if its a PMA or 510k.
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.
Wow, awesome work! It's crazy to think about how the FDA itself probably can't answer a question like "how many predicates does device X have", but I guess also on brand with the idea that government is incompetent more often than not.
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!
For this particular device, there were 40 devices in the ancestry tree. While certainly feasible to traverse a graph of 40 PDFs and keep track of these relationships, it would probably take more than 5 minutes.
Additionally, not having the data in a structured format prevents seeing overall trends in the data.
I agree it would take longer to map them all. This is fine if you never need or want to map them. I've worked in this industry for 15 years and I have never had a need to do it.
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?
I reported a bug with LibreLink to Abbott about 18 months ago and they still haven't fixed it.
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.
Is the override set in the system, or does the app somehow know about it? I can imagine some developer misinterpreting how DND detection works and not sending a notification if it's enabled, though I can also imagine android's implementation being bugged in some specific way.
Kind of surprises me that something this easy to replicate and this pervasive (200+ instances is a lot of instances when you consider the size of the user pool) got through the testing. Would be interested to see what the FDA makes them do as corrective action and a breakdown of how this got into production code.
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.
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)
Apple already has tons of custom rules for different types of applications. Does anyone know which restrictions they impose on medical apps? especially ones that control medical grade devices?
Perhaps but Apple has always lagged behind Google on approving diabetes device apps (or severely limit the functionality). I know the Android version of the app for the Tandem had the ability to deliver bolus well before the iPhone version, and the iPhone version of the Omnipod controller app has FDA approval but still isn't approved by Apple
You can safely replace this with: Apple does not care to regulate apps at all.
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.
> Does anyone know which restrictions they impose on medical apps? especially ones that control medical grade devices?
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.
The tech is really hit or miss sometimes. I have a pump that used to panic error out on a misused bluetooth connection, forcing you to set it up again.
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 was personally affected by this, but it did not harm me. The battery drain was obnoxiously high (having to charge 2x a day instead of once every 2-3 days). I am always near a power plug so I was never in much danger of shutdown. However, I can easily imagine how others would be.
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).
"Battery low", "blood sugar too low" and "blood sugar too high" all sound like warnings that should be acknowledged by the user within 5 minutes, and if not the device automatically calls an emergency contact or emergency services...
Good lord no. If that were the case, my emergency contacts would be getting called at least once a week on my drive to work. However, seems reasonable to have that as an option.
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.
Well, yeah. Controlling things with an app may seem like a sensible and efficient design given that the user already has a phone, but it seems outrageous to pull a whole phone's worth of complexity into the problem from a safety or security engineering standpoint. I'm genuinely surprised they're allowed to do things this way. Next you'll tell me the autopilot on a 737 runs as an app on the pilot's personal phone. The entire prospect seems to me approximately that crazy.
I think you're greatly overestimating the problem. The only action a user can take in the app is to give a bolus. This is a relatively (1-2 years?) new feature that I believe necessitated FDA approval. Everything else is surfacing information (blood sugar levels and notifications) to the end user.
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.
Software has different risk classes. Controlling a 737 has vastly more requirements of the operating system / runtime environment than an app that controls a small thing for a single person. What might be ok for one risk class is not ok for other risk classes.
That's exactly what I'm trying to say! By virtue of its being able to seriously injure you, software controlling an insulin pump is safety-critical software. This should make it more like an airliner's fly-by-wire system than like a toy rc car's. Not in terms of complexity or resource usage, but in terms of development philosophy and rigor.
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.
Just another piece of critical infrastructure or technology that’s suffering enshittification.
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.
From the look of these bugs, like this one but especially the other race condition bug that suggested 10x the user's input dosage, I'm gonna go out on a limb and say formal verification appears to be used little or none..
Smartphones provide a very easy and reliable way to have people interface with such devices. It can be done right, but you have to be careful. I'd rather that medical device manufacturers use well-known frameworks and technologies with almost two decades of engineering and UX improvements behind them than the alternative, which is them using some sort of slapdash in-house solution that will almost certainly be worse.
> Smartphones provide a very easy and reliable way to have people
interface with such devices.
I deeply disagree with you and think this encourages reckless
engineering and is a dangerous attitude to take.
Ease of use and reliability have nothing to do with each other. One
should not be used as a cover for defects in the other.
You may enjoy "ease of use". But smartphones are extraordinarily
complex devices that concentrate far too much functionality and risk
in one place without safeguards. They come literally "compromised out
of the box" with poor decoupling between subsystems like RF, memory
and processors.
If a medical device is not easy to use, you risk the patient not using it as a part of their therapy, or maybe even using it wrong to disastrous effects.
The alternative to a smartphone connecting with one of these devices is likely a proprietary interface that's worse in every measurable way, and could be just as compromised, if not more.
So, given two equally horrific options which can lead to the tragic
death of the patient, surely the correct course would be; Don't do
either.
Just because you can doesn't mean you should. We are not compelled by
any natural law to add gratuitous digital technology to problems which
are only made worse by it.
If patients didn't think this added something to their lives and ability to manage insulin-dependent diabetes, they wouldn't be paying far out the ass to get them either in direct costs or through insurance premiums. That's not what people do. I'm sure plenty of patients would much rather do anything else with the money. I know I would with the money I spend on chronic health problems.
Again, completely possible to do this right, but you have to be willing to put the resources into it.
That's what it currently is. Omnipod used to/still provides some kind of rebadged Android device.
Zoll was shipping various Android handsets with the bootloader unlocked and a custom APK built to take over the device to act as a 'hotspot' for their defibrillator vests to provide remote telemetry.
That's what Omnipod does. Their app is only approved for limited Androids, not yet for iOS, so many users depend on the device they provide which is pretty much what you're describing. Not sure what the hardware is, but it even has a camera that isn't used.
That was 40 years ago! What lessons were learned from that are even relevant to this? Should I be worried about early days development lessons today or the billion of lines code dependency for a simple medical device? You are aware of the trillion dollar target on the smartphone back? You want to incorporate that into you medical device for what possible reason?
The way that Apple added blood oxygen sensors to the Apple Watch seems instructive in showing how things have changed.
It's not a strictly a medical device -- with explicit disclaimers to that effect -- so making a diagnosis based on only those readings isn't something they would stand by. Defer to the experts.
Masimo's case seems to be looking for an answer to part of this question, determining whether or not the patents apply in nonclinical settings. Regardless of that outcome, it seems like there should be a legal distinction between these two classes of products as most reasonable people would argue they serve very different purposes.
The lesson is, business people will gladly let safety lapses occur with software because
1) software is complex and they don't understand it, and
2) good software is expensive, and they would rather that money go in their bonuses than into a real testing and verification budget, so they'll get less-than-qualified people to do the job for less money.
Those rules will apply to your non-smartphone device sure as any other device.
Smartphones are a juicy target but they're also fairly hardened for the case of one person's use. It's a scary thought, sure, but there is a dearth of attackers who have exploited security or reliability weaknesses of these devices to injure or kill someone in the wild. Most of those guys are far happier making credit card scanners, social engineering their way into your bank account, or helping Russia evade sanctions by holding your data hostage in exchange for crypto.
Contrast that with some sort of microcontroller-based device that hasn't had 15 years of security research done on it, and definitely won't at any point because the device manufacturer doesn't have the will or ability to make that sort of thing happen.
And then you're going to get into the practicality of that sort of device. People take their smartphones with them everywhere. They will not forget the thing that helps them manage their medical conditions. I'm less likely to remember to put the random weird device in my pocket when I leave the house or keep it charged.
It's a better solution to the problem if you do it right.
Source: 10 years of personal experience in the medical software industry.
> The lesson is, business people will gladly let safety lapses occur with software because
I'm going to stop you right there and refer you back to the 4lb hammer. If you are being pushed around to build violently shitty stuff you are part of the problem.
It's kinda terrifying to be honest.