A structured, well-documented design review process is a critical component of successful product development, particularly in the medical device industry. This blog provides a comprehensive overview of key considerations for planning and executing effective design reviews throughout the product development lifecycle.

Medical device development projects must conduct design reviews to comply with regulatory requirements. They are highly valuable to ensure the final product meets the intended business needs and technical specifications. Engineering and QA/RA experts provide their tips and insights on the Who, What, Why and When of Design Reviews with a focus on ensuring the final product meets the intended needs and specifications.

TL;DR

• Design reviews mitigate risk and align teams across development
• Tailor review scope and participants to the review’s objective
• Conduct reviews early and often to avoid costly rework
• Gate reviews enable informed go/no-go decisions
• Documenting reviews improves compliance and knowledge transfer

Why?

The overarching “why” of reviews is to collaboratively understand current status and make risk informed decisions to move forward (or not) before committing additional resources. Gaining alignment at key design and program points along the way is a fundamental part of the development process. Design reviews can range from informal, ad-hoc peer reviews to more formal, structured reviews at various stages of the development process.

It is important to align review content and participants with the specific objectives, whether they are technical, programmatic, or focused on client requirements; the ‘what’, ’who’ and the ’when’ will depend on the specific purpose of each review, whether the review is a very detailed technical or a higher-level program review.

What to review?

The “what” of the design review must be clearly defined, as objectives can vary greatly depending on the stage of development. For example, early-stage detailed technical reviews may focus on confirming the design intent and concept, while later-stage technical reviews may assess the detailed design and readiness for production. Program level stage gate reviews evaluate technology readiness along with the product’s ability to meet business and regulatory requirements. Tailoring meeting content and participants to the specific objectives is crucial.

Who to Invite?

The “who” of a design review is crucial and should include stakeholders with influence on the design or device, those who can speak for users, and the client. This is particularly important at key milestones.

The who must connect with the what. Tailor meeting content to the audience and objective of the review. In general, whoever owns the deliverable should attend. Stakeholders that have influence on the design, device or system should also participate. The specific titles and roles will vary depending on the type of design review.

Include technical leads from disciplines such as mechanical, industrial, and electrical engineering to ensure cross-functional alignment. Also include an independent subject matter expert to help remove bias from the design team or others associated with the project. Invite at least one, and sometimes multiple, independent reviewers to sanity check and pressure test assumptions and identify potential technical and programmatic pitfalls.

Principal Engineers are excellent independent reviewers. A principal engineer asks good questions and has lots of experience finding issues – both technical and programmatic and can help ensure the design meets the intended needs and specifications.

Look downstream past design towards manufacturing and include people that will make and produce the device for mass production or a limited run. Manufacturing and supply chain representatives should assess the feasibility of producing the product design and regulatory experts should make sure the device design will meet regulatory requirements and ensure compliance.

Design reviews provide the team with an opportunity to align their understanding of internal and/or external client needs amongst other requirements. There may be times to bring a client in at a lower-level review on a case-by-case basis depending on their expertise and day-to-day involvement in the project. When clients collaborate on design work and co-develop a device it is important to hold cross-organizational design reviews that include their collaboration feedback. While the client may not need to be present at every review, it is crucial to align with their requirements and incorporate their feedback throughout the development process.

A phase gate review is an opportunity to engage a set of stakeholders broader than the people that interface on the project on a regular (daily or weekly) basis. This review becomes an opportunity to align on a higher level with decision makers. Low-level details aren’t typically reviewed in this type of meeting.

“When” is an important design review “W”?

The “when” of the design review is a critical consideration, as reviews should be scheduled at strategic points to identify and mitigate risks before committing significant resources. “When” couples with “why” trigger points; hold a review before any significant activity that has risk to it, like ordering parts and building or testing something before moving to the next phase of development. This type of review is about derisking activities prior to initiation.

Design reviews should be conducted “early and often” at lower levels, followed by more strategic, higher-level reviews at key milestones. This allows for frequent alignment and course correction, reducing the cost and time associated with rework.

Hold concept reviews to confirm the goal and intent of the design, as well as to get alignment on proposed design direction. Be relatively informal and don’t take up a lot of time. Check in and make sure there is alignment because things often change.

Schedule a detailed review at the end of a design stage to confirm the device meets core needs. Is the technology feasible and economically viable? Does it meet user needs? Is it ready to produce and fit together?

What happens to the results of detailed lower-level technical reviews? Individual reviews usually sit in isolation until the system level technical review. That’s when the team looks at the individual review results and makes a conclusion or recommendation collectively.

Hold gate reviews at the end of key program stages. These allow the team to summarize key outputs from lower-level reviews, and along with business and regulatory considerations, evaluate the products readiness to move to the next stage of development. Passing a gate review is the milestone required to commit to additional resources needed to mature the product toward commercialization.

It is important not to skip or ignore the benefit of gate reviews. The cost of rework grows exponentially the further down the development path you are; aligning program and product requirements at key stages helps avoid costly pivots and rework.

Design Reviews and System Development Process

The system development process starts at a high level and at some point, gets to a detailed design that integrates the components together. To do that without any reviews almost ensures issues will arise. Nothing is going to come together if it is not collaboratively reviewed along the way.

There should be a progression of design reviews, from the initial concept reviews to detailed, component-level technical reviews, and ultimately to system-level reviews that assess the integration and overall functionality of the product. Conduct these reviews in a systematic manner, with each review building upon the insights and decisions made in previous reviews.

At each milestone, include an element of looking back at what has been done to understand where the project is, as well as looking ahead to decide if the project is ready to move forward.

Cycles of review from lower level to the top should be more frequent than the physical iterations of the system. Fit more reviews per cycle to help reduce the number of prototypes needed for overall system development. It’s a lot cheaper to conduct a design review than it is to order, build, test, and then realize the design/part doesn’t work, and you will have to order, build and test again.

Documentation and Compliance

Document the design review process and treat it as more than just a compliance requirement. Capturing the insights and decisions made during the reviews provide, information to leverage for future projects and ensure continuity in the development process.

Related Resources