PVP1-The People's Ventilator Project: A fully open, low-cost, pressure-controlled ventilator research platform compatible with adult and pediatric uses.

Mechanical ventilators are safety-critical devices that help patients breathe, commonly found in hospital intensive care units (ICUs)-yet, the high costs and proprietary nature of commercial ventilators inhibit their use as an educational and research platform. We present a fully open ventilator device-The People's Ventilator: PVP1-with complete hardware and software documentation including detailed build instructions and a DIY cost of $1,700 USD. We validate PVP1 against both key performance criteria specified in the U.S. Food and Drug Administration's Emergency Use Authorization for Ventilators, and in a pediatric context against a state-of-the-art commercial ventilator. Notably, PVP1 performs well over a wide range of test conditions and performance stability is demonstrated for a minimum of 75,000 breath cycles over three days with an adult mechanical test lung. As an open project, PVP1 can enable future educational, academic, and clinical developments in the ventilator space.

Introduction

The first mechanical ventilators date back to more than 150 years ago [1]. In the time since, they have undergone considerable design modifications; including, crucially, the transition from pure mechanical devices to the modern electronic machines in use today. Despite their commercial availability, very few platforms have been made open and fully transparent. Such a platform will enable the production of high-quality devices in virtually any laboratory, will further efforts in teaching and research/development, and may serve as development platform for a future medical tool [2-4].

In addition, over the past years, the global COVID-19 pandemic has highlighted the need for a low-cost, rapidly-deployable ventilator solution for the current and future pandemics. While safe and robust ventilation technology exists in the commercial sector, there exist a small number of suppliers who have been unable to meet the extreme demands for ventilators during a pandemic. Moreover, the specialized and proprietary equipment developed by medical device manufacturers can be prohibitively expensive and inaccessible in low-resource areas [4-9]. Ventilation as a technology is needed globally beyond pandemics for applications spanning neonatal intensive care, surgical anaesthesia, life support, and general respiratory treatments [10].

Finally, while the COVID-19 pandemic sparked a surge of interest in ventilation designs and some truly creative solutions, nearly all technologies put forth during this time have focused on evaluating performance with respect to adult guidelines. However, ventilation is of critical importance in pediatric medicine and it is valuable to consider developing a solution that is suitable for both adult and pediatric indications [10]. Hence there is a clear need for a broader range of solutions, both for research (e.g. to improve critical components [2]), clinical applications, and beyond [3, 7, 9, 11–15].

In response to these challenges, we present an open-source, rapid-deploy ventilator design with minimal reliance on specialized medical devices and manufacturing equipment. The People’s Ventilator Project (PVP1) is a pressure-controlled and fully automatic mechanical ventilator that can be built for $1,700 by a single person in few days (cf. Fig 1). As a point of reference, the lower-end average market values of open ventilators such as the freely-released Puritan Bennett 560 [16] or the Mechanical Ventilator Milano [17] cost approximately $10,000. PVP1’s parts were selected for widespread availability, and its modular software was designed to support component substitutions and extensions to new ventilation modes. Further, we have included comparisons here to commercial, pediatric-grade ventilators to emphasize the versatility of PVP1 and the goal of increasing global access to critical-care ventilation technology and making such technology available for teaching and research.

Fig 1

A system overview of the People’s Ventilator Project.

A Overview of respiratory circuit. B A snapshot of the online documentation in the form of a web-portal containing documentation and detailed build instructions. PVP1 Bill of Materials is highlighted. C The assembled device.

PVP1 is an automated ventilator that natively supports pressure-control ventilation (PCV), spontaneous inhalation monitoring ventilation (SIMV), and key alarms specified by regulatory agencies (e.g. high airway pressure, etc.). Pressure control was chosen over volume control because it is known to be safer [18] with respect to barotrauma risk, and SIMV was implemented because it increases the range of patients and conditions for which PVP1 can be used. Summarized in Fig 1, PVP1 operates as a computer-controlled, timed-cycle ventilator that requires only medical air and the patient-side respiratory tubing to be operated. To date, PVP1 has been set up three times by two different teams [2] and run continuously for over 300 hours with no alarms or failures noted (representative data from a physical test-lung shown in Fig 2).

Fig 2

Example of a PVP1 breath waveform.

Overlaid pressure control breath cycle waveforms for airway pressure and flow out over 70,000+ cycles, breathing into a Quicklung lung model. Test settings: compliance C = 20 mL/cmH2O, airway resistance R = 20 cmH2O/L/s, PIP = 30 cmH2O, PEEP = 5 cmH2O. Shaded areas indicate variability (standard-deviation) over the entire test period.

Materials and methods

PVP1 was designed as open source and transparent ventilation system. As such we have made all source code, electronics, bill-of-materials, complete CAD assembly, testing results, and relevant schematics open to the public (Fig 1). A certification is available from the Open Source Hardware Association (OSHWA; UID US002073). To aid discoverability, we have also generated an Open Know How Manifest (OKH-manifest), located in the hardware folder of PVP1’s git repository. A snapshot of the current repository (v1.0, githash 0a22452) is available on Zenodo [19]. For technical details, and complete documentation, we refer the reader to the Supporting Information, the online documentation and PVP1’s git repository.

Briefly, PVP1 follows the FDA’s (U.S. Food and Drug Administration) EUA (Emergency Use Authorization) key design criteria by automating the classic Manley ventilator design [5, 20]. A proportional–integral–derivative controller (PID) facilitates inflation of the lung to a set target pressure. This pressure is maintained for a set period of time. Then, air is allowed to escape passively through a second valve on the expiratory limb. The PVP1 schematic is shown in Fig 1A. The O2/air mixture is supplied to the system via a hospital gas blender. The patient breath cycle is actively controlled via a proportional valve on the inspiratory limb and a solenoid valve with mechanical PEEP (positive end-expiratory pressure) valve on the expiratory limb. The mechanical PEEP valve sets the positive pressure during expiration. This circuit is controlled by an embedded system (Raspberry Pi using the pigpio library [21]) supporting comprehensive monitoring of key alarm conditions, spontaneous breath detection and an intuitive touch-screen interface for clinician control. To use PVP1, the clinician programs a desired peak airway pressure (PIP), sets a manual PEEP valve to establish expiratory pressure, and sets a target respiratory rate and I:E ratio, the ratio of inspiratory to expiratory time. Convenient modifications to rise time and breath effort can be performed in real-time by the clinician. Core labeling specifications of PVP1 as required by the FDA EUA are presented in Table 1.

Table 1

PVP1 specifications.

