The waterfall methodology is ubiquitous in medical device design and development. It is straightforward, easy to understand, and appears to mirror exactly the format of the way regulations and standards are written. However, depending on the kind of device you are making, the waterfall method is not only inconvenient, it may not even bring you the best quality. So how do you move away from using it?
To move away from the waterfall method, you first have to understand what exactly the regulations and standards require you to do, and what is left up to you to define. Bearing in mind that regulations and standards want to ensure you build quality safe and effective devices, you can break down their intent into the following set of basic stages:
- Design and development planning – Activities and resources for development are planned.
- Design and development input – Goals of the design are established, such as user needs and requirement specifications.
- Design and development – Design and development is carried out according to the plan.
- Design reviews – Design reviews take place where designs are evaluated against the design and development input.
- Design and development output – Final accepted designs are documented.
- Design and development verification – The design and development output is evaluated against the design and development input.
- Design and development validation – The design is evaluated for its fitness for its intended and context of use.
- Design and development transfer – The design is transferred into production specifications.
- Risk management – Risk management activities are conducted at every stage of the project.
While domain language can differ between markets, the above provides a good basis to meet many regulations and international standards. It is then up to you, the manufacturer, as to how you implement them and to what detail. The following chapters outline a few different ways that you may configure the above design and development controls to meet your needs and those of the regulations.
Development Processes
Now that the stages of development are set out, you can then use these stages as building blocks that can be arranged the way that meets your needs. To do this, you have to understand the underlying development principals that regulations are trying to get across.
- Design and development on a component should not commence before its respective design and development input has been developed
- Design and development on a component should not commence before the planning for this activity has been defined (resources assigned, authority is clear, references to processes to use)
- The design and development verification on a component should not commence before the respective design and development output for that component has been defined.
- The design and development verification on a component should not commence before the planning for this activity has been defined (resources assigned, authority is clear, references to processes to use, verification tests and acceptance criteria defined)
- The design and development validation for a product should take place on a valid exemplar of the device (depending on what is being validated) has been defined (e.g. a 3D printed version may be acceptable for some usability validation studies, but perhaps not for transportation validation)
- The design and development validation for a product should not take place before the planning for this activity has been defined (resources assigned, authority is clear, references to processes to use, validation tests and acceptance criteria defined)
If you adhere to these principles, there are a wide range of different and novel approaches to development that you could use. Approaches such as Agile Development, Test Driven Development, Design Thinking or User Centered Design could all be addressed.
You can also make more than one approach available to projects. The project plan is a good place to reference the specific approach or approaches that is to be used for the project and clearly set out the concrete way in which this development project will use them.
Example: Iterative Waterfall Method
Below shows an example waterfall development process for a medical device which also incorporates stage-gates and freezes.
- First, all activities from the design and development input through to design and development validation are planned and clearly reference or describe the processes used. Only when this plan is accepted can design and development input begin.
- From there, the design and development input that covers the complete device, must be fully completed before design and development can begin.
- When design and development is complete (including the conducted design reviews as detailed in the project plan), and the design is in a format that can be verified, the project can move to design and development verification.
- If problems are found in design and development verification, the project can step back to either the design and development input or design and development, and then follow the process back to design and development verification. Only when design and development verification is complete, and the result is accepted, can the project move to design and development validation.
- Design and development validation activities are the conducted, and if the project needs to step back to update design and development input or design and development, it can but then needs to move through the process again to reach design and development validation.
If requirements are not well understood at the beginning, especially where new or novel technologies are being investigated, this method can be unduly rigid. It is not optimized for changes to the requirements specifications and can be inefficient as each stage must be completed in full before progressing.
To make the waterfall process more agile and efficient, it could be possible to break it down into smaller iterations as below:
Example: Rapid Prototyping
With the advancement of rapid prototyping technologies, manufacturers are finding that they can find issues with their medical devices earlier by producing prototypes of their design. In the below process, you could use rapid prototyping to produce a test article of the device and send this prototype to design and development verification. While not all aspects of the design might be able to be verified (especially those that are affected by the material), many other aspects could be tested. This is also true of initial design and development validation. In this case, the prototype might be used in early usability studies to gather some data on their fitness for use. Verification and validation activities using the prototype will need to have some sound reasoning for how applicable the results are to the final product if you do not intend to run all the tests again with a finished device.
Once the design has stabilized, the output can then be transferred to production. It is expected that this approach can help iron out as many problems with the design as possible in advance so that production development may not require so many development iterations. This could be helpful if outsourcing production as many iterations could be time-consuming and expensive.
Example: V-Model
Sometimes it can be useful to allow various components of the medical device to be able to advance to different stages of the design and development independently. In the below example, not all design and development input needs to be defined for the entire system at the beginning, instead only the product level design and development input is required. During the design and development process a subsystem architecture is formed which feeds into the design and development input of each identified subsystem. As each subsystem is being developed, an architecture for the various components that make up this subsystem is formed. This can iterate over as many levels as is needed through smaller and smaller assemblies, depending on the complexity of the device.
This model has advantages that not all aspects of the system must be known in advance. In this way a lot of development can be conducted in parallel and then verified at each layer as needed, picking up issues as early as possible.
