Inexpensive multi-patient respiratory monitoring system for helmet ventilation during COVID-19 pandemic

Background Helmet continuous positive applied pressure is a form of non-invasive ventilation (NIV) that has been used to provide respiratory support to COVID-19 patients. Helmet NIV is low-cost, readily available, provides viral filters between the patient and clinician, and may reduce the need for invasive ventilation. Its widespread adoption has been limited, however, by the lack of a respiratory monitoring system needed to address known safety vulnerabilities and to monitor patients. To address these safety and clinical needs, we developed an inexpensive respiratory monitoring system based on readily available components suitable for local manufacture. Open-source design and manufacturing documents are provided. The monitoring system comprises flow, pressure and CO 2 sensors on the expiratory path of the helmet circuit and a central remote station to monitor up to 20 patients.


Introduction
Non-invasive ventilation systems, such as continuous positive application of pressure (CPAP) and high flow nasal canula, have emerged as important tools for treating coronavirus disease 2019 (COVID-19) patients who need respiratory support but not intubation [2,3].Such non-invasive approaches conserve traditional ventilators and improve patient outcomes by reducing or eliminating the need for invasive ventilation [4].Additionally, COVID-19 patients show surprisingly poor outcomes on June 29, 2020 2/29 invasive ventilation [5], making non-invasive ventilation (where applicable) uniquely valuable during the pandemic.
Helmet non-invasive ventilation (NIV) is a form of CPAP that uses a clear, polyvinyl chloride (PVC), bubble-like helmet, attached to a soft collar that seals around a patient's neck [6].The helmet delivers an air-oxygen mixture to the patient at slightly higher than atmospheric pressure, to keep the patient's airways open and the patient oxygenated.Helmet NIV is appealing for pandemic use because it can be run directly from a constant flow of air-oxygen, which is readily available in hospitals [7].Helmets cost less than 300 USD, are straightforward to manufacture, and have been available during the pandemic, despite supply chain disruptions for other ventilators [1].
Importantly, Helmet NIV is an enclosed system that uses viral filters to protect clinicians and other patients from droplets or aerosolized SARS-CoV-2 viral particles shed by the patient [8].Helmet NIV is permitted by the FDA for COVID-19 treatment [9].Despite these advantages, lingering safety concerns have prevented wider adoption of the helmet in the United States.Steady airflow is required to clear the patient's expired CO 2 from accumulating in the helmet [10].An unexpected drop of airflow caused by a disruption in gas supply or blockage in the circuit could lead to rebreathing of CO 2 and asphyxiation [11].Therefore, one of the greatest concerns when using helmets is the lack of an effective monitoring and alarm system.Antisuffocation valves can help mitigate this risk, but ultimately a dedicated monitoring and alarm system is needed to employ helmet NIV safely [12].Partly for this reason, helmets in the US have been primarily restricted to the ICU, where clinician-to-patient ratios are high enough to allow clinicians to observe patients around-the-clock.
We have addressed these safety risks and clinical needs by developing an inexpensive respiratory profile monitoring system, which we call the Princeton Open Ventilator Monitor (POVM), that is based on readily available commercial components and is suitable for rapid fabrication during a pandemic.The system is designed for use in conjunction with non-invasive helmet ventilator systems, such as the COVID-19 Helmet developed by Sea-Long Medical Systems, LLC [1], but is modular and can be used in other systems.The system comprises one or more flow and pressure sensors per helmet, and crucially includes a central station that can be used to remotely monitor up to 20 patients simultaneously.The system reports to clinicians the flow and pressure in the helmet, the patient's equivalent tidal volume (≈TV), respiratory rate (RR), ratio of inspiratory to expiratory time (I:E ratio), peak inspiratory pressure (PIP), and peak end expiratory pressure (PEEP).The system allows helmets to be deployed more broadly on the wards, since a single clinician can now monitor many patients simultaneously.The respiratory profile provided by the system allows clinicians to track disease progression and informs treatment decisions, including decisions about when to intubate.
We have produced and tested 50 such devices in a matter of weeks at a marginal cost of under 300 USD.Commercial alternatives, like the Philips Respirionics NM3 monitor, offer some of the functionality of our device, but those systems are currently unavailable due in part to disruptions in the medical supply chain.In addition, the commercial alternatives are single-patient devices that cost 20 to 40 times more than our device, thus making them impractical for rapid scale-up and deployment in a pandemic setting.To facilitate local manufacture, we provide detailed parts lists, computer-aided design files, software, and instructions for assembly and testing.

Design and construction of the device and software
The Princeton Open Ventilation Monitor device consists of a flow-sensor assembly and an interface box located at the patient's bedside, as well as a multi-patient remote monitoring station, as shown in Fig 1 .When used with a helmet for monitoring patients undergoing non-invasive ventilation, the flow-sensor assembly is inserted into the exipiratory path.A schematic of the system is shown in Fig 2.

