# Design History File (DHF) for SaMD: Your Software's Design Story

Author: Sebastian Skorka
Published: 2025-10-07
Updated: 2025-10-07
Source: https://openregulatory.com/articles/design-history-file-dhf-for-samd-your-software-s-design-story

---

Developing Software as a Medical Device (SaMD) is a complex process. Throughout the software development lifecycle – from the initial concept and requirements gathering to coding, testing, and deployment preparations – countless decisions are made, algorithms are refined, code is written and tested, and extensive documentation is generated. The FDA requires that you meticulously track all these design-related activities and records in a designated location: the Design History File (DHF).

What exactly is the DHF, especially for software? Consider it the complete history or official record of your SaMD's design evolution. Its fundamental purpose is to demonstrate to the FDA (and other stakeholders like auditors) that the software wasn't developed at random. Instead, it proves you followed a structured, controlled plan – compliant with 21 CFR Part 820.30 (Design Controls) – to ensure the final software is safe and performs its intended medical function effectively. Essentially, it documents that your software design and development process was well-managed.
Why Does the FDA Emphasize This for SaMD?

The requirement for a DHF originates directly from the FDA's Quality System Regulation, specifically 21 CFR Part 820.30. This section exists because inadequate or poorly documented design processes, have historically contributed to unsafe medical devices. The FDA views robust design controls as essential for ensuring patient safety, regardless of whether the device is hardware, software, or both. The FDA's guidance, such as the one on "Content of Premarket Submissions for Device Software Functions" further underscores the importance of detailed design documentation.

Your DHF serves as the objective evidence that you adhered to these critical design control regulations throughout the software development lifecycle. It establishes traceability – a key concept for SaMD – showing how initial user needs and intended uses (e.g., analyzing images for potential skin lesions) led to specific software requirements, how those requirements were implemented in the software architecture and code (design outputs), and how rigorous testing (verification and validation) confirmed that the final software functions correctly and meets the original needs. An incomplete or disorganized DHF might suggest to the FDA that your development process lacked rigor, raising concerns about the software's reliability, safety, and effectiveness, potentially impacting premarket submissions.
Okay, What Actually Goes in This SaMD "Design Storybook"?

The regulation (21 CFR 820.30(j)) states the DHF must contain or reference the records necessary to demonstrate the design was developed according to the approved design plan and regulatory requirements. While the FDA does not provide an exact template, a comprehensive DHF for SaMD will always include evidence related to these key design control activities:
1. Design and Development Plan: This is your project's roadmap, often tailored for software (potentially incorporating agile methodologies as discussed in AAMI TIR45 while still meeting design control needs). It outlines the software development lifecycle model, phases/sprints, key activities (requirements analysis, architecture design, coding, testing levels), tools to be used (version control, issue tracking), responsibilities, and review milestones. 
  • Example:A Software Development Plan detailing an iterative lifecycle, planned sprints, definition of "done" for user stories, roles (developer, tester, reviewer), required design reviews, and tools like Git for version control and JIRA for issue tracking.
2. Design Input: This defines what the SaMD must accomplish. It includes documented user needs, the specific intended use (as defined in FDA's "Policy for Device Software Functions and Mobile Medical Applications"), and formal, testable software requirements. These cover functional requirements (what it does), performance requirements (how fast, how accurate), security requirements (critical for SaMD - see FDA's Cybersecurity guidance), interface requirements (user interface, data inputs/outputs), safety-related requirements derived from risk analysis (ISO 14971), and applicable standards (e.g., DICOM for imaging). 
  • Example:User need: "Dermatologists need a tool to help assess skin lesion images for potential malignancy risk." This translates into Software Requirements Specifications (SRS) detailing: 
    • "The software shall analyze uploaded JPEG images," 
    • "The algorithm shall output a risk score from 1-10," 
    • "Accuracy shall be X% sensitivity and Y% specificity compared to biopsy results," 
    • "User authentication required via username/password," 
    • "Data transmission must use TLS 1.2 or higher," 
    • "System must handle image resolution up to Z megapixels."
