The DHF compilation tax nobody plans for

We've written before about what happens when your design history file lives in binders: missing signatures, version conflicts, a single source of truth that's actually three sources, none of them current. Read the seven problems with a paper-based DHF if you haven't already.

Here's the part that surprises people. Swap the binders for a spreadsheet, or even for a general-purpose electronic quality management system (eQMS), and most of those same problems come right along with you. You've traded paper cuts for tab sprawl. Someone still has to open eight different records, confirm the version numbers match, chase down the one reviewer who never signed off, and paste it all into a document that's due Friday.

Call it the compilation tax: the hours, sometimes days, a team pays at the worst possible moment, right when they should be focused on the submission itself, because the DHF was never assembled as they worked. It got assembled after the fact, under a deadline, by whoever drew the short straw.

→ Bonus resource: 7 Problems with a Paper-Based DHF

An inspector from the Food and Drug Administration (FDA) or a notified body auditor isn't going to care that your records technically exist somewhere in your eQMS. They're going to ask for your records, and if those files take your team three days to produce, you've already told them something about how well controlled your process really is.

What the delay actually costs

A founder or a VP of Engineering usually feels this cost secondhand, when a submission slips by a week because three engineers got pulled off actual product work to go spelunking through old records.

A DHF assembled at the last minute costs hours, but the bigger cost is launch timing. Launch timing is the one variable that touches every other part of the business: funding milestones, sales forecasts, the runway conversation with your board.

Across growing device companies, a DHF compilation crunch routinely eats up a week or more right before submission, and that's a week nobody budgeted for because the work was supposed to already be done. Multiply that across every submission a company files, and the compilation tax stops looking like a one-time headache and starts looking like a recurring line item nobody put in the plan.

What a DHF actually has to contain

A design history file is proof that a set of other documents connect to each other correctly, not one document in itself, over the life of a project that might run two or three years.

For years, the citation for this was 21 CFR Part 820.30(j): a manufacturer had to establish and maintain a DHF for each device type, showing the design was developed according to the approved plan. That specific citation no longer applies. Since February 2, 2026, the FDA's Quality Management System Regulation (QMSR) folded 21 CFR Part 820 into ISO 13485:2016 by reference, and the requirement now lives in Clause 7.3.10, the design and development file. Read the full breakdown of what QMSR changed for the complete picture.

The renaming doesn't touch what has to be in the file, even though "Design History File" is simply no longer the FDA's defined term for it. A design and development file still needs to reference:

• User needs and design inputs
• Design outputs
• Design verification and validation protocols and reports
• Design reviews tied to those inputs, outputs, and verification and validation activities
• The materials used to transfer the design into manufacturing

Most of the industry still calls this file a DHF, and this post keeps using that term for the same reason everyone else does. Just know the citation now points to ISO 13485:2016 Clause 7.3.10, not the retired 820.30(j), and that the requirement is the same whether a device ships in the US or anywhere else that recognizes ISO 13485.

Notice what's missing from that list: a single template. There's no one file that contains all of this natively. A DHF is a web of references between records that, in most companies, get created by different people, in different tools, months apart from each other.

That's exactly why manual assembly breaks down. Compiling a DHF by hand is a reconstruction task, not a documentation one, where someone has to rebuild the connections between inputs and outputs and reviews after the fact, hoping nothing changed in the meantime and nobody forgot to log a decision.

If your team already missed that window and needs to rebuild design controls after the fact, that's a real situation, but a fixable one.

→ Bonus resource: How to Retroactively Create Design Controls and DHF

That said, a retroactive fix is a fire drill you might want to run once, but it's not a process you want to repeat every submission cycle. The better fix removes the reconstruction step entirely.

How Ultra removes the compilation step

Ultra treats the DHF as a byproduct of the design controls work your team is already doing inside the tool, not as a separate deliverable you build at the end.

When your engineers log a design input, it's already connected to the requirement it traces back to, and when someone completes a verification protocol, that record links directly to the output it's testing and the input that drove it. When a reviewer signs off, that approval attaches to the specific version of the record they reviewed. Not a snapshot copied into a different tool three weeks later, and not a screenshot pasted into a shared drive somewhere.

What if an engineer updates a design output six months into development, after a supplier swaps a component? In a spreadsheet world, somebody has to remember which verification protocols pointed at the old output and go update every reference by hand, assuming they remember to do it at all. Inside Ultra, the update happens once, and every input, protocol, and review still linked to that output reflects the change immediately, because they were never separate copies to begin with.

By the time you're staring down a submission date, the connections your DHF needs to prove already exist. Generating the file becomes a matter of pulling a report from links that were built the moment the work happened, not a project that starts the week before your deadline.

Paper and spreadsheets both ask a person to recreate traceability after the fact. Ultra asks nobody to recreate anything, because the traceability was never broken to begin with, and that's the actual difference between a paper DHF, a spreadsheet DHF, and an automated one.

If you want the fuller picture of how design controls fit together before you get to DHF automation specifically, our design controls guide covers the process end to end.

Most engineers only think about the DHF once a year, at submission time. That once-a-year moment is exactly when a broken process costs the most, right when a team can least afford a delay.

Compiling a DHF by hand was always about timing more than effort. You either pay the tax at submission time, under pressure, with the FDA clock running, or you don't pay it at all because the file was already assembled as you worked.

Keep reading

If you are building out your design controls and DHF process, these related guides go deeper on the specific components:

• Medical Device Design Controls: FDA QMSR & ISO 13485
• 7 Problems with a Paper-Based Design History File
• How to Retroactively Create Design Controls and DHF
• QMSR & the End of DMR, DHR, DHF
• 3 Tips for Managing Your Medical Device Design History File
• DHF vs. DMR vs. DHR: Differences Explained

If you want to see what that looks like for your own product development process, take a look at Ultra.