Can Open Source Hardware Mechanical Ventilator (OSH-MVs) initiatives help cope with the COVID-19 health crisis? Taxonomy and state of the art

Graphical abstract

Abstract

The field of Open Source Hardware Mechanical Ventilators (OSH-MVs) has seen a steep rise of contributions during the 2020 COVID-19 pandemic. As predictions showed that the number of patients would exceed current supply of hospital-grade ventilators, a number of formal (academia, the industry and governments) and informal (fablabs and startups) entities raced to develop cheap, easy-to-fabricate mechanical ventilators. The presence of actors with very diverse modus operandi as well as the speed at which the field has grown, led to a fragmented design space characterized by a lack of clear design patterns, projects not meeting the minimum functional requirements or showing little-to-no innovation; but also valid alternatives to hospital-grade devices. In this paper we provide a taxonomic system to help researchers with no background in biomedical engineering to read, understand and contribute to the OSH-MV field. The taxonomy is composed of ten properties that are read through the lenses of three reflection criteria: buildability, adoptability and scalability. We applied the taxonomy to the analysis of seventeen OSH-MV projects, which are representative of the current landscape of possibilities available for COVID-19 patients. We discuss the different design choices adopted by each project highlighting strengths and weaknesses and we suggest possible directions for the development of the OSH-MV field.

1. Introduction

The novel coronavirus (SARS-COV-2) has spread exponentially through the world, largely due to its high contagion rate. Each person tested positive to the virus infects on average 2.2 other persons (R0) as first determined in Wuhan [1]. On March 11, 2020 the World Health Organization (WHO) declared the disease caused by SARS-COV-2, COVID-19, outbreak a global pandemic [2]. As of July 2020, the USA is the country with the highest number of people tested positive (more than 3 M), while France has the highest mortality rate (^~15%) [3]. Besides people affected by pre-existing medical conditions and over the age of sixty, medical professionals have an order of magnitude higher mortality rate because of potentially being exposed to aerosolized virus while treating patients. Studies [4], [5], [6] show that between ^~15% and ^~20%, (up to ^~40% in disadvantaged communities [7]) of people who get the disease require hospitalization for multiple weeks due to the respiratory complications produced by the virus, such as pneumonia or, in the most severe cases, ARDS (Acute Respiratory Distress Syndrome) – a life-threatening form of respiratory failure. About 25% of the hospitalized patients will at some point require admittance to an intensive care unit (ICU). As no anti-viral drug therapy has been officially adopted yet, COVID-19 treatment is today limited to administering oxygen to the patients using non-intrusive techniques or, in severe cases, via mechanical ventilators (MVs) on anesthetized and intubated (insertion of a tube into the airways) patients.

Global demand for medical equipment has risen steeply; and there is not enough global supply. Ramping up the production takes time, because many medical device production plants were already at capacity before the pandemic started. Re-purposing other supply and manufacturing chains also takes time and it may be slowed down by lockdown restrictions put in place by many governments [8]. For example, large car companies in the United States re-purposed part of their production line to produced thousands of ventilators per month – but it took three months to have the first sizeable output.

Over the last decade, a number of initiatives belonging to the field of Open Source Hardware (OSH) have developed low-cost alternatives to medical devices such as prosthetics [9], lab equipment [10], and MVs [11]; for a review see [12], [13]. Medical OSH is a niche field that claims itself to be an alternative to the traditional medical device industry, which is characterized by high-costs, proprietary systems, patented technology and years-long development cycles due to clinical trials [13]. Although this rigorous development process provides quality results, it often cannot be afforded by low-budget healthcare systems in developing countries, and it lacks the flexibility to respond to rapidly escalating emergencies, such as the one posed by COVID-19. Conversely, an OSH approach to medical devices contributes to rapid innovation by allowing anyone to contribute to the development [14] and it enables designs to be quickly modified and repaired – a critical requirement for hardware projects, being harder to modify compared to software. By allowing more people to inspect the designs OSH projects might lead to better safety [12]. Finally, open-source medical devices prevent lock-in mechanisms, enabling seamless data sharing necessary to create the large datasets for Machine Learning (ML) and Artificial Intelligence (AI) [15] techniques. Despite those advantages, most medical OSH are not tested nor certified by health authorities. They must be used under direct supervision of medical personnel; e.g. for educational purposes or during emergencies, as a last resort when medical-grade devices are not available.

The COVID-19 pandemic has been a call to arms for OSH engineers, researchers and designers, and many existing and new medical OSH initiatives have seen a steep rise in contributions [13]. In particular, a broad range of organizations including universities, corporations, schools, hackerspaces and startups are rushing to design and fabricate MVs that can be produced in a decentralized way, with low budgets, short turnarounds time and requiring a simple infrastructure. The fabrication of those devices usually leverage digital manufacturing techniques such as consumer-grade 3D printing and popular DIY hardware platforms such as Arduino and RaspberryPi; with blueprints and instructions provided in an open-source manner. Yet many of those projects are still at an early phase, highly fragmented and less published in peer-reviewed literature compared to medical OS software [15], which has long-established projects, e.g. in the field of AI applied to imaging [16], [17]. Although this is comprehensible since they represent a quick reaction to an unexpected global calamity by a wide range of actors characterized by very different modus operandi, this fragmentation leads to multiple versions of similar designs, projects not meeting minimum functional requirements, unsafe because of lack of knowledge about operating in high-oxygen environments, not buildable or that don’t learn from the successes and mistakes of the others.

This paper charts the current landscape of OSH projects aiming at the fabrication of essential medical equipment for prevention and treatment of COVID-19, with a focus on ventilators. We aim at investigating (i) what analytical lenses and discrete characteristics can be used to analyse and compare OSH-MV projects, and (ii) what is the state of the art of OSH-MV projects, their design patterns, strengths and weaknesses. We aim at providing makers, designers and engineers without a biomedical background, as well as managers in charge of planning the COVID-19 emergency response, guidelines to navigate the landscape of OSH ventilator projects, adopt and contribute to existing ones or start new ones.