Parameter	Range	Comments: tested range, theoretical performance, notes
RR (BPM)	10–40*	12–20 tested based on ISO test tables [22]; *higher is feasible.
VTE (mL)	100–500*	*Pressure controlled ventilation does not explicitly set VTE; we validated resultant VTE under PC as within the FDA EUA targets.
Flow Rate (L/min)	0–100 L/m	Valve specifications; maximum needed for testing was 85 L/m.
PIP (cmH2O)	15–60	Tested up to 35 cmH2O during normal operation; safety hardware and alarms can support up to 60 cmH2O as per FDA EUA guidelines.
PEEP (cmH2O)	5–25	Validated PEEP range using approved commercial PEEP valves.
I:E Ratios	1:1–1:3	Tested based on ISO test tables [22].
Available Ventilation Modes	PCV, SIMV	Modular system can be adapted for CPAP or non-invasive-modes at the software level.
Air Source	Hospital air	Rated for 50 psi, pre-blended oxygen/medical air mix.
Alarms	See Supplement	High/low airway pressure, hyper/hypoventilation, obstruction low FiO2, PEEP not met, Disconnect/high leakage, Technical Alarms.
Display variables	N/A	Airway pressure, expiratory flow, FiO2. Derived quantities: actual PIP, PEEP, estimated VTE.
Set variables	N/A	Target PIP, Target PEEP, Flow adjustment, Respiratory Rate, I:E ratio (or inspiratory time).

Notes: Parameter ranges supported by PVP1. RR is respiratory rate, VTE is the Expiratory Tidal Volume, PIP is peak inspiratory pressure, PEEP is positive end-expiratory pressure, the I:E ratio is the ratio of inspiratory to expiratory phase of the breath cycle. PCV is pressure-control ventilation, and SIMV is spontaneous inhalation monitoring ventilation.

We feel that an open design should include justification of design decisions and be able to serve as a teaching and learning tool. As such, the Supporting Information here and online documentation aim to enable anyone to build PVP1, and to learn why and how key components were chosen. Based on independent validation from collaborators, following the guidelines will lead to a functional PVP1 in fewer than 24 work-hours (≈ three eight-hour days). To further mitigate risk and expedite exploration and evaluation of the PVP1 platform, we provide the ability to run a simulation of the PVP1 system on any computer. This simulation was also used for automated software tests.

Results

Core performance

In the following paragraphs, we will present a representative set of benchmarks and tests to demonstrate and validate PVP1 performance in key ventilatory processes. For clarity, we will focus on these results, followed by a more detailed discussion of how PVP1 was designed at the hardware and software level. More details and extended tests are provided in the S1 Appendix.

Normal operating behavior

First, we evaluated the long-term stability and performance of PVP1 by performing standard pressure-controlled ventilation across more than 70, 000 contiguous cycles over a period of 3 days (Fig 2). All testing was performed using a high-grade test lung (Quicklung, Ingmar Medical) that offered the ability to tune compliance (C) and resistance (R) to meet FDA EUA test specifications (C = [5, 20, 50] mL/cmH2O; R = [5, 20, 50] cmH2O/L/s). Fig 2 shows pressure control performance for midpoint settings: C = 20 mL/cmH2O, R = 20 cmH2O/L/s, PIP = 30 cmH2O, PEEP = 5 cmH2O. PIP is reached within a 300 ms ramp period, then holds for the PIP plateau with minimal fluctuation of airway pressure for the remainder of the inspiratory cycle (blue). Once the expiratory valve opens, exhalation begins and expiratory flow is measured (orange) as the airway pressure drops to PEEP and remains there for the rest of the PEEP period.

Individual patient variation means that a one-size-fits all approach to pressure-controlled ventilation can have problems, and fine-tuning of key parameters such as the rise time (how quickly the ventilator reaches PIP) can allow more tailored ventilation. PVP1 supports such adjustment through a flow adjustment setting available to the clinician. This flow adjustment setting allows the user to increase the maximum flow rate during the ramp cycle to inflate lungs with higher compliance (briefly: this variable scales the proportional gain in the feedback control loop of the PID controller, similar to the mechanics of retinal contrast gain control [23]). The flow setting can be readily changed from the GUI and the control system immediately adapts to the user’s input. An example of this flow adjustment is shown in Fig 3A for four breath cycles. While all cycles reach PIP, the latter two have a higher mean airway pressure, which may be more desirable under certain conditions than the lower mean airway pressure of the former two.

Fig 3

Demonstration of waveform tuning and system capabilities.

A Demonstration of flow adjustment. If necessary, the operator can increase the flow setting through the system GUI to decrease the pressure ramp time. B Demonstration of a phase-shift if spontaneous breath is detected. C Demonstration of the response to a rapid high pressure transient. Test settings in all three cases: compliance C = 20 mL/cmH2O, airway resistance R = 20 cmH2O/L/s, PIP = 30 cmH2O, PEEP = 5 cmH2O.

Breath detection validation

A key feature of modern ventilators is to support spontaneous breaths should a non-anaesthetized patient try to breathe. Such patient-initiated breaths during the expiratory phase cause a sharp and transient drop in PEEP, and PVP1 can be set to detect these and trigger initiation of a new breath cycle. We tested this functionality by triggering numerous breaths out of phase, using a device (QuickTrigger, IngMar Medical, Pittsburgh, PA) to momentarily open the test lung during PEEP and simulate this transient drop of pressure (Fig 3B).

Alarm response demonstration

Reliable and rapid alarm responses are a necessary feature of automated ventilators [24], and one of the most critical alarms (‘high priority’ in FDA EUA guidelines) for pressure control ventilation is the High-Airway-Pressure-Alarm (HAPA). According to peformance standards, the ventilator must detect and correct (within 2 breath cycles) abnormally high airway pressure. In PVP1, the HAPA alarm can detect and respond to elevated airway pressure within 500 ms, while also throwing a high priority visual and audible alarm (Fig 3C).

PVP1 in a pediatric setting

PVP1 is generating breath waveforms using a simple and robust PID control scheme. In principle, this control scheme should allow reliably operation across physical lung parameters. To test the system’s performance in the limiting case of an extremely small lung volume, we performed a number of experiments with a pediatric lung model (Ingmar QuickLung Jr.) and compared PVP1’s performance to a Servo-I commercial mechanical ventilator. Recording the precise volume, pressure and flow waveforms allowed us to perform a comparison of both systems. The waveforms are shown in Fig 4. Notice that PVP1 rapidly delivers air at breath cycle onset (inset in Fig 4A) and then slows down. This suggests that the limitation is the PID-control-system, and not the physical hardware of the device, highlighting potential benefits of a more sophisticated control scheme. Overall, the pressure (Fig 4B) and flow (Fig 4C) waveforms were similar, even though PVP1 deviated from target values slightly more than its commercial cousin (dashed lines in Fig 4B). The correlation coefficient between the waveforms of PVP1, and the professional ventilator were r = 0.990 for pressure, r = 0.999 for volume, and r = 0.979 for flow, reflecting the high similarity.

