Monitors and tests don't need to be perfect to be useful. If you were a doctor running a poor rural hospital, would you rather have:

1. No monitoring, or

2. Monitoring that fails to alarm for 50% of events.

If you have plenty of staff, maybe you'd prefer no monitoring, as it's worth than having someone sitting next to each bed. But that's probably not the reality of the situation.

I could be wrong, but I'm not convinced RaspPi is better suited for the task, even cost-wise. SoC are cheap these days - I have zero evidence to back this up, but I would wager most of the "cost" associated with e.g. ICU monitoring devices is strictly to non-technical aspects (brand name, margin, etc.)

In theory, an open source and safe design is definitely feasible. I just wouldn't marry "safe" and "raspi" on most days.

Sure, at scale there might be better options. But it's probably easier to develop a prototype on something like a Pi, than on an ESP32 or other development board. Because you can plug a keyboard, mouse and monitor into the Pi.

That's not how you develop embedded stuff normally. You usually do that over some serial line to control the remote debugger-related interrupts and whatnot and drive it via GDB. You can also emulate many SoC's via Qemu, Bochs, etc. (to varying degrees) during the development process.

Further, you don't run hard realtime applications on a normal OS. Preemptive multitasking can cause a userspace program to drift out of sync, or have other side effects - for example.

There is a pretty well known RTOS but the name is escaping me.

You wouldn't really benefit from prototyping on the pi as a lot of that software has to be purpose built for the hardware.

RPi+Linux+sensors has an easier learning curve, and is accessible to people with a wider range of backgrounds/skills.

I don't disagree with you, it's just that medical equipment that is critical (e.g. ICU monitors) would benefit from real, robust hardware. It's not about learning curves.

You'd be surprised. When I started my career in medical devices, we specifically based our product on Windows & C++ in part because it was a well-known platform and we would have no trouble finding developers. That system, and its descendents ran on off the shelf single-board Windows PCs.

There is a lot of medical equipment out there that's running Windows. FWIW, I have one next to me right now that uses Linux for its UI.

> It's not about learning curves.

When it comes to experimenting and prototyping I think it is. The lower the learning curve the more cross polinations take place, projects and ideas get shared.

Clearly RPI is not optimal for clinical machinery that is supposed to run unattended by engineers in the real world but for prototyping why not?

Because there isn't a lot in the way of "prototyping" necessary. We already know how to effectively monitor patients. A lot of the shitty parts are actually in software and licensing and process - not hardware.

If you "prototype" for raspi, you will have to completely start from scratch if you want to manufacture reliable devices later on. It's not like porting a program from one system to another.

Go build it!

> Monitoring that fails to alarm for 50% of events.

As Waymo found out early on - unreliable automation may lead to counter-intuitive results when people put too much trust in such systems, as humans do. It is in the realms of possibility that patients will get worse outcomes because doctors/medical staff are paying them far less attention than they were without any monitoring.

Although that would be the end game, trying to get off the ground would be much easier with a RPi

I agree. Nothing running a GPOS is suitable here.

But do those include graphical capabilities, USB connectivity, jack for alim, etc. all-in-one and for a few bucks? I am aware medical devices should provide guarantees, but a smaller guarantee is still better than none at all, innit? For context, in many countries people are simply left to die in the most atrocious ways if they cannot afford care. You should see how african people react when they're admitted to the hospital, even in developed countries.

> but a smaller guarantee is still better than none at all, innit?

Raspberry Pi comes with no guarantees at all and has well documented problems with flaky power and burning out SD cards. It works great for the hobbyist/learning system that it was designed for and might even be good enough for the blood testing system in the article, but active monitoring for intensive care? Just...no.

I'm no expert in this field and was genuinely asking, but if someone knows of better things then please go for it!

The raspberry pi will be a very capable CPU for a medical monitoring. The issue is the sensor and the power unit. Isolation is very important and the sensor reading needs to be correct.

It's certainly a fair question. I don't work in medical devices, but know people that have, and the problem for medical hardware has two steps: One, build something that won't kill the patient, and then step two is proving that you're correct about step one. Step two is the expensive bit.

Yes. For example, most of the STM32 lineup has builtin USB support, and can connect to displays through a range of protocols.