To this extent, we have developed a taxonomy consisting of ten properties and three reflection lenses: buildability, adoptability and scalability. Buildability describes the effort required to build one device. It is affected by properties such as the parts and infrastructure needed for production, the documentation provided and the project’s community. Adoptability summarizes the amount of effort required to deploy an OSH-MV in a hospital. It is affected e.g. by the features provided, as well as tests and certification processes the device might have gone through. Scalability refers to the potential for large scale fabrication and adoption. It is influenced by core design choices as well as the licensing terms. This taxonomy has been used to analyze and compare seventeen OSH-MV projects with varying degrees of complexity and features; made by both makers, academic institutions and industrial entities. We believe that the selected projects are representative of the current landscape of possibilities available for COVID-19 treatment.

The paper is organized as follows. In the next section we provide a brief introduction on mechanical ventilation, core concepts and its use for COVID-19 treatment. After presenting the taxonomic system we developed to survey the state of the art and the methodology adopted, we describe how different characteristics have been implemented by seventeen OSH-MV projects. We discuss popular design patterns, their strengths and weaknesses. We conclude the paper highlighting future trends.

2. Mechanical ventilators, fundamental concepts and operations

Mechanical ventilators are devices that help people to breath, thus keeping their blood oxygenated. A breath begins with inspiration (when air enters the lungs) and finishes at the end of expiration, when the lungs are deflated. Inspiration is caused by a pressure differential in a person’s airways, which creates a flow of air. This pressure can be exerted naturally by diaphragm and chest muscles movements; or artificially, by machine-induced mechanical or pneumatic forces. Expiration is passive and produced by the elastic force of the lung tissue; like a balloon deflating, it requires no assistance.

Mechanical ventilator machines are complex and expensive in large part because they are configurable. They are primarily used on people that cannot breathe by themselves at all. This is a common condition among patients affected by ARDS (Acute Respiratory Distress Syndrome), an often fatal consequence of COVID-19 which requires administration of oxygen under full anesthesia. Because a fully anesthetized person without constant mechanical ventilation would soon die, MVs are essential to keep a patient alive. They are equipped with sensors, alarms and a sophisticated control of how the air is pushed to the lungs. They might also include mechanisms for air heating/humidification and for suction of airways secretions.

2.1. Fundamental concepts

To push air into a patient’s lungs an artificial air pressure needs to be generated. During a respiration cycle, three different pressure levels rotate: peak pressure (PIP), plateau pressure, and Positive End-Respiratory Pressure (PEEP). PIP is the highest pressure measured during a breathing cycle. Plateau pressure is the end-respiratory pressure when the flow of air is zero, or the alveolar pressure when the lungs are inflated. PEEP is a small pressure that is always applied, especially at the end of exhalation, to prevent the lungs from collapsing.

The relation between pressure and volume is encapsulated in a property called compliance: the ratio between the change in volume and the change in pressure. As a matter of fact, each human’s lungs have a unique elasticity: some can be harder to inflate (low-compliance lungs), requiring more pressure; other are easier to fill with air. Compliance is not a constant property: it is lower at full deflation and higher at full inflation, showing an S-shape in a Pressure–Volume plot on the Cartesian plane. The Tidal Volume parameter defines the volume of air delivered during inspiration. This is usually defined as about 6 ml/kg of body weight, oscillating in adults between 240 ml (42 kg) and 780 ml (130 kg). The Tidal goal is achieved by generating a flow of air moving in and out the patient’s airways, which is usually measured in ml/s.

Besides pressure, tidal and flow, correctly timing the MV action plays an important role. The Respiratory Rate is the number of breathing cycles every minute, usually ranging between 10–30 breaths per minute. The Inspiratory:Expiratory ratio (I:E) is the proportion of each breathing cycle that is spent inhaling compared to exhaling. This is usually set to 1:2 (expiration lasts twice as long as inspiration), but it could vary in the range 1:1–1:3. Finally, the Fraction of Inspired Oxygen (FiO2) parameter represents the concentration of oxygen in the gas mixture the patient inhales. This setting varies with the severity of the respiratory disease. Patients with ARDS often require to inhale up to 100% of O2 during parts of the treatment cycle, but should be variable to allow weaning during recovery. As room air is 21% oxygen, the air is blended with 100% oxygen supplied from wall outlets or portable oxygen canisters to meet a defined FiO2 level.

2.2. Operations

As pressure and volume are related, a machine can adjust its functioning either keeping track of volume of air pushed into a person’s airways (volume-controlled ventilators or VCV), or keeping track of the pressure instead, (pressure-controlled ventilators or PCV). In VCV the operator sets the tidal volume and inspiratory flow and the machine adapts pressure levels to meet those goals. In PCV instead the operator sets the inspiratory pressure, the difference between PIP and PEEP [18], and the machine regulates the gas flow.

Over-inflating the lungs either by adding too much air volume or applying too much pressure can damage them, a condition called Barotrauma [19]. To mitigate this risk, ventilators are equipped with pressure sensors and emergency valves that open when either a positive or negative pressure approaches dangerous levels. This scenario might happen both because of a misconfiguration of the machine, a technical failure or when a patient unexpectedly wakes up from anesthesia and their muscles start compressing the lungs. Pressure and flow sensors are also necessary because the MV operation can be tailored to sync its activity with the patients’ own respiratory efforts. This is a very important feature to support transition in and out full ventilation support, e.g. waking up from anesthesia. MVs might also include heating and humidification circuits. While upper airways usually warm and humidify the air before it gets to the lungs, their role is taken out when a patient is intubated. If air artificially introduced in a person’s airways is cold and dry, the lung tissues might be damaged.

Not all ventilators are meant to work the same. Some of them are better tailored for emergencies, while others are designed to support the patient for longer periods. Mechanical ventilators are covered by several ISO norms like the 80601-2-12:2020 [20]. In the United States, the Food and Drugs Administration (FDA) has two approval paths for regular use and emergency use. The UK’s Medicines & Healthcare products Regulatory Agency (MHRA) has developed a document [21] providing a specification of the minimally clinically acceptable performances a ventilator should have to be used in UK hospitals during the COVID-19 crisis. If a machine doesn’t meet those requirements it is likely to provide no clinical benefits, or worse, to be harmful to the patient. The American and Australian Governments have also released similar guidelines [22], [23].