Fig 4

PVP1 performance in a pediatric setting, compared to a Servo-I commercial ventilator.

A Volume of delivered air during a breath cycle. Blue is PVP1, Orange is Servo-I. The inset shows a magnified view of the first 0.3 s. Notice how the increase in volume is more rapid in PVP1 when compared to the commercial system. B Pressure waveforms produced by PVP1 and Servo-I. Dashed lines indicate target PEEP and PIP. C Flow in and out of the lung produced by both systems. For all three plots, we set the breath rate to 25 breaths per minute, PEEP to 5 cmH2O, PIP to 20 cmH2O, and inspiration time to 0.6 s. The pediatric lung settings were R = 25 cmH2O/L/s and C = 10 ml/cmH2O with an uncompensated residual capacity of 400 ml.

To assess the deviations of PVP1 from the set values, and compare the results with the commercial systems on long time scales, we collected several hundred breath cycles, and compared averaged statistics and standard deviation. In this second experiment, we obtained peak pressure values of (21.5 ± 0.4) cmH2O, a PEEP of (5.7 ± 0.1) cmH2O and inspired tidal volume of (128 ± 3) ml of air, for the same settings as in Fig 4. These averaged metrics were comparable to Servo-I which delivered: Peak pressure (20.6 ± 0.01) cmH2O, PEEP (4.79 ± 0.01) cmH2O, Inspired Tidal Volume (146.9 ± 0.1) ml. Across experiments, PVP1 deviated from the target pressure by ≈ 1 cmH2O, and delivered an inspired tidal volume ≈ 13% below that of Servo-I in a challenging pediatric setting.

Discussion

PVP1 is a flexible, stable, and open platform for pressure controlled ventilation with a total cost of 1300 USD for low-volume production. PVP1 is open source, featuring detailed documentation, automated software tests, and modular design. It offers anyone a state-of-the-art platform for exploring mechanical ventilation. For documentation and source code, we refer the reader to the Supporting Information, and the online documentation and the git repository. In the remainder of this section, we will discuss the history, key areas for improvement and performance notes worth bearing in mind for those considering PVP1 for different use-cases.

Overall performance assessment

PVP1 has demonstrated sustained operation over at least 70,000 continuous cycles without failure while maintaining stable ventilatory performance using a default test condition from the EUA test table. PVP1 reaches PIP, and required VTE for key EUA tests. The greatest deviation from target PIP, by 9%, was observed under challenging conditions, when ventilating with very high airway resistances (50 cmH2O/L/s; see S1 Appendix). These are uncommon patient conditions and PVP1 performs significantly better in all other test cases. Future improvements to better compensate for challenging patient conditions could involve updates to the proportional valve to allow for finer control over flow, as well as more advanced control schemes to better modulate overshoot [2].

Design considerations in a pandemic

In response to the COVID-19 pandemic, the scientific community developed numerous exciting ventilator projects, many of which leverage earlier designs developed to combat prior respiratory pandemics such as SARS and H1N1 [5]. When designing PVP1, we sought to learn from the challenges and limitations noted in these prior studies while aiming for an open and transparent design. There are two key ventilator designs that received early FDA Emergency Use Authorizations—The University of Minnesota Ventilator [25] and the Mechanical Ventilator Milano [17]. To handle production and FDA EUA approval, both projects eventually shifted manufacturer-of-record status to major companies—Boston Scientific and Elemaster, respectively. Other academic projects such as the Vent4Us/PezGlobo ventilator (Stanford / University of Utah / University of Delaware) [26] have merged over time and also incorporated a variety of commercial backers. Still other projects such as the MIT E-Vent bag-valve ventilator [27], the RapidVent system [11] and the Portsmouth Ventilator [12] have remained open, but with a more limited scope. A more comprehensive discussion of numerous ventilator projects can be found in [5], where it is highlighted that the most successful projects have necessarily become less open due to constraints from industrial partners. Hence, a key goal with PVP1 was to describe and demonstrate a fully functional ventilation platform that both highlights how effective a minimal design can be and provides a fully open platform for the broader community to leverage.

PVP1 was designed to align with the constraints and demands of a pandemic such as COVID-19, and special care was taken to specify reliable, commercial, off-the-shelf components outside of the traditional ventilator or scientific supply chains. Most components are available from general hardware suppliers and the chosen parts listed here did not experience supply chain disruptions due to COVID-19 during the period of development. The internal layout and chassis design are also sufficiently modular and simplistic to allow PVP1 to be adapted to a given clinical context without altering function. Modular and well-documented code facilitates simple adaptation of the system to different hardware. Finally, we hope PVP1 can either directly or indirectly improve access to ventilators even beyond the COVID-19 pandemic, while also offering a reliable and open research platform for further ventilator development.

Design process and critical iterations

PVP1 went through multiple iterations of its software and hardware. To be as open and transparent as possible, the following paragraphs discuss the challenges of this process, as well as describe the evolution of the design. With regards to hardware decisions, some brief context on the landscape of ventilator methodology will help explain key choices made in PVP1’s design. First, the Ambu-bag (a manual resuscitator) squeezers: Ambu-bags are very low-cost devices which require an attendant to squeeze a bag to force air into the lungs of a patient. These may have valves which help maintain PEEP, and external devices designed to continuously squish the bags [15, 25]. However, it is uncommon to leave a patient on these bags for long periods of time: notably, COVID-19 patients in critical condition need ventilator support for 2–3 weeks, and these devices are hard to precisely and digitally control. Second, CPAP/BiPAP machines: CPAP (continuous positive airway pressure) machines are used by people with sleep apnea and are intended for use with patients who need some assistance breathing but can breathe on their own. The patient does not need to be sedated to use a CPAP, as they just involve a mask on the face. However, while CPAP machines are excellent instruments for ventilation [8], they cannot sustain high pressures like more invasive ventilators can, and thereby cannot sustain patients in more critical conditions. Critical COVID-19 patients’ lungs become stiffer and ultimately an invasive ventilator is required. Additionally, there is a concern that CPAP machines may pose risk of spreading the airborne viruses. BiPAP machines are slightly more advanced than CPAP machines (multiple pressures can be set) but associated pros/cons are similar. Finally, invasive ventilation remains both the standard-of-care for many medical procedure, and cost prohibitive in many localities. Hence, while the design of PVP1 ensured compatibility with severe respiratory conditions such as COVID-19, we also sought to ensure that PVP1 would be valuable beyond the current pandemic. We therefore decided to build a ventilator that allowed ventilation support for several weeks to maximize the versatility of PVP1. Overall, PVP1 hardware went through three major design changes that we refer to as Mk1, Mk2 and Mk3, illustrated in Fig 5. CAD files for all three versions are provided in the online materials and details are covered in the following paragraphs.

