FDA Registration
Design History File
Compile comprehensive design control records demonstrating systematic development and regulatory compliance.
Summary
The Design History File (DHF) is a comprehensive compilation of records documenting the design and development of your medical device according to FDA design control requirements. It contains all design inputs, outputs, reviews, verification, validation, and design transfer activities, serving as evidence of systematic design control compliance under 21 CFR Part 820.30.Why is Design History File important?
The Design History File serves as the regulatory foundation for demonstrating FDA design control compliance and is essential for 510(k) submissions and PMA applications. It provides the FDA with complete evidence that your device was developed using systematic design controls, ensuring safety and effectiveness. The DHF is your primary defense during FDA inspections and demonstrates that your device meets all specified requirements. Without a properly maintained DHF, you cannot demonstrate design control compliance or obtain FDA clearance for most medical devices.Regulatory Context
Under 21 CFR Part 820.30 (Design Controls):- Mandatory for Class II and III devices and some Class I devices
- Must contain design inputs, outputs, reviews, verification, validation, and transfer
- Required for 510(k) submissions and PMA applications
- Must be maintained throughout device lifecycle and available for FDA inspection
Special attention required for:
- Software lifecycle documentation according to FDA software guidance
- Risk management integration throughout design process
- Design change control and impact assessment procedures
- Verification and validation evidence for all design outputs
Guide
Your Design History File must demonstrate systematic application of design controls throughout your device development process. The DHF serves as a comprehensive record that links design inputs through outputs, reviews, verification, validation, and transfer activities.Design Inputs Documentation
User Needs and Requirements: Document all user needs identified through stakeholder analysis, market research, and clinical input. Transform these into specific design inputs that are measurable, verifiable, and traceable. For software medical devices, include functional requirements, performance requirements, interface requirements, and safety requirements. Regulatory Requirements: Include all applicable FDA regulations, consensus standards, and guidance documents that apply to your device. Reference specific sections of 21 CFR Part 820, relevant FDA guidance documents, and applicable standards such as IEC 62304 for software or ISO 14971 for risk management. Risk Management Integration: Document how risk management activities inform design inputs. Include hazard analysis results, risk assessments, and risk control measures that drive specific design requirements. Demonstrate traceability from identified hazards to design inputs that address those risks.Design Outputs Documentation
Design Specifications: Document all design outputs including software specifications, architectural designs, interface specifications, and performance specifications. For software devices, include software requirements specifications, software architecture documents, and detailed design documents. Design Reviews: Maintain records of all design reviews conducted throughout development. Include review agendas, attendee lists, review findings, and resolution of identified issues. Demonstrate that reviews were conducted by qualified personnel not directly responsible for the design stage being reviewed. Verification and Validation: Document all verification activities that demonstrate design outputs meet design inputs, and validation activities that demonstrate the device meets user needs and intended use. Include test protocols, test reports, and evidence that all requirements have been verified and validated.Design Controls Implementation
Design Planning: Document your design control procedures and how they’re implemented throughout development. Include design planning documents, responsibility assignments, and resource allocation. Demonstrate that design controls are proportional to device risk and complexity. Design Changes: Maintain records of all design changes including change requests, impact assessments, approvals, and verification of change implementation. Demonstrate that changes are controlled and don’t adversely affect device safety or effectiveness. Design Transfer: Document design transfer activities that ensure design outputs are correctly translated into production specifications. Include manufacturing procedures, quality control measures, and evidence that production units meet design specifications.Software-Specific Documentation
Software Lifecycle Process: For software medical devices, document your software lifecycle process according to IEC 62304 or equivalent. Include software planning, requirements analysis, architectural design, detailed design, implementation, integration testing, and system testing. Software Risk Management: Document software risk management activities including software safety classification, hazard analysis, and risk control measures. Demonstrate how software risks are identified, analyzed, and controlled throughout the lifecycle. Software Verification and Validation: Include comprehensive software testing documentation including unit testing, integration testing, system testing, and user acceptance testing. Demonstrate that software meets all specified requirements and performs safely under normal and fault conditions.Example
Scenario
You’ve developed a Class II software application for remote patient monitoring that analyzes vital signs and alerts healthcare providers to abnormal patterns. You need to compile your Design History File for 510(k) submission to the FDA.Design History File Structure Example
1. Design Inputs User Needs Document: UN-001-2024- Healthcare providers need real-time patient monitoring
- System must detect abnormal vital sign patterns
- Alerts must be timely and actionable
- Interface must be intuitive for clinical workflow
- Monitor heart rate, blood pressure, temperature, oxygen saturation
- Detect abnormal patterns within 30 seconds
- Generate alerts with 95% sensitivity and 90% specificity
- Comply with HIPAA security requirements
- 21 CFR Part 820 (Quality System Regulation)
- IEC 62304 (Medical device software)
- ISO 14971 (Risk management)
- IEC 62366 (Usability engineering)
- 127 functional requirements covering all monitoring functions
- 45 performance requirements including response times
- 23 interface requirements for user interaction
- 34 safety requirements addressing identified risks
- Modular architecture with monitoring, analysis, and alert modules
- Database design for patient data storage
- Communication protocols for device integration
- Security architecture for data protection
Design Review 2: Completed May 20, 2024 - Software architecture approved
Design Review 3: Completed July 10, 2024 - Detailed design approved
Design Review 4: Completed September 5, 2024 - Verification and validation approved
Design Review 5: Completed October 15, 2024 - Design transfer approved 4. Verification and Validation Software System Test Plan: SSTP-001-2024
Software System Test Report: SSTR-001-2024
- 156 test cases executed with 100% pass rate
- Performance testing confirms 15-second response time
- Security testing validates HIPAA compliance
- 15 healthcare providers completed usability testing
- 98% task completion rate achieved
- No critical usability issues identified
Risk Assessment: RA-001-2024
- 23 hazards identified and analyzed
- 15 risk control measures implemented
- All residual risks determined acceptable
Design Transfer Report: DTR-001-2024
- Production procedures established
- Quality control measures implemented
- First production units verified against design specifications
Q&A
What documents must be included in my Design History File?
What documents must be included in my Design History File?
Your DHF must include design inputs, design outputs, design review records, verification and validation documentation, design change records, and design transfer documentation. For software devices, also include software lifecycle documentation, software requirements, architecture documents, and comprehensive testing records. The exact contents depend on your device complexity and risk classification.
How detailed should my DHF be for software medical devices?
How detailed should my DHF be for software medical devices?
For software devices, your DHF must include comprehensive software lifecycle documentation according to IEC 62304 or equivalent standards. This includes software planning, requirements analysis, architectural design, detailed design, implementation records, and extensive testing documentation. The level of detail should be proportional to your software safety classification (Class A, B, or C).
When do I need to update my Design History File?
When do I need to update my Design History File?
You must update your DHF whenever you make design changes that affect device safety, effectiveness, or performance. This includes software updates, hardware modifications, or changes to intended use. Minor bug fixes may not require DHF updates, but document the rationale in your change control records. Major changes typically require design review and reverification.
How long must I maintain my Design History File?
How long must I maintain my Design History File?
You must maintain your DHF for the lifetime of the device type plus additional time as specified in your quality system procedures. The FDA recommends maintaining DHF records for at least the expected lifetime of the device. The DHF must be readily available for FDA inspection and should be stored in a secure, retrievable format.
Can I use the same DHF for multiple software versions?
Can I use the same DHF for multiple software versions?
You can maintain one DHF for a device type, but you must document all design changes and their verification in the file. Each significant software version that affects safety or effectiveness should have its own design change documentation within the DHF. Minor updates can be documented as design changes without creating a new DHF.
What is the difference between verification and validation in the DHF?
What is the difference between verification and validation in the DHF?
Verification demonstrates that design outputs meet design inputs (building the device right), while validation demonstrates that the device meets user needs and intended use (building the right device). Your DHF must include both verification evidence (like testing against specifications) and validation evidence (like clinical or usability studies demonstrating the device works for its intended users and use environment).