EUROPEAN ORGANIZATION FOR NUCLEAR RESEARCH (CERN)

CERN-EP-TECH-NOTE-2020-002

The HEV Ventilator

HEV Collaboration†††Authors are listed at the end of this paper.

HEV is a low-cost, versatile, high-quality ventilator, which has been designed
in response to the COVID-19 pandemic. The ventilator is intended to be used
both in and out of hospital intensive care units, and for both invasive and
non-invasive ventilation. The hardware can be complemented with an external
turbine for use in regions where compressed air supplies are not reliably
available. The standard modes provided include PC–A/C (Pressure Assist
Control), PC–A/C–PRVC (Pressure Regulated Volume Control), PC-PSV (Pressure
Support Ventilation) and CPAP (Continuous Positive Airway Pressure). HEV is
designed to support remote training and post market surveillance via a web
interface and data logging to complement the standard touch screen operation,
making it suitable for a wide range of geographical deployment. The HEV design
places emphasis on the quality of the pressure curves and the reactivity of
the trigger, delivering a global performance which will be applicable to
ventilator needs beyond the COVID-19 pandemic. This article describes the
conceptual design and presents the prototype units together with their
performance evaluation.

© 2024 CERN . CC-BY-4.0 licence.

###### Contents

  1. 1 Motivation
  2. 2 Overview of HEV functionality
    1. 2.1 HEV operation modes
    2. 2.2 Specifications
  3. 3 HEV Conceptual Design
    1. 3.1 Central Pneumatic Unit
    2. 3.2 Alternative air supply
    3. 3.3 Accessories and disinfection protocols
    4. 3.4 Electrical design
    5. 3.5 Control and User Interface
      1. 3.5.1 Control
      2. 3.5.2 Microcontroller functionality
      3. 3.5.3 Raspberry Pi functionality
      4. 3.5.4 Communication
      5. 3.5.5 Software Practice
      6. 3.5.6 User Interface
  4. 4 HEV Prototypes
    1. 4.1 Prototype mechanical design
    2. 4.2 Alternative mechanical design
  5. 5 Prototype test results
    1. 5.1 Setup
    2. 5.2 Target Pressure Performance
    3. 5.3 Inhale Trigger Peformance
    4. 5.4 Oxygen mixing test
  6. 6 Conclusion
  7. Acknowledgements

##  1 Motivation

The worldwide medical community currently faces a shortage, especially in low
and middle income settings, of medical equipment to address the COVID-19
pandemic [1, 2, 3, 4, 5]. In particular this is the case for ventilators,
which are needed during COVID-19 related treatment both in the acute phase,
when invasive fully controlled ventilation is needed, and also in the subacute
phase during the weaning from mechanical ventilation, which can last for an
extended time period. Companies are scaling up production [6], but this will
not be sufficient to meet the demand according to the current forecasts. There
currently exist a wide spectrum of ventilatory support devices, ranging from
highly sophisticated through to simpler units [7, 8]. In the context of the
COVID-19 pandemic a large number of proposals are already circulating for
devices which can be quickly manufactured cheaply and on large scale [9, 10,
11, 12, 13, 14, 15].

The pandemic has also drawn attention to the lack of ventilation equipment in
low and middle income countries. Globally, pneumonia is the most common
infectious cause of death [16, 17, 18], and the need for adequate respiratory
equipment for treatment and management of pneumonia patients will persist even
as the COVID-19 pandemic wanes.

In this paper we describe the design of a high-quality ventilator, named HEV
(High Energy particle physics Ventilator), which is intended to provide full
functionality while being capable of manufacture at relatively low cost, and
show the results obtained from the prototype testing. This is an update from
the original proposal [19]. The HEV design [20] is based on readily available
and inexpensive components, and the ventilator is intended to be used both in
and out of the intensive care unit environment, and for either intubated or
non-intubated patients. The design began in March 2020, using as a starting
point the set of MHRA (Medicines and Healthcare products Regulatory Agency)
guidelines provided by the UK government regarding Rapidly Manufactured
Ventilator Systems [21]. As the project evolved, regulations and
recommendations from other bodies, including the EU, AAMI and WHO [22, 23, 24]
were taken into consideration, the team was reinforced by an international
advisory body of clinicians, and advice, collaboration and equipment was
provided from local hospitals. The design and prototypes described here are
not, at this moment in time, a medically approved system and will need a
process of verification according to medical certification. However, the
design is sufficiently advanced that the functional results can already be
shared, as the HEV collaboration moves forward towards certification and
manufacture.

##  2 Overview of HEV functionality

###  2.1 HEV operation modes

Patients affected by COVID-19 face serious issues of lung damage, and the
ventilatory equipment must be able to handle situations of rapidly changing
lung compliance as well as potential collapse and consolidation. It is
critical that the ventilator is able to deliver protective ventilation to
patients with nearly normal as well as patients with low compliance. The
driving pressure of the ventilator is a crucial factor for patient outcomes
[25]. In particular, when a low tidal volume is used, the driving pressure is
an important variable to monitor and assess the risk of hospital mortality
[26]. In light of the prolonged recovery/weaning phases involved in COVID-19
critical care cases, there is a need for ventilators which are able to deliver
protective controlled ventilation but also are able to delivery assisted
ventilation to be efficient for the ventilator weaning process.

Following the COVID-19 guidelines, the HEV development has prioritised
pressure modes, and aims to offer these modes in the simplest possible format.
The HEV ventilation modes are divided into two groups: pressure-assist-
controlled modes, where the patient effort plays no role or a partial role in
the ventilation, and pressure-supported modes, where the patient breathing is
spontaneous but supported by the ventilator111For a pedagogical discussion of
ventilator modes, see [27].. The former group includes PC–A/C (Pressure
Control – Assist Control) and PC–A/C–PRVC (Pressure Control – Assist Control –
Pressure Regulated Volume Controlled), while the latter includes PC-PSV
(Pressure Control – Pressure Supported Ventilation), and in addition provides
CPAP (Continuous Positive Airway Pressure). The CPAP mode is also available,
as for lower-cost devices which offer less versatility than the HEV
ventilator. This mode is included with the HEV modes in order to provide the
widest range of support throughout COVID-19 treatment, and may be a crucial
option for selection in low resource settings [28].

The modes supported by HEV are summarised in table 1. Note that in the
interests of simplicity and ease of operation the patient inhalation trigger
is to be set for all modes, although the exact trigger levels can be adjusted
by the clinician. This is important to avoid isometric contractions of the
diaphragm against a closed valve that could promote diaphragm injuries and
prolonged duration of ventilation. The HEV design also allows PEEP (Positive
End-Expiratory Pressure), which is not a ventilation mode in itself but is
designed to support steady low positive pressure to the lungs to avoid
alveolar collapse.

HEV nomenclature |  Patient trigger |  Inhalation start |  Exhalation start |  Respiratory rate (RR) |  Comment
---|---|---|---|---|---
Pressure Control modes |
PC-A/C |  on |  Machine/ patient triggered |  Machine cycled |  Minimum RR programmed, patient effort can increase RR |  $\mathrm{p_{inh}}$ constant
PC-A/C-PRVC |  on |  Machine/ patient triggered |  Machine cycled |  Minimum RR programmed, patient effort can increase RR |  Volume guarantee via $\mathrm{p_{inh}}$ variation
Pressure Support modes |
PC-PSV |  on |  Patient triggered |  Patient cycled |  Spontaneous In case of apnea fail-safe to PC–A/C |  $\mathrm{p_{inh}}$ constant
CPAP |  on |  Constant Positive Airway Pressure Spontaneous breaths In case of apnea fail-safe to PC–A/C
Table 1: Summary of HEV basic ventilation modes.

