An Intensive Push to Make Ventilators for the COVID-19 Pandemic

Creating a New Design in 47 Days for the UK Ventilator Challenge

On March 13, 2020, Cambridge Consultants, a technology consultancy in England, received a call from the UK government. COVID-19 was sweeping through the country, and while the National Health Service had 8,000 ventilators on hand, they were expecting to need 30,000 in worst-case scenarios. Even if established ventilator manufacturers worked full steam ahead, they wouldn’t be able to meet the demand. What’s more, travel restrictions were creating a shortage of parts in global supply chains.

In just 47 days, Cambridge Consultants designed a simple new ventilator that provided several settings for clinicians, eight alarms, and a custom mix of air and oxygen.

So, the government issued the Ventilator Challenge, asking several UK firms to design new devices from the ground up that could be made quickly with local parts. The firms had a few weeks to do it.

“Day one, we had a call from the cabinet office saying, ‘Do this please,’” says Sean Thompson, a senior mechatronics engineer at Cambridge Consultants. “That came Friday. A team of senior consultants and technical leads in the med tech division worked the entire weekend.

“I showed up Monday, and I had a whole bunch of missed calls. I logged into my email, and I’ve been invited to two days solid of workshops. I wondered, ‘Oh no, what’s going on?’ And so, a team of 30 or 40 of us from all around the business sat for two days and just smashed through a whole bunch of different concepts.”

What they landed on was a relatively simple design with only two sensors—airway pressure and inspiratory flow rate—but a lot of features. Clinicians would be able to set the inspiratory pressure, the oxygen level, the respiratory rate, and the ratio of inspiratory and expiratory time. In addition, it would have eight alarms for things like patient disconnection, airway obstruction, tidal volume out of bounds, and overpressure. It would also have a custom blender for mixing pure oxygen and regular air.

The ventilator is connected to the various hardware components used for HIL simulations. — Cambridge Consultants accelerated the design of the ventilator using simulation, including hardware-in-the-loop simulations. Image credit: Cambridge Consultants

From Virtual to Reality

The project timing would not have been possible if they’d had to design and test everything starting with physical parts. Building and rebuilding the machine would have been too slow. Instead, they first built it in software, running simulations that they could tweak endlessly.

Much of that work was done with MATLAB^® and Simulink^®. The team used graphical programming by connecting blocks that represented mathematical functions. Libraries of physical components in Simscape™, such as springs and valves, enabled the team to create models of the lung and ventilator. Simulations let them test the system-level operation each time one of the blocks in the design was tweaked.

Even the simplest ventilator is tricky to design. “It has to do a good job of providing air to the lungs in a way in which the lungs can actually take the air,” says Kirthi Devleker, a senior product manager at MathWorks. “You can’t just turn on a fan and then think, ‘Okay, that’s going to be my ventilator.’”

The pneumatic system model in Simscape is shown as a block diagram. — Pneumatic system model in Simscape. Image credit: Cambridge Consultants

“There wasn’t enough time to identify a component, order it, test it in the lab, then make a decision. We could go at the speed of simulation. That was really cool.”

Basic ventilator and lung models were supplied by MathWorks, but Thompson expanded on them. The lung model was basically a gas-driven piston with springs and dampeners, “and that actually models the human lung really well,” he says.

Building the ventilator model, and writing the algorithms for controlling it, involved pair programing, with Thompson sitting at a computer while on a video call with others on the team. His collaborators, each responsible for an aspect of the system, would give high-level instructions, and he would implement them in the model. Both the visual nature of the coding and the tools for visualizing results allowed nonprogrammers to understand what was happening. “We could just leave it running there, watching it step through the program, a whole bunch of charts going by—that’s that event, that’s that event, that’s that event,” he says.

“The accessible nature of graphical programming in Simulink made it easy for us to tap into the expertise of many of our colleagues,” Thompson says. “That meant we could get all of these really useful insights into the system. Due to the accelerated schedule, there wasn’t enough time to identify a component, order it, test it in the lab, then make a decision. We could go at the speed of simulation. That was really cool.”

Once the design started to shape up, about a third of the way through the project, the team built a physical prototype and hooked it up to an ASL 5000 Breathing Simulator, which acted as a physical lung model. The ventilator was still controlled by the algorithms on the computer (thanks to Simulink Desktop Real-Time™), though, in a setup akin to a hardware-in-the-loop rig.

Despite the power of simulations, testing in hardware is important. Hardware testing also helped the team calibrate the software model. In software, the team could iterate designs faster and test the ventilator’s limits without worrying about causing damage to the hardware.

A Change of Plans

