MedicalUX & Human Factors

How design reviews play an essential role in medical device development

Product development is a complex process that involves making a multitude of decisions and choices, with all the potential for error 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:

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.

End-of-phase reviews

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.

CLEIO 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:
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 CLEIO team created a template that contains the following sections and fields:

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 CLEIO’s expertise to develop an ophthalmic diagnostic tool. Since the product included a circuit board with around 20 complex functionalities, CLEIO 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!

Assessment of the design reviews on the project

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.

Author & collaborators

Written by
Laurent

Newsletter & Monthly Digest

Subscribe to get our insights delivered to your email inbox.

Other posts you may like

Product Development

Keys to Successful Medical Device Development: Navigating Challenges and Regulations

Product Development

From Idea to Prototype: Why Adopt Iterative Design Process

Events

LSI USA ’24: we’ll be there!

Product Development

Keys to Successful Medical Device Development: Navigating Challenges and Regulations

Product Development

From Idea to Prototype: Why Adopt Iterative Design Process