After validation, quality runs the final design review. The team confirms that verification and validation are complete, residual risk is acceptable, and the release build and its labeling are ready to be handed to production. For software, design transfer means the build, installation instructions and labeling move under release control. Quality then audits the design history file against the development plan and collects the approval signatures, including the truthful and accurate statement for the submission.
On the map: Final design review as design transfer. DHF completeness audit. Signatures.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Use the final design review as the gate where regulatory, engineering and clinical confirm one version, one document set and signed approvals before the eSTAR is assembled.
Representatives of every function that worked on the design, plus at least one reviewer with no direct responsibility for the work under review. In a small team the independent reviewer may be a colleague who was not involved in the activities being reviewed, or an outside consultant.
Walk the development plan deliverable by deliverable and confirm each record exists, is the approved revision, and refers to the same software version. Mismatched version numbers and unsigned documents are the usual findings.
Treat the archived build, the installation procedure, the release checklist and the labeling as the production specifications. Confirm they are reviewed and approved, and that only the approved build can be shipped.
Only if they do not change the submitted content or the risk conclusion. Each open item is recorded with an owner and tracked under change control, so the submission and the design history file stay consistent.
See the open positions and apply.