The PC–A/C mode supplies a defined target pressure to the patient, with a PEEP
defined and set by the clinician. In the case where there is no patient
effort, the breathing rate and the inhalation time are fully defined by the
parameters entered by the clinician. The mode also allows the start of
inhalation to be triggered by patient effort, detected from the air flow
measurement. The PC–A/C–PRVC mode is an extended mode of PC–A/C ventilation,
where the ventilator aims to provide a set tidal volume at the lowest possible
airway pressure. This works by ventilating at an initial set pressure, and if
the tidal volume is not achieved, (due to, for example, changes in the patient
airway resistance or lung compliance), the ventilation can be gradually
adjusted. In both of these modes the exhalation part of the cycle is triggered
by timing, defined by the parameters set by the clinician.

In PC-PSV mode, the inhalation and exhalation parts of the breathing cycle are
defined by patient effort and lung mechanics. The inhalation is triggered as
for the PC–A/C modes, and the exhalation is triggered when the flow drops to a
pre-defined fraction of the peak value – typically 25%, but can be set by the
clinician.

In all modes it is possible to measure the plateau pressure and intrinsic PEEP
in order to provide clinical diagnoses and estimation of the patient static
lung compliance or to detect AutoPEEP. The ventilator operation sequence
includes a pause time at the end of the inhalation phase during which the
valves are closed, normally set to an imperceptibly short time of 5 ms. The
pause time can be increased, for a few breaths, to a few hundred milliseconds,
in order to accurately measure to plateau alveolar pressure at zero flow. The
intrinsic PEEP at the end of the exhale phase can be measured in the same way
during the pre-inhale state. These measurements are manual operations
performed typically over the course of three or four breaths, and can be used
to track clinical parameters.

Particular attention has been paid during the design of HEV to the ability of
the machine to synchronise to the patient and to offer suitable pressure
profiles, issues which directly influence the patient comfort [29]. This is
discussed more completely in section 5 where the HEV prototype measurements
are presented.

###  2.2 Specifications

The HEV ventilator is designed to meet the main specifications defined in
table 2.

Specification |  Characteristics
---|---
Operation modes |  PC–A/C, PC–A/C–PRVC, PC-PSV, CPAP, as defined in the text
PEEP installed |  Adjustable in the range $5-20$$\,\mathrm{cm\,H_{2}O}$, in increments of $5$$\,\mathrm{cm\,H_{2}O}$
Inhalation airway plateau pressure limit |  Set to 35$\,\mathrm{cm\,H_{2}O}$ by default, with an option to increase to up to 70$\,\mathrm{cm\,H_{2}O}$ in exceptional circumstances and by positive decision and action by the user
Mechanical fail-safe valve |  At 80$\,\mathrm{cm\,H_{2}O}$
Mechanical fail-safe valve to connect patient to atmosphere in case of failure |  Present
Minute volume flow capability |  Up to 20 L/min
Inspiratory flow capability |  Up to 120 L/min
Respiratory rate |  $10-30$ breaths/min, adjustable in increments of 2
Inhalation:Exhalation time ratio |  1:2 provided as standard, adjustable in the range 1:1–1:3
Inhalation time |  Optional setting
Tidal volume setting |  Provided in the range $250-2000$ mL in steps of 50 mL
Inhaled oxygen proportion $\mathrm{FIO_{2}}$ |  Adjustable between 21% and 100% in 10% steps
Gas and power supply inlets |  Set according to the MHRA standards [21]
Mandatory alarms |  Gas or electricity supply failure Machine switched off while in mandatory ventilation mode Inhalation airway pressure exceeded Inhalation and PEEP pressure not achieved Tidal volume not achieved or exceeded Hypoventilation and high leakage
Monitoring of set parameters |  Ventilation mode, Respiratory rate, Tidal volume, PEEP, and $\mathrm{FIO_{2}}$
Monitoring of actual measured parameters |  Airway pressure, Respiratory rate, Achieved tidal volume, PEEP, $\mathrm{FIO_{2}}$, and real time confirmation of each patient breath in pressure support mode
Table 2: Summary of the HEV main specifications.

##  3 HEV Conceptual Design

###  3.1 Central Pneumatic Unit

Figure 1: Conceptual design of the HEV ventilator.

The HEV conceptual schematic is shown in figure 1. The design is based around
a central buffer which pneumatically decouples the ventilator circuit into
two, almost independently functioning parts, relating to the filling of the
buffer and the gas supply to the patient, respectively.

On the filling side of the circuit, two inputs are provided for air and
oxygen. These may be supplied via the standard compressed hospital air and
oxygen supplies, in which case typical input pressures will be between 2 and 5
bar. Alternatively, the input may be supplied via a compressor, oxygen
concentrator, or turbine, in which case lower pressures can be expected. In
either case, regulators ensure a step down of pressure to the buffer, and the
input valves are used to control the gas flow into the buffer. The individual
flows are passively mixed inside the buffer, which is filled to a target
pressure. Once this has been achieved, the buffer output valve is opened,
initiating the respiratory cycle. This valve is controlled by a PID
(Proportional–Integral–Derivative) controller, which allows a stable delivery
of pressure and a fine tuning of the pressure rise time. The controller takes
as input the inhale pressure measurement and regulates the valve opening to
maintain the inhale pressure at the target value. This has the advantage that
the pressure delivery is independent of flow and buffer pressure. At the end
of the inhalation phase there is a possibility to set a wait time, during
which both the inhale and exhale valves are closed. After the inhalation phase
finishes, the exhale valve is opened for exhalation and the buffer is re-
filled for the next breath cycle. The standard state diagram illustrating
these actions is shown in figure 2. The state changes are controlled via the
microcontroller and may be time or condition driven. For CPAP operation the
input valves to the buffer are kept open and the PID valve is regulated to
supply a constant level of pressure. The PID algorithm ensures that the system
is robust against fluctuations in flow or gas supply pressure.

Figure 2: HEV Ventilator State Chart.

The buffer concept presents many operational advantages. In general, the
separation of the fill and exhale cycle into two separate circuits makes the
design, control and component selection more straightforward, and allows less
expensive components to be selected. The initial step-down of the pressure
between the supply and the patient introduces safety and robustness against
variations in the gas supply. It also makes the fine tuning of the precise
pressure control which is required for the patient side of the circuit more
readily accessible. The buffer volume also avoids that the O2 and air delivery
systems need to be able to handle the peak flow rates of up to 120 L/min
needed in the inhale phase, and the patient air supply is protected. The
mixing of the gases, which is provided in a natural way inside the buffer,
avoids the need to purchase an external gas blender. In addition the
measurement of the O2 concentration, which can be done by spying on the static
gas volume, is an inherently more precise measurement than measuring on a gas
stream, and does not require a fast reaction time of the meter, nor a
medically compatible meter. Should the design need to be adapted to a more
extreme (very hot, or very cold) environment, thermal control of the gas in
the buffer is straightforward. In addition there is a monitoring advantage:
the delivered tidal volume can be calculated from the pressure drops in the
buffer. This provides a precious monitoring cross-check in addition to the
standard tidal volume measurement, reinforcing the safety of the design.

Figure 3: Schematic of the pneumatic part of the HEV system.

To ensure better oxygen intake and to prevent lung collapse, the exhalation
branch is fitted with a PEEP valve. The respiratory rate, inhalation time and
pause time are all controllable. If a PEEP pressure is set, then the pressure
in the lungs will not fall below the minimum of the PEEP pressure. For normal
vent mode operation the pause time is set to be imperceptibly short ($\sim 5$
ms), however longer values can be set, for instance when the care giver wishes
to measure the lung static compliance. The design concept provides inherent
safety in that there is a step down of pressure from the regulator before the
air reaches the buffer, and in addition the inhale valve is only opened once
the pressure is stabilised. Via the buffer step the system is also inherently
protected from variations in the inlet pressures. The volume of air taken by
the patient (tidal volume) can be calculated knowing the buffer pressure
measurements, the PEEP value, and the fixed volumes of the buffer and tubes in
the system. The volumes of the tubes, typically between 1 and 2 L, including
any equipment such as humidifying devices, may be routinely confirmed, along
with checking for leaks and measuring tube compliance, before the ventilator
is connected to the patient.

