Hacker News Reader

Comment by rscho | Hacker News Reader

What would be really cool and useful would be an open source bedside (ICU/OR) monitor. RPi would probably be a good base, I guess...

View on HN

No way. Medical devices need very strong guarantees. RaspPi does not offer those. You want a cheap RTSoC.

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!

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.

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.

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

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.

> 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!

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.

> 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.

I agree. Nothing running a GPOS is suitable here.

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

Stuff like this is always cool and gee whiz, but it will never muster in the US that I know of, and I suspect most developed countries.

Anything on the bedside, especially in ICU, has to be examined by the FDA to the point where they want to know exactly what the chemical composition of parts are. If there's a risk of things releasing fumes that might be dangerous for a sick patient if the device gets too warm, they'll ding it. Diagnostic software powering these devices are scrutinized by the FDA, too.

Of course it would never do in developed countries! For context, I work with such monitors daily in a (very) rich country. I was thinking of the most backwater context you could still find use for it. Some parts of Africa, for instance.

Ah yes, in the US they can't occur the risk of "fumes" from an affordable electronic device, that's why they need to charge people a year's income for a minor emergency room visit.

Never mind the fact that for millions in the US the air is toxic, the water is full of lead, and the food full of agro-toxins. But they are lucky, because the FDA makes sure medical devices don't release any accidental fumes and they only cost 2 or 3 magnitudes more than they need to.

I suppose a parallel would be a Mars Helicopter based on off the shelf components vs making one of radiation hardened components.

It may work, and it may work very well in fact. However, if you can afford it - you'd opt for something with more reliability and consistency.

In economics, the most important question is "as compared to what?" You might be able to afford a gold plated system designed with 15-9's of reliability, but do you want to work 10 hours week to afford that system? On the margin, do you want to have a 10% smaller house to pay for that level of medical awesomeness?

Not Open Source but relatively cheap : https://shberrymed.com/products/patient-monitor-pm6100

A company called "Anidra" (Australia + India) is offering the full package (HW based on the PM6100 and cloud based Monitoring SW) both for Hospital and Home use: http://www.anidra.com.au/ and https://www.anidra.in/

Weird choice of name Anidra in Hindi means sleeplessness. Nidra is sleep, anidra is its opposite.

On second thought, I think they are probably implying their devices (or they themselves) do not sleep.

Let’s do it!

Reply on news.ycombinator.com