Design History File (DHF): How to Build One Using ALM Software

The Design History File is one of the first things an FDA investigator requests during a 21 CFR Part 820 inspection. It is also one of the most common sources of 483 observations. Not because teams fail to generate the right records, but because they cannot demonstrate that those records are connected, traced properly, controlled, and complete.

That distinction matters. A DHF is not a folder of documents. It is a structured, traceable body of evidences controled documents that prove your device was designed and developed in accordance with your approved design plan. Design Control/ALM software, when configured correctly, can serve as the backbone of that structure, addressing the ”documentation debt” that medical device manufacturing (MDM) faces. Here is how to build it right.

‍

What the Regulation Actually Requires

Under 21 CFR §820.30(j), each MDM  shall establish and maintain a DHF for each type of device. The file must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of the regulation.

ISO 13485:2016 Clause 7.3.10 aligns closely: the organization shall maintain a DHF that demonstrates that the design and development outputs meet requirements for each medical device type or medical device family.

Two phrases carry the most audit weight:

• "Contains or references": Your DHF does not need to house every artifact in one location, but every record must be retrievable and traceable from a single point of control.
• "In accordance with the approved design plan": You must be able to show that what you planned (design inputs, verification approach, risk controls) maps directly to what you executed and recorded.

Both requirements collapse quickly when teams manage design and quality records in separate, disconnected tools.

The 5 Core Layers of a Compliant DHF

A well-structured DHF addresses five interconnected areas. Design Control/ALM software provides the connective tissue between them.

1. Design and Development Planning (§820.30(b) / Clause 7.3.2)

Your design plan defines phases, review gates, responsibilities, and interfaces with other functions. In an ALM system, this translates to a project structure with defined milestones, assigned owners, and documented review approvals at each gate.

What auditors look for: evidence that the plan was actually followed, not just written. Version-controlled plan documents with timestamped approvals meet this bar. A plan in a shared drive folder does not.

2. Design Inputs (§820.30(c) / Clause 7.3.3)

Design inputs are the requirements your device must meet: performance specifications, safety standards, intended use constraints, and applicable regulatory requirements. In an ALM system, these live as formal, uniquely identified requirements with approval status, version history, and the name of the approving authority.

Common failure mode: inputs defined in a Word document that was revised six times, with no audit trail showing what changed and who approved the changes. ALM tools solve this structurally, not procedurally.

3. Design Outputs (§820.30(d) / Clause 7.3.4)

Design outputs include drawings, specifications, software source code, labeling requirements, and manufacturing procedures. The critical requirement is that outputs must reference or trace back to design inputs. If you cannot show that your output satisfies a specific input, the output is orphaned from your design evidence.

In an ALM system, traceability links between requirements and outputs are created explicitly. A traceability matrix is not a separate deliverable you produce at the end of the project. It is a live view of links that have been maintained throughout development.

4. Design Verification and Validation (§820.30(f-g) / Clause 7.3.6 and 7.3.7)

Verification confirms outputs meet inputs. Validation confirms the device meets user needs under simulated or actual conditions of use. Both require documented test protocols, results, and a formal conclusion.

In an ALM context, each test or validation activity should link to the requirement or output it is testing. This linkage is what allows you to answer the audit question: "How do you know your device meets this requirement?" The answer should be a traceable path from the requirement through the verification result, not a verbal explanation pointing to a separate test binder.

5. Design Review and Risk Management (§820.30(e) / Clause 7.3.5 and 7.3.8)

Design reviews must be documented, must include individuals without direct responsibility for the stage being reviewed, and must address action items to closure. Risk management records, per ISO 14971:2019, must connect identified hazards to design decisions and show that residual risk is acceptable.

This is where fragmented toolsets create the biggest compliance gap. Risk records maintained in a standalone risk tool (usually Excel), disconnected from the requirements and design outputs that implement the controls, cannot demonstrate that the control exists in the device. The link between hazard, control, and verified output must be traceable.

‍

How ALM Software Supports Each Layer

A properly configured ALM system does not just store documents. It enforces structure.

Requirements management gives every input a unique ID, version, and approval workflow. You cannot accidentally lose a requirement revision or approve a change without leaving a record.

Traceability matrices are generated from actual link data, not assembled manually from spreadsheets. When a requirement changes, you immediately see which outputs, verification tests, and risk controls are affected. This is called impact analysis, and it is the difference between managing change and reacting to it.

Review and approval workflows replace email chains. Design review meeting records, with attendees, action items, and closure evidence, live in the same system as the artifacts being reviewed. The auditor sees a complete record without you assembling a presentation.

Integration with risk records is where combined ALM and QMS platforms provide the clearest advantage. When your risk file and your requirements file live in the same system, a traceability link between a hazardous situation, its design control (a requirement), and the verification test that confirmed the control works is a structural relationship, not a manually maintained reference.

‍

The DHF Readiness Test

Before your next inspection or audit, run this check against your current DHF:

1. Can you produce a complete list of design inputs, with version history and approval records, in under 10 minutes?
2. Does every design output trace to at least one design input?
3. Does every design input have at least one verification or validation record linked to it?
4. Can you show that risk controls are implemented as specific requirements and verified by specific tests?
5. Are all design review records, including action item closure, retrievable from a single system?
6. If a design input changed after initial approval, can you show the impact on downstream outputs and risk records?

If any answer is "no" or "not easily," your DHF has a structural gap, not just a documentation gap. The distinction is important because documentation gaps can be corrected with records. Structural gaps require process changes.

‍

Building DHF Structure with Orcanos

Orcanos is designed specifically to close the gap between design control and quality records. Because it combines ALM and QMS capabilities in a single platform, requirements, risk management, design verification, CAPA, and DHF records all share the same data layer. Traceability links are maintained automatically. Impact analysis is built in.

When a requirement changes in Orcanos, the platform flags affected risk records, linked verification tests, and any open CAPAs related to that requirement. Your team sees the full compliance picture without manually chasing references across multiple tools.

For teams preparing for FDA inspection or CE technical documentation review, Orcanos can generate a DHF-ready traceability report directly from the system, covering inputs, outputs, verification, validation, and risk controls in a single, auditable view.

‍

The Practical Takeaway

A compliant DHF is built record by record, link by link, throughout development. It cannot be assembled at the end of a project from artifacts stored in disconnected systems. The regulatory requirement for traceability is not a documentation exercise. It is a structural one.

ALM software provides that structure. The question is whether your ALM and QMS tools are connected enough to maintain it across the full development and quality lifecycle.

If you want to see how Orcanos builds DHF traceability from design inputs through verification and risk management in a single system, schedule a demo with the Orcanos team.

‍

Get Free Orcanos Academy course about Product Realizations ISO 13485:Clause 7

‍