The patient is directly protected from over-pressure via the pressure relief
valve, which opens at 50$\,\mathrm{cm\,H_{2}O}$. In addition, the pressure
sensor in the buffer continuously monitors for over-pressure. In case of over-
pressure in the buffer, the electro-valve is opened to purge its contents and
refill it to the correct level. In case of failure of the output valve of the
buffer or a power cut, the system switches to exhalation mode, and the patient
is connected to atmosphere via the inhale guarantee valve, which opens
mechanically.

A schematic of the central pneumatic part of the system is shown in figure 3.
This diagram highlights how pure oxygen and air are injected separately into
the buffer by using two different valves. To achieve a good mix, a tube is
inserted into the tank from the air side, taking air to be injected close to
the oxygen injection point. Due to the high flow and the transition of the
tube into the larger buffer a turbulent flow is generated, which mixes the
oxygen and air. The mixture then travels to the other side of the buffer where
it is removed via the proportional valve. The concentration of the oxygen is
measured and in case it is not correct it is possible to vent the buffer and
the cycle can start over. The oxygen levels can be mixed from 21 to 100
percent. The oxygen fraction is measured with zirconia sensors inserted after
the oxygen tank which are reliable, inexpensive and readily available. The
sensors are installed after a bypass, which enables them to be independent of
the patient supply and to use a low flow of gas. As an additional option, a
CO2 sensor can be installed at the exit of the of the respirator and read out
from the controller. CO2 sensors based on non-dispersive (NDIR) technology are
inexpensive, have good selectivity, and are no affected by the oxygen level.

###  3.2 Alternative air supply

The HEV collaboration is actively investigating alternatives to the compressed
air supply available in hospitals. The major requirement is that the system
should be able to fill the HEV buffer in less than one second.

The first option considered is a relatively small and transportable system,
based on turbine blowers. A prototype has been built with 3 small turbines in
series, powered by 24 V. The speed is controlled by a 0 to 5 voltage level.
The prototype is illustrated in figure 4. The air is filtered by a HEPA (high-
efficiency particulate air) filter. The different parts are interconnected by
pieces of 1 inch plastic pipe. Before reaching the outlet, the air is
transported by a corrugated steel pipe, about 1 meter long, acting as an
intermediate reservoir. In addition, the corrugated steel pipe allows thermal
exchange with the environment, reducing the temperature of the air which is
heated in the turbines. In the system, the temperatures of the turbines and of
the compressed air are continuously monitored with thermal sensors. Pressure
sensors are used to maintain the required air flow by acting on the turbine
speed. The prototype has been tested by connecting to a $\sim$10 L buffer
acting as a HEV simulator, with one input valve and one output valve
alternatively working on a 3 to 4 seconds cycle. The test shows that the
turbines are able to fill the buffer in the required time and are thermally
stable. The change of the temperature in the reservoir was less than
$0.5\text{\,}\mathrm{\SIUnitSymbolCelsius}$, after one hour of continuous
work.

Figure 4: Left: prototype of the turbine system proposed as an alternative to
the compressed air supply. Right: drawing of the concept for a complete system
which is a box divided in two parts: the top contains the turbines, the bottom
contains the corrugated steel pipe, the thermal and pressure sensors and the
outlet connector. Mounted on the left side of the box are the air filter, the
power supply and the box containing the controller. The blue box on the right
provides an enclosure for the optional battery system.

For increased independence from the hospital setting, it would be ideal to
include an external battery which could power the turbine and the HEV.
Suitable candidates, of the order of 80 Ah, 24 V can be found on the market,
which also include the option to be recharged by solar panel. A relatively
low-cost option which will be tested in the next prototype is based on a
battery from the e-bike market. Figure 4, right, shows the concept for a
complete turbine-based system. The system is divided in two parts separated by
the support for the turbines. The corrugated steel pipe, temperature and
pressure sensors, and the outlet connector are at placed behind the support.
The air filter, power supply, and a box with a controller are on one side of
the structure. An optional battery system can be installed at the other side.
A system of low-power fans is used to cool the turbines.

An alternative to a custom designed turbine unit would be a commercial oil-
free compressor. Suitable candidates have been identified with high
availability and low cost and are being tested in parallel with the turbine
system.

###  3.3 Accessories and disinfection protocols

The choice of breathing circuit is an element of the system which is
considered as an accessory which can be finalised in the manufacturing stage
of the ventilator. HEV has been tested with concentric tube geometry and a
double limb circuit, and could be supplied with an adapter to use either
method.

The breathing circuit can also be equipped with humidifier or a heat and
moisture exchanger (HME) filter by choice, which is necessary to protect the
patient, who may be dehydrated, from the dry medical or ambient air. The
additional volume and the small pressure drop introduced by the humidifier
device will be taken into account during the calibration setup phase of HEV
and do not affect the operational parameters in any way. Alternatively, an HME
filter might be used to maintain humidity levels and provide particle
filtering, particularly if there is a worry that condensation in the flow
pressure sample lines can affect the monitoring. The HEV will likely feature a
HEPA filter to be used before the exhale valve to filter 99.9% of bacteria and
virus, allowing the exhale to be released to atmosphere. In this case there
would not be a need for a scavenger circuit.

All equipment that comes in contact with the patient needs to be either
changed or disinfected and sterilised after every patient. There are multiple
options to do this and currently autoclave cleaning is supported, i.e all the
materials which will be reused need to withstand a temperature of
$132^{\circ}$C for up to 4 minutes. The entire exhaust block may be easily
dismounted and swapped with a spare block, so that the ventilator can continue
to be used for the next patient while the block undergoes steam or autoclave
sterilisation.

The PEEP valve is a purchased accessory. Care must be taken to select a valve
with sufficient range and precision and priority will be given to reusable
components which can be cleaned by chemical disinfection or autoclave
procedures.

###  3.4 Electrical design

The electrical design has focused on rapid production for the HEV prototype.
It has been implemented as two parts to allow flexibility in design choices
and to simplify future modifications: a motherboard for hosting a
microcontroller, interfacing to valves, sensors, and connecting to the user
interface provided by a Raspberry Pi via a touchscreen; and a power system,
including an uninterruptible power supply (UPS), to provide the power to the
motherboard and components connected to it.

The motherboard is the core of the system with the following features. A
connector serves to mount and power the Raspberry Pi and access the signals on
its general-purpose-input-output (GPIO) bus. The board also has connectors to
mount and power the ESP32 microcontroller, and access the input/output signals
for valve control, sensing and other ancillary functions. There are integrated
circuits to drive control signals to valves and the corresponding connectors
for cabling to the valves. These circuits are driven by the ESP32 using pulse-
width-modulation appropriate to the choice of valve. Further connectors serve
for the cabling carrying signals from sensors. The signals are attenuated on
the motherboard before connection to the ESP32 for digitisation. The
motherboard also provides a number of embedded sensors for monitoring and
debugging, light-emitting-diodes (LEDs) and a buzzer for user information and
alarms, spare channels for additional valve and sensor connections, and
connectors to allow the powering of fans and the touchscreen.

The motherboard (figure 5) has dimensions $322\,{\rm mm}\times 160\,{\rm
mm}\times 60\,{\rm mm}$, and is compatible with the mechanical design of the
prototype HEV system. It runs on a nominal 24 V DC ($18-36$ V DC) power
supply, and contains local power regulation to generate the lower voltages
required for the hosted components.

Figure 5: Photograph of the PCB motherboard as implemented for the HEV
prototype.