Differential pressure sensor
The flow meter consists of a differential pressure sensor that measures the pressure drop across a flow channel.This pressure drop is then used to calculate flow through the channel.The differential pressure sensor was chosen to be capable of measuring relatively small pressure drops (±500 Pa) with good dynamic range.Stable operation in a humid environment was also a key consideration, as were cost and availability.The device selected was the Sensirion SDP31 differential pressure sensor.This part works by diverting a small portion of the flow and measuring the change in temperature as the gas passes over a small internal heating element.The temperature change in the gas as it flows through the sensor is related to the mass flow rate of the diverted flow stream, which in turn is related to the pressure difference across the sense ports.Readings from the SDP31 are routed to the controller over an I2C bus at a rate of 120 readings per second.
The SDP31 flow sensor, which comes in a surface mount package, is mounted to a small printed circuit board (PCB, see Supplementary Design File 1) that is fixed to the flow block as shown in Fig. 3. To prevent condensation from forming in the narrow flow-sensor channel, a heater has been added.Heat is generated in a TIP32 transistor housed in a TO-220 package.The TIP32 is mounted on the opposite side of the printed circuit board from the SDP31.Operating the transistor at a power of less than 1 W suffices to raise the temperature in the SDP31 sensor to 45 • C, which is above the dew point of the air in the system.The operating temperature is regulated using a pulse-width modulation signal from the readout controller.

Gauge pressure sensor
A second sensor, the MP3V5004G from Freescale Semicondutor, is included to measure the gauge pressure in the flow block.The MP3V5004G measures pressures in the range 0 < p < 3920 Pa (approximately 0 to 40 cm H 2 O) and provides an analog output in the range 0.6 < V < 3.0 V.The analog output is digitized using a Microchip MCP3202 12-bit analog to digital converter.PCB layout and schematics are included in Supplementary Design File 1.

Flow-sensor assembly enclosure
A 3D printed enclosure houses an RJ-45 jack and surrounds the PCBs and flow element.
The enclosure was printed from PLA by a commercial fabrication house (3DGence), see Supplementary Design File 1.

Flow element design
The flow element, shown in Fig. 4, is a 19-mm-diameter tube, partially obstructed by a 10 mm thick wall perforated by nineteen 3.175-mm-diameter channels arranged in a hexagonal pattern.One of the channels is partially obstructed and is used to guide a small fraction of the air flow through the flow sensor.The obstruction is only partial, as a portion of the air flow can directly cross the central wall through a small aperture.
We tuned the diameter of this aperture in order to match the dynamic range of the sensor to the typical flow rates to be measured.We found that a 1.59-mm-diameter aperture is well adapted to a 500 Pa dynamic range differential pressure sensor.Flow is detected as a pressure drop across a small obstruction in one of the channels (red arrow), as measured by a differential pressure sensor (two pronged device, pictured).An additional sensor measures gauge pressure.One of the goals of the machining was to make the blocks repeatable enough that the flow versus pressure drop of all blocks could be characterized with a just a few parameters, eliminating the need for individual calibration.It was particularly important to maintain the uniformity and spacing of the eighteen 3.175 mm-diameter holes (for example, see Fig. 10).Drill wander was minimized by using stiff bits and starting the hole by "pecking."Deburring is also important, as there is a tendency for residual Delrin "hair" to form at the entry and exit of the hole, see 5.This was reduced by touching up the holes with a slightly larger bit.With proper jigging and after some practice, one block could be machined in under 20 minutes.The yield is about 80%.
Cleaning the blocks to "medical grade" required some care.The primary goal was to remove all residual Delrin hair.This was most successfully done by a commercial company [13], using a frozen CO 2 deburring technique, see Fig. 5.The hair could also be melted away by application of a heat gun.In addition, we had success by mounting a 3.175-mm-diameter "low scratch" tube brush dipped in 80 grit water-based slurry in a hand drill and then polishing each hole.These last two methods require some care with the spinning brush being preferable.After the mechanical processes, blocks were cleaned with soap and water and then sonicated in isopropanol for 10 minutes.

