MedCity Influencers

How to run effective medical device design reviews

Design Reviews are intended to be checkpoints in a medical device product development to ensure the product design is safe, effective, and progressing. Design Reviews are also a way to ensure Design Controls are being captured and documented throughout the project. But I’ve worked on plenty of medical device projects when Design Reviews seemed like […]

Design Reviews are intended to be checkpoints in a medical device product development to ensure the product design is safe, effective, and progressing.

Design Reviews are also a way to ensure Design Controls are being captured and documented throughout the project.

But I’ve worked on plenty of medical device projects when Design Reviews seemed like a waste of time and only held to satisfy a check box.

Still as a product development engineer back in the day, I looked forward to Design Reviews.

Why?

Design Reviews represented a time in my projects when we were one step closer to getting into production and the market. I would be sure to invite the affected functions and be prepared. I was ready to show the progress our team had made and get the approval to move forward.

However, my ideal Design Review rarely worked out the way I had imagined. And it took me a few Design Reviews to put my finger on why.

sponsored content

A Deep-dive Into Specialty Pharma

A specialty drug is a class of prescription medications used to treat complex, chronic or rare medical conditions. Although this classification was originally intended to define the treatment of rare, also termed “orphan” diseases, affecting fewer than 200,000 people in the US, more recently, specialty drugs have emerged as the cornerstone of treatment for chronic and complex diseases such as cancer, autoimmune conditions, diabetes, hepatitis C, and HIV/AIDS.

  • The company did not fully appreciate and understand Design Controls and Design Reviews.
  • I invited too many people and sometimes the wrong people.
  • I tried to cram too much into Design Reviews.
  • I thought I was prepared but did a poor job communicating to attendees of the Design Review agenda, purpose, and goal.
  • I expected Design Review attendees to be as knowledgeable about my medical device project as I was.

Fortunately, I had the chance to learn these lessons quickly and was able to ensure more successful and meaningful Design Reviews for the rest of my medical device product development career.

 

Design Controls Process Is Not Same As Product Development Process

In my experience, there is a great deal of confusion about Design Controls process and product development process. The confusion in many companies is that Design Controls is interpreted to be synonymous with product development. But this is not the case. Design Controls “sits” within product development.

 

What Does This Have To Do With Design Reviews?

If a company does not understand the separation between Design Controls and product development, this confusion makes Design Reviews complicated too. Why? A typical product development process consists of project phases or stages. Design Controls and its deliverables do fit within specific project phases. But remember, Design Controls are objective evidence to prove your medical device design is appropriate, safe, and effective. When there is confusion about Design Controls and product development, Design Reviews are used as phase “gates”, meaning the Design Review is used as a means to proceed to the next project phase.

It can be confusing.

Design Reviews are intended to be formal documented reviews of medical device design and development results and should be planned and conducted at appropriate stages within the Design Controls process. Design Reviews need to include the right people to objectively ensure that the medical device design and development appropriate.

 

What Are Design Reviews?

Let me share with you what FDA regulations state about Design Review from 820.30(e):

Each manufacturer shall establish and maintain procedures to ensure that formal documented reviews of the design results are planned and conducted at appropriate stages of the device’s design development. The procedures shall ensure that participants at each design review include representatives of all functions concerned with the design stage being reviewed and an individual(s) who does not have direct responsibility for the design stage being reviewed, as well as any specialists needed. The results of a design review, including identification of the design, the date, and the individual(s) performing the review, shall be documented in the design history file (the DHF).

And ISO 13485:2003 in section 7.3.4 Design and Development Review:

At suitable stages, systematic reviews of design and development shall be performed in accordance with planned arrangements (see 7.3.1)

a) to evaluate the ability of the results of design and development to meet requirements, and

b) to identify any problems and propose necessary actions.

Participants in such reviews shall included representatives of functions concerned with the design and development stage(s) being reviewed, as well as other specialist personnel (see 5.5.1 and 6.2.1).