Fig 5

The two earlier versions of PVP1, and its current design.

A Mk1 of PVP1 was a simple pressure limited time-cycled continuous flow ventilator. B Mk2 was a significant step up in complexity. Its upright design featured an air humidifier, and numerous valves and sensors. At this point we had also committed to pressure controlled ventilation. C Mk3 is the up-to-date version of PVP1, described in this article, featuring a screen and keyboard, and tailored to the supply chain limitations. To aid mechanical stability, we also transitioned to a flat design.

Mk1 was the mechanically simplest version, realizing a pressure limited time cycled continuous flow ventilator. Such a device connects the patient to a continuously flowing air supply. The only controlled element is a single expiratory valve. If this valve is closed, the lung inflates. With the valve open, the patient can exhale. PEEP pressure is maintained by the continuous airflow. While this system is very simple and robust, it lacks precise control of ventilation parameters, and is relatively wasteful regarding medical oxygen, a commodity that became a key limiting factor in many localities during the COVID-19 pandemic. Mk2 addressed these concerns, realizing a full pressure controlled ventilator.

Mk2 used wall O2/medical air from the hospital wall, passing it through a gas blender, a humidifier, and then controlling the flow (using a series of devices, including a pressure regulator, expiratory valves, etc) to the endotracheal tube of the patient. Mk2 allowed to set upper pressure values (PIP), lower pressure values (PEEP), and other relevant parameters (breath rate, inspiratory time, etc.). The sensors of this version were specified to specific operating conditions: high flow, low pressure, and sometimes high humidity. However, supply chain limitations constrained numerous choices in the early design. For example, we initially planned to use a servo-proportional valve for fine control of inspiratory flow (RCV-075, Enfield Technologies, Trumbull, CT), but sourcing such valves operating at low pressures (0–50 cmH2O) and sufficiently high flow (over 120 LPM) was challenging due their being needed for existing commercial ventilator design. Therefore, few manufacturers were willing or able to provide us with valves, due to existing contracts with ventilator manufacturers. Moreover, such specialized valves are often costly and thus antithetical to the goal of a broadly accessible ventilator design. While more available, generic industrial proportional valves are typically not designed to run at clinically-relevant pressures or flow rates. Likewise, the expiratory valve selection was constrained to those valves which would open even with zero pressure differential because the pressures exhibited inside the human respiratory tract are far lower than in a typical industrial process. Again, these factors heavily constrained what was possible during the COVID-19 pandemic and what would be possible in a resource limited setting moving forward. The Mk3 design emerged specifically to combat the valving constraints encountered in Mk2, namely: high cost, lack of availability of advanced valves, difficulty sourcing valves that could operate in the physiological range. In addition, we incorporated a number of critical user-interface and functionality upgrades in Mk3. First, Mk3 was rotated down to a table-top or rack-based configuration to improve stability. A screen was also incorporated to make the unit entirely self-sufficient (Mk2 had assumed a clinic-provided display). We froze structural elements of the design here as well, including the use of imperial standard fittings. Additionally, at this stage in PVP1’s design process, it became untenable to source additional flow sensors, and we made the decision to run PVP1 entirely with a single flow sensor at the inspiratory side of the circuit—a cost and computational saving measure that precluded the use of volume-controlled ventilation. As for the valves, we made two key decisions that largely removed us from supply chain limitations. First, we identified an industrial current-controlled proportional valve (PVQ31–5G-23–01N) with a sufficient performance envelope and high input pressure to support human ventilation and obviate the need for more expensive and less accessible low-pressure-high-flow medical valves (see Methods). Next, we decided to couple a low-cost, accessible solenoid valve (ON-OFF) to a standard, fully-mechanical commercial PEEP valve to regulate expiratory with minimal financial and computational cost. Noting that even commercial PEEP valve supply can be disrupted, we also provide a prototype for a 3D-printable membrane-based PEEP-valve with the online materials. Finally, the new form factor of Mk3 allowed us to significantly reduce tubing length while increasing tubing stiffness. This reduced compliance proved essential to enabling PVP1 to achieve therapeutic performance during pediatric ventilation simulation. We were particularly determined to ensure pediatric compatibility given the lack of pediatric testing or consideration with any existing open ventilators, thereby again increasing the utility of PVP1 within and beyond a pandemic.

PVP1: An open source project during a pandemic

PVP1 aims to follow the best practices for open projects [28]: (i) transparent and public communication on the GitHub repository, (ii) standardized and automated tests of individual modules and the full system with >99.5% coverage using Travis CI [29], (iii) merger of pull requests only after passed tests and independent code review, (iv) high-level hardware and build documentation, and API-level documentation generated from docstrings and (v) PVP1 made accessible via pip and the Python Package Index which allows anyone to easily install, run, and experiment with the software.

Designing a device like PVP1 during the COVID-19 pandemic provided us with unique challenges that we wish to briefly summarize here. Historically, this project started around April 2020, early in the pandemic, from a small group of core developers. As PVP1 matured, more expertise was required, but the strict social distancing and remote-work requirement made it challenging to build a community, i.e. a broader group of developers personally committed to developing this device without pay or other compensation. To address this, we employed various methods. First, we obtained external help by experts in crowdsourcing projects, on citizen science, and science communication. To this end, we leveraged internal connections within the university to reach out to such experts, who amplified our needs on social media, such as Twitter. Second, we have published multiple university-level press releases to access and recruit people outside of the limited scope of our personal social media presence. In addition, we set up a Slack channel, a Discord server, and a public git repository on GitHub as a platform for interested people to engage. In addition, to aid discoverability, we have also generated a standardised Open Know How Manifest (OKH-manifest).

