Design history files (DHFs) are crucial for both your compliance efforts and overall product quality. However, many life science organizations still grapple with managing them well. Why?
1. The DHF is paper-based
Many life science organizations still rely on paper-based DHFs. But as the industry moves to more data-centric product development models, these systems are becoming outdated and more risk-prone. Greater abilities to generate data in massive quantities, combined with changing workforces—both in demographics and geography—present real challenges to adequately manage product data in paper-based systems. The risks of physical documents being lost, not filed, or out of date are much greater.
2. Traceability is missing
In all DHF systems, paper-based or electronic, tracing data between documents and files is necessary. If a high-level system requirement or user need is related to a handful of subsystem requirements, linking between the documents they reside in is vital. Otherwise, any design changes or data loss/alteration can’t be properly evaluated up and down the requirements flow, potentially compromising product safety and effectiveness.
3. Disorganization
Even with project data adequately linked, lack of organization in the design file can lead to serious design issues. And, in the event of a regulatory audit, a disorganized DHF is difficult for inspectors to navigate. This can result in warning letters, remediation, or other regulatory issues that can negatively impact your organization. Therefore, your DHF should be organized so that both internal and external stakeholders can understand your design data laid out in a logical flow.
4. Documents and data are spread out
DHF management becomes more complex when you have remote sites completing product design work. Documents and data are vulnerable to getting tucked away at remote sites, possibly impacting transparency and product fidelity. Design changes can occur without oversight or full team knowledge, and design activities can be inappropriately completed or initiated.
There are also cybersecurity and data integrity risks to consider. Confidential documents being sent back and forth can be intercepted or lost, cyberattacks can compromise data stored at remote worksites, remote hardware can fail, and so on. Also, if personnel turnover, critical design data on their old devices might no longer be accessible.
5. Irregular DHF updates
FDA’s Design Controls regulation, 21 CFR 820.30, does not explicitly require routine DHF updates. However, it’s best practice to regularly monitor, update, and adjust your design files, with all documents reflecting the most recent work. This is particularly important for postmarket activities, but is also beneficial for premarket activities.
6. Too much/not enough design data included
Not knowing what to put in your DHF can lead to two possible outcomes: either everything gets put in the file, or not enough is included. Both of these situations can impact the organization and clarity of your design files. Looking at 21 CFR 820.30 is a good starting point for remedying this confusion.
The regulation states that your DHF must “contain or reference records necessary to demonstrate that the design was developed in accordance with the approved design plans and the requirements of [21 CFR 820.30].” In other words, documents and data showing your product design is compliant with both the regulation and your identified design and development plan are necessary to include in your DHF. This could include things such as:
- Design verification & validation data
- Essential outputs traces
- Design review plans and results
- Standard operating procedures/work instructions
- Production specifications for design transfer
It is up to your organization to determine what design data and documents make it into your DHF. However, following 21 CFR 820.30 to scope them out is a worthwhile exercise. Making sure these deliverables are well scoped out, included in your design and development plans, and communicated to your team is critical for improving your DHFs.
7. Lack of accountability
Transparency and accountability are important aspects of your DHF. There should be evidence within the file that project data has been authored, altered, or otherwise administered by appropriate personnel. This can include anything from audit trails to management sign-offs to design review data. For both product quality and regulatory oversight, this accountability is key. It allows you to see if and when design issues, changes, data alteration/loss, etc. occur in your development timeline, and—when combined with robust traceability—can help you identify the resulting impact and remediation necessary to resolve the problem.