3. Design Output: These are the detailed specifications and artifacts derived from the design inputs that fully describe the software – essentially, the "recipe" for the code. This includes the software architecture design (how modules interact), detailed design specifications (algorithms, data structures), interface specifications (APIs, UI mockups/wireframes), the actual source code (well-commented), database schema, configuration files, and potentially outputs related to cybersecurity controls. These outputs must demonstrably meet the corresponding design input requirements. 
  • Example: Software Architecture Document showing separation of UI, analysis engine, and data storage modules; detailed description of the image analysis algorithm; API specifications for data exchange; the final, version-controlled source code in Python/Java/etc.; database design documents; cybersecurity threat model and control specifications.
4. Design Verification: Did you build the software correctly according to the requirements? Verification activities confirm, through objective evidence, that your design outputs (code, architecture) meet the design input requirements (SRS). For SaMD, this heavily involves various levels of testing: unit testing (testing individual code modules), integration testing (testing module interactions), and system testing (testing the whole application against requirements). It also includes code reviews, static analysis, and potentially cybersecurity vulnerability testing. 
  • Example:Unit test results showing code modules perform as expected; integration test reports demonstrating correct data flow between modules; system test reports verifying functional and performance requirements against the SRS; records of code reviews identifying and fixing defects; static analysis tool reports; penetration testing results.
5. Design Validation: Did you design the right software that meets the user's needs? This step confirms that the final, compiled software fulfills its intended use in the actual or simulated use environment with intended users. For SaMD, this often involves usability testing (Human Factors Engineering) with representative users (e.g., dermatologists) and often clinical evaluation or investigation to confirm clinical performance and safety claims. 
  • Example:A usability study report demonstrating dermatologists can successfully upload images, interpret the risk score, and use the software safely and effectively; results from a clinical study comparing the SaMD's risk score performance against dermatologist assessment and/or biopsy results on a relevant patient population.
6. Design Reviews: These are documented, formal meetings held at key project milestones (e.g., after requirements definition, architecture design review, pre-validation review). A cross-functional team reviews the design status, results, and plans, ensuring requirements are met, risks (including cybersecurity) are addressed, and the software is ready to progress. Records of these reviews are mandatory (21 CFR 820.30(e)). 
  • Example:Signed minutes from the "Software Requirements Review" and "System Test Readiness Review" meetings, documenting attendees, discussion points, action items, and formal approval to proceed.
7. Design Transfer: For SaMD, this involves ensuring the finalized, validated software design (the approved outputs) is correctly translated into the final product that gets deployed or distributed. This includes procedures for compiling the code, building the deployment package, server configuration (if applicable), installation/deployment instructions, and ensuring manufacturing/operations can reliably release the correct version. 
  • Example:Approved build and release procedures; validated software installation scripts; server configuration specifications; final software bill of materials (SBOM); procedures for deploying updates.
8. Design Changes: Any modifications made to the software after its formal approval (especially post-validation or release) must be handled through a documented change control process (21 CFR 820.30(i)). This includes evaluating the change's impact (regression risk, impact on safety/performance, regulatory implications), documenting the reason, obtaining approval, and performing necessary verification (re-testing) or validation. This is crucial for managing software updates and patches. Consider FDA's guidance on "Deciding When to Submit a 510(k) for a Software Change to an Existing Device."
  • Example: An approved software change request detailing an update to the image analysis algorithm to improve specificity. The record includes the rationale, impact assessment, results of regression testing and performance re-verification, and approval signatures before release.


Chapter: DHF vs. DMR vs. DHR - Clearing Up the Confusion