The power system is modular and uses commercially available components
mountable on standard DIN-rails. The main stage is a stabilised power supply
unit with battery management. This generates the 24 V DC for the motherboard
and is compatible with $110-230$ VAC. It is connected with a UPS which will
take over if mains power is lost and allows autonomous use of the system for
more than 20 minutes. Configuration of the battery management is done by the
Raspberry Pi through the motherboard via a specific connector and cable to the
UPS. Connection to the mains power is with an IEC (International
Electrotechnical Commission) inlet filter and power is turned on and off with
a rotary switch. The DIN-rail mounting is compatible with the mechanical
design of the prototype HEV system.

###  3.5 Control and User Interface

####  3.5.1 Control

Figure 6: Conceptual layout of the controls and user interface.

The control concept, based around the embedded controller receiving the
signals from the sensors and valves, and the touchscreen interface to the
clinician, is illustrated in figure 6. The control software is implemented
directly on the embedded controller, which fully controls the ventilator
operation. The controller uses feedback from sensors to control valves in
order to achieve the desired pressures.

The general overview of the control system and the user interface is shown in
figure 7. Central to the operation and monitoring is the Microcontroller. An
ESP32 Microcontroller chip has been chosen at the time of prototyping, due to
its high availability and low cost. This is a dual core, single process
Arduino compatible controller with additional CPU power and memory. It runs
with no operating system which can be an advantage from the point of view of
reducing complexity and promoting stability. Several alternatives exist and
could be used depending on local availability in different geographical
locations. All of the primary functions corresponding to the breathing
function of the patient are controlled by the Microcontroller. The
Microcontroller connects to the electronics to read the pressures, flows and
temperatures. It controls the opening and closing of the valves and provides a
simple status/warning via a speaker and a set of LEDs. Interconnect
electronics is provided via the intermediate PCB (not shown) which steps up
and down voltages where necessary.

The Microcontroller is connected to a Raspberry Pi which handles
communications to the touch screen, WiFi and Ethernet, and controls the
displays. If the communications are interrupted, the ventilator continues to
run normally. A web server is also provided such that display information can
be seen remotely (although this is not considered an essential function for
operation).

Figure 7: Diagram of the location of the different elements of hardware and
software in the two computers (Microcontroller and Raspberry Pi) and the
circuit board attached to the Microcontroller.

####  3.5.2 Microcontroller functionality

The Microcontroller software design consists of three distinct threads of
processing:

  * •

A breathing loop responsible for operating the valves in a manner
corresponding to the ventilator modes, such as PC–A/C or PC-PSV, as described
in section 1.

  * •

A User Interface (UI) loop for relaying the current status and readings to the
Raspberry Pi, and for accepting commands for setting modes and parameters.

  * •

A Safety Loop which is responsible for raising alarms when patient or system
readings deviate from acceptable limits.

For all loops a finite state machine is employed to ensure operation is
achieved in a repeatable and deterministic manner. The state machines operate
semi-independently, with defined interfaces for information to pass between
them. For example, this allows the Safety Loop to know both the current
parameters set by the UI loop, and the current breathing loop ventilation
mode. This allows each state machine to be tested individually by expressly
checking the state response to each input at the interface.

The Microcontroller design allows the breathing and safety loops to continue
to operate in the event of loss of connection to the Raspberry Pi via the UI
loop. Visual and audible alarms signify a loss of connection but breathing and
safety functions continue whilst the connection is being re-established. The
lack of an underlying operating system in the Microcontroller reduces the
probability of system lock-up/failure caused by other processes running in the
background.

####  3.5.3 Raspberry Pi functionality

The Raspberry Pi software is designed to display the readings from the
Microcontroller in a UI on the touchscreen. Both the webserver and the native
displays receive the same information. Both can be used to send control
messages to the Microcontroller. However, in the case of the webserver, the
controls may be disabled for reasons of security and safety. Both interfaces
employ the same layout, such that they appear as similar as possible.
Following the advice of clinicians, the user interface has been designed based
on the following concepts:

  * •

Clear text, symbols and graphs which can be seen from the end of a hospital
bed through PPE.

  * •

Neutral colours when all is OK, and by contrast, flashing indicators and
messages when there are alarms. In general, safe and unsafe status should be
easily distinguished.

  * •

Screen locking/unlocking feature (with a timeout) to prevent accidental
touchscreen presses.

  * •

Confirmation of all parameter changes (two parameter changes would require two
separate confirmations).

  * •

Setting and reading back information (so that they can be compared).

  * •

Simple navigation: no setting/parameter should be more than two clicks away.
Normal operation should be separated from calibration/expert testing, to
maintain an uncluttered interface.

  * •

Interface should be touchscreen friendly: items should be placed far enough
apart to minimise accidental mis-clicks.

  * •

Familiarity: designed to look familiar to clinicians, similar to already
existing ventilator interfaces.

####  3.5.4 Communication

Communication between the Microcontroller and the Raspberry Pi is achieved
using the High-level Data Link Control Protocol (HDLC) [ISO 13239:2002]. A
subset of the full protocol functionality was implemented, including
supervisory (ACK/NACK frames) and information (INFO) frames. Information
frames are subdivided into Data, Command and Alarm subtypes. Error detection
is provided by a checksum (CRC16-CITT). More details are available in [30].
The protocol implementation is provided as a set of libraries on both the
Microcontroller and the Raspberry Pi.

On the Raspberry Pi the protocol library is employed by a dataserver which
broadcasts the data and alarm messages from the Microcontroller to the user
interface processes. Similarly, Command messages are relayed from the user
interfaces in the reverse direction. This is the expected method of operation,
however, any message type can be sent in either direction. JSON is used as the
communication format for messages from the dataserver to the user interfaces.
These messages are built from the data, command, and alarms formats defined in
the HDLC protocol library such that duplicate definitions are not required in
JSON. More detail on the dataserver is given in [31].

####  3.5.5 Software Practice

The software development has been done in a robust and flexible manner,
prioritising considerations of component failure from the start. The
development team has been organised into pairs of developers working in the
same domains, with strong familiarity with the code such that no individual is
irreplaceable. Readability and simplicity of code has been favoured over
complexity, for ease of bug tracing and testing. For the prototype, the
guidelines of IEC 62304 have been used, and internal checking/assertions are
included in the software. The communication protocols follow the High Level
Data Link Control recommendations from ISO/IEC 13239:2002. In particular, data
transmission is done with acknowledgement, and checksums are performed to
confirm the data integrity. While the software system in place for the
prototype is not yet fully qualified to ISO standards, the structure has been
set up in such a way as to show that this is possible.

####  3.5.6 User Interface

The User Interface (UI) is designed to be familiar and readily usable in a
medical environment, follows industry standards and conventions, and respects
the regulatory guidelines. Two interfaces are be provided: a Native User
interface and a Web User Interface. The Native User Interface runs on the
touchscreen integrated into the ventilator unit. It continuously displays
settings, measurements, patient waveforms and accepts instructions from the
clinician. The displays are implemented in large clear fonts that can be seen
easily from a distance of about 2 m away. Furthermore, the buttons or control
elements are spaced well enough apart to accommodate thumb sized control.
Figure 8 contains examples of the Native UI display. Remote access is provided
via the Web UI, accessible via WiFi or Ethernet connection to the ventilator
on computer screens or mobile devices. In this way the data of one or more
patients can be collected and displayed at the nurses’ station. This also
opens up the possibility of remote consulting, which can be very useful for
training or patient management in remote settings. The web interface can be
configured so that full control, partial control, or no control is possible
remotely. Access rights will be configurable as required. A Web UI example can
be found in figure 9) The Native UI is automatically displayed on power up of
the device. At start-up, a mode selection screen allows for selection of one
of the modes described in section 1. Associated with each mode are the set
parameters to be chosen for that mode. The parameter settings can be revisited
at any time during operation. Each setting change requires a confirmation from
the user. The UIs are designed with safety in mind. A locking feature of the
Native UI prevents accidental touches. Inactivity will activate automatic
locking. Locking can be enabled/disabled by holding the lock button for 3
seconds. Visual feedback is given during the locking/unlocking procedure.
Indicators for the power source (mains or battery) are given on the UI,
including residual charge indicators (e.g. charge $<85\%$, 30 mins remaining).