Interface box
The interface box reads out the flow and pressure sensors, provides an alarm system with a human interface, and transmits data to a central remote monitoring station for remote, multi-patient monitoring.The core element of the interface box is the microcontroller, which was chosen to be the Raspberry Pi (RPi) Model 4B, running the Raspbian operating system.The RPi is low in cost, widely available, and enjoys the support of a broad user community.It also provides flexibility and allows for additional sensors and interfaces.Wired and wireless network ethernet interfaces are available on the RPi.The human interface was chosen to be simple and minimal.The setting and management of alarm functions is accommodated by a two-line 20-character-per-line LCD screen with individual Red/Green/Blue LED backlights, a pushbutton rotary encoder, and a red-colored "Silence" pushbutton.
On the sensor readout side, the digital bus interfaces were restricted to comply with 3.3V I2C and SPI and the control elements to 3.3V PWM and GPIO.The data transmission distance of the I2C bus imposes a proximity requirement on the interface box to the flow element of approximately 2 m.The time-base of the readout is derived from the RPi system clock using timer interrupts.The human interface is based on asynchronous signal interrupts.
The SDP31 differential pressure sensor is placed into continuous, average until read, mode.The RPi reads the SDP31 over I2C at a rate of 50 Hz, where each reading is the The preferred operating temperature of the flow block sensors is 45 • C to avoid condensation from hot, humid vapor.A heating circuit located on the flow block is adjusted using a convergent "take-back-half" servo algorithm operating on a PWM control signal.The heating circuit has a maximum heating power of 1 W and reaches a maximum temperature of 64 • C. A convergent algorithm enables the circuit to operate at a fixed heating value approximately 200 seconds after power-up, with infrequent adjustment.Small shifts of the analog signal from the pressure sensor are observed when the heating power is adjusted.
The addition of a single, customized two-layer PCB was found to be sufficient to make the connections between the interface box hardware and the 40-pin GPIO through a short ribbon cable, see Supplementary Design File 1.This construction made it simple to design an enclosure to host the RPi and interface box components: • 2x20 character LCD screen with RGB backlight • pushbutton rotary encoder • red-colored silence pushbutton • RJ45 connector for the flow element cable • alarm buzzer

• cooling fan
Laser cut design files for the enclosure and an assembly video are in Supplementary Design File 1 and Supplementary Video 1.
The initial system software for the RPi is installed on a 32GB microSD memory card with a separate data partition.The disk image is then replicated using multiple USB3 hubs running in parallel to provide identical systems for all interface boxes.The custom enclosure allows the microSD card to be removed and replaced, but to minimize handling of the microSD card, the preferred method of software update is through a local repository on the remote monitoring station.
The alarm is based on a 10 s running average of the flow rate and pressure, as well as the average respiratory rate, calculated using a decaying weight on the last several breaths.Maximum and minimum values are entered directly via the pushbutton rotary knob.Rotation of the knob cycles through alarm setting menus, and a "push and turn" operation is used to change the alarm threshold settings.
The sounding of the alarm generates a PWM volume-controlled buzzer and introduces a red back light to the LCD display.A red silence pushbutton on the interface box may be used to temporarily silence the audible alarm, turning the back light to orange.Silence can be invoked preemptively or post-alarm.The silence duration defaults to 120 s, but can also be manually adjusted upon invoking the silence button.The alarm status and all monitoring data is continuously streamed to the remote monitoring station through a wired ethernet interface.The unique digital identification of the flow element sensors, RPi ethernet MAC address, and a unique interface box naming system allows the remote monitoring station to unambiguously assign alarms to patients, as described in Section 2.1.14.

Remote Monitoring Station
The remote monitoring station is the primary means of providing clinicians with detailed patient information.The remote monitoring station comprises a networked computer and a 27 inch monitor.Both an Intel NUC miniPC and a Raspberry Pi were tested, although any modern PC running Python on any operating system will suffice.The remote monitoring station provides a simultaneous overview of all patient interface box data and alarm states.For each patient it shows flow, pressure and volume waveforms and a set of derived quantities, including respiratory rate and equivalent tidal volume (see Fig. 1).In a "drilldown" view it provides full-screen plots of the waveforms for a single patient as well as a pressure-volume plot and derived quantities, while still displaying alarm status information on all patients, see Fig. 15.
The remote monitoring station receives data from interface boxes over a wired or wireless network.In a hospital setting we expect an air-gapped wired network to be used.Our system was tested on an ethernet network with a 24 port hub.The monitoring station acts as an always-on appliance and handles the automatic discovery, pairing and logging of patient interface boxes, described in Section 2.1.14.Because the interface boxes lack battery-backed real-time clocks, the remote monitoring station maintains a master time record for recorded data streams.

Bill of materials
A summary level bill of materials is shown in Table 1  The software is written entirely in Python and uses only open-source components.
On top of a base Python 3.7 installation, additional requirements are currently NumPy, SciPy, PyQt5, pyqtgraph, pyzmq, confuse/pyyaml, zeroconf and the Python Raspberry Pi tools.Qt was selected for both its ability to display real-time graphics with minimal computation resources, and for its portability across computing platforms including for embedded devices.The sections below discuss the software design and implementation of the interface boxes, the remote monitoring station and the communication between them.