We found collaboration in small sub-groups of around three people to be most effective. These groups communicated in a self-organized way, and were concerned with conceptual parts of the ventilator (such as software/control, electronics, and mechanics/hardware). During the pandemic, we remained in continuous contact, and the entire team all met at least once per week to monitor overall progress and identify bottlenecks. Over the last two years, we have grown to a core team of about 10 developers, plus another 10 who contributed temporarily.

At the current scale with around 20 contributors, GitHub proved viable to maintain and curate this work. However, our aim is to develop a growing and active community to continuously improve this product. For added transparency, and better support for large groups of contributors, a Wiki would be a viable and desirable addition to the PVP1 ecosystem.

The case for open source medical technology

Open source medical technology [3, 6, 9] can improve the capability and access to medical technology as a whole in several ways: (1) enabling faster device innovation with lower costs [3, 4]; (2) increasing economic value, with associated public benefits, compared to traditional proprietary development [30]; (3) facilitating external review and inspection by avoiding black-box hardware and software designs, and (4) providing a benchmark for innovation towards next-generation technology such as smart ventilators [31]. Finally, the open source approach can make these problems more accessible to academic researchers, thereby greatly expanding the ability to train students in approaching such problems through hands-on open-ended pedagogy [32] as well as encouraging unconventional approaches [2, 7]. While many pandemic ventilator projects began as open-source initiatives, these often transitioned to a closed format due to the strong structural and regulatory incentives to enter into industrial partnerships. With PVP1, we provide a completely open build guide and software platform for a functional, pressure-controlled ventilator designed for FDA Emergency Use Authorization standards with viability in both adult and pediatric settings.

The world is moving towards more open technology. Other projects of the medical instrumentation universe [3, 4, 9] that were recently published include an open peristaltic pump build around an arduino controller [33], a syringe pump build using a Raspberry Pi [34], and a low-cost positive airway pressure ventilation system, working with water-columns for pressure control [10]. These examples show that particularly in low-resource settings, open medical [9], but also scientific instrumentation (e.g. [35, 36]) are becoming a reality. In particular, some of these items can constitute valuable components of a revised version of PVP1, such as the pressure sensor developed by Goertzen and colleagues [37] or the monitoring system developed by the Princeton Open Ventilation Monitor Collaboration [38].

Challenges of open hardware

There is rough consensus in the open source software community around some basic development best practices like version control and automated testing. Open hardware has relatively few analogous best practices. One challenge is the lack of open formats that support versioned designs, instead most rely on proprietary CAD programs with opaque binary formats. For PVP1’s software, we were able to track almost 1,000 commits in the git repository, numerous issues in the issue tracker, and 73 descriptive merge requests. This is much harder to do in hardware.

We have briefly summarized important design changes in the earlier paragraphs, but systematic documentation and version control of hardware is an ongoing challenge in many fields. For example, one author had to implement a system for hardware knowledge organization from scratch in their Autopilot wiki [35]. Documenting the many hardware components, CAD files, and usage guides used with the system required self-hosting an instance of semantic mediawiki and populating it with hundreds of properties, forms, and templates. This system is still only a partial replacement for the version control and dependency specification tools available for software, though it is an improvement over traditional hardware design repositories like thingiverse, open neuroscience, and others that are typically composed of static documents organized with a uni-dimensional “tag” field. We describe the autopilot wiki here as an illustration of the challenge of exhaustive hardware documentation that constrains our ability to fully reconstruct PVP’s design history, as well as an open space in tooling that we have attempted to fill in subsequent projects.

We attempted to follow the best practices for open source hardware that do exist. PVP1 is OSHWA-compliant (OSHWA UID US002073), and we provide a standardised Open Know How Manifest in the hardware folder of our git repository. Our hardware documentation includes a high-level overview, full solidworks models including two prior designs, descriptions of the system components and reasoning behind their selection, complete assembly instructions with accompanying pictures of each step, CAD files for the custom electronics and 3D printed components, and a bill of materials with purchase links. Since the hardware documentation is automatically built on readthedocs.org from source files included in the software repository, we also welcome questions, clarifications, and contributions using issues and pull requests.

Future hardware development goals

PVP1 is released as a minimal implementation of a safe, invasive ventilator capable of Pressure Controlled Ventilation with spontaneous breath detection. There are, of course, many ways that the software and hardware design can be improved. Indeed its continual improvement is the point: we have developed and documented the system such that it is not a static design, but can be modified and improved as a general-purpose ventilation platform. We welcome programmers and users to submit issues to discuss bugs and needed developments, and submit their own improvements via pull requests, or in their own branches. PVP is intended to be a continually, communally developed project. We specifically invite others to contribute to the project, and consider this reviewed report as a solid foundation for future developments.

A useful upgrade would be to incorporate an inspiratory flow sensor which would further open the possibility of Volume Controlled Ventilation and allow for the use of inspiratory flow for improved PSV. However, as PVP1 is inherently modular, both in terms of hardware and software, these features can genuinely be added both to the open code base and to the assembly with minimal complication.

Another useful future development goal is a version of PVP1 with metric parts. While imperial parts are readily available from sources like McMaster-Carr in the United States, and certain countries in the Commonwealth of Nations, it is important to note that such parts may not be readily available in many countries. The same holds for certain standardized medical parts, where we again followed US standards. We hope that people with similar limitations will find our designs transparent enough to overcome supply limitations.

Future software development goals

Modifications made purely at the software level (e.g. a firmware upgrade) would allow PVP1 to additionally support complete Pressure Supported Ventilation (PSV, for spontaneously breathing patients) as well as Non-Invasive Ventilation (such as Continuous Positive Airway Pressure, CPAP). We did not implement these at the present time as they were considered luxury-features in a pandemic ventilator.

In addition, automatic ventilator data collection can eliminate delays, improve charting efficiency, and reduce errors caused by manual entry of data [39]. Standards are specified in ISO/IEEE 11073, describing communication between medical, and health care devices with external computer systems [40]. PVP1 is easy to integrate into existing software. Its data logger already supports the export of all raw data into hdf5 and standard data formats (MatLab’s .mat and comma-separated-values .csv). A future version could provide a RS-232 or other interface for digital output, and automatically insert data into SQL-tables to facilitate integration into a patient’s file. Similarly, since the xml-rpc inter-process communication module operates over a network socket, it is straightforward to allow centralized control or monitoring of PVP1 in hospital settings [39].

Missing steps towards a medical device

While anyone can build PVP1 in around 24 work hours, we explicitly emphasize that it is not a legally licensed medical device (it currently lacks US-FDA regulatory approval or that of any other regulatory body). Anyone producing PVP1 for clinical use would need to take on the legal responsibility of Manufacturer-of-Record (MoR) and seek appropriate regulatory approval. Moving PVP1 forward thus primarily requires formal regulatory approval beginning with certifications of achieving key international performance and safety standards as discussed below.