Figure 8: Example displays of the Native User Interface. Numbers and graphs
are purely indicative.

A “homepage” is shown for the current ventilation mode with the most important
settings, parameters, waveforms and control buttons. Similar to the locking
feature, the Native UI defaults to presenting the homepage after a period of
inactivity by the user. A selection is provided for time ranges of the
waveforms (i.e., showing the last 5, 15, 30 or 60 seconds). Historical data
are recorded for up to 10 days. Encryption will be an option for stored
patient data. Settings (or target values) and measured values are clearly
distinguishable in the UI. The HEV Graphical User Interface is organised to
respect all of the requirements listed in [21, 24, 23] on both
implementations, and includes the following items on the homepage:

  * •

Ventilation mode.

  * •

Working inhalation pressure setting.

  * •

Respiratory rate setting.

  * •

Inhalation time setting.

  * •

FIO2 setting.

  * •

Monitored plateau pressure.

  * •

Monitored respiratory rate.

  * •

Monitored PEEP.

  * •

Monitored FIO2.

  * •

Monitored exhaled tidal volume.

  * •

Monitored exhaled minute volume.

The following items are plotted as a continuous graphical display, with an
option given to pause the display should the clinician wish to study the
waveforms more closely.

  * •

Volume vs time.

  * •

Pressure vs time.

  * •

Flow vs time.

Alarms are displayed in an intuitive way at the top of the screen at all
times. A dedicated alarm page gives more detail on the alarms. An ordered list
of the last ten alarms is shown, ordered by alarm priority, and current and
historical alarms are easily distinguishable. It is possible to reset or
silence alarms (for a period of time). The user interfaces match the “traffic
light” lamps in terms of on-screen visualisation.

Finally, more technical details of the internal operation and calibration of
the ventilator are provided on a separate “expert” page. A visual warning
indicates that this is not for normal usage. The aim of the prototyping was to
put in place all underlying software flexibility to be able to freely
implement the desired UI. Before final manufacture a full useability study
will be performed in order to optimise the UI.

Figure 9: Example displays of the Web User Interface. Numbers and graphs are
purely indicative.

##  4 HEV Prototypes

Figure 10: HEV prototypes as tested for full functionality.

Three prototypes were constructed with an identical mechanical design in order
to allow work in parallel on different aspects of the design implementation.
The prototypes (figure 10) are designed as standalone units, each with two
separate compartments, pneumatic and electrical, separated by a support plate.
The mechanical description below as well as the functional tests described
were all performed on these prototypes.

In parallel, a fourth prototype, illustrated in figure 11, was developed at
the Galician Institute of High Energy Physics at the University of Santiago de
Compostela (IGFAE/USC) with a two-fold goal. Firstly, we wished to demonstrate
that such a respirator could be developed easily in other places than CERN.
Secondly, having successfully reproduced the design within a short timescale,
we were able to launch additional development and contributions to the control
software. In addition, this triggered discussions with local hospitals and
physicians, further improving the design of the device.

Figure 11: Functional table top prototype produced for collaboration and
development purposes.

###  4.1 Prototype mechanical design

The prototype mechanical design was created with the aim of enabling the
production of a fully specified and functional ventilator. Additional space
has been deliberately added, so that the working prototypes could be built as
quickly as possible, and to ensure that there will be no problem to
interchange components for others with similar properties if this is necessary
for full medical compatibility. The resulting design iis a unit with
approximate dimensions $500\times 500\times 1350$ mm. Note that due to this
choice, the machine is larger than necessary and not in its optimal packaging;
this can be easily optimised at the manufacturing stage.

The simple mechanical design was chosen to feature standard components, not
commonly used in respiratory equipment. This would enable it to be produced
locally by adapting the parts to the availability of local suppliers. The
ventilator is simple to construct and requires little or no machining. A list
of the typical parts required includes:

  * •

A proportional solenoid inhale valve with 8 mm internal diameter.

  * •

Two fast acting solenoid valves for inlet of air and oxygen into the buffer
volume.

  * •

A solenoid valve for purging. It could be low volume, that in case of over-
pressure only some air is released.

  * •

An exhale ON/OFF valve with large diameter internal orifice.

  * •

Five check valves.

  * •

Two pressure relief valves, one for the patient circuit and one for the
buffer.

  * •

A 10 L buffer container.

  * •

Two pressure regulators, able to operate up to a maximum pressure of 10 bar,
one for oxygen and one for air.

  * •

Eight pressure sensors.

  * •

A bidirectional differential pressure sensor for the flow measurement.

  * •

Two temperature sensors.

In addition to these parts, there is a list of required and optional
accessories, described in section 3.3, such as the PEEP valve, breathing
circuit, filters and humidifiers.

Functionally, the prototype designs follow the concept described above. The
resulting cabinet is mounted on wheels, can easily be moved by one person, is
very stable, and provides a convenient surface to mount the display at head
height. The cabinet is closed with doors, so that easy access for cleaning is
possible. The cabinet is subdivided internally into two separate compartments,
front and back, housing the pneumatic and electronics components separately,
which provides protection against explosion risk from potential oxygen leaks.
The air tubes connect through a standard bulkhead thread connector on the
outside. In this way it is easily replaceable to match hospital connection
standards around the world.

Figure 12: Potential alternative mechanical designs with an identical
functionality to the HEV prototypes.

###  4.2 Alternative mechanical design

The prototypes have been built with a deliberately large amount of space to
allow rapid development and exchange of parts. The final ergonomics of the HEV
may look quite different depending on the requirements in the region of
deployment and the accessories included. The HEV collaboration has provided
two different mechanical designs to which the HEV design could be adapted to
fulfill different needs, which are illustrated in figure 12. Option A is more
compact and can be mounted on wheels or a trolley. Space is provided to
support oxygen and compressed air bottles, as well as the turbine system, such
that the entire system and accessories can be provided as one integrated unit,
which can be desirable for certain geographical locations. Option B is a still
more compact and light version, for which the total dimensions are comparable
to existing commercial ventilators and the weight is targetted to be around 25
kg. The touch screen can be folded away for transport and the ventilator
easily mounted on a trolley. Both options are identical in functionality to
the HEV prototypes which have been built and tested.

##  5 Prototype test results

###  5.1 Setup

The HEV prototype is tested by connecting it to a lung simulator through a
coaxial breathing circuit set, as shown in figure 13. The coaxial breathing
circuit set222Hamilton PN 260128. has a differential pressure based flow
sensor333Hamilton PN 281637. whose readout is embedded in HEV (dP_patient).
Alternatives to this sensor are available with other manufacturers
444Intersurgical P/N 2072000, and a specific breathing circut for HEV in order
to decrease reliance on the existing supply chain can also be an option. The
lung simulator is a TestChest light 555Organis GMBH, Landquart, www.organis-
gmbh.com[32], which allows for the change the mechanical parameters of the
lung (resistance of the airways, compliance of the lung) as well as generates
adjustable spontaneous breathing. The setup is equivalent to the MHRA [21] and
ISO 80601-2-12 figure 201.102 [33].

Figure 13: Test setup schematics.

###  5.2 Target Pressure Performance

As discussed in section 3.1, when the inhale starts, the proportional valve
valve_inhale opens in a controlled way in order to reach the target pressure
in a given time. This is done through a PID controller that monitors the
P_inhale pressure measurement as input for the inhale valve opening control.
As illustrated in figure 14, any pressure level within the setting range can
be reached and the system stays stably locked to this value with an
uncertainty below 3% in most of the cases.

Figure 14: Left: pressurisation of a 50 ml/mbar compliance, 5 mbar/l/sec
resistance patient with various target pressures. The inhalation time is set
to 1.5 seconds, and is followed by a pause of 0.5 seconds. Right: the
deviation of the inhale pressure from the target is computed during the pause.