Interface box software
The interface box simultaneously runs two python applications called device loop and patient loop.
The device loop collects raw data from the sensors and converts it to JSON, which it both transmits through a ZeroMQ broadcast to port 5556 and logs to a simple file.A basic JSON "packet" is produced at 50 Hz containing the monotonic clock, pressure, and flow data.The flow data is averaged over four readings taken at 200 Hz.Every second, an extended packet is produced, which includes the device temperature measurement, heater duty cycle, sensor identification number, and the path of the current file used for logging.This application does not read the main configuration file, and is completely stand-alone from the rest of the system.It is started when the device starts up and runs until the device is powered down.
The second application is the patient loop This application is responsible for reading the ZeroMQ stream from the device loop, powering the on-device LCD display, taking input from the rotary and silence button, applying calibrations, computing the alarm and respiratory analysis, and producing a new 50Hz JSON ZeroMQ broadcast stream for the remote monitoring station to ingest.The new 50 Hz stream is similar to the original stream, except calibrations have been applied.A different type of JSON structure, with rotary information (including the clinician-set alarm thresholds for respiratory rate, flow and pressure), unique per-device MAC address, current on-device timestamp, silence timer, and last interaction time is sent at 1Hz or whenever the rotary is changed.A configuration file in YAML format allows most settings to be changed or overridden without changing the Python code.
The patient loop runs several threads.There is a collector thread, which reads the input stream and broadcasts to the output stream (the actual reads and writes to the stream are buffered inside the internal ZeroMQ thread).There is also an analysis thread, which runs a lightweight analysis several times per second and a full breath analysis every few seconds (both rates are configurable); this thread can update the display if a displayed value has changed.The rotary and silence button are interrupt driven, though the silencer does launch timers which run in a thread.Locks are used in several places to protect communication of rotary settings and analysis products.
All communication from the device loop to the patient loop is one-way; and all June 29, 2020 12/29 communication from the patient loop to the remote monitoring station is also one-way.This provides a simpler architecture that was easy to make robust, and ensures that one box can be monitored by multiple stations if needed.One side effect of this is that the realtime clocks on the patient stations are not synchronized, so synchronization is made possible by the timestamps on the remote monitoring station.
Configuration is handled through several YAML files.There is a processor/config defaults.yamlfile that stores the defaults for most settings.
There is a top-level file povm.yml that stores copies of settings that might be commonly configured in a deployment.And then, when running, the patient software stores a povm-live.ymlfile in the data directory that keeps track of runtime changes to the alarm limits, so that the alarm settings get restored when the system is restarted.This file is not intended to be edited directly, and is only searched for the rotary settings.If this file were to be corrupted, this is not a failure -the settings are just not restored.A dedicated thread stores the rotary settings every 10 seconds if they have changed.

Calculating derived quantities
Patient breaths and respiratory features are analyzed both locally on the interface box and on the remote monitoring station.
The interface box sensors produce two direct observables as a function of time: absolute pressure (cm-H 2 O) and air flow (mL/min).These two quantities are presented with a digital readout on the bedside interface box.The remote monitoring station displays pressure and air flow as continuous time-series waveforms, along with air volume (mL), integrated from the flow.Since the helmet is designed to have a large constant flow through the circuit, the raw integral of flow steadily increases with time.
To obtain a times eries that shows volume fluctuations associated with breathing, we apply a weak high-pass filter (Butterworth critical frequency of 0.004 Hz) that removes the slow drift while preserving the shape on timescales relevant to breathing.See We call our estimate of tidal volume an "equivalent Tidal Volume" because it represents our best estimate of the tidal volume as measured on top of the constant flow through the helmet.To estimate equivalent tidal volume (≈TV), the volume per-breath is needed.Here we use a slightly different scheme to estimate the volume.We subtract off the mean of the flow before integrating and then use a weaker high-pass filter (Butterworth critical frequency of 0.0004 Hz).This improves accuracy in our per-breath estimate of tidal volume when used in an invasive ventilator context, and it offers a good compromise between controlling drift and distorting the shape of each waveform when computing derived quantities.
Many derived quantities of interest, such as equivalent tidal volume (≈TVi and ≈TVe), respiratory rate (RR), inspiratory-to-expiratory time ratio (I:E), peak inspiratory pressure (PIP), and peak expiratory endpoint pressure (PEEP), are functions of a breath cycle.Breaths can vary in duration, so we need to identify landmarks on the time series that define points along the breath cycle.We do this by first smoothing the absolute pressure and air flow time-series using locally estimated scatterplot smoothing (LOESS) with a Gaussian kernel that has a 0.2 second standard deviation, then finding the roots of the smoothed curve and its derivative as the four turning points of the breath cycle.These four turning points correspond to the time points during a breath cycle when the lungs are least inflated, mid-inhale, most inflated, and mid-exhale, as shown in Figure 7. Once these turning points have been identified, each quantity of interest is derived by analyzing an extremum or a difference of pressure, volume, or time between these points.Breath-based derived quantities are listed in The analysis functionality is implemented using the rolling buffer functionality described above together with numerical functions from the NumPy and SciPy Python packages.It produces Python dictionaries for breath measurements, cumulative measurements, and alarm states.The analysis is run on both the interface box and the remote monitoring station.