3. A taxonomy for OSH-MV projects

In order to compare OSH-MV projects among each other and for benchmark against hospital-grade devices we have developed a taxonomy that focuses on highlighting what characteristics make a project quickly buildable, adoptable and scalable to meet specific scenario requirements. While the first criterion is relevant for the work of formal or informal engineers, the second one is most relevant for healthcare personnel. Finally the third one is of particular interest for healthcare managers that are looking to large scale deployment of OSH-MV initiatives.

Criteria can be used as reflection lenses to evaluate and rate specific projects. To be able to evaluate criteria in a more fine grain we provide ten properties or attributes, which are easier to quantify (Fig. 1). Criteria can be described as a continuum or analog range of choices; while properties and sub-properties offer rather discrete and in some cases a binary set of options.

Fig. 1.

Relation between criteria lenses and properties.

3.1. Criteria

Buildability denotes the necessary resources and skills to fabricate one unit. It is affected by factors like the complexity of the device core design, the number of parts to be purchased, their availability on the market, and the infrastructure or equipment required for fabrication. Documentation plays a critical role in assessing buildability. Besides the source files (e.g. CAD, gerber and software code) necessary to reproduce parts, high-level schematics, assembly guides and video tutorials can considerably facilitate the building process especially for those not familiar with some of the required parts or tools. The community built around a project is also an important resource whenever an issue arises during fabrication. Buildability can range from high to low.

Adoptability encapsulates the amount of effort to be taken by healthcare personnel to replace a hospital-grade MV with an OSH alternative. It is affected by the type of settings provided by the OSH-MV, monitors and alarms and the level of training and supervision that is required to operate the device. Although a minimum set of requirements must be provided, OSH-MVs often do not include parts that are generic or that can be replaced with external accessories, which are usually provided with hospital-grade MVs. For example, backup batteries are often not included in their OSH counterparts because they can be replaced with generic UPS (Uninterruptible Power Supply) systems. In the same way, internal Oxygen regulators are frequently omitted because they can be replaced by external ones added on the line between the MV and the Oxygen supply (wall socket or portable canister). Although certain substitutions might serve their purposes well, they add an additional burden on the healthcare personnel who deploy and use the systems or they might be subjected to procurement bottlenecks. Finally, devices that do not go through full testing and certification might need continuous supervision from personnel to ensure a device operates correctly. Adoptability can range from easy to hard.

Scalability describes the potential for large scale fabrication and adoption. Beside being closely related to the previous two criteria, it is influenced by specific design decisions that might lead to bottlenecks in case an OSH-MVs is produced on a large scale and/or used for an extended amount of time. For example, the use of parts which are rare or have a short lifespan, a complicated assembly procedure, or the need for an expensive infrastructure might affect scalability. This criterion is also influenced by the degree of customization of a project, whether it can be easily adapted from a domestic to an industrial production process, which in turn is largely due to the source files provided; as well as the technical documentation and guidelines on how to modify or extend the systems. Finally, the license under which source files are released might grant the authors exclusive rights for commercialisation of the projects or constrain the time and location a project can be adopted. Scalability can range from quick to slow.

These criteria are closely linked to the forms of openness identified by Balka et al. in [24]: transparency, accessibility and replicability. We excluded from our review projects showing low-level of transparency (all source files needed to be available) or accessibility (sources provided in a format that allow modifications). Besides their definition of replicability partially overlaps with buildability and scalability criteria; the focus of their trichotomy is on assessing the potential for extension and co-development of current products into new ones, rather than adoption and scalability of current designs.

3.2. Properties

• •
  Core Design – the core components common to any OSH-MV project

  • –
    Driver – the approach used to create the air flow that is transferred to a patient’s airways, e.g. via ambu bags, motor blowers and pressure regulation systems
  • –
    Controller – the hardware electronics used to sense and control the operation of the driver, based on ventilation parameters set via an user interface. Most common controllers are based on popular platforms such as Arduino and RaspberryPi
• •
  Operations – the minimum set of features required by the MV to fulfill duties in COVID-19 ICUs. This property is broken down into binary sub-properties inspired by the UK’s design guidelines for rapidly manufactured ventilator systems [21]

  • –
    Ventilation – provides continuous mandatory ventilation (either pressure or volume controlled), fail-safe valves for over and under pressure and settings for TIDAL, I:E, respiratory rate and PEEP
  • –
    Oxygen and electricity – provides inlets for incoming oxygen supply (either via wall sockets or portable canisters) and allows control for the oxygen/air mixture (FiO2) as well as a backup battery lasting minimum 20 min
  • –
    Monitoring and alarms – embeds feedback sensors for ventilation settings and for actual airway pressure. Provides visual and auditory alarms for failures
  • –
    Infection control & safety – all parts in contact with the patients are disposable, the MV has impermeable casing and surfaces are easy to sanitize. Materials are safe and easy to procure. The MV should be capable of continuous operations for at least 14 days, and require less than 30 min training for the user
• •
  Documentation – types of information to describe a system that are provided

  • –
    Source files – both modifiable (e.g. DWG, DXF) and non modifiable (e.g. STL, gerber) source files
  • –
    Diagrams – block-based, eye-bird description of system’s main components
  • –
    Manuals – high-level narrative either targeting end users (user manual) or engineers (assembly or customization manual)
  • –
    Videos – quick, step-by-step tutorials to visually describe a system
  • –
    Scholarly articles – formal description of the system design and validation procedure
• •
  Infrastructure – the equipment, materials and skills required for fabrications

  • –
    3D printer – for fabrication of small parts like valves, latches and fans; usually via stereo-lithography or extrusion techniques
  • –
    CNC machine – for fabrication of large parts like chassis panels; usually making use of a laser cutter or a mill machine
  • –
    Electronic workshop – for production and assembly of PCBs
• •Parts – number of main parts that compose the system
• •Cost – cost estimation for the production of one unit
• •Test – protocols, procedure and results for validation and benchmark
• •Certification – the MV design has been submitted for certification or it has been approved, e.g. by the ISO (International Organization for Standardization) or by the FDA (Food and Drug Administration)
• •License – the legal terms that cover release, use and modification of the MV
• •Community – the extent of contributors, adopters as well as tools to engage with the community to contribute to the project

