The COVID-19 Pandemic Highlights the Need for Open Design Not Just Open Hardware

Abstract

The COVID-19 pandemic has seen a surge in development of Open Source Hardware, especially open source ventilators. Many of these open source ventilator projects have adopted an open-when-finished model due to legitimate legal and liability concerns. This, however, has led to a proliferation of projects with teams across the world independently designing over a hundred mutually incompatible ventilators, representing a huge amount of duplicated effort. A functioning design is necessary but not sufficient for a project to help patients. The device must be taken through regulatory approval by a manufacturer that understands why design decisions were taken. In this article we argue that the open design process developed for Open Source Software can be used for Open Source Hardware. This process not only allows remote teams to work together improving a single design, it also provides the rich history of design decisions that manufacturers need to take the device through regulatory approval.

Keywords:

• Open design
• medical device
• COVID-19
• co-design

Introduction

Open Source Hardware has been thrown under the spotlight in the COVID-19 pandemic, with a huge number of rapidly prototyped medical device projects announcing that their design is ‘Open Source’ (Pearce 2020). The motivation for making the designs open source stem from a consensus that it would be wrong to assert intellectual property (IP) during a pandemic. For an Open Source approach to be beneficial it is important to understand what a project wants to achieve by being open, and design the approach around this goal.

The Open Source Hardware movement has been heavily influenced by the success of the Free and Open Source Software (FOSS) movement (Jones et al. 2011). The goals of these movements are usually to increase access to the technology being developed and for developers to work together to improve the technology. This reduces the amount of time spent than re-engineering solutions to the same problems (Chagas 2018).

For a medical device, increasing access to a technology relies on more than designing a working prototype and building the device. It also relies on certification (European Parliament 2017). Under the current internationally-aligned regulations it is not possible to certify a design for a medical device. The certification is for a product.

Medical device certification covers more than just the current iteration of the design. It covers the methods of production, and the quality assurance procedures that ensure the device is manufactured to specification. The certification also requires manufacturers to describe the history of design decisions and to commit to continual improvement of the device and their entire manufacturing process (ISO 2016).

The medical device certification procedures have been written with companies that design and manufacture their own equipment in mind. One might argue that these rules should be modified to allow distributed manufacturing of equipment by those who did not design the device. However, it is still necessary for the manufacturer (who is legally responsible for the product) to understand the rationale behind the design decisions. Understanding the design is essential to the implementation of a quality-managed production process. This understanding also enables the manufacturer to fix design flaws and improve the product, as required by ISO13485 (ISO 2016). This is of critical importance to the safety of the product. We then must ask how to capture not only the final design of a medical device, but the reasoning behind all of the design decisions. With this information manufacturers can understand and build on a device together in a way that is compatible with certification.

We argue than an Open Design process is as important as the design itself being released under an open license. Open Design is the most effective way to avoid duplicated effort in a crisis producing hundreds of partially complete designs. Open design is also the best way to ensure that all of the necessary information about the design process is available to every potential manufacturer.

In this manuscript we will broadly classify open hardware projects into two categories, ‘Openly Designed Hardware’ (ODH) and ‘Open When Ready’ (OWR). An ODH project has all aspects of the design process publicly available from original CAD drawings to detailed design discussions. An OWR project is developed by a team internally and the final design is released under an open source license. Many projects will fall somewhere between these two extremes.

The purpose of this paper is not to criticise either medical device projects or medical device regulations. Many of the recommendation made in this paper will not be entirely new to those who have studied open design. We have focused on distilling numerous hard learned lessons that are both of practical use to design teams that are embracing open-hardware for the first time, and to those experienced with ODH projects but that are new to working on medical devices. We also suggest that governments and institutions clarify numerous policies that leave practitioners of open design in an ambiguous position. This ambiguity slows down innovation in a crisis.

The motivation for openness

Ventilator shortages during the COVID-19 pandemic inspired engineers across the world to build solutions. The usual Technology Transfer route taken by design teams in universities—registering and asserting IP—was clearly not appropriate at a time of global crisis. As such, most teams took the route of declaring that their device was ‘open’. It is important, however, for a project to understand its motivations for being open in order to properly decide on its methodology. Without a clear motivation it is not possible to assess whether the project is fulfilling its goals.

