Remediation of Medical Device Design History File
Written by Richie Christian
Introduction
The complexity of medical device development often results in deviations from quality system expectations. A frequent challenge experience by development teams is inadequate design controls that leads to Design History File (DHF) debt. This white paper addresses the issue of DHF debt and how to resolve this debt through DHF remediation. It also addresses the reasons for DHF debt and best practices for effective remediation.
DHF: More than an infamous acronym
Medical device quality and regulatory requirements demand controlled design and development. Depending on the context, this can involve stage-gate control in a waterfall model, or incremental / evolutionary approach for developing software using Agile methodologies. Regardless of the model used, an artifact of controlled design is a Design History File, also known as a DHF. The term DHF will soon become obsolete due to the FDA’s new quality management system regulation, but I will stick with it in this article series.
The DHF is a compilation of documents that contain how the device was designed and ultimately verified and validated prior to its production for human use. It is a result of the application of a controlled design process, achieved through careful and methodical execution of design controls by a cross-functional team. The DHF is a broad term and includes results of other concurrent activities during design and development, such as risk management, usability engineering, software development, security risk management, and AI/ML model development and evaluation.
IEC 62304, the international standard for medical device software development, provides a helpful framework for understanding processes, activities, tasks, and deliverables during the software development process. It is important to note that documentation (which is part of what the standard calls “deliverables”) is an output of applying processes, undertaking activities, and completing tasks. The concept is visualised in Figure 1 below and can be applied to design controls instead of only software development.
tasks and deliverables per IEC 62304
DHF Debt
Technical debt in software represents the future cost of prioritizing speed over optimal design or implementation. The short-term benefits come with accruing “interest” in the form of extra work needed later. There are many reasons why technical debt exists, some of which could be intentional. Regardless, the concept of technical debt very much applies in the context of DHF.
Development without documentation does not exist in the realm of medical device development. In an ideal world, the DHF would be created concurrently with design controls. However, in reality, DHF documentation often lags development. The result is DHF debt, where the DHF neither reflects the actual state of design and development nor meets quality system and regulatory requirements. Like technical debt, DHF debt may be caused by time pressure, tight deadlines, insufficient up-front planning, lack of alignment between development and quality teams, or lack of knowledge.
In mature organisations, DHF debt may be permitted within design controls; however, stringent processes ensure debt is paid in a planned and controlled manner (i.e., interest is accrued intentionally but paid in full and on time). In contrast, teams unfamiliar with design control requirements may accidentally create DHF debt due to lack of knowledge or unforeseen challenges. If left unaddressed, DHF debt can lead to serious quality issues, potentially impacting an organization’s ability to obtain or maintain market access.
To illustrate this point further, Figure 2 below shows an arbitrary number of DHF documents (or their quality) against time when actual design and development has occurred under adequate, partial, or no design controls. DHF debt is the delta between adequate design controls and partial or no design controls.
DHF Remediation: The solution to DHF debt
DHF remediation is an activity that addresses DHF debt. DHF remediation usually addresses DHF debt that has accumulated over a long period of time, resulting in significant deviations from quality system and regulatory requirements. The focus of this white paper is on DHF remediation due to accidental debt.
It is important to note that the goal of DHF remediations may not be to simply create new documentation but also to improve the quality of existing documentation due to significant deficiencies. Therefore, DHF remediation is likely to involve more than just “documentation exercise”. Depending on the extent of DHF debt, remediation may require either complete creation of a new DHF or significant updates to parts of an existing DHF.
The table below includes common examples of DHF debt for specific areas of the DHF for an AI/ML-based SaMD.
| Product Development | Design inputs do not include requirements from regulatory requirements, international standards, and outputs of risk management. |
| Software Development | Inadequate application of software development process rigour due to incorrect software safety classification. |
| Risk Management | Inadequate risk assessment as a result of relying solely on FMEA to manage risks. |
| Usability Engineering | Usability engineering activities per IEC 62366-1 have not been completed during design and development. |
| Security Risk Management | Security risks from relevant threat sources have not been evaluated in a threat model. |
| AI/ML | Performance of the AI/ML model is not generalisable to clinically and technologically relevant subgroups. |
Reasons DHF Remediations are Required
DHF remediations may be necessary for many reasons. Some of the most common reasons are outlined below.
Lack of Awareness of Design Control Requirements
Early-stage companies often lack internal quality and regulatory expertise and may not recognize the need for external support. This can be further exacerbated by misunderstanding of, and unfamiliarity with, regulatory standards for SaMD. This ultimately leads to retroactive implementation of design controls.
Non-compliant Design Controls Processes
Another reason might be that design control processes exist but there are significant deviations from quality and regulatory requirements, resulting in major non-conformances. These deficiencies are usually identified via audits (first, second- or third-party audits). As part of corrective action plans, companies are not only required to address quality system non-conformances within procedures but also required to address deficiencies in the DHF through DHF remediation.
Review of technical file during regulatory review also often leads to identification of major deficiencies in the DHF. This is especially true for first-time submissions where deficiencies are not addressed prior to submission. Addressing deficiencies after submission requires DHF remediation of the affected areas of the DHF, including design verification and validation activities.
Evolving Regulatory Landscape
Changes in regulations, particularly for previously self-certified Class I devices that now require stricter conformity assessment, can trigger DHF remediation.
Misclassification of Software as a Medical Device
Early-stage companies may not realize their healthcare software fulfils a medical purpose after development is well underway. The initial misclassification of the healthcare software requires retroactive application of design controls through DHF remediation.
Corporate Restructuring
Mergers and acquisition may require consolidation of DHFs from different companies.
Common Pitfalls with DHF Remediations
While DHF remediations are necessary to address regulatory compliance, it's crucial to avoid common pitfalls that can hinder effective implementation.
Treating Remediation as a Documentation Exercise
Focussing on documentation whilst avoiding re-engineering at all costs is a mistake made frequently. As noted in the previous article, documentation is a key artifact of the design controls process. However, it is not uncommon for DHF remediations to require more than simply documenting what was done.
Working in Silos
Design controls is a shared responsibility. It is a collaborative effort that requires expertise from regulatory affairs, engineering, clinical, marketing, and product teams. However, remediation effort is often led by quality teams in a silo. This isolation is a missed opportunity for truly effective remediation where cross-functional teams could bring their knowledge and expertise to build a safer and more effective device.
Lack of Planning
DHF remediation projects can be significant undertakings that usually take months to complete. They require careful planning and resource allocation. Without proper planning, remediation projects can be delayed or even abandoned due to competing priorities.
Effective Remediation Strategies
Having explored reasons for DHF remediations and common pitfalls, I will now discuss some effective remediation strategies.
Planning
Whether it’s establishing a QMS or performing design verification, planning is key to ensuring desired outcomes are reached. DHF remediations are no different. Planning can be documented as a Quality Plan (5.4.2 of ISO 13485) or project-specific plan within the DHF.
Remediation plans can differ depending on the nature and complexity of the project; however; the following aspects should be considered:
- The goals expected to be achieved through the remediation project
- Project lead and their responsibilities
- Composition of the cross-functional team and their responsibilities
- Timelines for key milestones, design reviews, and expected completion
- Interface of remediation activities with ongoing updates to the DHF
- Definition of done (i.e., when the remediation project can be considered complete)
Holistic Approach
Maintaining a holistic perspective is crucial during remediation projects. While focusing on the primary objective, it is important to consider ancillary updates that add value and enhance the overall quality of the DHF. For instance, risk management remediation might necessitate revisions to design inputs beyond those directly linked to risk controls.
Regulatory Change Assessments
DHF remediations could lead to changes to the device design. Therefore, it is important to ensure regulatory change assessments are performed to determine regulatory reportability of significant modifications that may impact device safety and effectiveness.
Tell a Story
Following extensive updates, DHF remediation efforts can appear complex to external parties. Therefore, a comprehensive final review report is crucial to tell a complete project story. It confirms completion of planned activities, documents any changes or deviations, and formally verifies the "definition of done". Finally, this report streamlines project reviews during internal or external audits.
Conclusion
The DHF is a cornerstone of medical device quality and regulatory compliance, serving as a comprehensive record of a device's design, verification, and validation. The emergence of DHF debt, analogous to technical debt in software development, arises when documentation lags behind the actual development process, leading to a DHF that fails to accurately represent the device or meet regulatory expectations. To address this critical issue, DHF remediation is essential, often requiring more than just documentation and potentially involving significant updates to an existing DHF.
DHF debt can be addressed successfully through DHF remediation strategies that emphasize thorough planning, maintaining a holistic perspective by considering broader impacts, performing regulatory change assessments, and ultimately, clearly documenting the entire remediation process to tell a comprehensive story for internal and external reviewers. Ultimately, proactive DHF management and diligent remediation when necessary are vital for ensuring medical device safety, effectiveness, and continued market access.
About the Author
This white paper was authored by Richie Christian, a Medical Device Consultant at wega Informatik where he helps teams secure FDA clearances and build quality systems that work. He has 11+ years’ experience in medical device quality management systems and regulatory affairs and is driven by a simple belief: the MedTech community deserves clear, practical guidance without the fluff.
About wega
wega Informatik is a service provider specialised in the Life Science, Pharma and MedTech industries.
Our unique combination of Business, Process and IT knowledge enables us to fulfil our demanding mission: “Building the bridge between business and IT”.
We are a team of more than 100 consultants across Europe, serving more than 100 active customers ranging from startups to large organisations across the medical device and pharma industries.
We specialize in navigating the intricate world of medical device software regulations. Our seasoned experts seamlessly blend their deep understanding of modern software development with the nuances of regulatory requirements.
We have successfully helped our clients with DHF remediation projects for their innovative software-based medical devices. Consult our medical device experts in for customised DHF remediation strategies.