Design Stage Checklists
Design Review Checklist
Verify design completeness and readiness for verification through systematic review criteria and evaluation.
Summary
The Design Review Checklist verifies that your medical device design is complete and ready for transition to verification and validation. This systematic review ensures all design inputs are properly implemented, user needs are addressed, and risk controls are incorporated before proceeding to testing phases.Why is Design Review Checklist important?
Design review serves as a critical quality gate between design and verification phases. Regulators require evidence that your design process was systematic and complete before you begin testing. This checkpoint prevents costly rework by identifying missing requirements, incomplete designs, or inadequate risk controls early. The checklist provides objective criteria to demonstrate that your design outputs meet all inputs and are ready for validation, ensuring regulatory compliance and reducing development risks.Regulatory Context
Under 21 CFR Part 820.30 (Design Controls):
- Design review is mandatory before verification activities (Section 820.30(e))
- Must verify design outputs meet design inputs and user needs
- Review must be conducted by qualified individuals not directly responsible for the design
- Documented evidence of review completion is required
- Design controls apply to all Class II and III devices and most Class I devices
Special attention required for:
- Software medical devices (FDA Guidance on Software as Medical Device)
- Design input validation against user needs and intended use
- Risk management integration per ISO 14971
- Traceability between user needs, design inputs, and design outputs
Guide
Your design review checklist systematically evaluates three critical areas to ensure regulatory compliance and design completeness.General Design Review
The primary checklist verifies fundamental design control requirements. Each user need must have traceable identifiers linking to design inputs and outputs. Your user needs should address all stakeholder requirements including patients, healthcare providers, and regulatory bodies. Verify that user needs consider intended use comprehensively, covering normal operation, reasonably foreseeable misuse, and environmental conditions. Design inputs must align precisely with user needs while incorporating applicable standards and regulatory requirements. Your product design should demonstrate manufacturability through detailed specifications, assembly instructions, and process controls. Most critically, verify that risk control measures identified in your risk management process are properly integrated into the design rather than relying solely on protective measures or information for safety.Software Architecture Review
For software medical devices, conduct additional verification focusing on requirements implementation and safety classification. Ensure your software architecture implements all system and software requirements with clear traceability. Each software system must have determined safety classification following IEC 62304 standards. Document all software items and interfaces comprehensively, including data flows, communication protocols, and integration points. Verify that interfaces between software items and with hardware are properly specified and supported. For Software of Unknown Provenance (SOUP), ensure your architecture supports proper operation and integration with documented version control and risk assessments. Confirm that your software architecture is implementable with available resources, considering development team capabilities, timeline constraints, and technical infrastructure requirements.Physical Product Review
Hardware components require verification of design schematics completeness ensuring all electrical, mechanical, and assembly drawings meet specified requirements. Material selection must demonstrate biocompatibility through appropriate testing per ISO 10993 series and durability validation for intended use duration. Your design must address comprehensive safety factors including electromagnetic compatibility (EMC), electrical safety, mechanical integrity, and environmental resilience. Even software-only devices often require EMC consideration for deployment hardware. Packaging and shelf-life design must comply with sterility requirements (if applicable), environmental protection needs, and labeling regulations while supporting the intended product lifecycle.Example
Scenario
You are reviewing the design of a mobile ECG monitoring app with a connected hardware sensor before proceeding to verification testing. Your team has completed user needs analysis, system requirements, software architecture, and hardware design. The design review ensures all components are ready for validation.Example Design Review Checklist
ID: DRC-001-ECG-Monitor Purpose: This checklist verifies that the ECG monitoring system design is confirmed and design inputs were properly generated based on user needs. Scope: This checklist applies to the Mobile ECG Monitor System including mobile application and sensor hardware. Design Review Checklist| Checklist Items | Yes/No | Justification if No |
|---|---|---|
| Each user need has an identifiable number for traceability. | Yes | User needs UN-001 through UN-015 all assigned unique identifiers |
| The user needs address all relevant stakeholder requirements. | Yes | Requirements from cardiologists, patients, and IT administrators captured |
| The user needs take into consideration all relevant aspects of intended use. | Yes | Includes home monitoring, clinical review, and emergency detection scenarios |
| The user needs include all necessary organizational, technical, or other requirements. | Yes | HIPAA compliance, FDA cybersecurity, and clinical workflow requirements included |
| The user needs are not ambiguous, self-contradicting or conflicting with each other. | Yes | Requirements review identified and resolved three conflicts in version 2.0 |
| Design inputs align with user needs, intended use, and regulatory requirements. | Yes | Traceability matrix demonstrates complete alignment with 21 CFR 820.30 |
| Product design can be manufactured, assembled, and tested. | Yes | Manufacturing partner confirmed feasibility and provided cost estimates |
| Risk control measures have been incorporated into the design, if applicable. | Yes | Implemented encryption, signal validation algorithms, and fail-safe mechanisms |
| Criteria | Yes/No | Comments |
|---|---|---|
| The software architecture implements all system and software requirements. | Yes | Architecture review confirmed coverage of SRS-001 through SRS-087 |
| All software systems are listed and their respective safety class has been determined. | Yes | Mobile app: Class B, Cloud backend: Class A, Sensor firmware: Class B |
| All software items are listed and described, including interfaces. | Yes | 12 software items documented with API specifications and data schemas |
| The software architecture supports interfaces between software items and between software items and hardware. | Yes | Bluetooth LE, HTTPS REST APIs, and USB interfaces fully specified |
| The architecture supports proper operation of any SOUP items, as needed. | Yes | React Native, AWS services, and encryption libraries properly integrated |
| The software architecture can be implemented with resources provided by the manufacturer. | Yes | Development team skills assessed, AWS infrastructure capacity confirmed |
| Checklist Items | Yes/No | Justification if No |
|---|---|---|
| Design and assembly schematics of the product are complete and meet requirements. | Yes | Electrical schematics, PCB layout, and enclosure drawings approved by engineering |
| Material selection meets biocompatibility and durability needs. | Yes | Medical-grade silicone tested per ISO 10993-5, ABS plastic for 5-year lifecycle |
| Physical, environmental, performance, and safety factors have been considered in the design. | Yes | IP65 rating for water resistance, drop testing specifications, EMC compliance plan |
| Design follows Electromagnetic Compatibility (EMC), safety, and environmental compliance, if applicable. | Yes | Pre-compliance testing completed, formal EMC testing scheduled before release |
| Design of packaging and shelf-life is compliant with product and regulatory requirements. | Yes | 24-month shelf life validated, packaging includes all required labeling elements |
Q&A
How can user needs be documented to ensure they are comprehensive for design review?
How can user needs be documented to ensure they are comprehensive for design review?
User needs should be documented as high-level requirements that capture essential product functions while remaining flexible enough to accommodate future changes. Document needs that cover basic functions, performance expectations, and regulatory requirements. Ensure each need has a unique identifier for traceability and addresses all relevant stakeholders including end users, healthcare providers, and regulatory requirements. If user needs are incomplete during design review, they can be updated, which will lead to new system and software requirements.
How should system requirements be structured to pass design review?
How should system requirements be structured to pass design review?
System requirements should be more granular than user needs but remain objective and testable. They should translate user needs into specific, measurable design criteria that can be verified through testing. Requirements should be flexible enough to allow design evolution while maintaining traceability. Focus on covering all intended software and hardware functions comprehensively rather than being overly technical in specification.
What should be done if the design review identifies missing or incomplete requirements?
What should be done if the design review identifies missing or incomplete requirements?
If the design review reveals gaps, update the relevant requirements documents before proceeding to verification. This may require revising user needs, system requirements, or software requirements. Document all changes in your change control process and update traceability matrices. It’s acceptable and preferable to revise requirements before certification rather than discovering gaps during testing or regulatory review.
How should software architecture be documented to demonstrate regulatory compliance during design review?
How should software architecture be documented to demonstrate regulatory compliance during design review?
Software architecture documentation should demonstrate complete implementation of all system and software requirements with clear traceability. Document all software items, their interfaces, safety classifications per IEC 62304, and integration with any Software of Unknown Provenance (SOUP). Include data flow diagrams, interface specifications, and evidence that the architecture is implementable with available resources and timeline constraints.
What constitutes adequate risk control measure integration in design?
What constitutes adequate risk control measure integration in design?
Risk control measures should be designed into the product rather than relying primarily on protective measures or user information. During design review, verify that identified risks from your risk management process have corresponding design controls implemented. Examples include fail-safe mechanisms, input validation, encryption for cybersecurity risks, and physical safeguards. Document how each risk control measure is integrated into the design specification.
How should design review checklist findings be documented and managed?
How should design review checklist findings be documented and managed?
Document all design review findings with clear identification of any “No” responses and their justifications. Strong justifications should demonstrate why the finding doesn’t prevent proceeding to verification or how alternative measures address the concern. Track any required corrective actions through your change management process and ensure all findings are resolved before final design approval. Maintain review records as evidence of design control compliance.