Yes we are :)
The first days were fun. Then the french government pushed the project. Challenging, crazy, but exhausting. 25 days without coming back home!
Then the lockdown did the job, and the project was not so urgent, so the ANSM (french equivalent of US FDA) was not so in a hurry. And now it seems to take ages for us between two administrative steps, but it is still fast for ANSM. Development of a ventilator take normally a few years!
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).
Problem with vent bag is that you cannot maintain a positive expiratory pressure (around 10mmHg of pressure during the expiration to prevent lung to collapse alveoli). For Covid-19, all the projects based on mechanized vent bag where useless because of the type of disease.
There are several companies behind the project. The company who makes the electronics is Tronico (https://www.tronico-alcen.com/en/markets/medical). It has all the medical certifications needed.
We are currently going on with ANSM certification (equivalent of US FDA). It is a long 2 years way, with lots of papers and tests... If it is approved, sure it can save life everywhere in the world. If it is not, it was a project where we learned a lot.
By the way, ambulance ventilators are harder to develop and to approve. Hardware must resist huge shocks and accelerations.
I'll be very happy for my industrial projects if BCM2711 come with CAN or RS485 built-in, but for the moment, there is nothing planned by Raspberry...
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.
As far as I understood doctors, in march there was no guidelines for the disease. It was considered as a respiratory disease.
Later on, it was requalified as a vascular disease, scientists looked at cytokines / interleukin (I AM A ELECTRONIC ENGINEER, please correct me doctors).
As soon as ANSM (french equivalent of US FDA) hears "linux", "wifi", "connected", they see a scary green monster...
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.
Short answer is no, I don't trust Rpi for vital tasks.
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.
If you're in the middle of a world crisis, and you need a small computer + touch screen, Rpi is THE solution. Farnell and radiospares have tons of stocks.
But the kiss approach was great here.
WarpScript includes all you need to render text, vectors, images... The limit is that I cannot use the touchscreen.
With this little SPI screen, there is no GPU behind, so no way to use DRM. If you want to run X, you also need to use framebuffer turbo driver. So everything goes through the framebuffer anyway.
The fun here was to use only Warp 10 database on the system, the only time series database that has built-in image creation function in the language. Normal use is to build heavy dataviz on the server, then return a base64 encoded png.
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.