Accelerating medical device development: Lessons from CoVent and the UK ventilator challenge

Developing a medical device in weeks rather than years during the coronavirus pandemic was an extraordinary undertaking. Dan Strange reviews TTP’s “Project Jarre” to develop the CoVent(TM) ventilator and draws some lessons as to how – when needs must – faster medical device development is possible.

On 13 March 2020, TTP joined a mid-Friday-afternoon call with the Cabinet Office, where it was outlined that the UK would soon be facing a shortage of 20,000 ventilators for COVID-19 patients. TTP was then asked to develop a simple ventilator that could be manufactured from readily available parts and supplied to the National Health Service on a timescale of 6-8 weeks. 

Even for the simplest of medical devices, it normally takes in excess of 2–5 years to complete all stages of a development, set up a manufacturing line, and submit a regulatory file for approval. This is grudgingly accepted by the industry, although given that consumer (non-regulated) healthcare products enter the market with much faster development times, many have wondered if there is a better way.  

During what followed, we effectively put our company on a war footing and by the end of Project Jarre, we had developed a ventilator from a blank sheet of paper within 5 weeks under our ISO 13485 medical device development quality system. By 25 April, our devices had gone through verification testing, were manufactured on the final production line through our partners at Dyson, and a regulatory file demonstrating appropriate compliance to the essential requirements of the European Medical Device Directive was submitted to the Medicines and Healthcare products Regulatory Agency (MHRA).

We clearly had a fair wind, but there are lessons that can be learned from our experience as to how to accelerate medical device development and consequently the pace of innovation. This TTP blog describes what made successful the massively parallel development approach that allowed us to make rapid progress, how we rapidly tested and iterated the design to test assumptions and build confidence, and how we managed programme risk in the face of the evolving device specification for COVID-19 patients. 

Medical device development mostly follows a well-trodden waterfall model. An initial specification phase is followed by concept generation, detailed design and prototyping, before moving on to verification testing and scaling for manufacture. 

Given the urgency of the impending national emergency, in Project Jarre within 24 hours a team of experts that quickly grew to 140 people came together and began to carry out all these tasks in parallel. By necessity, the pneumatics, mechanics, user interface and electronics of the ventilator were all designed simultaneously before the first MHRA device specification had been released. The regulatory documentation plan was being put together without a clear idea of what the device would be. Prototype units were being designed and built at the same time the production line was being laid out. The instructions for use were being drafted prior to having a functioning prototype. Furthermore, all of this happened without a traditional line management structure but instead with highly distributed authority and responsibility. What is surprising is that we didn’t see all the mistakes and substantial knock-on consequences that would be expected when working in such a fashion. 

Much of the success of this way of working was down to tight coordination and synchronous execution by the experts on the ground, and the radical trust between teammates that enabled this. With such rapid pace, no single individual could hold all the key activities and key decisions in their head across the streams. Adopting a top-down approach and pausing to fully plan out or micromanage the details would have slowed down the project. Instead, akin to a high performing sports team, groups of people coalesced around activities and worked autonomously and independently with common purpose, always trusting each other’s ability to overcome any problems encountered as the development progressed. These individuals had the relevant experience, skill and capability, and largely knew what needed to be done, what decisions needed to be made, what risks needed to be addressed and when wider input or more data was needed. The individuals on the team covered a whole gamut of personalities from visionary to pedant, blasé to paranoid, head-down technical to head-up communicator, gung-ho to nervous, fiery to calm, and as a result checks and balances were naturally built into the development.

Strong and instantaneous communication across the whole team was key to ensuring that these individuals had the best possible context to be able to make the right decisions. Early on into the project, 23 ‘single points of contact’ (SPOCs) were designated for the many ongoing work streams ranging from ‘clinical’ to ‘mechanical development’ to ‘risk management’. These SPOCs facilitated communication across the different streams and helped ensure critical inputs were not missed, but deliberately did not aim to gate or control communication. Hence, when it was identified the changing clinical picture required patient-triggered breathing to be added to the specification, hardware, firmware, human factors and electronics teams came together to create a modified system within 48 hours. In many ways, the virtual working imposed by the lockdown measures helped and hindered this: it facilitated instant conversations between individuals from across the whole project team regardless of location, but also perhaps made it harder to naturally absorb the wider picture. 

This approach meant that the teams’ efforts were not held back by conforming to existing structures or processes and could rapidly re-deploy where most needed in the programme. Decisions were taken by those with the most immediate knowledge, and the highly parallel nature of the development (akin to a souped-up version of concurrent engineering) made it easier to identify the knock-on effects of a single decision on manufacturing, clinical, usability and regulatory activities as early as possible within the design phase while they were still easy to change. 

