Are you planning to make a disclosure regarding that statement, such as being co-founders with Quentin Adam, the founder of Clever Cloud, in other projects?
Stuff like this should always be disclosed. Something like "My co-founder / friend built ..." would be totally fine, but this comment looks like it intentionally obscures the connection. Not a good look.
> Other project meaning being contributor to open source together?
Other project meaning actually founding that project together [1]:
> The Makers for Life collective and project were founded by three entrepreneurs in Nantes. Quentin Adam (CEO Clever Cloud), Baptiste Jamin and Valérian Saliou (Co-founders Crisp) [...]
You live in the same city. You founded a project with him. It's not like you have submitted patches to Linux from different parts of the world, without ever seeing each other.
I don't want to sound like I have something personal (I didn't even know your names until yesterday) but your assumption that the readers here on HN have no clue makes me sick.
If you know each other, that should be disclosed. I have no qualms about recommending a friend's startup, given that the friendship is disclosed.
I have moved my side project (single server handling ~3 requests/s) from Heroku to Clever Cloud about 3 years ago and they work very reliably for me.
The truth is, on this scale Heroku worked well too. The reason to move for me was that they are an EU company so there is less questions from my clients about GDPR compliance.
I'd say the UI is quite old-school and I am missing good built-in metrics. There are some paid add-ons providing metrics but I'd really want to have it built-in.
I don’t really understand why this information is now #1 on HackerNews.
Boeing 777 engines are the world’s largest turbofans and pw4000 Engine, involved in this explosion is in production since the 80/90, and is already used on other Airframes like a330.
I know this accident looks impressive, but engine explosions like this one are things that happens years over years.
On Airbus a380, similar explosions occurred.
This kind of explosions looks very impressive, but those are things that happens quite a lot in aviation Industry.
Don't worry, the breathing system does not rely on the Rasberry at all.
We use an electronic board that was made on purpose by a Medical company and relies on STM32 hardware.
This board sends telemetry to the Rasberry PI and we have a Rust based interface that shows charts and some controls.
If the Raspberry fails, the Firmware still run fine, and you can still change the settings on the machine using physical buttons and a LCD screen that is directly connected to the firmware
A good friend of mine had the experience of nearly dying after a mobile ventilator in an ambulance failed after he was involved in a serious car accident. It was later found that the ambulance operator was using devices that hadn't been cleared by the FDA yet. Although they came from a Turkish "medical device" company, they were not cleared for use in the US and left my friend with brain damage and PTSD.
I don't care that the hardware involved in your project was "made be a medical company", it's not hardened tech. Also, rust is by no means hardened - look into "provably complete" languages if you want to see what a true "hardened" lang is. There's a reason why medical devices and serious "hardened" tech (military or otherwise) is validated and cost tens if not hundreds of thousands of dollars. It's because teams of engineers spent weeks or years coming up with every possible problem or failure pattern.
To be frank, I'd rather pay a nurse $50k in cash to pump a vent bag next to me than rely on your "project".
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.
> If it is approved, sure it can save life everywhere in the world.
It's worth noting that mostly regulatory approval is jurisdiction specific, so the device will need to be separately approved by a bunch of different bodies. ANSM is the french local body, but it is EU MDR you probably have to meet; this at least gets you the EU countries but for example will allow your device to be used in the USA, you would still need FDA there. Some jurisdictions, particularly smaller ones, will rubber stamp things if you have the right approvals but it's still finicky and of course with a physical device you have to deal with things like different power standards.
The approaches are similar but annoyingly different enough that this isn't easy. Luckily they are both reliant on ISO13485 at core, so there is overlap. It's not just paperwork either, you can definitely design something that will not pass in another jurisdiction if you aren't careful (e.g. due to materials used). Further, you need separate certification to a standard as both a manufacturer and developer, and these don't carry over automatically either.
People are working on making this easier to do worldwide, but it still isn't easy. For example you can use MDSAP to get a regulatory audit that meets multiple countries requirements at once.
How big portion of these approvals is to have right people to get paid and to actually make sure the product is safe? We're the any "blunders" like with Boeing?
I agree that this project can be incredibly dangerous if people try to sell them in countries with well-developed, well-tested systems of healthcare.
However, billions of people don't have the luxury of tested and verified medical devices. The price of a single machine might be close to the monthly budget of the entire hospital. In those cases, any small hacks are welcome if they can help save a patient's life. A crappy, half-decent ventilator is way better than no ventilator at all. Until rich countries start buying hospital devices for poor countries en masse, providing cheap alternatives to proper medical devices can save lives.
The company behind this seems to be French and if it ever gets used in France without certification then they've probably got a huge lawsuit and potential criminal liability on their hands.
According to the project's website, they are trying to comply with European medical regulation (if Google translate got that right) and their Github mentions they're working with regulators. This isn't a hobby project by a bunch of bored students, the project seems to be a proper attempt at making capable medical devices that can be extended upon without IP problems.
While I don't disagree with your overall sentiment (I can't imagine relying on a RPi powered device -- even if it is just a display -- for clinical use), I think you're overthinking the motivation here...
> To be frank, I'd rather pay a nurse $50k in cash to pump a vent bag next to me than rely on your "project".
From what I've read (admittedly not much) -- this project isn't trying to disrupt the ventilator industry or make a bunch of sales. It isn't designed to give you a choice of a ventilator to remove a nurse. It's for situations when you don't have another choice... for when a hospital has run out of proper ventilators or there isn't a nurse available. This is not a first-choice device (even if it could be adapted to that in the future).
Our initial design was mostly based on 3D printed SLS bio-compatible parts.
The current design is still 3D-printable, but we had to go with metal valves for instance for long term usage, and mass-proction. 3D printed parts just don't scale.
When possible, we replaced some 3D parts with on-the-shelf parts, for instance for the medical 22mm tubing connectors.
Those makers chose this solution because it was the easiest way to do a ventilator if a few weeks.
This idea is bad because it creates many different problems:
- After 30 minutes, patients will start having high C02 levels
- It spreads the virus in the hospital room
- It can clog
At the beginning of the pandemic, we choose a completely different design and started something from scratch.
Our goal was to make a very safe ventilator, so we could be confident our ourselves, our parents, our family would have to use it.
We asked doctors, specialists, we quickly figured out that the best design was using a turbine design as most emergency ventilators come with turbines.
The big challenge was to finely the pressure very accurately: so we needed valves to manage the airflow.
All the Airflow systems needed to be biocompatible and no pressure valves existed on the market for that purpose.
We tried many ways doing that and engineers in the team found that the best way to make those valves was doing a "Pinch Valve"
The idea is you have a medical-grade flexible pipe, which is pinched using an excentric valve. This way you can finely tune the pressure.
Researchers and doctors tested early prototypes and they found the design was smart and very promising.
It was tested on very complicated lung simulators, and then two pigs.
Following those studies, french authorities started to look at our project and gave us funding (around 500k euros). Allowing us to have access to 2 ASL 5000, the rolls of lung simulators to try our prototypes.
Many different local companies (engineering, manufacturing) help us as well.
A complete team (5 people) made internally all the paperwork for French Health Authorities so they can approve clinical trials.
After a few months, the Makair was approved for Clinical trials and 2 hospitals started to try it on patients.
Meanwhile, we are working on CE marking and production lines. Multiple countries are interested.
If we had to start again, we would choose the same design.
thanks for sharing so many details about the process.
1. quality controls for medical devices are necessary since they can be fatal as you said. that said, are there ways of accelerating the certification/control process without sacrificing quality?
2. it sounds like you had access to great local talent. how could we improve the collaboration process so other people could contribute to the design process?
3. if you were the head of the EU, what's the first change you would make to improve the innovation cycle for medical devices?
1. What we did is we worked on certification and on the eneenering at the same time. We figured out that it was easier to certify an hospital ventilator rather than an emegerncy transport ventilator. An emergency ventilator needs to support 15G (so around 330KG in our case) accelerations. Quite a lot :) So, we choose to the "hospital ventilator" regulations then.
We unit tested everything using a lung simulator (ASL 5000) and that was a great help. When you can try your ventilator in almost real condition, that is change changer.
Then, we tried to make our ventilator exactly as an MVP. We implemented very few features at the beggining. Something very minimalistic. Only pressure control. It was our first version, and was certified for clinical trials in June. First patients in July then.
It's only later than we added new features, LCD Screen, new sensors, new metal valves, to make the ventilator better. We filed all the paper work again, and it got approved in september.
2. We used Slack. It works great, but at some point, we had to work all together. 30 people were lockdown together and worked in March/April on this project. It was a non-stop start-weekend and we slept only 5 hours per night, during more 30 days.
At the beggining of the project, we struggle on two essencial parts : Making the turbine, and the pressure valves.
Multiple engeenering teams work at them same time on different solutions. We used up to 30 3-D printers, lent from people/company.
At the core, we did all the integration tests, and tested all the solutions from the mechanical teams (different turbines / valves), as well as the software, electronics.
At the end, we had the right turbine, the right valves, the right electronics, and we just had to make integrate everything on the software.
3. The hardest thing was the software. Most of us are software developpers and we are used to deploy continuously. You can't do that here. You need the perfect software, immediately.
You can't do an OTA update on all the ventilators.
During the certifiation process, we had to change the software to do many improvements. I think regulatoriy authorities don't understand how software works. That was the hardest part: Explaining them that a software they don't understand is actually safe.
It is something that needs to change, because in the future, we will have more and more sotware in medical devices.
> [Software certification] is something that needs to change, because in the future, we will have more and more sotware in medical devices.
I think this is wrong thinking. Software which drives safety critical systems needs to be perfect, and that is an impossible bar. Whether or not such a target is achievable, it is much MUCH harder if the software is under continuous development. It needs to take enough time to do it properly, and therefore software for critical systems ends up basically being your MVP. It does only what it must, but it does it right. You really don't get a second chance on safety critical systems.
