by Robert L. Read and Nariman Poushin

In just the last four weeks, thousands of engineers have self-organized around the problem of designing, testing, manufacturing and deploying ventilators to address a present and possibly worsening shortfall of mechanical ventilators required by the unusually virulent and transmissive COVID-19 pandemic.

An even greater effort has worked to provide personal protective equipment, as is fitting; we each have our own way of helping. As is also fitting, large firms have begun manufacturing ventilators, and existing manufacturers have increased production, either by themselves or in partnerships. This increase in production may meet the need, at least in the wealthier nations. Personally, I believe that even if this is probable, it is far from certain. Therefore as of April 7th, there remains a pressing need for open source pandemic ventilators.

In less than a month, there has been a lot of learning. No less than 70 projects world-wide were begun and made some progress, which we have attempted to analyze and track in various forms. One of these, the AmboVent from Israel, is close to being both clinically acceptable and easily mass-produced. Its plans are freely open-sourced so that any nation or firm may build them.

I have personally learned a lot about pulmonology. I daresay many other engineers like me began working on the problem before fully understanding the subtlety of attempting to build a life-critical ventilator to treat a desperately sick person with the worst COVID-19 symptoms, the ARDS-like phase. You can’t solve this problem with an oscillating leaf-blower.

This is natural, because when they began, the communities supporting and connecting the engineers were less strong. People felt like they could be “the“ solution instead of being “part of” the solution.

But since then many organizations have been established or refocused: HelpfulEngineering (at least 16,000 people) and EndCoronaVirus.org (4,400 people), DIY Ventilators, Pak Innovation Club, Ventilator Crowd ,#industryvirus, 1 million Ventilators Project, 1M Ventilators, Global Ventilator & PPE DIY Collaboration, #EngineersAssemble, The Ventilator Project, and the Ventilators Collaboration Network, are the ones we know of. (We are probably unintentionally more aware of English-language projects.) These organization are world-wide and often international in their focus. Please report additional ones to us at our open source list of ventilators projects and resources.

When you can count twenty thousand people in a few slack channels, it is fair to say you are a community.

Would a community of 20,000 engineers attack the problem of building open source ventilators by creating as many projects as possible? Of course not.

They would do what engineers do: break the problem into smaller pieces. They would in fact, modularize the problem, and let different teams work on different pieces in parallel to shorten the time to first life saved. Nine women cannot make a baby in one month; but 20,000 engineers may be able to save lives quickly, if they do compete or pull in separate directions.

Making disparate pieces work harmoniously together is not simple, but engineers have gotten good at it. Openness is now seen as our greatest tool. It allows massive reuse and massive crowd-sourced brainpower. Other tools are standards, protocols, testing regimes, and different methodologies — all forms of communication, however specialized.

In hindsight, we should have divided up into teams, or even whole communities staffed by thousands, working on separate pieces. But a month ago the pieces were not clear. I believe now the pieces are becoming clearer, and I would like to try to articulate them, in hopes that the overall community will self-organize more efficiently.

Ventilators must deliver air in a precisely controlled manner. However, they are fundamentally simple. For example, they are far simpler than an internal combustion engine. In fact, we have started an open-source project called COROVAMP (COROnaVirus Abstract Physical Model). It is at the moment just a diagram, shown at the top of this article.

Believe it or not, every mechanical ventilator can be mapped onto this diagram; some even have fewer conceptual parts.

Thinking about the physical machine, the airway, the patient, the control, and, importantly, the exhausted clinicians wearing PPE who may have to use a pandemic ventilator, allows us to identify several independent modules.

The key to deploying pandemic ventilators is testing. But the act of testing is closely related to the monitoring which we have all seen in movies: the machine gives feedback to the clinicians. In this case, that feedback is about pressure, volume, respiration rate, and a few other things.

The machine has to sound an alarm when something goes wrong, either with the patient, or the machine. One thing that can go wrong is that pressure or the volume is too high or too low.

Because the act of testing is so closely related to monitoring and monitoring is the basis of alarming, these functions are closely related. Testing is done on a bench with an artificial lung; monitoring is done in an ICU or critical care ward. So you need monitoring for every ventilator connected to a patient; but with one tester you can test many ventilators; so of course, testing precedes monitoring.

In a community of 20,000, there should probably be at least 4,000 working on testing, monitoring, and alarming. Three of us at Public Invention have started one such project (VentMon), but there is room for far more projects.