While we built PVP1 to address the most critical performance targets and safety alarm integrations specified in the US-FDA Emergency Use Authorization (EUA) for ventilators, a manufacturer-of-record would need to take on liability and formalize these results. More specifically, several important international standards exist that regulate medical devices. Particularly relevant are the international standards ISO 13485, ISO 14971 and IEC 62304 [41-43]. These set standards for clinically used hard- and software, more specifically regarding requirements for quality (ISO 13485 [41]) and risk (ISO 14971 [42]) management system. IEC 62304 specifies international standards for life cycle requirements regarding software within medical devices [43]. In this report, we have focused on FDA EUA guidance (which is largely harmonised with international standards), but only partially followed these international norms given the unprecedented nature of the COVID-19 pandemic. It should also be noted that international standardization is an ongoing challenge in a multilateral work. The Global Harmonization Task Force (GHTF) and its successor, the International Medical Device Regulators Forum (IMDRF) have made important progress in this regard, but much remains to be done.

Tuning

PVP1 is built around sensitive pressure-sensors that can be subject to drifting when exposed to extreme environments (such as air travel). Re-adjustment and tuning can easily be performed with air of known pressure (available in nearly all medical settings), and copying the voltage readings of the sensors to the program code. In general, this will be necessary in regular intervals, or after travel. Failure to calibrate the sensors properly can lead to deviations on the order of a few cmH2O and the recommended calibration routine would become part of the formal product labeling and appropriate use documentation.

Customization

PVP1’s completely open design and modular code base makes customization trivial. For example, the GUI can be adjusted to fit various screen sizes, resolutions or color schemas. It can also be easily manipulated by removing, or adding panels and information. In fact, we have often operated PVP1 from a simple LCD external monitor, and even remotely via a Secure Shell connection (ssh). In the latter case, a webcam is useful to independently monitor the experimental setup. This enables the potential for telemedicine in a future crisis.

The internal code can also be customized easily. For example, it is straight forward to swap-out the controller with a more complex piece of code [2]. The hardware abstraction layer allows easy calibration and tuning of the sensors, while also allowing for complete replacement of a software- and hardware-module if a particular sensor becomes unobtainable.

Performance in a pediatric setting

Waveforms produced by PVP1 were similar to a commercial ventilator. Importantly, initial rise time is very rapid, suggesting that PVP1’s hardware is indeed viable across very different patient settings. The relatively slow inflation during inhalation might be related to conservatively chosen PID constant, more specifically a too large integration (I) term. A large integration term is useful to avoid ringing in the limit of high flow rates, i.e. to rapidly inflate large, adult lungs. In the pediatric setting with small lung volume, this coefficient can decreased. Tailoring the PID coefficients to the pediatric settings will likely improve PVP1’s performance considerably.

Further tests, and validation data of PVP1.

The appendix contains the complete set of EUA ISO standard tests [22], elaborates on the design, and provides calibration and validation data.

(PDF)

Click here for additional data file.

16 Dec 2021

A rebuttal letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'.

A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'.

An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'.

If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter.

If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: https://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols. Additionally, PLOS ONE offers an option for publishing peer-reviewed Lab Protocol articles, which describe protocols hosted on protocols.io. Read more information on sharing protocols at https://plos.org/protocols?utm_medium=editorial-email&utm_source=authorletters&utm_campaign=protocols.

We look forward to receiving your revised manuscript.

Kind regards,

Andre Maia Chagas, PhD

Academic Editor

PLOS ONE

Journal Requirements:

When submitting your revision, we need you to address these additional requirements.

1. Please ensure that your manuscript meets PLOS ONE's style requirements, including those for file naming. The PLOS ONE style templates can be found at

https://journals.plos.org/plosone/s/file?id=wjVg/PLOSOne_formatting_sample_main_body.pdf and

https://journals.plos.org/plosone/s/file?id=ba62/PLOSOne_formatting_sample_title_authors_affiliations.pdf

2. Thank you for stating the following in the Acknowledgments Section of your manuscript:

This work was supported by Princeton University which provided funding and facilities.

JLS is supported by NSF Graduate Research Fellowship No. 1309047. We would also

like to thank Grant Wallace, Zhenyu Song, Moritz K¨utt and Philippe Bourrianne for

very valuable discussions and technical support. In addition, we would like to thank

Elad Hazan and Daniel Suo with the Google AI team at Princeton for testing the

quality of our build instructions. We would also like to acknowledge the contribution of

the open science community as a whole, by providing guidelines, standards and tools.

We note that you have provided funding information. However, funding information should not appear in the Acknowledgments section or other areas of your manuscript. We will only publish funding information present in the Funding Statement section of the online submission form.

Please remove any funding-related text from the manuscript and let us know how you would like to update your Funding Statement. Currently, your Funding Statement reads as follows:

This work was supported by Princeton University which provided funding and facilities. In addition, JLS is supported by NSF Graduate Research Fellowship No. 1309047. The sponsors and funders did not play any role in the study design, data collection and analysis, decision to publish, and preparation of the manuscript.

Please include your amended statements within your cover letter; we will change the online submission form on your behalf.

3. In your Data Availability statement, you have not specified where the minimal data set underlying the results described in your manuscript can be found. PLOS defines a study's minimal data set as the underlying data used to reach the conclusions drawn in the manuscript and any additional data required to replicate the reported study findings in their entirety. All PLOS journals require that the minimal data set be made fully available. For more information about our data policy, please see http://journals.plos.org/plosone/s/data-availability.

Upon re-submitting your revised manuscript, please upload your study’s minimal underlying data set as either Supporting Information files or to a stable, public repository and include the relevant URLs, DOIs, or accession numbers within your revised cover letter. For a list of acceptable repositories, please see http://journals.plos.org/plosone/s/data-availability#loc-recommended-repositories. Any potentially identifying patient information must be fully anonymized.

Important: If there are ethical or legal restrictions to sharing your data publicly, please explain these restrictions in detail. Please see our guidelines for more information on what we consider unacceptable restrictions to publicly sharing data: http://journals.plos.org/plosone/s/data-availability#loc-unacceptable-data-access-restrictions. Note that it is not acceptable for the authors to be the sole named individuals responsible for ensuring data access.

We will update your Data Availability statement to reflect the information you provide in your cover letter

[Note: HTML markup is below. Please do not edit.]

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Yes

