it will be so budget friendly, i am sure many hospitals in the world can use it...
Long answer : In this project, Raspberry is used to display curves and set some parameters. The core (ventilator algorithm) is implemented on the STM32F411, there is just a serial link in-between.
The STM32 also monitor the Raspberry... If there is no heartbeat on the serial link, the STM32 shuts down the power supply of the raspberry, and ventilation goes on.
The fact is that it never happens yet during our tests (4 months uptime now for some devices). The ArchLinux is restricted to the bare minimum, and the Rust app do not overheat the CPU. Is it by chance, or not ? Before any MTBF conclusion, you need thousands of units running during months...
On another project of medical datalogger, I also put a little arduino as hardware watchdog. If no heartbeat of the main application, it just resets the Rpi.
I also use industrial SD card, which are far more reliable and provide SMART informations. See another article on this subject: https://blog.senx.io/a-10-year-warranty-thanks-to-iot/
The great thing about the Pi in this case is that it's non-critical, and if it ever does die, you spend $35 and put in a new SD card.
And to be honnest, I understand their point. How can you certify Linux ? So much code behind... It is not a car multimedia center, it is a ventilator, a class III vital device.
In this project, what was really impressive is the gap between the bare minimum (a 4 lines lcd screen + a few buttons + a pressure sensor, and you can make people breath), and the doctors expectations (curves, flow meters, statistics, O2 sensors...).
This is the same for lots of activity: experts cannot work with basic tools anymore. Only High level experts still can.
Conclusion: do not work with high level experts to build your specifications. Also listen to normal experts and doctors that needs more UX assistance.
Do you think relying on something like a hospital-provided tablet would have worked? Was this considered?
I mean, having that many screens may be a bit redundant, if you can have a single high-quality one. That said, I understand it introduces some complexity due to wireless protocols, paring with the right ventilator, etc.
In our initial requirement list, it was designed to be used in temporary hospitals (any public hall for example).
Screen convergence is not for now in hospitals. Behind one sensor, there is one company that sells its monitor with the sensor. Some old well known sensors now converge to one monitor (philips, edwards life science...), but there is a still one screen for every other functions.
Gathering data (when the constructor made it available) is a mess... look at HL7 specs! To build a medical datalogger, you sometimes must interface to an analog output (it is part of my job).
By the way, most monitors runs windows CE behind. Which is also a problem now: https://www.integrasources.com/blog/windows-ce-end-of-life-m...
I can see the convenience of using UART but as a very cautionary advice, hospital environments are electrically quite harsh in terms of EM noise. A serial line even a short one can absolutely suffer from interference.
You already made it relatively fail-safe with the heartbeat/watchdog but please consider upgrading your design to use comms with a differential signal, anything like CAN or even RS-485 in that Rpi/STM32 link would be a significant improvement.
A low speed 115200 baud link does the job, with applicative CRC on both side to be sure there is no corruption.
My method to test communication robustness: I inject pulses through a capacitor directly on the UART lines. I did it on this project, no problem. The four bytes CRC32 prevents random EM noise errors.
STM32 telemetry code is here:
https://github.com/makers-for-life/makair-firmware/blob/mast...
Pierre, author of the article.
Also there are CAN hats for rPi (SPI) or USB<->CAN bridges (using slcan protocol and Linux driver).
Sounds like a fun project!
I've seen 18 months before, but that was primarily software. I think the FDA clock on evaluation is 120 days now, that's after all the i's are dotted and t's crossed. EU MDD/MDR is similar, iirc.
Congrats on getting something together quickly!
If this is the case, then this would make the reliability much better and there is a chance it could be useful to many places. If the SD card on the Pi dies (which, if they are logging the data to SD and not RAM, is a likely event), then they can have spare SDs available as part of the standard operating procedure. It's not ideal, but so long as the main microcontroller is functioning, the display could be considered non-critical. Although, ICU staff might disagree...
We planned to develop a small gateway to gather all the devices alarms, linked to bed number. It was not developed, but hardware has the feature.
The LoRa fairness will allow very few data to come up, but high level alarms vital could be transmitted several times in a second if needed.
We know we cannot use it to transfer waveforms of course.