Enabling collaboration and enhanced scrutiny of the design

Both ODH and OWR projects can meet the Open Source Hardware Association (OSHWA) definition of ‘Open Source Hardware’ (OSHWA 2016). However, only ODH projects are able to leverage the benefits traditionally associated with ‘open source’. These include scrutiny from those outside the core design team to identify and mitigate problems earlier, sharing of information within and between teams, and avoiding duplicated effort by re-using parts of other teams’ designs (Government Digital Service 2017; Svorc and Katz 2019). Finally, an effective ODH project is to a degree self documenting, as the only way for distributed teams to work together on a hardware design is to understand each other’s work. If these explanations of the work are in a public forum, then all the design information is publicly accessible—even if it needs collating into a more helpful form for others that wish to join the project.

OWR projects are often easier to run for many engineering teams. During the initial design phase a team is able to work in the same way it does on any other project. Once the design has been shared, others can undertake further development and manufacturing only if a full history of the design process is included. Thus the designers must be diligent in preserving the design history with version control and storing information about the design decisions.

An OWR project can continue to develop and periodically release the updated design once it is ready. However this approach discourages other teams from also participating in the design because it is not possible to know whether these updates clash with other ongoing design work. Furthermore if the design history is not captured it is unlikely that any others will ever be able to use or contribute to the design. We do understand that many projects adopted a OWR approach due to liability and safety concerns, we cover this in detail in the section Liabilities and Dangers of an Unfinished Design. While it is possible to transition a project from and OWR to ODH after the first prototype this only works if the team is willing to release some control over the design.

For the reasons stated above it is difficult for multiple distributed teams to work together on OWR projects. This goes some way to explaining why so many ‘competing’ ventilator projects were started. ODH projects do not preclude competition, however they can reduce the number of projects as designers can contribute to existing projects. Competition between ODH projects is also fundamentally different as it allows competition on the design merits rather than the limited information revealed in press releases and private conversations. ODH also allows for good ideas to be adopted by other projects (Von Hippel 2006).

The comparison between OWR and ODH projects has many parallels to the Cathedral and Bazaar models of open source software design (Raymond 1999). In the Cathedral model software built by a few dedicated architects and presented when complete, whereas in the bazaar model software is built in an ad hoc fashion by numerous developer-users. A major difference between the Bazaar model and ODH is that in the Bazaar model software is very regularly released, and users form a major part of the design team as they add features and fix bugs. For hardware, especially medical hardware, a ‘release’ is much more costly, requiring significant documentation, tooling, and certification. However, the core philosophy and advantages of the Bazaar model—especially that ‘Debugging is parallelisable’—apply to ODH. It has also been noted that the Bazaar model is an oversimplification, as open software design (and ODH) retain a hierarchy and structure within a core development team while welcoming external participation (Gaudeul 2007).

Trust and equitable partnership

Getting involved in an open hardware project, whether as a designer, tester, consultant, or potential manufacturer, requires a contribution of time and resources. It is therefore important that anyone joining the team has confidence they (or others) will enjoy the benefit of the open design once it is ready for use. In an ODH project, this is assured as everything is already openly licensed. In an OWR project, openness is not guaranteed until the release date. This means that one or more parties must agree to release the designs, and complicated or expensive contracts and governance arrangements may be needed to ensure this proceeds in line with everyone’s expectations. This can make it hard to collaborate equitably until legally binding agreements are in place. Equitable collaboration is particularly important when there is an imbalance of power or funding, for example between a well-funded university and a manufacturer in a low or middle-income country (LMIC).

Both ODH and OWR projects can allow commercial exploitation of the finished design without further permission being required from the designers. This allows manufacturers to take ownership of a product and ensures they have the independence to customize it to local needs. Giving up the control, and financial return, associated with a traditional licensing agreement changes the balance of power in the relationship between a designer and manufacturer. In the case of collaborations between countries where there is already entrenched inequality, we argue that this shift can be incredibly valuable to the LMIC partner.