Further tests will be performed in presence of leaks, but even with the
highest leak setting of the TestChest, no difference in the pressure profile
is visible.

The time needed to reach the maximum of pressurisation can be tuned between
the fastest setting of about 50 ms and about 300 ms, as illustrated in figure
15. This gives the clinician the flexibility to use the fastest response of
the ventilator, typically for intubated, sedated patients, through to slower
rise times which may be useful at other periods of recovery.

Figure 15: Rising edge of the inhalation for various rise time setting. The
lung compliance here is 50 ml/mbar for a resistance of 5 mbar/l/s Figure 16:
Pressure, flow and volume registered for patient configurations with
increasing lung compliance and airway resistance. As expected, the flow is
more peaked with reduced resistance and compliance.

In figures 16, the response of the HEV ventilator to patients with compliance
varying from 10 to 100 ml/mbar and with resistance from 5 to 50 mbar/l/s is
shown. The PEEP values range from 5 to 15 $\,\mathrm{cm\,H_{2}O}$ and target
pressure up to 45$\,\mathrm{cm\,H_{2}O}$ are tested. The behaviour of the
ventilator is illustrated in figure 16.

When the patients shows no airway resistance or when their lung compliance is
low enough, the flow can fully develop during the allocated inhalation time
such that the tidal volume can be computed from the product of the compliance
and the differential pressure. The slowing down of the flow with the increased
resistance and increased compliance is also well visible. Lower compliance
patients could not be tested with this lung simulator but will be the subject
of a dedicated test later; the performance is expected to be good.

###  5.3 Inhale Trigger Peformance

The inhale and exhale trigger are essential to guarantee the comfort of the
patients and to ensure fast recovery time. The trigger functionalities were
developed with this aspect in mind and particular effort was made to qualify
them.

Figure 17: Measured parameters to qualify the inhalation trigger. The
variables used in this work are based on the work presented in [34] and [35]

##### Inhale trigger algorithm description

Whenever the patient initiates a breath, the proximal flow sensor sees an
increased flow and an under-pressure. The increase in flow is used as a
trigger for the inhale sequence. The inhale trigger algorithm works in the
following way. Whenever the flow reaches 10% of the maximal exhale flow, the
window allowing for a inhale trigger is opened. This condition is by
definition always met when the patient initiates an inhalation. The expected
flow at a given instant is computed by a linear regression from a given time
window before that point. It provides the baseline, to which the measured flow
is compared. If the measured flow, corrected for the baseline, is above a
threshold that can range from 0.2 l/min to 20 l/min, then the inhalation
starts. Lower thresholds are sensitive to noise, in particular that induced by
the heart-lung interactions. This threshold is set by the clinician.

##### Inhale trigger qualification

To qualify the performance of the inhale trigger, the variables defined in
[34] are used. Figure 17 illustrates those variables: the Time to Minimum
Pressure, TPM, is defined as the time between the beginning of the inhalation
effort and the minimum value measured reached by P_patient, and the Trigger
Delay Time TDT is defined as the time between the beginning of the inhalation
effort and the moment the pressure returns to zero. Values of TPM in
commercial ventilators typically vary between 50 and 150 ms depending on the
inhalation effort, see for example [34], while TDT, which should ideally be
below 150 ms so as not to be felt by the patient, varies for commercial
ventilators in practice between 90 and 250 ms [34]. The pressure-time product
during trigger, PTP, is represented in figure 17 by the grey area and
represents the effort until the pressure is effective. It ranges from 0.02 to
0.3 mbar.s in commercial ventilator [34]. The ideal PTP300 percentage and
ideal PTP500 percentage,referred to as PTP300 and PTP500 in the following, are
respectively the ratio of the pressure integral over the 300 ms (500 ms)
following the trigger delay (the area of the green regions in figure 17) and
the ideal PTP at 300 and 500 ms. It should be as large as possible, with
typical commercial ventilators exhibiting values between 10 and 50% (20 and
75%) for PTP300 (PTP500) depending on the inhalation effort [34].

To test the inhalation trigger, the same lung parameters, pressurisation
parameters and inhalatory effort than in [34] were used. TestChest was set
with a compliance of 50 mbar/ml and a resistance of 5 mbar/l/s, the breath
cycles at 12 respiration per minutes consisted in a 1 s inspiration with a
constant inspiratory flow giving a occlusion pressure at 100 ms (P0.1) of
2$\,\mathrm{cm\,H_{2}O}$ (low effort) and 4$\,\mathrm{cm\,H_{2}O}$ (high
effort) and several pressurisation parameter: $\Delta$P of 10,15 and 20 mbar
with a PEEP of 0 and 5 mbar. The inhale trigger threshold is set to 0.5 L/min.

Table 3 summarises the results of the inhalation trigger qualification.
Comparing the results to the ventilator studied in [34], HEV inhale trigger
appears to perform very well.

P0.1 [mbar] | 2 | 4
---|---|---
PEEP [mbar] | 0 | 5 | 0 | 5
$\Delta P$ [mbar] | 10 | 15 | 20 | 10 | 15 | 20 | 10 | 15 | 20 | 10 | 15 | 20
TPM [ms] | 100 | 99 | 79 | 121 | 104 | 74 | 118 | 69 | 74 | 95 | 95 | 72
TDT [ms] | 130 | 105 | 101 | 139 | 112 | 98 | 150 | 105 | 98 | 135 | 107 | 96
PD [mbar] | 2 | 1.9 | 1.6 | 1.9 | 2 | 1.7 | 4.7 | 3.7 | 4 | 4.1 | 3.9 | 2.6
PTP [mbar] | 0.09 | 0.03 | 0.02 | 0.12 | 0.08 | 0.07 | 0.24 | 0.15 | 0.13 | 0.28 | 0.2 | 0.18
PTP300 [%] | 28.8 | 41.4 | 43.8 | 29.1 | 38.6 | 46.4 | 24.8 | 36.6 | 41.0 | 29.8 | 36.1 | 43.5
PTP500 [%] | 39 | 53.8 | 55.6 | 43.7 | 51.2 | 58.8 | 34.6 | 44.6 | 49.1 | 38.2 | 44. | 52.2
Table 3: Results of the inhale trigger characterisation.

The trigger response is studied again in presence of leaks. Only one set of
pressurisation is used, with PEEP at 0$\,\mathrm{cm\,H_{2}O}$ and $\Delta
P$=20$\,\mathrm{cm\,H_{2}O}$. Four settings are tried: no leaks, weak, medium
and strong leaks as set by TestChest, and results are reported in table 4. No
significant difference is observed.

| No leaks | Small | Medium | Large
---|---|---|---|---
TPM [ms] | 74 | 72 | 70 | 70
TDT [ms] | 98 | 94 | 94 | 94
PD [mbar] | 4 | 4 | 3.7 | 3.4
PTP [mbar.s] | 0.13 | 0.13 | 0.11 | 0.1
PTP300 [%] | 41 | 40.5 | 41.4 | 41.1
PTP500 [%] | 49.1 | 48.5 | 49.3 | 49.1
Table 4: Inhale trigger sensitivity to different leakage level for lungs with
compliance of 50 mbar/ml and resistance of 5 mbar/l/s

##### Exhale trigger algorithm description

The implementation of the exhale trigger is more straightforward. When the
inhale flow decreases down to a fraction of the maximum inhale flow, the
exhale phase is triggered.

##### Exhale trigger qualification

In order to qualify the performance of the exhale trigger,
$\mathrm{T_{I_{ex}}}$ defined as the duration of pressurisation by the
ventilator in excess with respect to $\mathrm{T_{I}}$, which represents the
true duration of inhalation by the patient, is measured as in [35]. This is
illustrated in figure 17. It is not a property of the ventilator per se, but
by appropriate tuning of the exhalation trigger it should be possible to bring
it to below 100 ms. Values of $\mathrm{T_{I_{ex}}}$ below 10 ms are achieved.

###  5.4 Oxygen mixing test

