The worldwide medical community currently faces a critical shortage of medical equipment to address the COVID-19 pandemic [1]- [3] . In particular this is the case for ventilators, which are needed during COVID-19 related treatment at onset, during the intensive care phase and during the very extended recovery times. Companies are scaling up production [4] , but this will not be sufficient to meet the demand according to the current forecasts. There is a wide spectrum of devices, ranging from highly sophisticated through to simpler units [5] , [6] useful in the milder phases of illness. There is already a large number of proposals circulating for devices which can be quickly manufactured cheaply and on large scale [7] - [12] .
We propose here a ventilator design to be integrated into a hospital environment. The HEV (High Energy physics community Ventilator) concept is based on components which are simple and cheap to source, complies with hospital standards for external connections and operating modes, and supports the most requested operation modes. The starting point of the design is the set of MHRA (Medicines and Healthcare products Regulatory Agency) guidelines provided by the UK government regarding Rapidly Manufactured Ventilator Systems [13] . The proposal here is, at this stage, not a medically approved system and will need a process of verification with medical experts. However, in the interests of rapid development the concept is presented to generate feedback, corrections, and support as the project progresses. A demonstrator has been built and the design is now in the prototyping stage.
Patient management during COVID-19 faces serious issues of lung damage, and the ventilators must be able to handle situations of rapidly changing lung compliance, and potential collapse and consolidation. The driving pressure of the ventilator is a crucial factor for patient outcomes [14] . In particular, when a low tidal volume is used, the driving pressure is an important variable to monitor to assess the risk of hospital mortality.
In light of the extreme importance of the pressure monitoring, the HEV ventilator will target pressure controlled modes. This will include: PRVC (Pressure Regulated Volume Control) mode, SIMV-PC (Synchronised Intermittent Mandatory Ventilation); and in addition a basic mode of operation: CPAP (Continuous Positive Airway Pressure). The HEV design also provides PEEP (Positive End-Expiratory Pressure), which is not a ventilatory mode in itself but is designed to support steady low positive pressure to the lungs. The PRVC mode, which is standard for commercial ventilators, aims to set the tidal volume at the lowest possible airway pressure. In the case where the tidal volume is not achieved at a particular pressure setting, due to changes in the patient's airway resistance or lung compliance; this can then be gradually adjusted. SIMV-PC mode will allow the patient to take spontaneous breaths, and will assist the breathing when the spontaneous breath is taken. This mode uses an additional sensor for the detection of the negative pressure initiated by the patient breath. If the patient respiratory rate does not achieve the target value, additional mechanical ventilation is provided by the unit.
The HEV ventilator will also be capable of a basic non-invasive operation mode where a fixed pressure is made available to the patient. Although international definitions vary, this corresponds to the CPAP definition from the MHRA documentation [13] . In all modes of operation, PEEP will be available, which is important for patient management to avoid alveolar collapse. Note that the ventilator design outlined here is not intended to replace the high-end devices needed for the most intense phase of treatment, but should be appropriate and useful in the hospital environment for milder symptoms or long term care and recovery.
We describe here the conceptual layout of the system. The targeted modes of operation, as explained above, are principally PRVC, SIMV-PC and CPAP, as defined in the MHRA documentation [13] . The design has the patient safety built-in as a priority, so that all failure modes revert to a situation which prioritises patient safety. In particular, if the patient stops breathing in pressure support mode, the ventilator fail-safes automatically onto mandatory ventilation.
The conceptual schematic is shown in figure 1 . The unit takes as input the standard compressed or mixed air supply available in hospitals, in such a way that one supply could be connected to several units. We expect that typically the pressure supplied will be between 2 and 5 bar. The connections presented by the unit to external input/outputs will follow hospital standards. The supply pressure is reduced by a pressure regulator to approximately 200 mbar. The system concept is based around a buffer volume of approximately 2 litres. The filling of this buffer is controlled by the input valve (valve in). By controlling of the opening time, one can achieve the desired target pressure in the buffer after which the valve (valve in) is shut. This buffer filling occurs during the expiratory part of the breath cycle. If the buffer pressure is within tolerance of the required pressure, the output valve (valve out) is then opened, initiating the respiratory cycle. The respiratory rate, inspiratory time (corresponding to the open time of valve out) and pause time are all controllable. If a PEEP pressure is set, then the pressure in the lungs will have the minimum of the PEEP pressure.
We define P 1 as the obtained pressure in the buffer before the inhalation cycle starts, and P 2 as the pressure in the buffer at the end of the inhalation cycle, when the valve is closed. The volume of air taken by the patient (tidal volume) can then be calculated knowing P 1 , P 2 and the fixed volume of the buffer and tubes.
During operation all parameters are monitored. If the minute volume drops below the programmed value, the pressure P 1 can be increased in units of 1-2 mbar, until the target minute volume is achieved or the maximum pressure allowed is reached.
For the CPAP operation mode all valves are left open and a manual regulator setting is set to a fixed low pressure.
The patient is directly protected from over-pressure via the safety valve, which will open at 80 cm H 2 O. In addition, the pressure sensor in the buffer (P buffer) will continuously check for over-pressure. In case of over-pressure in the buffer, an electro-valve (valve purge) will be open to purge its contents and refill it to the correct level. In case of failure of output valve of the buffer (valve out) or a powercut, the ON/OFF two say valve will connect the patient to the atmosphere allowing non-assisted breathing. During the expiratory cycle, the valve scavenger opens allowing the air from the lungs to flow to the scavenging system.
The mechanical design will be based on this concept and will result in a unit with approximate size 500 × 500 × 350 mm. The unit dimensions and the positioning of the main components are indicated in figure 2.
The HEV ventilator will be designed to the following specifications:
• Working Pressure: Up to 50 cm H 2 O.
• PRVC peak pressure limit set to 35 cm H 2 O by default with an option to increase this in exceptional circumstances and by positive decision and action by the user.
• Operation modes: PRVC, SIMV-PC, CPAP, as defined above.
• Exhaust mode: PEEP available with a set range between 0 and 5 cm H 2 O.
• Minute volume flow capability: Up to 20 litres/min.
• Inspiratory flow capability: Up to 120 litres/min.
• Respiratory rate: 10-30 breaths/min. • Inspiratory:Expiratory ratio; 1:2 will be provided as standard, and the unit will be adjustable in the range 1:1-1:3.
• Tidal volume setting to be provided in the range 250-800 ml in steps of 50 ml.
• Gas and Power Supply Inlet: Set according to the MHRA standards [13].
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 3 . The user interface will consist of an intuitive panel which displays the needed information and controls in a dynamic and continuous fashion. The controls and alarms described here are extremely preliminary and simply give an idea of the system functionality. The finalised list will emerge during the prototyping stages.
The following items will be included in the display:
• Ventilation mode.
• Working pressure, corresponding to the manually set and monitored input pressure to the unit. • Inspiratory Minute Volume setting.
• Breaths per minute setting.
• Tidal volume display, based on previous two parameters.
• Inspiration time setting.
• Pause time setting.
• Expiration time display based on previous two parameters.
• Expired minute volume.
• Airway pressure display based on the reading of P 2 .
• PEEP setting.
• Trigger sensitivity to patient-initiated breath.
The following items will be plotted as a continuous graphical display:
• Volume vs time.
• Pressure vs time.
• Flow vs time.
The HEV will pay particular attention to the MV leak alarm which is a standard hospital setting alarm, but of crucial importance in the case of a highly infectious disease such as COVID-19 to protect staff and patients. It will trigger with high sensitivity on any leak in a circuit, which could come from the balloon in the patient airway leaking, a disconnection or a poorly tightened tube and so on. In the current version the O 2 concentration is not measured, but this is being investigated actively. The display format will be similar to the typical display seen in a hospital setting.
In pressure support modes the ventilator will go into an alarm state and fail-safe to mandatory ventilation in case the patient-initiated breaths cease. For all modes alarms are given if breath rate or minute volumes fall below acceptable levels.
The following items will be displayed as audible and visible alarms:
• Push Button manual alarm.
• Gas supply alarm.
• Apnea alarm.
• Expired minute volume.
• Upper pressure limit.
• Power failure.
Several solutions are currently being considered for the embedded controller including Arduino, Raspberry Pi, and ESP32. Each have their strengths and weaknesses. Raspberry Pi performs better for a human interface and greater graphical power, and support for HDMI which allows for larger displays. Raspberry Pi lacks ADCs which precludes the use of some devices. On the other hand, the requirement of an operating system adds a complexity that may reduce overall stability.
Arduino and ESP32 have ADC capability and Wifi in several variants, but mostly the graphical add-ons tend to be of a smaller form-factor (5 inches or less) which may not be ideal for hospital use. The ESP32 is an Arduino compatible device with additional CPU power and memory. The parts supply is being investigated and the availability may be a significant deciding factor in the technology choice. Additionally, given the potential use in several geographical locations, different variants may be developed to adapt to locale.
The current baseline design considers Arduino for controls and Raspberry Pi for monitoring. The combination of the two offers the most power, and many developers already have one or both of these devices in hand whilst working from home. Code will be written in a portable manner should a change of platform be required. 
For the mechanical structure the aim is to use as many standardised parts as possible. A list of the typical parts required includes:
• Solenoid valve with ID bigger then 22 mm. This is the assumed diameter of the hose to the patient.
• Fast acting solenoid valve for inlet of air into buffer volume.
• Solenoid valve for purging. It could be low volume, that in case of over-pressure only some air is released.
• 2 litre buffer container.
• Pressure regulator from 2-5 bar to up to 200 mbar.
• 5 pressure sensors 1 .
For the embedded controller similar concepts apply. A typical part list could include:
• 1 Arduino and 1 Raspberry Pi per unit.
• 1 touchscreen, preferably 15", also 10" could be acceptable. If the touchscreens are not available an option could be a standard PC monitor with an interface appropriate for the hospital setting i.e. with buttons. Medical touchscreens could be an option but are likely to be more expensive.
• Typical small supplies such as 5V power supplies, power supplies for the valves, USB cables (1 standard, 2 micromax).
• Optional ethernet cable.
The first stage of prototyping is to demonstrate that the working principle of an alternatively filled and emptied buffer is sound, and allows the ventilator to operate within the required ranges of pressure and time. This was achieved on 27 th March 2020 with a first demonstrator. A photograph of the bench test stand is shown in figure 5 . Note that the demonstrator was built with readily available parts, and therefore the mechanical look of the device seen in these photographs is completely different to the final design. Based on the experience with operating the demonstrator, the desired physical characteristics of the pressure regulators, valves and pressure sensors could be refined, and the system is now in prototyping stage. Figure 5 : Prototyping the HEV "buffer concept". The demonstrator system is developed with the buffer concept to demonstrate the "breathing" and flow capabilities. This demonstrator is built with in-house parts and looks mechanically very different to the final system. Control is provided via LabView, whereas in the final system it will be via an embedded controller.
The deployment of the device will pass through the following stages:
1. In the first phase the concept will be demonstrated with a working unit prepared using the available hardware and with a control system implemented with standard software.
2. Consultations on testing and validation are taking place with hospital clinicians, both in the CERN region and beyond.
3. Based on the experience of the demonstrator unit and the consultation with the clinicians, a prototype will be built and tested possibly with standard test facilities for ventilators, available in hospitals.
4. Control software will be developed, able to run in embedded microprocessors and with a dedicated graphical user interface allowing clinicians access to the settings and providing alarms in a mode familiar to the operators. This will shadow the standard software development in such a way that the hospital deployment gives identical functionality.
5. 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 (as soon as available following completion of testing and validation), for these institutions to follow up in accordance with local possibilities and standards; on the other hand, directly through industry, for which purpose contacts have been established with the WHO, on the basis of the Cooperation Agreement in place between CERN and WHO.