Software on Remote Monitoring Station
The back-end software is shared between the interface box and the remote monitoring station.A Generator is the core class, which handles the analysis thread and most of the data structure.The subclass that does the on-device collection and rebroadcast thread as described in Section 2.1.10 is the Collector.There is also a RemoteGenerator subclass of Generator, and this instead only reads from an interface box broadcast in a thread.This is used by the main Graphical User Interface (GUI) to monitor each connected interface box.
The remote monitoring station GUI is implemented in PyQt [14].The GUI main window displays a grid of patient stations, each of which shows waveforms for flow, pressure, and volume and derived quantities.The grid can be rearranged via drag and drop.Clinicians can adjust the waveform axes.Clicking the status button shows advanced options, such as removing a disconnected sensor.Alarm status is displayed using both colors and symbols, as described in Table 3.
Clicking any of the grid tiles on the main screen will bring up a "drilldown" screen of information for that interface box (see Fig. 15).The drilldown screen shows a larger set of waveforms and additional derived quantities.It also includes a Volume vs. Pressure plot and additional information about alarm limits and averaging times, the duration elapsed since the last seen breath, the time elapsed since the last interaction at the patient station, and the countdown until the end of any silence mode.An overview status bar shows status and alarm information from all of the other interface boxes.
The device logs both software state and sensor data.Software-related logging is performed by the main thread and at the level of each Generator.Python errors, changes to the rotary knob, alarms and silencing events are all logged.Sensor data is stored in a CSV file, and breath data is stored in JSON files.3. Alarm status GUI scheme for remote monitoring station.

Device discovery and pairing
When patient interface boxes are connected to the network, they are automatically discovered by the remote monitoring station using the python-zeroconf framework.
Clinicians then need only to associate the interface box with a given patient by entering the patients name, room number or other identifier.
To reduce the chance of error when associating interface boxes with patients, each interface box has an effectively-unique human-friendly name.The interface box and remote monitoring station share a deterministic naming algorithm that assigns adjective-noun combinations to the patient interface box's ethernet address.Two word names are chosen from 4096 curated adjectives and nouns each (for a total of 16.7 million possible names), using a pseudorandom algorithm seeded by the bits of the ethernet address.Unlike assigned names, which could be lost due to memory or disk errors, and which require careful records to avoid collisions, the device names are fully determined from the hardware ethernet address.Names are displayed on each interface box, and also on the remote monitoring station.
The names of the first 20 devices we produced are given in Table 4.
2.2 Methods for testing and evaluation of the device and software

Software testing
Software was designed with the following testing strategies in place: Static type analysis is performed to ensure basic validity of the code on every commit.Some portions of the code, such as the custom rolling window, have unit tests.A simulation and a data recording playback feature provide tools to perform integration tests for the hardware, analysis, and the clinician GUI.An alternative patient loop that runs using Qt instead of requiring the hardware rotary, screen, and silence button enables testing with the playback even without a physical device present.

Flow-sensor assembly calibration tests
The flow-sensor assembly was calibrated by using a mass flow controller (Alicat Scientific MCR-100SLPM-D).As sketched in Fig. 8c, the inlet port of the mass flow controller (MFC) was connected to compressed air and the outlet port was connected to the flow element by a long segment (1.5 m) of medical tubing.To minimize the effect of    The relation between a Darcy friction factor f D and Reynolds number can be looked up in standard Moody diagrams [15].For turbulent flow in sufficiently long smooth tubes, f ∝ Re −1/4 , which implies ∆P ∝ Q 7/4 .When our flow is lower, the Reynolds number drops.At a flow of 10 L/min (Re = O(200)), the flow in a shorter tube will have a growing boundary layer.In such laminar flow cases we expect ∆P ∝ Q 3/2 .We note that our calibration lookup table follows the ∆P ∝ Q 7/4 for high flows and the ∆P ∝ Q 3/2 for lower flows in agreement with expectations (Fig. 9).

Gauge pressure test
The gauge pressure sensor was calibrated by imposing a constant pressure with a pressure controller (Fluigent MFCS-EZ).The sensor saturates at a value around 3000 Pa and exhibits a linear response, see Fig. 11.