The Open COVID Pledge (Open Covid Pledge 2020) aims to mitigate some of the risks of OWR projects by providing a clear statement of intent that is much more concrete than simply specifying ‘open’. This makes it harder for organizations to change what they mean by ‘open’ and provides confidence that designs will be released under a suitable license. However, it is not legally binding and relies only on the pressure of publicity to hold organizations to their promise. The pledge is also time limited to the current pandemic; we cover this further in the section Open Source is For Life Not Just a Pandemic.

Good publicity

Universities and companies are keen to publicize their engineering efforts. Pressure on researchers and engineers to attract media attention encourages starting a new project rather than joining a large collaboration as a junior partner. Also as institutions are keen to express their open aspirations, this leads to announcements of OWR projects as ‘Open Source’, before any part of the design has been released openly.

Announcing that a project is open before the design is open is problematic as it can build distrust of open hardware. Often projects are unclear about their current status, what will finally be released, and when (if ever) this release will happen. We say ‘if ever’, not because we believe there are teams claiming openness in bad faith, but because of the difficulty in collating the design information and getting the sign off from an institution to release a design openly. This can lead to OWR projects never reaching a point when they are ready, or a change in circumstance can cause the project to reconsider the OWR approach.

A project is not open source hardware until the design has been openly shared. Projects that intend to be open should be clear that this is an intention rather than the current status. Announcing the intention provides clarity and can be considered similar to labelling a product ‘patent pending’ before a patent is granted. Similarly, it is illegal in most jurisdictions for a manufacturer to claim it is producing a medical device until the device is certified for medical use.

Objective methods to judge whether projects meet an agreed definition of open source hardware exist, such as the DIN SPEC 3105 (DIN 2020) and the OSHWA certification scheme (OSHWA 2016). Both of these require already-released designs. However, it is not yet expected that a project is assessed by these criteria before they declare the project open source.

The benefits of and the barriers to open design

Open source is for life not just a pandemic

Initiatives such as the Open COVID Pledge have now been signed by many of the world’s largest technology companies (Open Covid Pledge 2020). Newspapers have been inundated with stories about open source software and hardware solutions to COVID-19. Collectively these show a broad consensus that working together and openly is the best way to fight a pandemic. A lot of this attention initially focused on ventilators. However going from a blank sheet of paper to shipping a product is a lengthy and time consuming process that can take years (see Figure 1). What are the chances that a ventilator project can complete this whole process in time for this pandemic?

Figure 1. Idealised flow chat of the steps needed before a medical device can help patients. Open designs for a working prototype still leave a large amount of work to be completed. Each manufacturer will have to complete the steps in the second column. In reality a design will not simply follow this linear pattern; some stages will be done in parallel, with experience from one feeding into another, while other steps will have to be repeated as the project evolves..

This impressive feat of engineering may well be possible if engineers across the world found a way to work efficiently together on a single ventilator project. Some engineering teams may achieve this with a manufacturer before the pandemic is over. But it is important not to lose sight of the fact that the world already knew how to build a ventilator. What was lacking was not the technology but the capability to produce, ship, and repair enough ventilators to meet demand, especially in LMICs.

Medtronic PLC released the designs and technical files for one of their older ventilator models (Pearce 2020). As a final design was released we classify this as an OWR approach. It remains to be seen whether other manufacturers will be able to get their device certified under the less stringent accreditation such as the FDA Emergency Use Authorization in the United States. We also note that Medtronic and many other OWR ventilator projects have opted for a time limited open license that will expire once this pandemic is over. When a medical device company releases their IP openly it seems inevitable that they would opt for a time-limited open license. However, it is less clear why publicly funded institutions would choose such a route (see the section Academic Pressure Towards Closed Design). Time limiting the license discourages companies from putting in the considerable work to set up production lines. This raises the question of what will happen next time there is a pandemic.

Academic pressure towards closed design

Many funding agencies require research outputs to be made openly available. However, it is common for researchers designing hardware to produce an open access paper with open data on the performance of a design but to protect the design IP. Some argue that the design itself is a research output and should be open (Dosemagen, Liboiron, and Molloy 2017). However, innovation is often assessed by the numbers of registered patents (Carvalho, Carvalho, and Nunes 2015). Thus, by allowing academics to make publicly funded designs openly available, the institution can be seen to be less innovative. Many universities are also under pressure to self-fund activities and measure the impact of their research with income generated by IP they create (Etzkowitz, Webster, and Healey 1998).