4. Charting the landscape of OSH-MVs initiatives

The field of OSH-MVs represent a niche domain that has been recently widely popularized by the scarcity of medical-grade mechanical ventilators, seeing a steep increase of contributions in just a few weeks, coming both from informal (makerspaces, schools) and formal (academia and the industry) settings. At this stage, the field cannot be reviewed in a systematic way. Many projects are still in the early phases of development, information is fragmented and shared among a number of channels (e.g. Google Docs, Slack, Github, forums) in multiple languages. Source files get updated overnight and only a few projects [25], [26], [11] have been reported in scholarly articles. As this is a rapid developing area we cannot claim the list of the reviewed projects provided in this section is exhaustive; rather, we focus on applying the taxonomy reported in Section 3 to a number of projects the we believe are representative of the current landscape, and which highlight design patterns, strengths and weaknesses that can help the community to grow.

4.1. Methodology

The inclusion criteria we adopted to select relevant projects are:

• •The OSH-MV can be used for the treatment of COVID-19 in ICUs
• •All design files, e.g. CAD schematics, circuit schematics, software code are available under an open-source license
• •The project has reached a working prototype stage (although might not yet have been tested in clinical settings)
• •Documentation is available in English
• •The project has been created or updated during the 2020 COVID-19 outbreak

On the contrary we excluded projects:

• •Still at a conceptual level
• •Provide only source files which are not editable: e.g. software binaries, STL files, hardware gerbers
• •Require industrial-grade facilities for fabrication
• •Require proprietary equipment/parts for fabrication
• •Ventilator parts-only projects, e.g. valves or CPAP masks

We surveyed journals and conference proceedings in the field of open source hardware as well as resources created by informal community that brought together physicians, hackers, makers and scientists with the common goal of tackling the scarcity of MVs, including [27], [28], [29].

4.2. Analysis

Our analysis of the state of the art has selected seventeen projects that are buildable (Table 1), and provides ventilation support that ranges from a bare minimum to level of services and functionalities comparable to a regular, hospital-grade MVs. Several of the reviewed projects have been evaluated for their degree of openness in [30]. Fig. 2 shows how the different projects are distributed with respect to the investigation criteria. In the remaining of this section we compare the different projects across the taxonomic properties. In the Appendix to this paper, Table 2 overviews the compliance of different projects to the taxonomic properties and Fig. 5 provides photos of all projects.

Table 1.

List of projects reviewed.

Project Name	License	Cost (USD)	Driver⁎	Controller
Ambovent	The Unlicense	200	BMV	Arduino
ApolloPVM	CC-BY	300	BMV	Arduino
Bristol	Generic OS	100	BMV	Arduino
E-Vent	MIT	500	BMV	Arduino
Gtech	Generic OS	100	BMV	None
MakAir	The Unlicense	500	Blower	RaspberryPi
MUR	GPLv3	100	PR	Arduino
MVM	CERN-OHL-S v2	300	PR	RaspberryPi, ESP32
Openbreath	CERN-OHL-S v2	200	BMV	Teensy
OperationAir	Apache 2.0	500	PR	RaspberryPi
Oxygen	CC-BY-SA	200–500	BMV	None
PanVent	CERN-OHL-S v2	300	PR	Arduino
LC-OSV	MIT	100	Blower	Arduino
PC-CMV	Generic OS	100	PR	555 Timer
Prevail	Generic OS	500	BMV	Arduino
Vent4us	Generic OS	200	PR	Arduino
VentCore	CC-BY-NC-SA	200	BMV	AtMega 32u4

^⁎BMV: Bag Mask Valve, PR: Pressure Regulation

Fig. 2.

The reviewed OSH-MV projects with respect to investigation criteria defined in Section 3.

Fig. 5.

Photos of the reviewed projects.

4.2.1. Core design

The principal design decision taken during the development of an OSH-MV consists of choosing a driver, the mechanism that creates a differential pressure to push air into a patient’s airways, and a controller, the piece of hardware that manages the driver according with feedback loops from sensors and inputs from the operator.

Driver

There are three main approaches for drivers: Bag Valve Mask systems (BVM), blowers and pressure regulation (PR) methods. The first approach makes use of AmbuBag, a popular manual ventilator widely available and cheap (^~20 USD). Its functioning is simple: an elastic bag is squeezed to insufflate air into the patient airways via a mask. Bag and mask are connected via a valve to avoid exhaled air to be recycled. AmbuBags are designed to be hand-squeezed, a tiresome operation usually performed by first responders as emergency breathing aid, often during ambulance transport. To extend its operation time OSH-MV projects designed mechanisms to automate the bag-squeezing movement; for example using motorized claws (E-Vent, Oxygen, ApolloBVM, Ambovent, Briston, Openbreath), pulleys (VentCore) or pressurized air (Gtech) (Fig. 3). A second approach makes use of a blower: a small turbine that pushes air into a pneumatic system. To achieve PCV (Pressure Controlled Ventilation) the pressure generated by the blower is regulated either by changing the turbine rotation speed (LC-OSV) or by using an electrically-controlled valve (MakAir). A third approach, pressure regulation, produces the airflow necessary for ventilation by using an external source of constantly pressurised air that is finely regulated by the MV to achieve PCV. This source of air, called medical air, is usually manufactured by the hospitals on-site, by pulling outside air into a compressor which is in turn connected to a piping system wired into hospital walls. Medical air sockets are usually available next to each hospital bed. In doing so, MVs relying on this approach (PanVent, PC-CMV, MVM, MUR, Vent4us) outsource to the hospital infrastructure the generation of pressurized air that is otherwise achieved via AmbuBags or Bellows drivers. Although this design choice creates devices that might be easier to manufacture and scale, it poses a strong requirement on the infrastructure required to adopt them, as a source of medical air might not be always available (e.g. in hospital tents or in hospitals in developing countries). To be precise, all the three design patterns, like hospital-grade MVs, require an external source of oxygen to meet FiO2 targets required for COVID-19 treatment, which can be provided by either a permanent hospital infrastructure (likewise for medical air) or by portable canisters, as described in Section 4.2.2.