Because the mixing is performed in the buffer in a phase which is physically
uncorrelated to the patient the breath cycle (i.e. during patient exhalation
when the buffer is disconnected from the patient), we perform the mixing test
independently from the test of the ventilator modes.

The O2 concentration in the buffer is controlled by changing the relative
opening time of valve_O2_in and valve_Air_in. For a given O2 concentration
setting, the opening times can be computed. After stabilisation of the
measured O2 concentration ($\mathrm{FIO_{2}}$) in the lung simulator, the
$\mathrm{FIO_{2}}$ is compared to the set value. Further control will be
introduced in the future by regulating the opening time from a feedback of the
measured O2 concentration in the buffer.

The measured $\mathrm{FIO_{2}}$ as function of the expected O2 percentage as
calculated from the relative time opening of valve_O2_in and valve_Air_in is
shown in figure 18. The measured $\mathrm{FIO_{2}}$ in the lung is within 5%
of the set value, which is an acceptable performance. Further tuning to the
valve opening time can be done in order to correct for the small non-linearity
in the response.

Figure 18: Measured $\mathrm{FIO_{2}}$ as function of the expected O2
percentage as calculated from the relative time opening of valve_O2_in and
valve_Air_in. The grey band represents the region within $\pm 5\%$ of the set
value.

##  6 Conclusion

HEV has been developed to be a high-quality, low-cost ventilator, suitable for
use in a hospital setting. The design is intended for easy and fast
manufacturing that can be performed in a decentralised way with affordable and
readily available parts. The central concept of the design with a gas
accumulator gives many advantages in terms of robustness, safety,
affordability and precise ventilation behaviour. The electrical design is
conceived in a modular way for quick prototyping and deployment, which
facilitates mass production. The design is intended to be robust and adaptable
for a wide range of geographical deployment, including in regions where
compressed air may not be readily available and a turbine alternative can be
used. Three prototypes have been manufactured and have been tested in situ
under clinical supervision with the full range of simulated patients defined
in the MHRA specifications and the results are presented in this paper. HEV
has also been tested at the ETH Zurich Chair of Product Development and
Engineering Design Ventilator test rig. In pressure control mode HEV
accurately achieves the target pressures, with fast rise time which is
tuneable to slower times on clinician request. Special attention has been paid
to the inhale and exhale triggers to optimise patient comfort. The inhale
trigger, based on the flow measurement, accurately reacts to the patient
effort, with short rise times and excellent PTP values. The system displays
and monitoring use concepts familiar to particle physics such as the
possibility for remote monitoring from screens or mobile devices, data logging
for quality control and performance monitoring, and remote training.

As far as production is concerned, it is foreseen, on the one hand, to enable
this through providing partner academic institutions with the detailed design
for these institutions to follow up in accordance with local possibilities and
standards; on the other hand, directly through industry, non-governmental,
governmental and international organizations, such as the World Health
Organisation (WHO), for which purpose discussions are ongoing and contacts
have been established with potential partners. Every effort is being made to
finalise the design of the HEV in accordance with the state-of-the-art best
practices and standards, but the formal certification process should of course
be initiated by the parties that decide to place this device on the market.
The hardware and software design has been done in a flexible way which allows
the development of different modes of operation, for instance volume control
modes which in principle can be developed and applied as a firmware update. In
addition, the HEV prototypes can be used as a testbench to quickly implement
and test novel algorithms or hardware updates, and in this way could provide a
fresh avenue for medical research.

## Acknowledgements

We express our gratitude to Giovanni Anelli, Amy Bilton, Paola Catapano,
Manuela Cirilli, Paolo Chiggiato, Beniamino Di Girolamo, Doris Forkel-Wirth,
Benjamin Frisch, Samuel Herzog, Lucie Pocha, Javier Serrano, Erik Van Der Bij,
Jens Vigen and Maarten Wilbers from CERN, Geneva, Switzerland, the CERN
against COVID-19 task force, and to Simon Cohen from Monash Children’s
Hospital, Melbourne, Australia, for many illuminating discussions and much
practical support.