These external pressures on universities lead them to pressure academics to protect the IP they create. While there may be valid reasons for asserting IP in some cases, openly releasing hardware designs is not normally listed as an option. The open hardware technology transfer route is under-explored, so there is a significant lack of legal advice or institutional policy for academics who are considering it. As an ODH project is no longer patentable, institutional agreement may be required before the project can start. This often leads to an OWR approach, which defers the need to negotiate licensing terms or make binding decisions about openness. Deferring these discussions not infrequently leads to projects announcing themselves as open in good faith, but finding themselves unable to follow through due to contractual obligations or commercial pressures. An ODH approach forces these decisions to occur earlier, when there is less at stake, avoiding unfulfilled promises and building trust. Clear institutional policy makes it much simpler for academics to adopt an open design process.

Open source medical devices

Manufacturing and certification

Open-source hardware is often associated with the ‘maker movement’ where hardware is produced by users or on a small scale for local use. However, in the case of medical devices—especially life critical devices such as a ventilator—hospitals will only accept equipment that is manufactured to rigorous standards. Hospitals have neither the time nor the resources to build or certify medical equipment during a pandemic. Consequently, any open-source hardware project with an intended medical use needs to consider how it will partner with manufacturers that have the expertise and resources to take a product through certification. These manufacturers provide the necessary assurances and support to the hospitals purchasing the device. It is important to note that providing uncertified medical devices to a hospital can expose the hospital and/or medical staff to liability if a device does not perform as hoped. While not-for-profit groups, individuals, and universities are understandably keen to avoid liability, it is clearly unfair to leave already overstretched healthcare professionals responsible for a specialist certification process that is outside their remit.

The key reason for institutions to develop new open ventilators was to increase availability of ventilators. Manufacturing capabilities, access to supply chains, and quality assurance procedures are essential to the realisation of a certifiable medical device. As such, manufacturers must be engaged with the project as early as possible. An ODH project gives any manufacturer the opportunity to get involved with the project at an early stage. The manufacturer can either steer the design towards something that they can manufacture, or begin the process of creating an adapted design.

In principle, an OWR project could also collaborate with a large number of manufacturers by curating design decisions in a private digital repository along with complete version controlled designs. For those inside such a large collaboration this would bring many of the benefits of an ODH, while limiting the liability concerns of having an unfinished prototype available to the general public. However, working in a closed group often means knowledge is transferred face-to-face or verbally, which makes it more difficult to ensure full records are kept.

Anecdotally, we have found that the most common concern in relation to certifying open source hardware for medical use is the perception that anyone can change the design and that the design is constantly changing. While it is true that anyone can see the design, or modify their copy of the design, the maintainer of the project still has full control over whether a particular contribution is accepted into the official project.

The fact a design is always changing relates only to the development version of a project. This development ‘branch’ can coexist with a stable ‘branch’ of the design. The stable branch can be tested, finalized, and certified by a manufacturer. Any new changes added to the development version should be thought of as prototyping for a later version. One could argue that this is no different from what happens for proprietary hardware, where part of the team continues to work on features for an upcoming model. This need to freeze the design for certification is well established for safety critical Open Source Software (Comar et al. 2009), however it can be partially mitigated in the case of software by using continuous integration methods to continuously monitor the software.

Many projects have cited that their design is low-cost and suitable for LMICs. Our experience co-designing hardware in the UK and Tanzania (Stirling et al. 2020) is that due to the vastly different supply chains, both the availability and relative costs of components can be vary significantly. Similarly, the conditions for use must also be considered, with equipment needing to be robust in a hot and humid climate, or needing to be tolerant of intermittent or unclean power (Piaggio et al. 2019). For a product to have an impact in LMICs it is essential to engage not only with potential users, but also with local engineers to investigate local manufacturing capabilities. Even if a medical device will be built out-of-county, without the expertise of local engineers it is impossible to ensure that a design can be maintained and repaired locally. A lack of consideration will inevitably lead to the all-too-familiar outcome where 70% of medical equipment in Sub-Saharan Africa is out of service (World Health Organization 2000).

