Design History File (DHF)

The master schedule and organizational blueprint that defines who does what and when. This document outlines all design activities, assigns responsibilities, identifies interfaces between groups, and is continuously updated throughout development. It must align with ISO 13485 and 21 CFR Part 820.30(b).

The physical and performance requirements that form the basis of the device. These must be unambiguous, verifiable, and complete. For SaMD, inputs include:

• Intended Use Statement and clinical claims
• Functional, performance, and safety requirements
• Cybersecurity and interoperability specifications
• Applicable regulatory standards (e.g., IEC 62304)

The tangible results of the design effort that deliver against the design inputs. Outputs include software architecture diagrams, source code, compiled binaries, user manuals, and the Software Bill of Materials (SBOM). Each output must reference the specific design input it satisfies, creating a traceable, auditable link.

Formal, documented assessments conducted at major milestones to evaluate the design's maturity. Records must identify the reviewers, date, issues found, and resolution actions. Reviews confirm that the design can proceed to the next phase and that Verification and Validation (V&V) plans are adequate.

Objective evidence confirming that design outputs meet design inputs (i.e., 'did we build the thing right?'). For software, this includes unit test results, integration test logs, static code analysis reports, and traceability matrices. Verification is a continuous, iterative process, not a final gate.

Objective evidence confirming that the final device meets user needs in the intended clinical environment (i.e., 'did we build the right thing?'). For diagnostic SaMD, this includes clinical validation study data, Human Factors Engineering (HFE) usability test reports, and evidence of diagnostic accuracy (sensitivity/specificity).

Documentation proving the design was correctly translated into a production specification for manufacturing or, for SaMD, a reproducible release process. This includes build scripts, deployment configurations, and installation qualification records ensuring the software can be consistently distributed to end-users without corruption.

A chronological log of all post-approval modifications, maintained under Corrective and Preventive Action (CAPA) procedures. Each record must describe the change rationale, risk assessment, verification/validation activities performed, and regulatory impact analysis—especially critical for determining if an Adaptive Algorithm update requires a new 510(k).

The core evidentiary activities documented within the DHF. Verification confirms that design outputs meet specified design inputs (did we build the software right?), while Validation confirms that the final device meets user needs and intended uses (did we build the right software?). For SaMD, validation often includes rigorous clinical performance studies.

The international standard governing the software development lifecycle for medical device software. The DHF must contain evidence that software planning, requirements analysis, architectural design, detailed design, unit implementation, integration testing, and maintenance processes strictly followed this standard's risk-based classification system (Class A, B, or C).

The overarching organizational structure, such as ISO 13485, that mandates the creation of a DHF. The QMS defines the procedures for document control, design reviews, and change management. The DHF is a living collection of records generated by executing the QMS's design controls, proving a systematic, traceable development process.

The fundamental traceability pair within the DHF. Design Inputs are the physical and performance requirements of the device, including the Intended Use Statement and risk controls from ISO 14971. Design Outputs are the results of the design effort, such as the software architecture, source code, and test protocols. The DHF must prove each output maps back to a specific input.

A distinct but cross-referenced file that feeds directly into the DHF. It contains the Hazard Analysis, Failure Mode and Effects Analysis (FMEA) , and risk control measures. The DHF must demonstrate that identified risks were mitigated through specific design choices and that residual risk is acceptable, creating a direct link between safety and software architecture.

Formal, documented assessments conducted at key milestones. The DHF must include meeting minutes, attendee lists, and sign-off records proving that independent, qualified reviewers systematically evaluated the design for correctness, completeness, and compliance before advancing to the next development phase. These records are critical evidence of management oversight.