Reviewer #2: Partly

**********

2. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: N/A

Reviewer #2: I Don't Know

**********

3. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: Yes

**********

4. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: This paper presents the People's Ventilator Project (PVP1), a fully open-source and low cost ventilator which can serve as a research platform. While it has not been medically certified yet, it shows some promising results with artificial lungs in both adult and paediatric cases.

Overall, the paper is well written and provides an important addition to the literature. They authors make a strong case for the need for open source ventilators, while also highlighting that numerous other open source ventilators had to shift away from being open source due to external (primarily commercial and regulatory) pressures. The latter points to a need in societal changes to accommodate for open projects.

The authors can find my comments within the attached the PDF file. In addition to those, I'd like to mention that it is important that the images and tables move so that they are in a location that fits the flow of the paper. Right now, they really disrupt the reading experience. As a rule of thumb, it is good for figures and tables to follow after they have been introduced in the main body text. In conclusion, I am happy to recommend this paper for publication subject to the authors considering making the recommended minor changes.

Reviewer #2: The manuscript presents and open hardware ventilator for educational and research purposes. The authors appear to have taken considerable care to ensure that the ventilator is also appropriate to pediatrics. Some thought has been taken to how the design may be deployed as a medical device but this aspect is some way off. The authors correctly identify this and they should be commended for being explicit and clear about the current status of their project.

For context of this review my expertise is on open hardware design and transferring open hardware designs from within academia into distributed production in the global south. This review does not consider the ventilator performance itself. This aspect should be assessed by a reviewer with specific expertise.

The manuscript regularly describes the project as "fully open", boasting that a "complete" web-portal is "optimized" for sharing the entire design, and that complete design decisions have been provided. The software has indeed been developed using open source best practices. A github repository with almost 1,000 commits, and with numerous issues in the issue tracker, and with 73 descriptive merge requests. From this I am confident I could review and understand the software design. All software documentation is versioned in the same repository and rendered. However, this is far from the case for the hardware. The assembly instructions are a Google document, the rendered bill of materials is truncated on the website making it impossible to read. The original CAD files needed to continue the design are provided. However, they all dumped haphazardly into a Google drive folder titled "Julie Magic Air Machine", complete with names such as "I_AM_AN_IDIOT_ADAPTER_15M_TO_22F.SLDPRT". There appears to have been no attempt to document the design history, nor to curate and archive the design somewhere more stable than a Google Drive.

I suggest that at the very least the team organise and curate the design files into a directory structure complete with README files in place to help someone navigate. Any design history that is available could be captured in CHANGELOG files, perhaps with older versions in sub directories. These files should then be archived somewhere such as Zenodo so that this manuscript can link to an unchanging identifier.

To clarify, I pick out the "idiot adapter" not to say that when we make mistakes they should be hidden, however without a structured history the context of what this means is lost. Mistakes are also recorded in the software history, but they are removed from the current version and identified clearly with descriptive commit messages.

Considering design decisions, what is provided is in the supplementary information. A few pages of top down design information do little to mitigate the vast quantities of design information that has been lost by not following the same excellent open practices that were followed for the software design. Of course the processes for collaborative open hardware design are far less established than they are for software. The authors would do better to tone down the self-congratulation on how fully open they are and address head on the challenges they had in working openly on the hardware design. Comparing and contrasting these challenges to the standard practices that they mention for the software design would be both useful for future reference and would be more honest. The author should look to the literature for other commentary or examples on the technical challenges of open hardware design, both generally and specifically in the case of open design of ventilators during the pandemic.

Moving on..

The authors state that no specialist knowledge is required to reproduce the design. It should be clarified that this would not be true in the case of a medical device. It is worth explicitly clarifying that anyone looking to take the design to market would need to fully understand the device and take responsibility for it as a legal manufacturer. Of course this is why the design decisions mentioned above are so critical. The authors would do well to link the sharing of design decisions to medical device manufacturing in the context of international standards for medical device design such as ISO 13485 and ISO 14971. Due to the heavy software component IEC62304 should also be considered. I understand that the ventilator is not at the stage of a medical device, but putting the work needed to transition it to one in the context of the internationally harmonised standards is more useful than only considering only the FDA guidance (which is harmonised with international standards). The authors may find that documentation for the Global Harmonisation Task Force will help them put the work a more international context.

Furthermore it is a shame that the ventilator has been designed using USA-only threads and fittings. My experience working in Africa is that when we have tried to replicate American designs that use USA-specific fixing, we need to significantly modify the design before it can be implemented. USA threads and fittings are available in limited capacity in Europe, but they require highly specialised suppliers. The rest of the world has standardised on metric, having spent years working in the USA I know that metric components are readily available from sources like McMaster-Carr. I suggest that the manuscript should temper its claims to have selected readily available components, or be specific that the components are only readily available in one single country.

In conclusion the paper describes a ventilator designed during the pandemic. This ventilator has done more than many by ensuring that the orignally design files are available. However, reality of the open hardware design does not meet the rose-tinted description in the manuscript, which largely implies (incorrectly) that best practices used for software were also followed for the ventilator. The manuscript and design are also highly USA focused. With curation and archiving of the hardware design, and significant tempering of the language, tone, and descriptions in the manuscript I believe this work should be published in PLOS ONE.

**********

6. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: Yes: Rafaella Antoniou

Reviewer #2: Yes: Julian Stirling

[NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.]

While revising your submission, please upload your figure files to the Preflight Analysis and Conversion Engine (PACE) digital diagnostic tool, https://pacev2.apexcovantage.com/. PACE helps ensure that figures meet PLOS requirements. To use PACE, you must first register as a user. Registration is free. Then, login and navigate to the UPLOAD tab, where you will find detailed instructions on how to use the tool. If you encounter any issues or have any questions when using PACE, please email PLOS at figures@plos.org. Please note that Supporting Information files do not need this step.

Submitted filename: PONE-D-21-35089_reviewer Rafaella Antoniou.pdf

Click here for additional data file.

24 Feb 2022

We have submitted, as pdf files, the following items:

- A letter to the editor.

- A rebuttal letter that responds to each point raised by the reviewers, named 'Response to Reviewers'.

- A marked-up copy of our manuscript that highlights changes made to the original version, in blue. This file is labeled 'Revised Manuscript with Track Changes'.

- An unmarked version of our revised paper, without tracked changes, labeled 'Manuscript'.

Submitted filename: Response to Reviewers.pdf

Click here for additional data file.

29 Mar 2022