A further key consideration for an open source medical device project is defining the ‘source’ of a medical device. We have already discussed that without the history of the design process and design decisions manufacturers will not be able to produce a certified product. But we must also consider what we mean by the term design. To some, an open design may refer only to a prototype, others may expect the final designs for manufacture to also be open. We note that certain open licenses can be used which require derivative designs to be released under the same license. The CERN-OHL-S (CERN 2020) is an example of one of these ‘strongly reciprocal’ licenses. This can be used to ensure that the designs adapted for manufacture are also open source.

However, there is much more to a design than the CAD files that describe the physical part. For an open source medical device design to be useful it is important to include all stages required for a certifiable device. This includes the manufacturing methods, the tolerances required, and the selection of appropriate medical grade components (for example oxygen compatibility of components in a ventilator). Clear documentation is also essential, this covers: testing procedures; manufacturing, assembly and maintenance procedures; as well as user documentation. In this manuscript we consider all of the above to fall with the term ‘design’ for two reasons. Firstly, any one of these critical design steps that are not openly shared must be recreated from scratch by any manufacturer. More importantly, all of these processes must be performed in parallel and inform each other.

We previously mentioned that design history is essential for quality managed production. Designers should also consider whether a framework for the quality management system should be made available along with the designs. Collaborative creation of essential procedures and paperwork can allow a greater number of experts to provide the best solutions. However, producing ready-to-file paperwork doesn’t guarantee that the manufacturer understands the contents of the paperwork. A careful balance must be struck to provide a framework that asks the manufactures important questions about their processes, but to be effective it should not necessarily answer them.

Sustainability and Long-Term support

While an increased supply of a specific medical device may be necessary for a time-limited period during a crisis—such as ventilators in the current pandemic—the longevity of any project must still be considered. If a safe and effective medical device has been developed and produced, then it is advantageous if the device is supported long-term. As part of the certification process, each manufacturer must show that they understand the design well enough to support and maintain the device. While each manufacturer has a duty to develop any necessary fixes and improvements, this burden could be significantly reduced by manufacturers continuing to collaborate on the design. This begs the question of the sustainability of the underlying open source project. Whether the project is sustainable depends on the benefits that manufactures get from contributing back to the project, and on the stewardship of the project itself (Giuri, Rullani, and Torrisi 2008).

As previously mentioned, a reciprocal licence requires any changes to a design to be released under the same license. In practice, this only requires the design be passed onto end users that have purchased a device. In theory these end users are free submit the changes back to the original project. However, this would be an inefficient way to sustain a project, as the history and design intent of these changes may be lost. As such, whatever licence is used, it is essential for manufacturers to incentivises manufacturers to give back to the open project.

A key incentive for giving back to an open project is the same incentive for open design: collaboration. But collaboration requires a social contract built upon trust (Bacon 2012). Establishing governance of the project is one way to build that trust (O’Mahony and Ferraro 2007). This is particularly important for projects that start in academia or other research institutions that will not be able to guarantee active stewardship for the project long term.

Liabilities and dangers of an unfinished design

A major concern for groups designing hardware for COVID response has been liability. While most open hardware licenses like the CERN OHL (CERN 2020) disclaim liability to the greatest extent permissible by law, it is impossible to guarantee that all liability in all jurisdictions is waived. This uncertainty about liability is outside the expertise of most engineers who are designing medical hardware. For open source software there are numerous foundations that are able to advise projects on legal issues (Mackintosh 2018). As open hardware is much less well-established, similar foundations do not exist. This uncertainty leads projects to adopt an OWR approach. However, if the liability concerns are never resolved to the satisfaction of all designers and their employers, the project may never become open. This can lead to projects either stalling or taking a different approach with their intellectual property. This is particularly problematic if projects have already announced themselves as an open project, or accepted money and in-kind contributions on the understanding that results will be released openly.

There are two main groups of liability concerns. Firstly, that unqualified producers could manufacture substandard, untested products using a prototype design. If this untested product is used it is possible that an affected patient may bring a claim against the designers, even if they did not endorse the product. Secondly, that a design flaw may be discovered in an accredited medical device using the open design and the original designers could be held liable. This second case is less likely, however, as an accredited medical device manufacturer is very likely to either certify and assume liability for the open design, or contract with the designers directly to form a relationship that defines liability and responsibility for maintaining the design.