Fig. 3.

Different approaches for automating the squeezing of an AmbuBag, via pulleys (VentCore, left), motorized claws (E-Vent, center), pressurized air (Gtech, Right).

Controller

Getting a driver to pump air into the lungs is the first and probably most easy step. Rather, the complexity of mechanical ventilation lies in the ability of fine-tuning its action; e.g. to support a patient’s own respiration efforts, controlling the amount of air volume and pressure in a precise way. High pressure could lead to barotrauma [19], while falling short could suffocate the patient. This action requires fast computation, a set of sensor feedbacks, and an intuitive user interface to monitor and change system parameters. The algorithms used for tying together sensing and actuation, finely-tuned over years of development and clinical trials, are one of the competitive advantages (and industrial secrets) of hospital-grade MVs. Rather, the OSH-MVs reviewed range from providing no sensor-driven intelligence for controlling their action (Oxygen, Gtech, PC-CMV), making their adoptability very low; to projects that provide high level of control via multiple pressure and airflow sensors (e.g. E-Vent, Ventcore, MakAir, Panvent); and feature high-fidelity user interfaces (MVM, MakAir, OperationAIR). Nearly all the reviewed projects featuring some extent of digital control to ventilation are based on two of the most popular OSH platforms: Arduino, for simpler projects, and RaspberryPi. The type of sensors used are also popular options within the maker and DIY communities, such as Adafruit’s BMP280 pressure sensor (Panvent) or MPXV4006DP differential pressure sensors (VentCore). The user interface (Fig. 4) is usually implemented with standard knobs and switches (VentCore, MUR), e.g. to adjust respiratory rate and Tidal; often coupled with LCD displays to show the current settings and real-time sensor feedbacks (E-Vent, ApolloBVM, Prevail, Ambovent). Some devices feature touch-based interfaces either embedded (MVM, Panvent), or are delivered as smartphone or tablet app, to save on costs (Openbreath, Vent4US).

Fig. 4.

Three different user interfaces, physical controls (MUR, left), display showing settings (ApolloBVM, center), touchscreen showing real-time sensor data (MVM, right).

4.2.2. Operations

Most of the reviewed project satisfy the minimum operational requirements defined by the MHRA [21], and provide O2 gas interfaces. Yet the requirements for monitoring and alarms, infection controls and safety are often overlooked. Also, no projects featured heating and humidification circuits.

Ventilation controls

All projects reviewed provide pressure-controlled ventilation, yet the type of control offered on ventilation parameters varies largely. Ten out of the seventeen projects fully support the controls for Tidal, I:R, respiratory rate, PEEP, FiO2 and include failsafe valves for over and under pressure. Four projects provide nearly no settings (Oxygen, Gtech, Bristol, LC-OSV), meaning that they can only be used either on a very narrow set of patients that can tolerate the devices’ default settings and are fully anesthetized; or for educational purposes. Among other projects, settings for FiO2 are sometimes missing (Prevail, VentCore, MUR). Although this is a very important setting, it can be easily replaced by an external air/oxygen blender to be set up between the oxygen line and the MV. PEEP settings are missing in some machines (VentCore, MUR). We believe that is a critical shortcoming, as early scientific evidence [31] claims that different-than-usual PEEP settings can be beneficial for COVID-19 treatment. Finally, whereas a lack of controls is somehow expected by the simple and educational projects (Bristol, LC-OSV), it is odd when these features are not available in complex projects, at least not in an explicit way. This is the case of Oxygen, that allow settings only hard-coding them in the geometrical properties of some parts (supports, bearings, latches), meaning that a change in settings requires fabricating those parts from scratch.

Oxygen and electricity .

Although not always providing a setting for FiO2, all the ventilators surveyed include sockets for incoming oxygen supply using standard connectors. They use regional settings for electricity supply (AC): 240 V in Europe/UK and 110 V in the US. No project has declared compatibility with more than one standard/region (a common feature for hospital-grate MVs); limiting the adoption of the devices at the regional scale. We can hypothesize that compatibility to different AC standards depends in turn on the compatibility of the parts chosen during design. While parts powered by DC current (e.g. microcontrollers, sensors) are often provided with multi-region AC-DC adapters, larger parts like AC motors are usually compatible with one region only. Only six projects (Ambovent, MakAir, PanVent, MVM, Vent4Us, OperationAir) embed a backup battery capable of providing at least 20 min of autonomy in case of main electricity failure, as required by MHRA specifications. Although an external UPS can be added to a MV that does not embed their own backup mechanism, this comes as an extra burden for the hospital infrastructure.

Monitors and alarms

After ventilator settings are applied by a physician, monitors and alarms allow for both assessing the correct operation of the MV and the patient’s vitals. Designing MVs with feedback loops is incredibly important as the ventilation support needs to adapt to rapidly changing conditions, such as the patient moving between different levels of sedation, their condition improving or worsening. Once more, the capability of ingesting data from multiple sensors and rapidly compute settings to be applied (via proprietary algorithms) is one of the characteristics of regular MV machines that is often overlooked by OSH projects. Although all projects that provide settings for ventilator parameters make those settings visible via physical knobs and gauges; only a selection of devices embeds sensors to monitor and display the airway pressure in real-time, either via a matrix display, LCD touchscreen or connection with an external device (E-Vent, Ambovent, Prevail, Openbreath, MarkAir, PanVentMVM, Vent4us, OperationAir). Alarms are provided by means of visual, auditory or vocal feedbacks; whenever airway pressure and Tidal volume is exceeded or underachieved; although only two projects (MVM and OperationAir) embeds a Oxygen sensor and can alarm whenever a FiO2 target is not achieved (Panvent has it as optional). Only a handful of projects can alarm when the ventilator is shut down because of lack of electricity or low-battery (Ambovent, MakAir, Panvent, MVM, Vent4us, OperationAir).

Infection control and safety