VentMon will plug into the airway of ANY ventilator to provide (possibly redundant) monitoring and alarming.

Most ventilators have a physical control panel and status display. The AmboVent has a simple one that should be easy for any experienced clinician to use:

The AmboVent has a straight-foward control panel

I doubt the AmboVent control panel is perfect; but the beauty of an open source design is that we can improve on it. Indeed, we can go a step further: we can modularize it. Some games companies, such as Nintendo and Atari, allowed thousands of complex games to be played with a simple controller. There is no reason we could not build a “Universal Pandemic Ventilator Controller” that could be reused by other teams, so they don’t have to invent their own. In fact Sunday morning the Public Invention VentMon team met a team led by Prof. John Bennett of UC Boulder who had this idea, and we are attempting to cooperate, in part by defining a standard.

The internet runs on standards, although users don’t have to know that. In order for a Universal Pandemic Ventilator Controller to be a module that works with different ventilators, there must be a standard for how it communicates with other components. Some of what must be standardized is the respiratory data itself: the pressure, flow, temperature and O2 measurements taken by the machine that are clinically important. In an attempt to cooperate with Prof. Bennett’s team, we began such a standard Sunday night: Public Invention Respiratory Data Standard (PIRDS) (v0.1). It is of course, not very good yet, but it is open-source: you can take it and improve it, and hopefully, give your improvements back to us.

Every ventilator has a source of air. Many squeeze an AmbuBag. This has the advantage that the volume is easy to control. It may or may not have the drawback that the bag doesn’t last 14 days through the course of the illness; we will see. Perhaps a fan is better; perhaps a pump. The Brazilian OpenVentilator uses a bellows, which can be manufactured anywhere.

But the truth is: the patient doesn’t care. Even the doctors don’t care. What matters is the delivery of an air/oxygen mixture at pressures, tidal volumes, and rates that a doctors thinks best for the patient.

There is no reason that the drive mechanism could not be interchangeable, or to get a little extreme: why not hot-swappable? If you’re compressor goes bad and your supply chain has been disrupted, why not swap in an AmuBag drive?

The answer is, of course, it probably wouldn’t work without extensive testing, physical, electrical, and computer standards. In other words, without engineers doing a lot of what they love to do to make it possible.

Possibly a humidifier, an oxygen mixer, and an exhalation sanitizer should be modules. The modularization itself should be an open source project that 20,000 engineers can review and possibly extend and improve.

Nariman Poushin has suggested that there should be a small subset of the Robotic Operating System (ROS) that is specific to ventilators: a VOS. An operating system for ventilators would use software to tie together many different components elegantly.

If we are to save lives on a large scale, we must plan for manufacturing at a large scale. The meaning of “large scale” may vary depending on your nation and region. But every effort, including those undertaken by Dyson, Tesla, Ford and GM must be concerned with a breakdown in the supply chain of parts and components. This may be caused by the pandemic itself or the economic or political disruption it causes.

It seems to me the only way to have supply chain resilience is to have a modular design where different parts can be used. This must not be “dual-sourced” but “poly-sourced”. I suspect large ventilator manufacturers have an internal modular design. However, until now they would have had a disincentive to make that open. The pandemic has changed that.

In the presence of extreme supply chain disruption, economic catastrophe, and international strife, the only way to have modularity is to be open about every aspect of the design.

There are projects, possibly very good projects, that are not open right now. They are in no way benefiting the community, and they are in no way leveraging the community. I believe policy makers should be skeptical and mistrustful of every pandemic ventilator project, but they should be doubly skeptical of any project that is not a transparent open source project. A closed system forces them to rely on the authority and reputation of its makers rather than the evaluation of a community. We have proposed a distributed process by which confidence can be built by having different teams build and test open designs:

I recommend every project be fully open from day one with a license and a document repository. Use an open source hardware license. License your documentation with CC0 or CC-BY or CC-BY-SA or make a different choice. Use the Gnu GPL or some other license for code.

Don’t imagine that you are stronger by yourself. Publish your work. You don’t have to respond to anybody’s comment on it. If someone says something useful, use it; if not, keep your head down.

I can accept no argument that says more lives will be saved by a project keeping their work secret until some milestone is reached or some test is passed or some committee approves.

(Public Invention is a US 501(c)3 public charity.)