Traditional intellectual property licensing agreements can use indemnity clauses and requirements for licensees to procure insurance to mitigate risk. Such requirements would require writing new licenses, and would make designs under these licenses incompatible with other open hardware designs. Also, these licenses may not adhere to the open source definition due to the additional contractual burdens.

It is our understanding (as authors with no legal background) that a project can mitigate risk by clearly stating that the design provided is a prototype and should not be used as a medical device. Licenses allow these statements to be added in a Notices file. For clarity we would also recommend including them prominently in all documentation. This makes it clear that the purpose of the source release is collaboration, not providing a design for general use. Medical device manufacturers can still use the design for a product once they have done the work necessary for certification. Some residual risk does however still remain with the designers. We would encourage governments to clarify the liability of a designer of an open source design, as this uncertainty damages our ability to collaborate in times of crisis.

It is worth noting that the open license does not preclude a manufacturer entering into a contract with the original designer which can involve clauses for indemnity and insurance. The open license, however, ensures that any competent manufacturer is free use the design without further negotiation. This is particularly important if the original designers do not have the bandwidth to work with every interested manufacturer. The manufacturer will still need the necessary skills to understand the design, to set up production, and to pass regulatory approval in their jurisdiction.

Manufacturers and infrastructure

A large part of the effort involved in setting up medical device production is establishing a quality management system for the design and manufacture of a product. This infrastructure typically takes a year or more to establish, and is rarely found in makerspaces or small businesses that are sufficiently agile to re-purpose their facilities to produce products needed in an emergency. If open designs for critical medical supplies in a pandemic are available, it is crucial that local manufacturers have the expertise to manufacture them to a quality standard appropriate to safety-critical medical devices. High-income countries generally have well developed manufacturing sectors, producing complex high-value goods including medical devices, and so are reasonably well placed to ramp up production. However, the lack of infrastructure is particularly acute in LMICs. This is compounded by imported devices and components suddenly becoming unavailable as foreign governments focus on their immediate domestic needs (Iyengar et al. 2020). Our view is that it is essential to support the establishment of higher-value manufacturing—including regulated and quality-managed products like medical devices—in LMICs. This will ensure that the capability to manufacture high quality medical goods is available when it is needed. Our hope is that open designs, and openly shared documentation of assembly, testing, and quality management processes, can help to develop this much needed capacity in currently underserved parts of the world.

Conclusion

Engineers from many universities and companies dedicated a significant amount of effort to developing open source ventilators. However, a lack of clarity about liability and institutional policy has driven a large amount of this ‘open’ engineering effort to happen behind closed doors. This had led to many groups duplicating effort working on similar designs. This, coupled with a regulatory framework that is not able to handle distributed design and manufacture, has severely limited the effectiveness of these engineering efforts. A number of developments are needed if we are to be better prepared to handle future pandemics. Governments must provide clarity on the limits to the liability of individual contributors to an open design. Universities need clear policies and support for staff to engage in open design. Regulators must consider how to streamline the process of accreditation for multiple manufacturers to produce the same proven design. Finally, it is essential that workflows are found that allow large distributed teams of engineers and manufacturers to work together on multiple versions of a design, each tailored to local resources and needs.

Acknowledgements

We would like thank Andrew Katz for his advice on balancing open hardware licencing with liability concerns. We would also like to thank members of the Africa Open Science and Hardware community (AfricaOSH), the Gathering for Open Science Hardware community (GOSH), and contributors to numerous COVID response projects, for many insightful discussions about the role of open design.

Disclosure statement

The authors co-founded OpenFlexure Industries, a micro-business that sells open source hardware.

Additional information

Funding

We would like to acknowledge financial support from EPSRC (EP/P029426/1, EP/R013969/1), and the Royal Society (URF\R1\180153).

Notes on contributors

Julian Stirling

Julian Stirling is a Research Associate at the University of Bath. His research focuses on co-developing scientific equipment with partners in the Global South, and ensuring the equipment can be produced at high quality in a distributed fashion.

Richard Bowman

Richard Bowman is a Royal Society University Research Fellow and Proleptic Lecturer at the University of Bath. He leads the OpenFlexure project, which includes an open source microscope that is produced in Tanzania and the UK, aimed at research and diagnostic use.