Methods for bench test comparison to commercial medical systems
To compare our device against commercial systems, the April 22nd version of our device was tested on a commercial test lung (IngMar ASL5000) driven by a commercial ventilator (GE Avance CS2 Anaesthesia System) in series with a commercial respiratory monitoring system (Philips Respironics NM3).Our device and the commercial monitoring system were both situated in-line on the inspiratory path of the ventilator circuit.Simultaneous recordings of pressure and flow were made from our device, the commercial monitor, and the test lung system.Ground-truth volume information was also recorded from the test lung and precisely time-aligned.Pressure information from our device was also compared to the commercial monitor (NM3).Respiratory rate, PIP and PEEP were also recorded from our device and occasionally compared to the display of the commercial ventilator.Our device was tested under a variety of ventilation modes including Pressure Control Ventilation, Volume Control Ventilation, and Synchronized Intermittent-Mandatory Ventilation with Pressure Control (SIMV PC).The test lung's compliance was varied from 80 mL/cm H 2 O, typical for a healthy adult, to 20 mL/cm H 2 O which is more typical of a diseased lung.Respiratory rate was set on either the ventilator or the lung to be approximately 15 breaths per minute.

Quality control and acceptance testing of final assembled devices
We developed a quality control protocol that could be used to test finished assembled devices prior to delivering to patients.The test demonstrates that each flow-sensor assembly's combination of specific flow element and sensors gives measured results for flow and pressure within a set range, for example ±10% of actual values.This was done by providing a known flow (using an Aalborg GFC47 mass flow controller) or known pressure (measured at a low flow using a water manometer sampling the flow just upstream of the flow element), recording sensor data with an interface box, analyzing the data using the fixed average calibrations discussed in Sec.2.2.3 and 2.2.4,and comparing the recorded data to the known values.

Methods for human subject test
Human subject tests were conducted in accordance with IRB protocol # 12857 approved by Princeton University's Institutional Review Board.Written consent was obtained from a healthy adult volunteer.The subject was placed in a helmet (Sea Long Model PN5404) fed by 80 L/min of medical air (AirGas) configured as shown in Fig 1 with the PEEP valve set to its lowest limit, nominally 5 cmH 2 O.A one way valve (Teleflex Model 1644) was added to one of the helmet ports to serve as an anti-suffocation valve.The subject was in a standing position.The subject's spontaneous breathing was recorded on our respiratory monitor device over two 20 min trials as the subject was instructed to breath normally.A water manometer in our air delivery system appeared to contribute to dynamic changes to the volume in the helmet circuit coincident with the subject's breathing, so the manometer was inactivated during portions of the recording.

Flow, pressure and tidal volume agree with commercial systems
We placed a prototype of our device in a circuit with a commercial single-patient respiratory monitoring system (Philips NM3) on a test lung (ASL-5000) driven by a commercial ventilator.We compared recordings made by our device to those made by the test lung and the commercial monitoring system.Recordings from our device show strong agreement with the test lung for flow and volume.See Figs. 12, 13 and 14.Our device's flow measurement showed closer agreement to the test lung than the commercial monitoring system that was measuring flow simultaneously.There was a scaling factor of about 5% discrepancy between our device and the test lung's measured flow, while the commercial monitor reported flows that differed from our device by a scaling factor of about 15% and an offset of 2 L/min.The commercial respiratory monitor also would occasionally show a flat line for flow or pressure during a breath, while our system captured dynamics of all breaths (see artifact at approximately 158 s in Fig. 12 and as a horizontal spread around zero in Fig. 14).
In measures of pressure, our system had close agreement to the commercial respiratory monitor.We note that our system seemed to avoid quantization artifacts found in the commercial monitoring system at low pressures (see steps in pressure around 80 s in NM3 recording in Fig. 12 ).We also compared derived quantities-the equivalent tidal volume, PIP, PEEP, and breathing rate-with those reported by the ventilator at the same time.Our system largely agrees with the ventilator's own settings (see Table 5

Human volunteer study
A healthy consenting adult volunteer was placed in a helmet and received medical air at 80 L/min while undergoing monitoring with our device.The device captured reasonable waveforms for flow, pressure and equivalent tidal volume, as shown in Fig. 15.The measured respiratory rate matched that reported by the subject.Measured flow waveforms appear qualitatively similar to previous reports of human subjects in a helmet [10].Recorded device data stream is available in Supplementary Data Files 1.

External sources of variability
We tested the influence of relative humidity on our sensors, Fig. 8(d).We challenged our device by measuring 20 hours of continuous flow of saturated humid air (RH = 100%).Both sensors performed even in the presence of significant condensation in the flow element, which suggests that our heater circuit functions effectively.In tests with variable humidity, we observed that the flow Q increased slightly by less than 3% while the humidity rose from 5 to 100%.
Finally, the presence of curvature in tubing has been reported to affect measures of downstream flow [16,17].This is relevant because our device may dangle off the helmet at an angle, as can be seen in Fig. 1.We introduced a 90 • bend into the tubing a variable distance L upstream of our device and observed the change in our device's reported flow Q under a constant imposed flow of 100 L/min, Fig. 8(e) and Fig. 16.We observed a systematic increase in the flow Q reported by our device for bends less than 30 cm upstream of our device.The largest deviations from the imposed flow occurred when the bend was closest to the device (5% for L = 5 cm).

