Product development is a complex process that involves making a multitude of decisions and choices, with all the potential for error that that entails. Given that, it’s not surprising that organizations like the FDA or the ISO 13485 standard require medical product designers to build design reviews into their development process. After all, it’s still the best way to ensure that your products are safe, reliable, and effective (and also stay on time and on budget)!
But first, what is a design review?
A design review is an evaluation of part of a product by a group of reviewers. The reviewers take a critical look at what has been done and the decisions that have been made during the development, and voice their concerns. They identify existing and potential problems, discuss the best ways to address them, and develop a plan to implement corrective actions.
According to the Design Control Guidance for Medical Device Manufacturers document from the FDA, design reviews are primarily intended to:
- Provide a systematic assessment of the development results, including the device design, the associated designs for production and the support processes
- Assess project progress
- Provide feedback to designers on existing or emerging problems
- Provide confirmation that the project is ready to move on to the next stage of development
In short, design reviews are a kind of safety net for catching mistakes that could derail the project’s budget and schedule, or even compromise the product itself, as early as possible.
How often should I do a design review? And when?
Arguably, the right answer is “whenever you need to”. That’s not a very helpful response, but the truth is that there is no ideal frequency for conducting design reviews. It depends on the project and how complex it is.
For a very simple project, a single design review may be sufficient. For more complex projects, design reviews could be slated for the end of each milestone, to validate the basics of the design before moving on to the next steps.
At CLEIO, to make sure that design reviews are embedded into our product development process, we have defined a few steps and elements that need design reviews:
Design Reviews
Allows the team to verify any part of the development process in any phase.
Les revues de fin de phases
Allows the team to verify that all design reviews and deliverables have been completed in the current phase and that we can proceed to the next phase of our IDEAL process.
Who should be involved?
Choosing the right people for each design review is almost as important as choosing the right product development team. Of course, the people who designed the part of the product under review should participate in the review. They are in the best position to explain what they did, their approach, the decisions they made, and so on.
But remember when we told you in our co-creation article about how important it is to have an outside perspective when developing your product? Well, the same goes for design reviews. At least one external person should participate, which is also one of the FDA and ISO 13485 requirements for design reviews.
When we say an external person, that could be a consultant from outside the company or someone on the development team who’s not working directly on the part of the project being evaluated. What matters is that they have technical skills and experience that rival (or ideally, exceed) those of the designers, and that they are sufficiently independent to express their concerns freely.
NOVO further exceeds the regulatory requirements by also bringing a member of its Quality Assurance team on as a reviewer. That way, we can be confident that we have people on board with a higher-level and outside perspective, while still ensuring that the design reviews are conducted properly and rigorously. Besides, it’s always good for the QA team to have an in-depth knowledge of the product development progress.
What does a design review look like in practice?
There are no hard-and-fast rules for conducting design reviews. Depending on the complexity of the part that is being evaluated, they can involve a varying number of people and take several forms:
Team meetings to present and review the design
Independent review of the materials by each reviewer
Feature testing
However, what matters most is that you pinpoint the objective of the design review and what part of the project it should focus on. For example, depending on where it falls in the development process, a design review could be used to verify whether or not:
- The user needs or design inputs are well defined
- The design meets the product specifications and enables the product to meet the target efficacy and reliability objectives
- Opportunities exist to improve the design or even the development process itself
- Safety issues have been addressed
Once the objective is well defined, it must also be clearly communicated to the various reviewers to steer the design review in the right direction. Also, don’t forget to send them advance copies of all the documentation and information they’ll need during the review so that they have time to prepare properly. And since a picture is worth a thousand words, don’t be shy about using visual aids (graphics, images, etc.) if the review is conducted in meeting format.
How reviews are documented
Although the FDA and ISO 13485 require designers to document their design reviews, they don’t impose a standard document format. Essentially, they ask that the documentation provide general information about the reviews (date, participants, etc.), as well as describe the problems or questions that were raised, the decisions that were made to address them, and how the corrective actions should be implemented.
To make sure that nothing gets forgotten when documenting their design reviews, the NOVO team created a template that contains the following sections and fields:
- Identifying information about the product or project
- Date of the design review and its duration, if applicable
- Names of all the participants, including the independent reviewer
- Objectives of the design review
- Minutes of the discussion
- Actions to be taken, including who is responsible and the date by which they must be completed
- References for the documents presented (presentations, images, reports and other assets)
CLEIO doesn’t just document each design review. Our Quality Assurance team also keeps track of all the documents related to the product design, as well as their location in the Design History File (DHF) Index, which acts as a sort of table of contents for the project.
Doing so allows us to assemble everything in one place and quickly locate development-related documents, which is very useful when putting together the product design folder for the FDA.
How design reviews can make a real difference: the case of BJ Nimo DragonVision
At CLEIO, we sometimes make mistakes. We’re human, after all. But we pride ourselves on having a process that leaves ample space for design reviews, allowing us to catch those mistakes before they can have nasty consequences like delays or cost overruns.
On the BJ Nimo DragonVision project, we saw firsthand how important it is to have a rigorous design review process that truly works!
Ongoing design reviews
BJ Nimo sought out NOVO’s expertise to develop an ophthalmic diagnostic tool. Since the product included a circuit board with around 20 complex functionalities, NOVO quickly realized that design reviews would need to be conducted throughout the development process. In fact, they would have to be almost constant, since the product required approval from the NMPA.
A small mistake that could have thrown a wrench in the schedule
Sometimes little things can have big consequences. On the BJ Nimo DragonVision project, that little thing was a cable that was reversing the sequence of the signals between the circuit board and LCD. The reviewers quickly spotted the error during a design review that was intended to ensure that the product’s various components would be optimally arranged during assembly.
Since it was discovered at that point in the process, before the prototype was produced, the mistake was fixed in no time. It was a good thing too, because the project was already on a very tight schedule. Without that design review, we would have had to add a custom adapter or revise the board, both of which would have delayed production of the final product by several weeks. And we couldn’t afford that!
Bilan des revues de conception sur le projet
0
design reviews
conducted over the 9 months of the product’s beta development
0 +
anomalies or irregularities
found and suggestions made to address them
Proof that design reviews have a role to play
A hundred anomalies could give the impression that something was wrong with the product development process that CLEIO put in place. It’s just the opposite!
Above all, it shows that it gives our designers the peace of mind to push boundaries and take risks, while still being agile enough to do so without jeopardizing the final product, budget, or schedule.
As proof, despite the BJ Nimo DragonVision project’s complexity and tight schedule, the first version of the prototype was fully functional — thanks in large part to the design reviews.