A MV should be safe both for the healthcare workers and their patients. Regarding healthcare workers safety, the RMVS requirements [21] specify that all parts that get in contact in the patient’s breath must be disposable and have HMEF-bacterial-viral filters -a requirement satisfied by all the projects reviewed. Yet only a few projects have physical designs that minimize the risk of infection, adopting flat casings and surfaces that are easy to sanitize (Ambovent, Prevail, MakAir, MVM and OperationAir). Regarding operational safety, the RMVS document requires that a OSH-MV must be capable of continuous operation for at least 14 days. As for the information available today, we haven’t found that requirement to be satisfied by any project reviewed.

4.2.3. Documentation

The way a OSH-MV project is documented is the primary driver to assess its buildability and adoptability. All the projects reviewed are well documented, providing at least source files for hardware, software and mechanical parts, as well as high-level block diagrams showing how the different parts are interlinked. A few projects take further steps providing detailed assembly guides via textual and visual narratives (Bristol, LC-OSV, Prevail, MUR, OperationAir) or video tutorials (Ambovent, ApolloPVM, Gtech, MakAir, Panvent, Openbreath). Beside technical documentation, a couple of projects (Prevail, OperationAir) also provide an end-user manual. Although we believe a user manual is not strictly necessary, because the ventilators follow standard guidelines for controls and feedback, it is a nice addition for projects that provide advanced functionalities. Three projects (PC-CMV, MVM and Vent4us) are reported in scholarly articles (not yet peer-reviewed) that describe the design rationale and validation methodology.

4.2.4. Infrastructure

The reviewed projects require fabrications of both the exterior (e.g. case and knobs) and the interior (e.g. valves, latches, fans) via either CNC or 3D printing techniques. Due to the precision required by internal parts, most projects recommend to use Selective Laser Sintering (SLS) or Stereolithography (STL) techniques, rather than Fused Deposition Modelling (FDM) printers, which are pervasive due to their cheap cost but offer lower resolution. External parts of the MV casing often require to be fabricated by cutting acrylic, wood, or metal sheets with waterjet or laser techniques. These rapid prototyping tools are reasonably available in workshops in schools, fablabs or research labs; requiring just a few training hours. The infrastructure necessary for fabrication of the MV hardware electronics poses a strong requirement on the type of facilities necessary for fabrication. Although some projects (LC-OSV, Bristol, Gtech, Openbreath, Prevail, Vent4us) are based on generic hardware parts that can be plugged together using a breadboard or solder-free techniques; other projects require some skills in wiring and soldering electronics (E-Vent, ApolloBVM, Ambovent, Panvent, MUR, MVM). Finally, a few projects integrate custom-made printed circuit boards (PCB) that require an industrial-grade process for both production and assembly (Ventcore, Ambovent, Openbreath, MarkAir, OpenAir).

4.2.5. Parts and costs

Examining the Bill of Materials (BOMs) provided by the different projects, it is clear that the inventors tried to use parts that are as easy as possible to procure. The BOMs also often provide alternative parts and direct links to suppliers. The parts most used by projects are common mechanical (screws and bolts), plumbing (tubing, valves) and electronics (microcontrollers, sensors, motors, displays) components. Interesting, these parts are also common in DIY educational projects dealing with gardening and irrigation. The total cost for production of one project is hard to assess. Whereas the cost of single parts is rather fixed, costs for associated services, such as 3D printing or PCB manufacturing depends on geographical regions and demand–supply mechanics. It is reasonable to estimate the cost for fabrication of the reviewed projects in the range between USD100 and USD500; a striking contrast with the cost of hospital-grade ventilator, running between USD25,000 and USD50,000 a piece.

4.2.6. Tests and certifications

The complex process of clinical trials and certification, is one of the factors that makes development of a new MV a lengthy and costly process. The procedure used to validate an OSH-MV in the projects we analysed varies broadly, from no testing preformed, to projects that have been certified by a government agency (e.g. FDA in the USA) for emergency use. A number of public agencies [21], [22], [23] and open source projects [32] have compiled a list of validation tests an emergency ventilator should go through before being deployed. These test plans aim at benchmarking the operational and safety features described earlier in this paper (e.g. oxygen and electricity connection, operation mode, alarms) and provide a formal description of procedures, expected results and allowed tolerances. Those tests are usually performed with the ventilator attached to a lung simulator: a device that mocks the characteristics of human lungs. A lung simulator device can be as basic as a bag that approximates the resistance to inflation of human lungs. More advanced simulators include pressure sensors [33], up to devices that capture a full range of data including flow, volume of air and concentration of oxygen [34].

Some projects include an accurate description of the tests performed and results obtained (E-Vent, Panvent, PC-CMV, MVM, Vent4us, OperationAir); with one project (PanVent) including the instruction to build a DIY lung simulator. Other projects (ApolloBVM, E-vent) just report the operational time the devices have been tested without human intervention; without further details on the test methodology, nor results. Besides workbench tests, three projects (E-Vent, Oxygen, Ambovent) have performed tests on live animals. We could not find in literature whether testing MVs on animals, a practice that poses ethical concerns, is part of the clinical test hospital-grade MVs have to go through.

Some projects have their design developed based on standard requirements documents such as UK’s Rapidly Manufactured Ventilator Systems [21], in the case of Ambovent or the ISO 80601-2-12:2020 ‘Particular requirements for basic safety and essential performance of critical care ventilators’ standard [20] in the case of Openbreath. MVM obtained the FDA Emergency Use Authorization [35] while PanVent is going through the process as we write. Oxygen has already received authorization from Spanish health agency for clinical tests [36].

4.2.7. License

Licensing is a highly debated topic in the OSH community as it deals with the balance between the rights of the inventors to be acknowledged and the principles of the OS movement. The licensing terms provided by each OSH-MV initiative define how well a project can scale up, for example allowing modifications or re-use of source code for commercial purposes. Cooperation between the OSH community and the industry is still a rather unexplored domain affected, besides licensing, by communities and the tools and platforms they are provided with [37].