Records of the results of the reviews and any necessary actions shall be maintained (see 4.2.4).

FDA and ISO are very similar on the topic of Design Reviews. The one notable difference is that FDA specifies the need for an “independent reviewer” as a Design Review attendee.

 

When Should Design Reviews Happen?

All Design Controls–User Needs, Design Plan, Design Inputs, Design Outputs, Design Verification, and Design Validation–need to be part of Design Reviews.

As far as when you have Design Reviews, the fuzzy answer is that is depends on the project. If you take the FDA Design Controls waterfall diagram shown above literally, a Design Review should happen when each step in the Design Controls process is completed. This may or may not be practical.

When you draft your Design Plan, this is the time to define when Design Reviews should take place. Can you have too many Design Reviews in a project? To say it another way, should you take the FDA waterfall literally? That’s a tough one. If you have any questions about when to conduct Design Reviews, I would say there is no harm in having as many as possible during a project. Design Reviews are key moments in a product development project where you can communicate status and issues of design and development.

Some may even say that medical device companies are too lax with respect to Design Reviews. Here is a link to an interesting article from Cerulean LLC: “FDA, Experts Weigh in on Industry with Design Input, Design Output Activities”.

The article has some good insights. I found this quote particularly interesting on the topic of Design Reviews:

“Firms have available to them the very valuable tool of design review within their quality management systems,” said Jan Welch, Deputy Director of Regulatory Affairs in CDRH’s Office of Compliance. “To the extent that design inputs are inappropriate, unachievable, poorly characterized or not documented, the design review process should identify these concerns and flag them for resolution prior to the next design steps. The same holds true for design outputs.”

 

 Design Reviews Should Have a Purpose

As the quote from the article cited above illustrates, Design Reviews should identify design and development concerns. While the quote is specific to Design Inputs and Design Outputs, realize Design Reviews serve the same purpose for ALL Design Controls.

 

Improve Efficiency with Design Reviews

I shared in the opening of this post that early on in my career I had a few not so pleasant and not so productive moments with Design Reviews. Is there anything you can do to make sure your Design Reviews are meaningful and efficient?

Yes!

 

Here is a list of a few things you can do to improve your Design Reviews:

 

Strive to Keep Design Reviews to 1 Hour

To do this, you will need to be very aware of the Design Controls you plan to cover in Design Reviews. This may mean you have to have quite a few Design Reviews during your project. It may mean that some Design Controls, such as Design Inputs, may need to be split into multiple Design Reviews.

This may seem to be quite the opposite of efficiency. But if you try to cram too much into a single Design Review, then you will defeat the purpose.

Also, really try to stick to the one hour timeframe. Any longer, and you’re likely to lose a good part of your audience.

 

Be Prepared In Advance

Share all the documentation and information to be discussed during the Design Review with the attendees prior to the Design Review. The ideal amount of time to do this is about a week in advance, and no less than 3 business days.

Contact all intended attendees a day or two in advance of the Design Review. See what questions or comments they have and make notes. On the day of the Design Review, lead off the discussion with the comments and notes you gathered in advance.

Prepare an agenda for your Design Review. Stick to the agenda too! Don’t let sidebar discussions happen. If things come up that are outside the scope of the Design Review, make a note of it and get the discussion back on track.

 

Have a Design Review Form & Checklist

The whole purpose of Design Reviews is to ensure the design and development is safe, effective, and appropriate. You are reviewing specific Design Controls. You want attendees to communicate and raise any issues or concerns. Your agenda will help guide you through the Design Review. You may also want to have a checklist prepared too, in order to make sure all required aspects are covered.

And definitely document the event on a Design Review form. At a minimum, you need to capture the topics discussed, documents reviewed, any action items identified, and list of attendees.

 

Close the Loop

During Design Reviews, there will be action items identified. It’s very easy to capture these on your Design Review form. But it’s also very easy to forget about closing these action items out after the Design Review. This is a big no-no. Always close the loop for all action items.

 

Topics