Design History File Gaps That Cause FDA 483 Observations
- 1 day ago
- 9 min read
Updated: 7 minutes ago
By David Petrich, Landrich Group Co-Founder and VP of Quality and Regulatory
The Problem No One Wants to Discover Mid-Inspection
For an IVD/CDx manufacturer, it is the kind of painful outcome you make great effort to avoid. An FDA inspector arrives at your facility. Your team is prepared. The SOPs are current, training records are filed, and your QMS is in good standing. Then the inspector asks to see the Design History File (DHF) for your lead product. Two hours later, you have an FDA Form 483 Notice of Inspection.
A Form 483 is an FDA notice issued at the close of an inspection when an investigator observes conditions that may constitute violations of the Food, Drug, and Cosmetic Act. Each observation requires a formal written response from the manufacturer, typically within 15 business days.
The FDA issues hundreds of Form 483s to device companies every year. DHF deficiencies are among the most common and most avoidable sources of FDA 483s for IVD and medical device companies. This is particularly challenging because these gaps often do not surface during routine internal audits and quality reviews. A major reason for this is the fact that the DHF lives across multiple document systems, owners, and stages of the product lifecycle. This increases the risk that by the time an inspector arrives, the gaps have often been there for years.
IVD/CDx manufacturers and their clinical trial partners must have a working knowledge of potential gaps to minimize this risk. This article identifies the specific DHF issues flagged most frequently in FDA inspections. It examines why they occur and what to address before an inspector finds them.
What the FDA Is Actually Looking For in a DHF
The DHF is the collection of records that documents the entire design and development history of an IVD or medical device. This includes everything from initial user needs through design inputs, outputs, verification, validation, design reviews, and every change along the way.
The FDA regulates Quality Management for In Vitro Diagnostics under 21 CFR Part 820. According to 21 CFR Part 820.30, the DHF must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved Design and Development Plan.
In practice, it requires that every design input has a corresponding design output, every output has associated verification evidence, and every change be controlled and traceable. This can be complex in the case of an IVD, where there is a broad range of potential design outputs. This might include device specifications like hardware, cartridges, reagents, and assay parameters. It could also entail software requirements with code baselines and configuration files. Finally, it has a communication component. This could address instructions for use, packaging and labeling content.
An FDA investigator may approach a DHF review as a traceability exercise. In practice, this means your DHF must allow an FDA investigator to pick any requirement or labeling claim and follow a documented chain. They need to be able to reference the entire flow of design events, from user need to design input, to design output, to verification and validation evidence, and through any subsequent changes. And they need to be able to do this without relying on your team’s memory or tribal knowledge.
The Seven Gaps That Generate 483s Most Often
1. Design inputs are too vague to verify
Specificity lends credibility. Statements such as "the device shall be easy to use" cannot be verified since they lack an objective pass/fail criterion. The FDA expects design inputs to be quantitative, testable, and tied to tangible. Instead, write: “A trained user shall complete a full test cycle from sample prep to result readout in less than 5 minutes with no crucial use error per 30 test cycles under CLIA moderate-complexity conditions.”
2. Design outputs that don't map back to inputs
Design output, as referenced earlier, is defined as any result of the design process. For a complex diagnostic product, this definition touches nearly every task. The risk here is a gap where an output is created to solve a problem at some point along the way and never tied back to the original design input in the DHF. The device may work, but there is no clear link from the work instruction to a design requirement for an inspector to trace.
A hypothetical example might be an IVD team that discovers a reagent is unstable at room temperature. The storage instruction is revised to require refrigeration, with “no more than 1 hour at room temperature,” but the team fails to update the design inputs or the traceability matrix. During the inspection, the FDA reviews the work instructions, but there is no documentation of the verification that justified the decision. This can be solved by conducting an overall DHF traceability scan that flags the orphan work instruction. Then, the orphan output is addressed by rebuilding the full input-output-verification chain with a specific design input such as “The reagent share shall remain within performance specification when stored refrigerated at 2-8 °C, with cumulative room-temperature exposure no more than 1 hour.
3. Missing or incomplete verification or validation test results
This is the most common single gap in DHF inspections. Even when test protocols and test reports are available, the connection between them is missing, incomplete, or inaccessible to an inspector. Specific failure patterns include reports that don't reference the protocol they executed, reports with passing summaries but no underlying data, and tests performed on design iterations that were never formally linked to the current design baseline.
A concrete example: verification protocol VP-001, "Analytical Sensitivity and Specificity" for an IVD product. Several test reports exist, but some summarize "All criteria met" without including raw data, and another report is executed against VP-001 Rev B, but only references "VP-001" without specifying the revision. The current DHF baseline lists VP-001 Rev C, and there is no explanation indicating that the Rev B data remains applicable.
The correction requires three steps:
1. Create an inventory of all verification and validation reports, matching each to the
specific protocol ID and revision used.
2. Update each report to explicitly reference the executed protocol and revision, and
attach key raw data sets (Ct values, signal ratios, lot IDs, firmware versions) traceable
to a controlled data repository.
3. Add an applicability summary for each report explaining why prior-revision data
supports the current baseline or flag where supplemental testing is needed.
4. Verification testing performed on non-representative samples
The FDA expects verification testing to reflect how the device will be manufactured and used. Testing is often performed on prototypes manufactured by R&D, on non-representative samples, or on configurations that don't match the final design specification. These are all frequent reasons for a 483 source citation, particularly for IVD companies, where reagent lots and manufacturing scale can materially affect performance.
There are scenarios where the design freeze might specify a different reagent filing process or cartridge material after verification of precision and reproducibility was already conducted on lab-scale equipment. This creates a risk that the DHF lists early studies as evidence without noting hardware and process changes. It’s essential to map all verification activities against device configuration and categorize study phases, such as “prototype”, “pre-production,” and “final production equivalent,” within the DHF index.
5. Design changes without formal change control
Engineering changes made during development that were never put through design change control are a significant risk. This happens most often during the transition from development to design freeze, where informal iterations become permanent without documentation. The practical test: can you reconstruct every change made to the design after the initial design plan was approved, with rationale and re-verification decisions documented for each?
Let’s say that, during late development, the product team tweaks the assay algorithm to improve specificity and adjusts cut-off thresholds. At the same time, the marketing team changes the intended-use wording to emphasize a more specific patient population. The risk is that both changes happen in the code and labeling, but the change control form is never updated. To satisfy the inspection needs, the regulatory partner needs to “rebuild the timeline” of design changes for accurate recording of every post-plan modification with documented explanation and supporting evidence.
6. Risk management file that isn't integrated with the DHF
Risk-based management is increasingly critical for regulatory agencies like the FDA. The ISO 14971 standard requires that risk controls be implemented in the design. When the risk management file and the DHF are maintained separately, it can be challenging to demonstrate that all identified hazards have associated design controls and verification evidence. An output of the risk assessment process is an input to the design development process. The FDA’s recent adoption of ISO 13485:2016 in early 2026 underscores the integration of risk management into the design and development process. In practice, this means inspectors are increasingly asking to see the risk management file and the DHF side by side, not as separate submissions. This is why inspectors are increasingly looking for this integration explicitly.
Earlier this year, the FDA adopted ISO 13485:2016 through the agency’s QMSR. This reflects the agency's broader Quality by Design initiative, which emphasizes building quality into the design process rather than inspecting for it after the fact. In practice, this means inspectors are increasingly asking to see the risk management file and the DHF side by side, not as separate submissions.
7. Labeling is not treated as a design output
As mentioned earlier, labeling is defined as a design output under 21 CFR Part 820.30(d) and therefore must be linked to design inputs. This specifically involves the product’s intended use and user needs that drove the labeling content. Labeling written by marketing and never formally reviewed against design inputs is a common DHF gap for IVD devices.
Marketing teams might update IFU and box content to include phrases like “rapid test” and add performance claims that are not reflected in design inputs. These changes are managed in marketing systems, but not the DHF. This creates the risk that labeling contains claims different from the information supported by the DHF design inputs and test evidence. A mature process closes this gap with an inventory of all labeling artifacts (IFU, box copy, quick guides, marketing inserts) and manages them as formal design outputs per 21 CFR 820.30(d). Marketing collateral must be treated as product labeling that is reviewed by Regulatory and Legal professionals to ensure there are no false or misleading performance claims.
Why These Gaps Are Hard to Catch Internally
Most DHF gaps are not the result of negligence. They are the unintended consequences of how device development typically happens in real organizations. Development is iterative, ownership changes, document systems evolve, and the DHF quietly accumulates over the years and multiple releases.
Internal reviewers usually have too much context to see the situation through the eyes of an external inspector coming in cold. People inside have natural cognitive biases. They know what the team intended, where the “real” data lives. They understand the shortcuts taken to keep timelines moving. When they review the DHF, they unconsciously fill in holes that an FDA investigator will treat as missing links in the evidence chain.
In one recent mock audit for a mid‑size IVD manufacturer, the client was confident their DHF was “complete” because every required document type was present. In the first pass, we found that roughly half of the verification reports referenced outdated protocol versions, several critical design outputs lacked explicit mappings back to inputs, and labeling changes made during commercialization never flowed back into the formal change‑control record. None of those issues affected how the device performed at the bench. Yet any one of them could have supported a 483 observation for inadequate design controls and incomplete design history.
This is why mock audits and independent DHF reviews are more than box‑checking exercises. An external reviewer provides an invaluable rehearsal, approaching the file the way an FDA inspector does. The inspection starts from a requirement or labeling statement and follows the traceability chain forward, without the benefit of internal tribal knowledge or shared assumptions. The goal of these mock audits and pre-reviews is to find the weak links before the FDA does.
A Practical Pre-Inspection DHF Review
Before an FDA inspection,510(k), or Pre-Market Approval (PMA) submission, work through these questions for the product in scope.
• Can every design output be traced to at least one design input?
• Are there test protocols and test reports for every design output requiring verification?
• Do test reports reference the protocol executed and include underlying data?
• Are the data supporting verification and validation studies complete, accurate, and
traceable?
• Were tests performed on investigational products that are representative of the final
design?
• Is there a formal record of every design change, including re-verification or
re-validation decisions?
• Were design reviews conducted with an independent reviewer and documented in the
DHF?
• Are all risk control measures (i.e., mitigations) identified in the Risk Management File
implemented, verified, and traceable in the DHF?
• Is labeling treated as a design output with documented design input traceability?
The Cost of Waiting
A 483 observation on DHF deficiencies does not automatically derail a submission or trigger a warning letter. But it does force you into a response‑and‑correction cycle on the FDA’s timeline. That can mean re‑running verification or validation studies, , reconstructing traceability matrices under inspection pressure, and diverting scarce engineering and QA resources away from active product development projects.
For IVD and device companies preparing for pivotal trials or launch, even a modest delay in clearance or approval can ripple into missed commercial windows, frustrated partners, and internal “stop‑everything” fire drills. External analyses of 483 trends consistently show that design‑control issues remain a recurring cause of observations and, in some cases, lead to enforcement. The cost of repairing those problems after an inspection is almost always significantly higher than addressing them before the FDA ever walks in.