Understanding the distinction between these three related, but different, sets of records is crucial for managing your quality system documentation and navigating FDA inspections. They each serve a specific purpose mandated by the Quality System Regulation:
• DHF (Design History File): As detailed throughout this article, the DHF documents the history of how the SaMD was designed and developed (21 CFR 820.30(j)). It contains the evidence demonstrating the design controls process was followed, from initial needs to final validation and changes. Think of it as the design evolution record.
• DMR (Device Master Record): This is the official, comprehensive "master recipe" or set of instructions needed to produce the SaMD consistently (21 CFR 820.181). For SaMD, this includes the final, released software requirements, architecture design, source code (or reference to its controlled location), validated build and deployment procedures, labeling (like electronic Instructions For Use - eIFU), required operating environment specifications (OS, hardware), and cybersecurity controls documentation. Think of it as the current approved production instructions.
• DHR (Device History Record): This record provides evidence that a specific version, build, or batch of the SaMD was actually created according to the procedures outlined in the DMR (21 CFR 820.184). For SaMD, this typically includes build logs, results of automated tests executed during the build process, evidence of code signing or hashing to ensure integrity, the exact version numbers of all components used (including libraries and the OS, if applicable), and records confirming successful deployment or release. Think of it as the production record for a specific release.


In simple terms: 
• The DHF explains why the design is what it is. 
• The DMR explains how to build/release the current version correctly. 
• The DHR proves that a specific version was built/released correctly according to the DMR. 
• Each file supports different aspects of quality assurance and regulatory compliance.


Excursion: DHF Concepts under EU MDR & IVDR

It's important to note that the term "Design History File (DHF)" is specific to the FDA regulations (21 CFR 820.30). While the European Union's Medical Device Regulation (MDR - Regulation (EU) 2017/745) and In Vitro Diagnostic Regulation (IVDR - Regulation (EU) 2017/746) require comprehensive documentation of the design process, they use a different structure and terminology.

Under the MDR and IVDR, the core documentation compilation is the Technical Documentation (TD), outlined in Annex II and Annex III of both regulations. The TD is much broader than the FDA's DHF. While the DHF focuses specifically on design controls history, the EU TD encompasses evidence covering the entire device lifecycle required to demonstrate conformity with the General Safety and Performance Requirements (GSPRs - Annex I).

Here's a quick comparison:
• Scope: The FDA DHF is a subset of the information required in the EU TD. The TD includes not only design and development information (similar to DHF content) but also manufacturing details, risk management files, clinical/performance evaluation data, labeling, post-market surveillance plans and reports, etc.
• Structure: The EU regulations define a specific structure for the Technical Documentation in Annex II and III. The FDA does not mandate a specific format for the DHF, only that the required records are contained or referenced.
• Content Overlap: The principles are similar. Much of the detailed design information generated under a robust design control process (inputs, outputs, architecture, V&V, risk controls, changes) needed for the DHF is also required within the "Design and manufacturing information" section of the EU TD. Good design control practices generate evidence useful for both regulatory frameworks.
• Purpose: The DHF primarily demonstrates compliance with FDA's design control process requirements. The EU TD demonstrates overall conformity with the GSPRs, providing a complete picture of the device's safety, performance, and compliance throughout its lifecycle.
• IVDR Focus: The IVDR's TD requirements are tailored for in vitro diagnostics, placing a particularly strong emphasis on detailed Performance Evaluation documentation (analytical and clinical performance), which forms a significant part of the TD (Annex II, III, and XIII).


So, while you won't find the term "DHF" in the MDR or IVDR, the rigorous documentation of your SaMD's design, development, verification, validation, and risk management activities is absolutely essential for compiling the required Technical Documentation for CE marking.
Quick Example: Let's Imagine the "SkinScan AI" App

