Design History File

​

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

​

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

Design Input Specifications: DI-001-2024

• 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

Regulatory Requirements: RR-001-2024

• 21 CFR Part 820 (Quality System Regulation)
• IEC 62304 (Medical device software)
• ISO 14971 (Risk management)
• IEC 62366 (Usability engineering)

2. Design Outputs

Software Requirements Specification: SRS-001-2024

• 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

Software Architecture Document: SAD-001-2024

• Modular architecture with monitoring, analysis, and alert modules
• Database design for patient data storage
• Communication protocols for device integration
• Security architecture for data protection

3. Design Reviews

Design Review 1: Completed March 15, 2024 - User needs and design inputs approved
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

Usability Validation Report: UVR-001-2024

• 15 healthcare providers completed usability testing
• 98% task completion rate achieved
• No critical usability issues identified

5. Risk Management

Risk Management Plan: RMP-001-2024
Risk Assessment: RA-001-2024

• 23 hazards identified and analyzed
• 15 risk control measures implemented
• All residual risks determined acceptable

6. Design Transfer

Design Transfer Plan: DTP-001-2024
Design Transfer Report: DTR-001-2024

• Production procedures established
• Quality control measures implemented
• First production units verified against design specifications

​

Q&A