PVP1 - The People's Ventilator Project: A fully open, low-cost, pressure-controlled ventilator research platform compatible with adult and pediatric uses

PONE-D-21-35089R1

Dear Dr. Schottdorf,

We’re pleased to inform you that your manuscript has been judged scientifically suitable for publication and will be formally accepted for publication once the minor revision comments from the reviewers are addressed and all outstanding technical requirements have been fufilled.

Within one week, you’ll receive an e-mail detailing the required amendments. When these have been addressed, you’ll receive a formal acceptance letter and your manuscript will be scheduled for publication.

An invoice for payment will follow shortly after the formal acceptance. To ensure an efficient process, please log into Editorial Manager at http://www.editorialmanager.com/pone/, click the 'Update My Information' link at the top of the page, and double check that your user information is up-to-date. If you have any billing related questions, please contact our Author Billing department directly at authorbilling@plos.org.

If your institution or institutions have a press office, please notify them about your upcoming paper to help maximize its impact. If they’ll be preparing press materials, please inform our press team as soon as possible -- no later than 48 hours after receiving the formal acceptance. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information, please contact onepress@plos.org.

Kind regards,

Andre Maia Chagas

Academic Editor

PLOS ONE

Additional Editor Comments (optional):

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation.

Reviewer #2: All comments have been addressed

Reviewer #3: (No Response)

**********

2. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #2: Yes

Reviewer #3: Yes

**********

3. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #2: Yes

Reviewer #3: Yes

**********

4. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #2: Yes

Reviewer #3: Yes

**********

5. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #2: Yes

Reviewer #3: Yes

**********

6. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #2: I would like to thank the authors for making significant changes to the Discussion section manuscript. The section on the design process and critical iterations is interesting and well written. I also think that their new "Challenges of open hardware" section is very fair and balanced. I am very interested in their AutoPilot Wiki for hardware knowledge organisation, I shall dig into it in more detail over the coming weeks.

Whist reading the manuscript I notices the following minor formatting issues:

* One of the LaTeX quotes around "tag" is backwards in the "Challenges of open hardware" section

* The ISO standards are mentioned by name but have not been added to the reference list.

I apologise for the tone of my original review, some deep seated frustrations were contributed to a somewhat hostile tone. I thank the authors for their diligent work in updating the manuscript.

Reviewer #3: First, I would like to thank the authors for the time and efforts they put into developing and documenting this PVP1 project.

The authors highlight a clear lack of accessibility to open device and documentation for respiratory systems, and the need for more open designs in this field.

The manuscript clearly presents a pressure-controlled ventilator system. The documentation detailed in this manuscript and on the associated repositories follows open-source guidelines and it is quite pleasant to observe that this project documentation went through the OSHWA certification process before its submission for publication. In addition, the OKH manifest is a great addition though I fail finding this project on openknowhow.org. Finally, the modularity of the system described makes it reachable and upgradable to all.

The development history of the project is very enjoyable to read to allow the reader to get a proper insight on the developmental approaches, successes, and failure along with the reasoning that led to this reliable and modular system.

It is also quite appreciable to find a medical disclaimer on the manuscript and on all repositories.

I do not have any major comment regarding the last version of this manuscript and would recommend it for publication in PLOS.

I have however a few minor comments. I hope the authors will see them as my attempt to contribute to their project with suggestions to make it both more robust and user friendly.

The authors claim that their device could be beneficial for research and teaching, however I fail to understand the research application for their device. As I am completely ignorant of this field of study maybe a quick example would help the lambda reader to fully appreciate the potential of this project.

Is there any reason for an inspiratory flow sensor not to be installed in the current version as the authors themselves admit it would be a useful addition with minimal implementation complication?

Also, I can only encourage the authors, as an European, to make a metric version for global reproduction without modification from the user part to accommodate their own standard units. Even if I agree with the authors that their design is clear enough to be modified. Still this little effort will save time and trouble to so many. Otherwise, the rest of the building parts are available worldwide; it is unfortunately not a systematic concern to most OSH developers, and it is great to see the authors operating in this direction.

For the software development part, I admit my ignorance on hospital record databases. As I might not be the only one, a quick contextual sentence would give credit to the authors for their desire to extend their I/O interface. Also, is that an educational/research need?

Would it be possible to just quickly explain what is meant by paediatric settings (inflation during inhalation time I presume) so the reader could understand why a longer integration in your PID is relevant to these patients.

The assembly instructions are clearly annotated and easy to follow. It is appreciable that you share your PCB supplier for electronics neophytes that may wonder how to replicate your custom PCBs, however your gerber files are not easy to find, and would deserve to be highlighted on your pvp.org page as you do for your CAD files both in pvp/asset and direct download like the CAD parts.

A similar comment could be made for the software part. Personally, I appreciate the details of your documentation, but for future upgrade I would recommend adding an installation manual for people not use to work with Python libraries, raspberry Pi or any kind of electronics/programming. This is a trivial comment that does not concern the quality of the manuscript work, rather an observation that might suit the spirit of this project to be accessible to the greatest number.

While discussing trivial points, I have noticed a couple of typos:

-In the introduction page2 line 9: “there exists a small number”

-In the introduction page2 line 10: “during the/the last pandemic”

-In the results page6 line 9: consider fixing the syntax error: “[…], the ventilator must detect abnormally high airway pressure must be detected and corrected within 2 breath cycles”

- the acronyms EUA, VTE and PID were not defined, and PEEP was not defined at its first occurrence (first seen at table1 legend)

Overall, this is an impressive OSH project with a high-quality documentation available on multiple platform that still hold the promise to future upgrade.

Thank you to the authors and editor for sharing this manuscript to my review

**********

7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #2: Yes: Dr Julian Stirling

Reviewer #3: Yes: Maxime Zimmermann

18 Apr 2022

PONE-D-21-35089R1

PVP1–The People’s Ventilator Project: A fully open, low-cost, pressure-controlled ventilator research platform compatible with adult and pediatric uses

Dear Dr. Schottdorf:

I'm pleased to inform you that your manuscript has been deemed suitable for publication in PLOS ONE. Congratulations! Your manuscript is now with our production department.

If your institution or institutions have a press office, please let them know about your upcoming paper now to help maximize its impact. If they'll be preparing press materials, please inform our press team within the next 48 hours. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information please contact onepress@plos.org.

If we can help with anything else, please email us at plosone@plos.org.

Thank you for submitting your work to PLOS ONE and supporting open access.

Kind regards,

PLOS ONE Editorial Office Staff

on behalf of

Dr. Andre Maia Chagas

Academic Editor

PLOS ONE