3 ms·

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 pu

by Dove 2y ago

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.

jnsie 2y ago
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.
WA 2y ago
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.
- Dove 2y ago
  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.

by Dove 2y ago

jnsie 2y ago

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.

WA 2y ago

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.

Dove 2y ago
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.