[panabee]

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?

[baptistejamin]

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.

[jimmyswimmy]

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