## References

  * [1] Lisa Rosenbaum  “Facing Covid-19 in Italy – Ethics, Logistics, and Therapeutics on the Epidemic’s Front Line” PMID: 32187459  In _New England Journal of Medicine_ 382.20, 2020, pp. 1873–1875  DOI: 10.1056/NEJMp2005492
  * [2] S. Kliff, A. Satariano, J. Silver-Greenberg and N. Kulish  “There Aren’t Enough Ventilators to Cope With the Coronavirus”  URL: https://www.nytimes.com/2020/03/18/business/coronavirus-ventilator-shortage.html
  * [3] Megan L. Ranney, Valerie Griffeth and Ashish K. Jha  “Critical Supply Shortages – The Need for Ventilators and Personal Protective Equipment during the Covid-19 Pandemic”  In _New England Journal of Medicine_ 382.18, 2020, pp. e41  DOI: 10.1056/NEJMp2006141
  * [4] Monica Malta, Anne W. Rimoin, Nicole A. Hoff and Steffanie A. Strathdee  “The 2019-nCoV pandemic in the global south: A Tsunami ahead”  In _EClinicalMedicine_ , 2020, pp. 100384  DOI: https://doi.org/10.1016/j.eclinm.2020.100384
  * [5] Ezekiel J. Emanuel et al.  “Fair Allocation of Scarce Medical Resources in the Time of Covid-19”  In _New England Journal of Medicine_ 382.21, 2020, pp. 2049–2055  DOI: 10.1056/NEJMsb2005114
  * [6] T Netland  “A better answer to the ventilator shortage as the pandemic rages on”  URL: https://www.weforum.org/agenda/2020/04/covid-19-ventilator-shortage-manufacturing-solution/
  * [7] Centre de formation Urgences-santé  “Oxylator EMXtm”  URL: https://www.urgences-sante.qc.ca/wp-content/uploads/2014/03/Oxylator-EMX.pdf
  * [8] MIT E-Vent  “MIT Emergency Ventilator (E-Vent) Project”  URL: https://e-vent.mit.edu
  * [9] C. Galbiati  “Mechanical Ventilator Milano (MVM): A Novel Mechanical Ventilator Designed for Mass Scale Production in Response to the COVID-19 Pandemics”, 2020  arXiv: https://arxiv.org/abs/2003.10405
  * [10] Mechanical Ventilator Milano  “Mechanical Ventilator Milano”  URL: www.mvm.care
  * [11] Take a Breather Team  “Attachment to Automate the Bag Valve Mask in Low Resource Settings”  URL: http://oedk.rice.edu/Sys/PublicProfile/47585242/1063096
  * [12] VENTILAID Team  “Open-Source solutions to fight the Coronavirus pandemic”  URL: https://www.ventilaid.org
  * [13] OxVent Team  “OxVent”  URL: https://oxvent.org
  * [14] RTBF avec Belga  “Coronavirus: des ingénieurs belges développent un prototype de respirateur”  URL: https://www.rtbf.be/info/belgique/detail_coronavirus-des-ingenieurs-belges-developpent-un-prototype-de-respirateur?id=10463991
  * [15] R et al Read  “COVID-19 Ventilator Projects and Resources with FAQs”  URL: https://github.com/PubInv/covid19-vent-list
  * [16] JustActions  “ The Missing Piece. Why Continued Neglect of Pneumonia Threatens the Achievement of Health Goals.”  URL: https://stoppneumonia.org/wp-content/uploads/2018/11/The-Missing-Piece_-0611_Spread.pdf
  * [17] H J Zar, S A Madhi, S J Aston and S B Gordon  “Pneumonia in low and middle income countries: progress and challenges”  In _Thorax_ 68.11 BMJ Publishing Group Ltd, 2013, pp. 1052–1056  DOI: 10.1136/thoraxjnl-2013-204247
  * [18] Stephen J. Aston  “Pneumonia in the developing world: Characteristic features and approach to management”  In _Respirology_ 22.7, 2017, pp. 1276–1287  DOI: 10.1111/resp.13112
  * [19] J. Buytaert  “The HEV Ventilator Proposal”, 2020  arXiv: https://arxiv.org/abs/2004.00534
  * [20] HEV project  “High Energy physics community proposes HEV ventilator to help combat COVID-19”  URL: https://hev.web.cern.ch
  * [21] UK Medicines and Healthcare products Regulatory Agency  “MHRA Specification for Rapidly Manufactured Ventilator System (RMVS), version 4.0”, 2020  URL: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/879382/RMVS001_v4.pdf
  * [22] EU  “Guidance on medical devices, active implantable medical devices and in vitro diagnostic medical devices in the COVID-19 context”, 2020  URL: https://ec.europa.eu/docsroom/documents/40607?locale=en
  * [23] Association for the Advancement of Medical Instrumentation  “Emergency use ventilator (EUV) design guidance, revision 1.2”, 2020  URL: https://www.aami.org/docs/default-source/standardslibrary/200410_cr501-2020_rev1-2.pdf?sfvrsn=699e62b7_2
  * [24] World Health Organization  “Technical specifications for invasive and non-invasive ventilators for COVID-19: Interim guidance, 15 April 2020”  World Health Organization, 2020, pp. 10 p.  URL: https://apps.who.int/iris/handle/10665/331792
  * [25] Clinical Experts Group, Hamilton Medical  “Driving pressure in ARDS patients”  URL: https://www.hamilton-medical.com/de/E-Learning-and-Education/Knowledge-Base/Knowledge-Base-Detail~2017-05-08~Driving-pressure-in-ARDS-patients~09161a01-6223-4668-8fa8-d906319d64f9~.html
  * [26] Marcelo B.P. Amato et al.  “Driving Pressure and Survival in the Acute Respiratory Distress Syndrome” PMID: 25693014  In _New England Journal of Medicine_ 372.8, 2015, pp. 747–755  DOI: 10.1056/NEJMsa1410639
  * [27] Karin Deden  “Ventilation modes in intensive care”  URL: https://www.draeger.com/Library/Content/rsp-new-nomenclature-ventilation-modes-icu-booklet-9066477-en.pdf
  * [28] Rebecca Inglis, Emmanuel Ayebale and Marcus J. Schultz  “Optimizing respiratory management in resource-limited settings”  In _Current Opinion in Critical Care_ 25.1, 2019, pp. 45–53  URL: https://journals.lww.com/co-criticalcare/Fulltext/2019/02000/Optimizing_respiratory_management_in.8.aspx
  * [29] L. Brouwer, A. Hoedemaekers and J. Hoeven  “Effect of inspiration rise time on work of breathing and patient comfort during pressure support ventilation”  In _Critical Care_ 10.1, 2006, pp. P38  DOI: 10.1186/cc4385
  * [30] HEV project  “Communication protocol”, 2020  URL: https://ohwr.org/project/hev/wikis/Software-communication-protocols-for-HEV/
  * [31] HEV project  “Data server specification for the HEV”, 2020  URL: https://ohwr.org/project/hev/wikis/Software-communication-protocols-for-HEV/
  * [32] Josef Brunner  “TestChest Physiological Model”, 2017
  * [33] International Organization for Standardization  “Medical electrical equipment - Part 2-12: Particular requirements for basic safety and essential performance of critical care ventilators”, 2020  URL: https://www.iso.org/obp/ui#iso:std:iso:80601:-2-12:ed-2:v1:en
  * [34] Carlos Delgado et al.  “Performance of the New Turbine Mid-Level Critical Care Ventilators”  In _Respiratory Care_ 62.1 Respiratory Care, 2017, pp. 34–41  DOI: 10.4187/respcare.04938
  * [35] Laurence Vignaux, Didier Tassaux and Philippe Jolliet  “Performance of noninvasive ventilation modes on ICU ventilators during pressure support: A bench model study”  In _Intensive care medicine_ 33, 2007, pp. 1444–51  DOI: 10.1007/s00134-007-0713-0

HEV collaboration

J. Buytaert1,∗, A. Abed Abud1,2, P. Allport26, A. Pazos Álvarez11, K. Akiba3,
O. Augusto de Aguiar Francisco1,4, A. Bay10, F. Bernard10, S. Baron1, C.
Bertella1, J. Brunner21, T. Bowcock2, M. Buytaert-De Jode, W. Byczynski1,8, R.
De Carvalho23, V. Coco1, P. Collins1,∗, R. Collins18, N. Dikic1, N. Dousse23,
B. Dowd16, R. Dumps1, P. Durante1, W. Fadel1, S. Farry2, A. Fernández
Prieto11, G. Flynn16,25, V. Franco Lima2, R. Frei10, A. Gallas Torreira11, R.
Guida1, K. Hennessy2, A. Henriques1, D. Hutchcroft2, S. Ilic7, A. Jevtic7, C.
Joram1, K. Kapusniak1, E. Lemos Cid11, J. Lindner9, R. Lindner1, M.
Milovanovic1,6, S. Mico1, J. Morant1, M. Morel1, G. Männel20, D. Murray4, I.
Nasteva5, N. Neufeld1, I. Neuhold1, F. Pardo-Sobrino López19, E. Pérez
Trigo11, G. Pichel Jallas, E. Pilorz1, L. Piquilloud17, X. Pons1, D. Reiner13,
C. Roosens24, P. Rostalski20, B. Schmidt1, E. Saucet23, F. Sanders1, C.
Sigaud1, B. Schmidt1, P. Schoettker17 R. Schwemmer1, H. Schindler1, A.
Sharma1, P. Svihra4, J. van Leemput24, L. Vignaux22, F. Vasey1, H.
Woonton14,15, K. Wyllie1.

1European Organization for Nuclear Research (CERN), Geneva, Switzerland
2Oliver Lodge Laboratory, University of Liverpool, Liverpool, United Kingdom
3Nikhef National Institute for Subatomic Physics, Amsterdam, Netherlands
4Department of Physics and Astronomy, University of Manchester, Manchester,
United Kingdom
5Universidade Federal do Rio de Janeiro (UFRJ), Rio de Janeiro, Brazil
6Deutsches Elektronen-Synchrotron (DESY), Platanenallee 6, 15738 Zeuthen,
Germany
7University of Niš, Niš, Serbia
8Tadeusz Kosciuszko Cracow University of Technology, Cracow, Poland
9University of Applied Sciences Offenburg, Offenburg, Baden-Wuerttemberg,
Germany
10Institute of Physics, Ecole Polytechnique Fédérale de Lausanne (EPFL),
Lausanne, Switzerland
11Instituto Galego de Física de Altas Enerxías (IGFAE), Universidade de
Santiago de Compostela, Santiago de Compostela, Spain
13John Curtin School of Medical Research, Canberra, Australia
14Monash Health, Melbourne, Australia
15Dandenong Hospital, Melbourne, Australia
16Prince of Wales Hospital, New South Wales, Australia
17Centre Hospitalier Universitaire Vaudois, Lausanne, Switzerland
18College of Veterinary Medicine, Cornell University, Ithaca, NY, USA
19Anesthesiology-Reanimation and Pain Therapuetics Service, Lucus Augusti
University Hospital, Lugo, Spain
20Institute for Electrical Engineering in Medicine, University of Lübeck,
Lübeck, Germany
21Neosim AG, CH-7000 Chur, Switzerland
22Cardio-Respiratory Units, Hôpital de La Tour, Meyrin, Switzerland
23Hôpitaux Universitaires de Genève, Genève, Switzerland
24GZA hospitals, Antwerp, Belgium
25University of New South Wales, Sydney, Australia
26Particle Physics Group, School of Physics and Astronomy, University of
Birmingham, United Kingdom
∗Corresponding authors<EMAIL_ADDRESS>and<EMAIL_ADDRESS>