That is not to say that no mistakes were made, and one of the challenges was coordinating across all the different critical paths and spotting gaps or unintended dependencies. A stronger focus on planning was implemented halfway through the project to facilitate this, though mostly to highlight challenges rather than directly steer the development. The burden of massive point to point communication to understand context certainly had overheads and few individuals did have the full picture of where the development was, but overall the approach undoubtedly enabled us to make rapid progress.

Medical devices are often developed following a right first time approach. Unlike consumer electronics products or mobile phone apps, a medical device must not have a significant number of faults that arise in the field, with patches to follow later. This mindset generally flows through development, with significant effort going into analysis and testing and on proving out the design before each stage gate. 

In contrast, during Project Jarre, we accepted that some level of programme risk needed to be taken if the urgent timeline was to be met. This is as opposed to device risk: the ventilator still needed to be safe. Hence, we strongly emphasised the taking of decisions to move forward based on the information available and then testing and iterating the system itself to build confidence.  

Within 3 days of the kick-off call, our teams were testing integrated prototype systems made from off-the-shelf parts on test lungs, and this rapid testing and iteration carried on throughout the project. Analysis and careful design thinking is critical for developing an understanding of potential issues and the reliability of their solutions (and TTP has pioneered the application of many of these methods such as probabilistic design). However, analysis is blind to the unknown unknowns. Such rapid testing helps to quickly flush out the unknown unknowns, which often can have a significant effect on timelines.

Of course, a few things made this possible for this project in particular. Ventilators have well developed in vitro test procedures that simulate real-world clinical performance. So, we had a clear guidance as to what the measure of success would be, and in the first week of development we began to procure ventilator flow analysers to be able to truly benchmark performance. As a result, we were able to perform many formal verification tests, where the design is assessed against all aspects of the specification, throughout the development cycle as opposed to only late in the development.

We also had the luxury of implementing many of these tests as end of line tests in the manufacturing process, reducing much of the burden on ensuring the design was robust to tolerances – this end of line test approach would often be cost prohibitive in commercial situations. Lastly, the prototypes were deliberately designed to use off-the-shelf or rapidly manufacturable components, so the cost of iteration, both in time and financially, was relatively low. One of the reasons that the agile methodologies used for fast pace software development fall short when applied to hardware development is the costs of iteration can be prohibitive.

Yet, it is possible to devise conditions that favour a rapid iterative approach in other contexts. For example, our human factors team carried out over 15 iterations of the user interface with clinicians initially using digital animations and photo, before moving to mock-ups and prototypes. Consequently, many of the usability issues that might be difficult to anticipate had already been flushed out by the time hardware implementations had been built (Figure 3). 

Similarly, our electronics team designed the ventilator to run using VHDL rather than software, cognisant of the significant time that developing medical device software can take, which made it much quicker to implement changes later in the development process. A key aspect of the product development process was identifying how to simplify the design so that it was amenable to more agile development processes.

Uncertainty can cause significant delay in the form of additional development loops. Early on in the ventilator challenge there was significant uncertainty as to the specification and particularly what would address the clinical need. The specification then continued to evolve throughout the challenge. In order to make rapid progress it was critical to gain clinical input directly, and substantial effort was put into building a clinical advisory network to clarify what ventilator features were likely to be must-haves rather than should-haves. This network was then maintained throughout the development, with almost daily communication, and facilitated the translation of clinical requirements into actual technical requirements, as well as rapid decision making with respect to the overall goal. 

Even with such stakeholder input, there were still many risks which at the outset of the design process were unknowable and impossible to quantify: Would we able to source a particular type of component? Would this clinical feature become a must have rather than a should have, as more was learnt about the treatment of COVID-19? To manage this, we adopted principles akin to Set Based Concurrent Engineering (SBCE), also known as Redundancy Based Design (RBD). Multiple independent concepts were pursued through the concept development stage, which were deliberately selected to have different risk profiles. For example, a pneumatic system using solenoid valves was progressed in parallel with a mechanical bellows system using motors. This mindset continued throughout the development and meant that as the clinical need evolved or unknowable risks became apparent, we were able to pivot and quickly adapt to the new situation by drawing on some of the other device concepts. 

Many things made the development of the CoVent ventilator a unique experience, not least of which was the extreme personal commitment that all the individuals at TTP and all our partners demonstrated throughout, commensurate to urgency of the crisis.

Yet, there are more general potential lessons as to how to accelerate the pace of medical device development. Many of these takeaways have similarities to existing methodologies for software development like Agile or Lean development but applied in the context of medical device hardware development. 

These include going massively parallel with an engaged competent team while ensuring there is clear communication, adopting a fail fast mentality to flush out unknowns while minimising the cost of each iteration, and adopting practices to manage programme risk.

It would not be appropriate to adopt all these lessons in all medical device developments, but when time to market is truly critical, our experience in the ventilator challenge suggests that there are ways to break beyond the status quo.

How we help our clients | Medical Devices | Healthcare Blogs | Healthcare Case Studies