1. Purpose of the gate
Quality system regulations require design verification to confirm that design outputs meet design inputs, with the results documented in the design history file. This gate is the design review that accepts that evidence as a whole. Individual test reports may already have been reviewed; here the question is whether together they cover every input, and whether the design is fit to move into validation.
The risk management file closes a large part of its loop at this gate. ISO 14971 expects each risk control to be verified for implementation, that it is really in the design, and for effectiveness, that it reduces the risk as intended. The risk control verification record lists each control with its evidence. The hardware failure modes and effects analysis is finalised with the verified design.
The trace matrix is the reviewers' main tool. It should run from user needs through design inputs, design outputs and risk controls to verification results, and it should be generated from the tools rather than compiled by hand, so that a reviewer can pick any item and follow it through.
The review also checks that verification is ready to support the submission. Each report the submission will cite should be approved and filed, and the trace matrix should be exportable in a form the regulatory team can use. Where a chip supplier provides evidence the device team relies on, such as characterisation data or a reliability report for a custom analog front end, the review confirms the device team has assessed it rather than accepted it unseen, and that the quality agreement covers how changes to that evidence will be notified. Reviewers also look at deviations accepted during verification as a set: several small deviations against the same input can together point to a design weakness that validation is likely to expose.
10 more sections for registered members.