Let's walk through an example. Imagine an app that helps with the assessment of skin lesions.
1. Plan: They create a Software Development Plan with defined sprint lengths and design review checkpoints.
2. Input: User need: "Help dermatologists assess lesion images." Requirements documented: Analyze standard smartphone images, output malignancy risk score, achieve specific sensitivity/specificity targets, comply with HIPAA (security/privacy requirements), run on iOS/Android. Cybersecurity requirements defined based on threat modeling.
3. Output: They create the software architecture (cloud backend, mobile frontend), detail the AI/ML model design, write the Python backend code and Swift/Kotlin mobile code, specify APIs, design the UI/UX, and document the final, version-controlled source code.
4. Verification: Unit tests written for code modules; integration tests verify API calls; system tests run against requirements; code reviews performed; static analysis tools run; vulnerability scans conducted. All test results documented.
5. Validation: A usability study confirms dermatologists can use the app effectively. A clinical validation study compares the app's risk score against dermatologist assessments and biopsy results for hundreds of lesions, demonstrating clinical performance.
6. Review: Formal reviews held for requirements, architecture, risk analysis (including cybersecurity), test results, and clinical validation results, with documented approvals.
7. Transfer: Final, validated code baseline established in version control; build scripts created and validated; deployment procedures documented for app stores and backend servers.
8. Change: Post-launch, the AI model is retrained with more data to improve accuracy. This major change goes through full change control, including impact assessment, re-verification of performance, regression testing, potential usability re-assessment, and documentation updates, before release.


All these records (or clear references to their location in systems like Git, JIRA, Confluence, eQMS) constitute the SkinScan AI app's DHF for FDA purposes, and much of this information would also populate the relevant sections of the EU Technical Documentation.
Quick Reference: Key SaMD DHF Parts

 {{ table|design-history-file-dhf-for-samd-your-software-s-design-story-table-1 }} 
How to Actually Build Your SaMD DHF (Practical Steps)

How can you manage this effectively for software?
1. Start Early: Don't wait. Establish your DHF structure (index, pointers to tools) when you create your Software Development Plan. Integrate DHF documentation into your development workflow.
2. Get Organized (Leverage Tools): Utilize an electronic Quality Management System (eQMS) integrated with your development tools (e.g., JIRA, Git, Confluence). Group documents logically. Use clear naming conventions and version control religiously. An electronic DHF index linking to artifacts in various systems is essential.
3. Establish Traceability: This is critical for SaMD. Demonstrate clear links between requirements (e.g., in JIRA), architecture/design elements (e.g., in Confluence/diagrams), code (e.g., in Git commits linked to issues), test cases (e.g., in a test management tool), and test results. Requirements traceability matrices are vital. Auditors will focus on this.
4. Formal Review & Approval: Ensure electronic workflows capture formal reviews and approvals (e.g., using e-signatures compliant with 21 CFR Part 11 if applicable) for requirements, design documents, code reviews, test plans/reports, and change requests.
5. Control Changes Rigorously: Once requirements or code baselines are approved, all subsequent changes must follow your formal software change control process. Document everything meticulously in your issue tracking and version control systems, linked to formal change records.
6. It's Dynamic During Development: The DHF is actively compiled throughout the software lifecycle. After release, it represents the history of that version, but the process continues for subsequent updates and patches, with changes documented appropriately.
7. Location (Pointers are Key): The DHF for SaMD almost never resides in a single folder. It typically references artifacts across multiple systems (requirements management, version control, issue tracking, test management, document control). The DHF index or structure must provide clear pointers to find all the required evidence easily.


The Main Takeaway

While the Design History File involves significant documentation effort, it is an indispensable requirement for developing and marketing SaMD in the US. It serves as the official, traceable record of your software's design evolution, demonstrating to the FDA that safety and effectiveness were systematically addressed through a controlled process compliant with 21 CFR 820.30. Maintaining an organized, complete, and traceable DHF, integrated with your software development tools and practices, is not just regulatory compliance; it is fundamental to good software engineering and will significantly ease the burden during audits and premarket submissions. Consider it a crucial asset detailing your SaMD's design foundation.