Most projects are released under a specific OS license; although five projects (Gtech, Bristol, Prevail, PC-CMV, Vent4us) state that the source files provided are open without declaring a formal license agreement. Other projects vary from very permissive to less permissive conditions. Six projects have very permissive licensing terms, allowing the commercial use of sources and closed-sources derivatives under one of these four licenses: the MIT Open Source [38] (E-Vent and LC-OSV), Creative Commons BY [39] (ApolloBVM), The Unlicense [40] (Ambovent and MarkAir) and Apache 2.0 [41] (OperationAir) agreements. Five projects have less permissive terms requiring derivative products to remain open source under the CERN Open Hardware Licence [42] (Openbreath, Panvent, MVM), GNU GPL v3 [43] (MUR), and BY-SA [39] (Oxygen). One project has more restrictive terms which forbid any commercial use under the Creative Commons BY-NC-SA [39] terms (VentCore). PanVent is a registered trademark.

4.2.8. Community

The community formed around a OSH-MV project is a barometer of its popularity and its maturity stage. Communities are both important to foster engagement among project contributors, which are in large part volunteers, develop common values [44], and to facilitate remote collaborative work and project management. These characteristics are even more important in the OSH-MV domain where the community of practice [45] includes participants from different expertise such as physicians, nurses, engineers and hospital managers. Most of the scrutinized projects rely on GitHub tools for both source code versioning and collaboration tools, e.g. for task management and issue tracking. Some projects (E-Vent, Panvent, OperationAir) have official websites which include detailed information on COVID-19, basic medical knowledge on mechanical ventilation, announcements for update and releases; as well as getting-started guides for new contributors. Two projects (Oxygen and Vent4us) also provide a digital workspace for real-time messaging and file exchange. One project (MVM) is currently raising funds on a popular crowdfunding platform for the production of the first batch.

5. Discussion

By reviewing seventeen OSH-MV projects we evaluated the descriptive power of the taxonomic system we have designed to explore a novel, fast-growing domain, which is mobilizing formal and informal researchers, healthcare workers, and companies to propose emergency-alternatives to traditional MV devices. Beyond the scientific contribution provided by this paper, we hope that our work will help to respond to the COVID-19 crisis by empowering people to take action, leveraging the open and collaborative attitude of Open Source communities and the recent advances in digital manufacturing.

Our snapshot of the OSH-MV field taken in July 2020 shows projects widely scattered along a space of design choices created by intersecting adaptability and buildability criteria (Fig. 2). It reflects the very different goals and modus operandi of the inventors, including universities and research centers, non-biomedical corporations for example Gtech, a UK vacuum cleaner company, and JMA Wireless, which produces 5G antennas; fablabs like the Oshman Design Engineering Kitchen and Makers for Life, down to individual hobbyist. In this section we reflect on the lessons learned and identify strands for future development of the field.

Mechanical ventilation is a very complex activity during which the patient might transition through different stages of severity and levels of consciousness, due to drug-induced sedation. Most of the OSH-MVs reviewed have fixed controls (e.g. for inspiration rate), which require patients to be anesthetized for the machine to be in control of their breath. In the desirable case that the patient’s condition improves and they start breathing on their own, the MV cannot reduce its support and the patient will start to breath against it; which could lead to overpressure and barotrauma. Because of this limitations OSH-MVs can usually be employed under very specific conditions (the patient in general anesthesia) and cannot support patient’s triggered ventilation during milder states of sedation. This comes as a serious limitation especially for MV usage on COVID-19 patients, whom might require to be ventilated over several weeks: weaker levels of sedation might be preferable whenever possible, due to anesthesia side effects. Indeed, most of the reviewed projects focus on the mechanical part (which is relatively simple) rather than the patient monitoring/sensing side. Rather, hospital-grade ventilators can work with breath sequences triggered by the patient when they are still able to breathe or when they wean out of sedation; requiring a mix of sensors for detecting the diaphragm muscle activity, fast computation and algorithms. Future efforts should target adding intelligence to OSH-MVs, so they can support COVID-19 treatment in a more holistic way. That intelligence is currently available in proprietary algorithms owned by biomedical engineering companies, developed based on years-long clinical trials and feedback received from patients and healthcare personnel. Although some large MVs corporations like Medtronic have released design specifications for use during the COVID-19 crisis [46], those often don’t include software source codes and, in general, rely on industrial processes and parts that cannot be easily understood by non-experts nor easily implemented.

Instead of putting efforts in interacting with the OSH community, large MV companies have focused on making partnerships, often with car manufacturers, for increasing the production rate for their own products; for example GE Healthcare and Ford, Ventec and GM, Medtronic and Tesla. Although these are worthy efforts, those organizations don’t release developed source codes and do not contribute to the OSH-MV field. Governments followed a similar approach, giving mandate to large companies and consultancy firms the design and production of rapidly manufactured MV [47]. A stronger collaboration among biomedical companies, governments and the OS community would contribute to the growth of the OSH-MV field.

Our review also showed that there are concerns about the reliability of OSH-MVs for their use for long periods. Most parts adopted by the projects are not meant to be used for a long period of time. For example, Ambu Bags used as drivers by the majority of projects are devices designed to be hand-squeezed for short periods of time. It is not clear what will happen when a mechanical squeezer will hit a bag in exactly the same pattern 12–20 times a minute for weeks. The reviewed projects also ignore the safety hazards of operation in high oxygen environment. Future efforts should focus on providing and implementing more thorough test plans.

Projects that show high buildability are often very simple in terms of functionalities provided and can be used only for educational purposes, showing low adoptability. This is frequently due to the more complicated infrastructure required by high-adoptability projects; for example for PCB production. During assembly, specialized equipment, even just for soldering a circuit board, may be a barrier to adoption [48]. We argue that OSH-MV projects should be more modular, to make it easier to outsource the production of modules whenever the infrastructure available is not up to the task.

None of the projects reviewed includes capability to log and share data about both the device operation and the patient’s vitals. Although this functionality might rise privacy concerns, we believe it is a great value for engineering and medical research. It also leverages one of the strengths of Medical OSH: data exchange between devices and information systems is not hindered by vendors’ lock-in policies [15]. Perhaps this capability is omitted due to the many layers of data security to be put in place and legal implications; especially because a patient might be impaired to give consent to data acquisition and usage. The field should plan for safe and lawful capture and use of data generated during MVs operations to improve the design of future project.

