Design History File vs Device Master Record vs DHR: What Each Must Contain | ADB Consulting & CRO

DHF, DMR, DHR: Three Records That Can Make or Break Your FDA Audit

If you have ever sat across from an FDA investigator during a Quality System Inspection Technique (QSIT) audit and watched them open your document management system, you understand exactly how consequential these three records are. The Design History File (DHF), Device Master Record (DMR), and Device History Record (DHR) are not interchangeable acronyms — they are legally distinct, operationally critical documents with separate regulatory requirements under 21 CFR Part 820. Confusing them, or worse, failing to maintain them properly, is one of the most common root causes of FDA Form 483 observations and Warning Letters issued to medical device manufacturers.

This post breaks down exactly what each record must contain, why the distinction matters, and how to structure your quality system to keep all three audit-ready at every stage of your product lifecycle.

The Design History File (DHF): Proving You Followed Your Own Process

The DHF is defined under 21 CFR 820.30(j) and is fundamentally a record that your device was designed in accordance with your approved design plan. Think of it as the procedural evidence file — it does not describe the final device, it documents the journey taken to arrive at it.

What the DHF Must Contain

• Design and development plan: Including timelines, assigned responsibilities, and defined design phases per 820.30(b)
• Design inputs: User needs, intended use, performance requirements, and applicable standards (820.30(c))
• Design outputs: Drawings, specifications, software source code references, and manufacturing procedures that define the finished device (820.30(d))
• Design reviews: Formal review records including participants, dates, results, and action items (820.30(e))
• Design verification records: Test reports, analysis results, and inspection records that confirm outputs meet inputs (820.30(f))
• Design validation records: Clinical evaluation data, usability testing, simulated use testing, and software validation under intended use conditions (820.30(g))
• Risk management file reference: While not always explicit in Part 820, FDA strongly expects traceability to your ISO 14971 risk management activities
• Design transfer records: Evidence that the design was correctly translated into production specifications (820.30(h))
• Design change records: All changes post-transfer, including rationale and re-verification or re-validation where required (820.30(i))

A critical point that startup founders routinely miss: the DHF is not a single binder or folder. It is a structured index that references and links to all of the above records. FDA investigators expect to trace a clear, unbroken thread from user need to finished device specification through your DHF index.

The Device Master Record (DMR): The Blueprint for Reproducible Manufacturing

Where the DHF answers 'how did we design it,' the DMR answers 'how do we build it.' Defined under 21 CFR 820.181, the DMR is the complete set of specifications and procedures required to manufacture, package, label, install, and service a finished device.

What the DMR Must Contain

• Device specifications: Physical, performance, and functional specifications including drawings and component lists
• Production process specifications: Work instructions, manufacturing process flows, equipment specifications, and process parameters
• Quality assurance procedures and specifications: Acceptance criteria, in-process inspection points, and finished device testing requirements
• Packaging and labeling specifications: Including artwork masters, label copy, and packaging validation references
• Installation, maintenance, and servicing procedures where applicable to the device type

The DMR must be approved by a designated individual per 820.181, and any changes to the DMR must go through your formal document change control process. A common audit finding is a DMR that references outdated drawing revisions or lacks a controlled index — both are straightforward to prevent with a disciplined document control system.

The Device History Record (DHR): Your Lot-Level Proof of Conformance

The DHR is defined under 21 CFR 820.184 and answers a fundamentally different question than either the DHF or DMR: was this specific unit or lot manufactured in accordance with the DMR? Every production run requires a DHR.

What the DHR Must Contain

• Dates of manufacture
• Quantity manufactured and quantity released for distribution
• Acceptance records: In-process and finished device inspection results
• Primary identification label and labeling used
• Unique Device Identifier (UDI) or lot/serial number
• Equipment identification used during manufacturing where required

The DHR is your legal evidence that a specific device leaving your facility was built to spec. In a recall scenario or adverse event investigation, the DHR is the first document regulators and your legal team will request.

How These Three Records Work Together

The relationship is sequential and mutually dependent. Your DHF documents the design process and produces the outputs that become your DMR. Your DMR specifies exactly how to manufacture the device. Your DHR proves that each production lot was manufactured per the DMR. If any link in that chain is weak — incomplete design validation records in the DHF, vague process parameters in the DMR, or missing acceptance records in the DHR — you have a compliance gap that will surface during an audit or, worse, in the field.

FDA has reinforced this interconnected expectation in its QSIT guidance and through consistent 483 observation trends. The agency expects your quality system to make traceability between all three records straightforward for an investigator to follow in real time.

Common Mistakes That Lead to 483 Observations

• Treating the DHF as a post-market activity rather than building it contemporaneously during development
• Failing to document design transfer formally, leaving a gap between DHF outputs and DMR specifications
• Maintaining a DMR that does not reflect the as-built device after design changes
• Incomplete or missing DHRs for contract-manufactured components
• No procedure defining who is responsible for maintaining and approving each record

The Bottom Line

Getting your DHF, DMR, and DHR infrastructure right is not a paperwork exercise — it is the foundation of a defensible quality system. Whether you are preparing for a 510(k) submission, anticipating a pre-approval inspection, or scaling from prototype to commercial production, these three records are where FDA will look first to assess whether your quality system is real or performative.

At ADB Consulting and CRO Inc., we help medical device companies build quality systems that hold up under scrutiny — not just on paper, but in practice. If you are unsure whether your DHF, DMR, or DHR structure is audit-ready, do not wait for a 483 to find out.

Book a free discovery call with Andre Butler today at adbccro.com and get a candid assessment of where your documentation stands and exactly what it will take to get it where it needs to be.