Midway through the project, Cambridge Consultants received a curveball. The ventilator requirements changed. Originally, the idea was to treat the lungs as passive partners in breathing, inert bags to be inflated and deflated. But mechanical ventilation on a timer can cause lung damage after a few days. And if patients emerge from sedation and the timer doesn’t align with natural breathing, the discomfort can be extreme. In response, the Medicines and Healthcare products Regulatory Agency (MHRA) asked for a spontaneous breathing mode, in which the ventilator would take its cues from the patient’s lungs.

Thompson got his lung model to breathe actively, then spent an afternoon seeing if he could get the ventilator algorithm to detect breathing, despite the machine’s lack of ideal sensors for such a task. “We had it working with the test lung within two days of being asked to do this,” he says. “That was one of the most amazing things I’ve ever worked on. By all of us working in this big integrated environment, trying to solve all these different technical problems, we’d built this infrastructure that let us develop this complicated feature unbelievably quickly.”

Max Curzi, senior software engineer at Cambridge Consultants, took the control panel design and implemented it in Simulink to look just like it would on the device, using Simulink Dashboard blocks to make an interactive interface. This proved critical when the MHRA wanted to check on their response to the new requirement.

Computer screen. The left side shows a model of the control panel for the ventilator. The control panel is layered over a window showing the Simulink block diagram for the device. — A Simulink model of dashboard panel based on the actual UI of the device. Image credit: Cambridge Consultants

When requirements changed to include a spontaneous breathing mode, in which the ventilator would take its cues from the patient’s lungs, the team adapted their model and had a working test lung in just two days.

“Within a week,” Curzi says, “we were able to demonstrate the full working system to the MHRA panel of experts in a video call. The Simulink model had all the knobs, gauges, and buttons of the real system and could control the ventilator in real time. During the call, they asked to interact with the ventilator in a variety of scenarios, saying ‘Okay, what if you do this? What if you do that?’ They were trying to stress it to break it. But it didn’t. It worked well, and they were pleased with the results.”

Keep It Simple

The team faced many challenges. First, there was the time pressure. A project with this scope required all kinds of engineering expertise, but also experts in human factors, procurement, project management, and clinical. All these teams (about 200 people at its peak) worked in parallel streams over the seven weeks, many working overtime, and some sleeping in the office. And some aspects of the assignment weren’t well defined early on. Fundamental components, such as the pressure regulator and gas blender, were redesigned or replaced at a late stage, but by having different mechanical characteristics, they significantly changed the system dynamics: this required the team to redesign, implement, and test some alarms algorithms at a very late stage of the project.

On a desk in an office, the testing configuration comprises an ASL-5000 artificial lung (left) with two breathing tubes that connect to the ventilator (middle). The PC on the right-hand side is running the Simulink model for a hardware-in-the-loop test. — The design team runs the Simulink model (screen to the right), on a PC hooked to the sensors and solenoid valves of the ventilator (middle). Realistic patient behaviors were simulated using an artificial lung, the ASL-5000 (left). Image credit: Cambridge Consultants

The final design worked, cost a fraction of what commercial ventilators cost, and was simple.

But the final design worked, cost a fraction of what commercial ventilators cost, and was simple. “You can count on two hands the number of components,” Curzi says. Regarding his own contributions, “I was really proud of making something that was simple and robust,” he says. “As an engineer, it’s tempting to develop sophisticated systems, but the complexity makes it harder to prove safety and robustness under all scenarios. Using a few fundamental blocks allowed the development of alarms and assisted breathing algorithms that would be robust and require a few lines of code to implement and test. Simple systems fail in predictable ways, so it’s easier to prove that the ventilator would be safe to use once the failure modes are accounted for.”

Ready Should the Need Reemerge

One day before the ventilator was to be delivered, Cambridge Consultants learned it would no longer be needed. Demand in the UK was thankfully not as great as worst-case models predicted. That happens quite often with medical devices, Curzi says. “We developed the ventilator hoping that it would not be needed.”

The engineers learned a lot and found the experience hugely rewarding. “These things typically take years to develop,” Curzi says. “Being able to see the full development, from a blank canvas to the physical thing that will go into clinical trials, in 40 days was fantastic.”

“Being able to see the full development, from a blank canvas to the physical thing that will go into clinical trials, in 40 days was fantastic.”

“From a personal point of view,” Thompson says, “this project was an unbelievable experience, and it’s something I’m unlikely to repeat in my professional career. It was an amazing view of what is possible to achieve if you want it hard enough. I’m grateful to have been a part of something this unique.”

While the UK has paused the Ventilator Challenge, the design is ready should it be needed.

Read other stories

Academia / AI