Results of production run
We completed a production run of 50 devices.Producing devices at scale posed additional challenges regarding calibration and quality control.In particular manufacturing defects in the flow element altered the relationship between the measured pressure difference ∆P and the flow Q across the device, as shown in Fig. 10.Initial determination of ∆P vs. Q for each flow element with a fixed sensor array allowed us to eliminate outliers from the determination of the average calibration.After each flow element is integrated into its final flow-sensor assembly, it will undergo the acceptance testing described in Sec.2.2.6.An example test result is shown in Fig. 17.

Discussion and Conclusion
We designed and built an inexpensive respiratory monitoring device from conception to production in a six week period coincident with the initial peak of the COVID-19 pandemic in our region.Our device shows similar, and in some aspects better, agreement with a test lung than a commercial monitoring system that is currently unavailable.Measurements of a healthy volunteer in a helmet taken by our device are reasonable and match prior reports.Our device has the potential to improve patient outcomes and to mitigate well-documented safety concerns regarding CO 2 re-breathing that have prevented the helmet's widespread adoption.Our device also introduces the ability to monitor many patients simultaneously.Importantly, our device uses off-the-shelf components that have shown themselves to be robust to supply chain disruptions.The device is well suited for local manufacture during a pandemic.The device is designed for helmet systems but we have also successfully tested it in traditional invasive ventilator settings.We currently are seeking FDA emergency use authorization.
For future versions of the device we are exploring adding CO 2 -and O 2 -sensors, and possibly adding hardware, such as an EEPROM, with each sensor board to enable per-sensor calibration curves.

Fig 1 .
Fig 1. Device monitors respiratory features by measuring pressure and flow of air leaving a helmet.Top: Device is shown installed in a typical circuit.(1) Inspiratory path.(2) Filter.(3) Patient in helmet.(4) Filter.(5) Expiratory path.(6) Flow-sensor assembly.(7) PEEP valve.(8) Interface box.The interface box reports basic respiratory information and announces audible and visual alarms if flow, pressure or respiratory rate cross clinician defined thresholds.Bottom: The remote monitoring station displays flow, pressure, and volume waveforms and clinically relevant quantities including equivalent tidal volume, respiratory rate, I:E ratio, PIP and PEEP from up to 20 devices.Here 16 devices in a test-circuit are being monitored simultaneously.

Fig 3 .
Fig 3. Flow-sensor assembly.A flow and pressure sensor are exposed to the flow element.The electronic sensor elements are mounted on circuit boards that connect to an external RaspberryPi controller via a standard RJ-45 jack.

Fig 4 .
Fig 4. Flow element.The flow element is a 19 mm diameter tube of length 82 mm with an obstruction to create a pressure drop.a. Exterior view.b.View along the direction of airflow.A honeycomb pattern of holes decreases turbulence.c.Interior view.Flow is detected as a pressure drop across a small obstruction in one of the channels (red arrow), as measured by a differential pressure sensor (two pronged device, pictured).An additional sensor measures gauge pressure.

Fig 5 .
Fig 5. Delrin hair removal.Flow block is show a) before and b) after frozen CO 2 deburring.Note the small delrin hair filaments (red arrows) are gone.

Fig 6 .
Fig 6.Interface box.Raspberry Pi based interface box sits at patient bedside.It provides an alarm system with a human interface and it relays sensor information to the central remote monitoring station.

Fig 8 .
Fig 8. Calibration of the flow sensor.a) Standard flow sweep used to calibrate the flow sensor.Successive steps of flow Q (L/min) were imposed -the blue points are the flow measured in the mass flow controller (MFC).b) The differential pressure ∆P (Pa) as measured by our flow sensor.Black points are raw data measured by the sensor at 50 Hz.Red points are derived from the black points by eliminating the beginning and end of each step and averaging to match the 10-Hz of data from the MFC.c) Sketch of the standard configuration of our calibration setup.The MFC delivers a controlled flow Q to our flow element.d) More tests were performed by adding a humidifier and a PEEP valve.e) The influence of the tubing curvature was systematically tested by forcing a 90 • bend at a distance L of the flow block.

Fig 9 .
Fig 9. Calibration curve for measuring flow from differential pressure.Left: Measurements of ∆P as function of the imposed flow Q for a single flow element.For low flow (below 15 L/min), ∆P ∝ Q 3/2 whereas ∆P ∝ Q 7/4 for larger flows.Right: Averaged measurements of ∆P as a function of the flow Q on 42 flow blocks machined by commercial firm Xometry.The error bars represent standard deviations.The solid line shows the lookup table that is installed in all of our devices.

