What does a Design History File (DHF) need to contain?

The DHF should contain all the steps and procedures carried out through the design and
development phase in order to manufacture a process. These steps are also known as
design controls.

As such, it doubles as guidance for developing the same or similar products in the
future. It is typically divided into subsections with each one being dedicated to a
different phase of the design process:

Design and Development Planning

1. Project Plan: Details overall project objectives, scope, and deliverables.

2. Software Development Plan (SDP): Outlines the software development lifecycle,

methodologies, tools, and resources.

3. Timeline and Milestones: Gantt charts or similar documents outlining key project
phases and deadlines.

4. Roles and Responsibilities: Documentation of team members' roles and

responsibilities.

5. Budget Plan: Financial planning document detailing budget allocation for resources,
tools, and personnel.

6. Risk Management Plan: Identifies potential risks and mitigation strategies.

7. Communication Plan: Defines how information will be shared among stakeholders.

Design Inputs

1. User Requirements Specification (URS): Describes what the end user needs from the
software.

2. System Requirements Specification (SRS): Converts user needs into system-level

requirements.

3. Regulatory Requirements: Lists compliance requirements based on industry

standards and regulations.

4. Interface Requirements: Describes how the software will interact with other systems
or devices.
5. Performance Requirements: Specifies performance criteria like speed, efficiency, and
reliability.

Design Outputs

1. Software Architecture Document: Describes the overall software structure.

2. Detailed Design Documents: Includes data models, algorithms, and design patterns
used.

3. Source Code: The actual code developed based on design documents.

4. Unit Test Cases: Documentation of individual tests for components.

5. Traceability Matrix: Maps design outputs to design inputs.

Design Review

1. Design Review Plan: Defines the process and criteria for conducting reviews.

2. Review Meeting Minutes: Records of discussions, decisions, and action items from
design review meetings.

3. Review Reports: Formal documents summarizing the outcomes of the design

reviews.

Design Verification

1. Verification Plan: Outlines the strategy and methods for verification.

2. Test Protocols: Detailed procedures for testing.

3. Test Reports: Results and analysis of verification tests.

4. Traceability Matrix: Shows traceability between test results and design inputs.

Design Validation

1. Validation Plan: Describes how the software will be validated against user
requirements.

2. Validation Protocols: Procedures for conducting validation activities.

3. Validation Reports: Documented results of validation activities.

4. User Acceptance Testing (UAT) Results: Feedback and results from end-users
testing the software.

Design Transfer

1. Transfer Plan: Describes how the design will be transferred to production.

2. Production Procedures: Instructions for manufacturing the software, if applicable.

3. Installation and Deployment Guides: Instructions for deploying the software in the
production environment.

4. Training Materials: Documents for training production and maintenance staff.

Design Changes

1. Change Management Plan: Describes the process for managing design changes.

2. Change Request Forms: Documents requesting changes to the design.

3. Change Control Logs: Records of all changes made, including reasons and
approvals.

4. Impact Analysis Reports: Analysis of how changes will affect the existing design.

5. Updated Design Documents: Revised versions of design documents reflecting the

changes.

Release Management

1. Release Plan: Strategy for deploying the software, including versioning and
distribution methods.
2. Release Notes: Documentation accompanying software releases, including new
features, fixes, and known issues.
3. Installation and Operation Manuals: Instructions for installing, operating, and
maintaining the software.

Risk Management

Risk Analysis and Hazard Analysis Reports: Identifies potential hazards and assesses
the associated risks.

Risk Mitigation Strategies: Documentation of the measures taken to mitigate

identified risks.

Software Configuration Management

 Configuration Management Plan: Describes the procedures for managing changes to
the software throughout its lifecycle.

Version Control Records: Logs of software versions, including changes made and
reasons for those changes.

Software Problem Resolution

Bug Reports and Tracking: Records of software bugs, issues, and defects, including
their status and resolution.

Change Requests and Change Control Logs: Documentation of requests for changes
to the software and their approval, implementation, and verification.

Human Factors Engineering

Usability Study Reports: Results of studies conducted to evaluate the usability of the
software, including user feedback and recommendations for improvement.

Production and PostProduction Information

Installation Qualification (IQ) and Operational Qualification (OQ) Reports: Documents

verifying the software installation and operation in the intended environment.

PostMarket Surveillance Plan: Strategy for monitoring the software's performance and
safety once it is in use.

Regulatory Submissions and Approvals

Regulatory Submission Documents: Copies of submissions made to regulatory bodies

(e.g., FDA, CE Mark) and their responses.

Approval Letters: Documentation of regulatory approvals received for the software.

Training and Support

Training Materials: Documentation used to train users on the software.

User Manuals and Help Guides: Guides provided to endusers to help them operate the
software effectively.

Software Maintenance and Updates

Maintenance Plan: Strategy for maintaining and updating the software postrelease.
 Update and Patch Records: Logs of updates and patches applied to the software,
including details of the changes made.