There are examples of OSH-MVs projects that have managed to scale up and seems to be ready for deployment in hospitals. For example, the Spiro Wave ventilator [49] has been developed based on the E-Vent design, in just five weeks, to be produced at scale with industrial-grade processes and a streamlined supply chain. The project has already received the FDA emergency use authorization. Interestingly enough, Spiro Vent is closed source, as allowed by the E-Vent licensing term; which promotes scalability by attracting industrial partners willing to turn OSH projects into products.

Projects like Spiro Wave have also the potential to prove the long-term massive saving healthcare systems can achieve by switching to OSH alternatives. For example, Moritz et al. [50] has estimated multi-million dollars in saving for healthcare systems by switching to OSH Magnetic Resonance Imaging (MRI) devices; a piece of medical equipment as pervasive as MVs.

As of July 2020 we couldn’t find any example of OSH-MVs, nor rapidly manufactured MVs produced by the industry, that actually made their way into an hospital ward. It is not clear whether this is due to a lack of trust in OSH-MVs by medical personnel, or rather the decline of demand due to the positive effect of lock-down restrictions on infection rates. Yet, it is clear that the characteristic of the COVID-19 pandemic varies widely at the regional scale: there are places that still have to see a first wave of the epidemics and other that are expecting a second and third waves in the fall. Forecast regarding the capability of healthcare systems to absorb the demand for ICU patients have also shown a elevated variance. It is therefore important to keep the attention high and have MVs ready for deployment.

Finally, our taxonomy and review only considers OSH-MVs; yet there are different solutions to cope with the scarcity of MVs. Several projects, e.g. [51], [52] designed ventilator-splitters, devices that allow one ventilator to support two or more patients. Although these devices have a very high buildability and easy adoption, they cancel out the above mentioned intelligence of hospital-grade MVs of adapting to a patient’s breathing efforts; as those are not designed nor have hardware to provide ventilation settings for more than one person at the same time. Other initiatives focus on manufacturing consumables, such as tubes valves and masks, that should be replaced regularly both in regular and emergency ventilators; for example charlotte valves [53]. Another interesting take on the problem is the Vent2Life project [54], a platform that enables finding and repairing medical equipment that is currently out of service and allocating it to health institutions in need. YouTube also features several videos providing tutorial to repair hospital-grade ventilators.

6. Conclusion

In this article, by deconstructing seventeen OSH-MV projects across ten properties and reflecting on them though the lenses of three reflection criteria, we hope we have helped the OSH community to develop higher quality, safer and cost-efficient MVs projects to support healthcare systems that are either temporarily overwhelmed by the COVID-19 crisis or chronically under-resourced.

Our work has suggested a number of future directions for the field. It is important to remark that those actions can only be implemented via a closer collaboration between project owners (researchers and makers), governments and the industry. Project owners should learn from each other mistakes and aspire at achieving the level of service of hospital-grade ventilator, rather than creating minimum viable products. Governments should interact more closely with the OSH-MVs community, producing guidelines that can be efficiently implemented by decentralized, informal OS communities and identifying and supporting state-of-the-art projects. The industry should look at the OSH-MVs field as an opportunity rather than an obstacle for their business. Although there are fewer cases of businesses that flourished from OSH projects compared to the OSS (Open Source Software) domain, OSH is still a relatively young field that is fueled by innovations in rapid manufacturing and collaboration platforms that are likely to grow massively in the near future.

As of July 2020, it seems that the lockdown restrictions put in place in many countries have succeeded in slowing the pandemic. Although it is still not clear what will happen when those strict measures are first released (whether the number of cases will begin to rise again), the attention and demand of OSH MVs might decline in the western world. While urgent needs might seem to be gone, the work done can still add value in the future, especially in developing countries where a COVID-19 crisis might unfold in the near future. In any case, well designed OSH-MVs will always have the potential to save lives.

CRediT authorship contribution statement

Simone Mora: Conceptualization, Methodology, Formal analysis, Writing - original draft, Visualization, Project administration. Fábio Duarte: Writing - review & editing, Supervision. Carlo Ratti: Supervision, Funding acquisition.

Declaration of Competing Interest

The authors declare the following financial interests/personal relationships which may be considered as potential competing interests: The authors are employees of the organization that has developed one of the OSH-MV reviewed (MIT E-vent).

Appendix A.

Table 2.

Projects reviewed.

	Tools				Documentation						Operations
Project	3D Printer	Laser Cutter/ CNC	PCB Manufacturing	Part count	Source files	Diagrams	Manuals	Videos	Scholarly Articles	Community	Ventilation	Gas & electricity	Monitoring & alarms	Infection & safety	Testing	Certification
Ambovent	•	•	•	~50	•	•		•		Github, Website	•	•	•		Live animals	Follows RMVS specs
ApolloPVM	•	•		~34	•	•		•		Github, Website	•				Maximum operation time	None
Bristol		•		~20	•	•				Github					None	None
E-Vent		•	•	~50	•	•		•		Website, Forum	•		•		Live animals, Lab test plans and results	None
Gtech		•		~85	•	•		•		None					None	None
MakAir	•		•	~26	•	•				Github	•	•	•		None	None
MUR	•			~47	•	•				Github					None	None
MVM		•	•	~33	•	•			•	Website, Crowdfunding campaign	•	•	•		Lab test plans and results	FDA Emergency Use Authorization
Openbreath		•	•	~30	•	•		•		Wiki, forum	•		•		None	Follows ISO80601–2-12:2020
OperationAir	•		•	~200	•	•	•			Wiki, Github	•	•	•		Lab test plans and results	None
Oxygen		•		~50	•	•				Github, Slack					Live animals	None
PanVent			•	~25	•	•		•		Github	•	•	•		Lab test plans and results	Under review for FDA emergency use
LC-OSV				~10	•	•				Github					None	None
PC–CMV				~10	•	•			•	None	•				Lab test plans and results	None
Prevail		•	•	~100	•	•	•			None			•		Pre-clinical testing	None
Vent4us				~7	•	•			•	Discord	•	•	•		Lab test plans and results	None
VentCore			•	~41	•	•				Github,Website					None	None