Fig 10 . 1 2
Fig 10.Influence of large machining defects on flow calibration.Measurements on flow element A and B overlap nicely, but measurements on C are affected by the obvious defects in the honeycomb pattern (red dashed circles in the bottom picture).

Fig 11 .
Fig 11.Pressure sensor calibration.The pressure P measured varies linearly (solid line of slope 0.81) with the pressure P app applied with the Fluigent pressure controller and saturates above 3000 Pa.

Fig 12 .
Fig 12.Comparison to commercial monitor.Overlay of flow and pressure measured simultaneously from the Princeton Open Vent Monitor, a commercial respiratory monitor (NM3), and an artificial lung (ASL-5000) driven by a commercial ventilator.
Fig 13.Volume comparison to test lung.Overlay of derived volume from the Princeton Open Vent Monitor (using the high-pass filter with the weaker 0.0004 Hz Butterworth critical frequency) and measured volume from an artificial lung (ASL-5000), driven by a commercial ventilator.

Fig 14 .
Fig 14.Fine comparison of Princeton Open Ventilation Monitor (POVM), the artificial lung simulator (ASL), and a commercial respiratory monitor (NM3) in matched time-bins (100 ms wide).The commercial monitor occasionally drops to zero and has discretization effects at low pressure.POVM and ASL agree in flow up to a 5% scale factor; POVM and NM3 agree in flow up to a 15% scale factor, and POVM and NM3 agree in pressure up to a 5% scale factor.

Fig 15 .
Fig 15.Respiratory profile of healthy human subject in helmet.Top: Pressure, flow and integrated flow for gas on the expiratory path of a helmet worn by a healthy human subject is shown.Positive flow is defined to be gas leaving the helmet through the expiratory path.Bottom: Derived quantities, including tidal volume, respiratory rate, etc are visible on the remote monitoring station (shown here in "drilldown" screen).

Fig 16 .
Fig 16.Effect of bent tubing.Flow Q measured by our flow sensor in the presence of a 90 • bend positioned a distance L upstream of the flow block.A 100 L/min flow was imposed by a Mass Flow Controller.

Fig 17 .
Fig 17. Results of acceptance testing of a final flow-sensor assembly.Left: comparison of calibrated flow reported by the device under a test to flow set by a Mass Flow Controller.Right: comparison of calibrated pressure reported by the device under test to pressure measured with a water manometer.Red text uniquely identifies the flow-sensor assembly.

Table 1 .
and detailed bill of materials is in Supplementary Design File 2. Summary level bill of materials.Full details are available in Supplementary Design File 2. Circuit board costs include assembly and minor components.Each remote monitoring station accommodates up to 20 patients.Software is released as open source under the MIT License and is available athttps://github.com/Princeton-Penn-Vents/princeton-penn-flowmeter.The software integrates together the data collection and handling in the interface boxes and remote monitoring stations, provides an analysis suite for monitoring and alarm determination, drives the rotary-dial interface of the interface box and implements the graphical user interface of the remote monitoring station.It has been designed to work with minimal computational resources, to be easily portable, to have few external dependencies, and to use standard, well supported, tools when external dependencies are used.

Table 2 .
Breath records are logged and accumulate as a growing list.Cumulative Fig 7.Signal processing to calculate volume and identify breaths.Left: effect of a high-pass filter in removing drift in volume (integral of flow).Recording here is with a test lung.In a helmet circuit the integral drifts because the ventilation system is designed to continuously vent expired air.Right: identifying breath cycles in the time-series data via turning points: roots of smoothed flow and its derivative.

Table 2 .
Quantities derived for each breath from the original timeseries (flow, pressure, and volume versus time).measurementsarederivedfrom these breath-based measurements as exponentially weighted moving averages (EWMA) of breath records with α = 0.3, meaning that it takes approximately 1/0.3 = 3.3 consecutive breaths for a new trend to emerge.In particular, the respiratory rate, inspiratory and expiratory-endpoint pressures (PIP and PEEP), inspiratory and expiratory tidal volume equivalents (≈TVi and ≈TVe), and compliance are all reported as moving averages.2.1.12Softwaredetection of AlarmsAlarms are raised when a monitored quantity exceeds a predefined threshold (either too high or too low) and are immediately removed once the quantity returns to a suitable value.Thresholds are set via the rotary dial on each interface box and are passed to the analysis software together with other data.Some alarms are raised on time-window averaged time series, specifically, flow and pressure, while others are raised on EWMA averages of derived quantities, currently only respiratory rate.In addition, "stale data" alarms are raised if any derived quantity is not received after a time window, which could indicate a bad connection.