How to Prepare a Design History File for FDA Inspection

Food and Drug Administration (FDA) inspections are stressful, especially if your documentation isn’t audit-ready. Creating and maintaining a compliant design history file (DHF) will help ensure that when the time comes, you’ll be ready for an FDA inspection that results in minimal findings.

It’s not uncommon for DHFs to be lacking, especially when the product development process doesn’t have a strong emphasis on regulatory requirements. Device designers are focused on what they do best, not necessarily prioritizing documenting design controls along the way. The more proactive you can be, the fewer issues will arise. Don’t wait until a surprise inspection to learn that your DHF needs some work.

Elements for Inclusion in Your Design History File

A DHF is the complete record of the design and development of a device—“complete” is the keyword here. The FDA is looking for the DHF to, “contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part." The FDA will look at your design controls procedure and ensure it includes the following elements:

• Design and development plan
• Design input
• Design output
• Design review
• Design verification
• Design validation, with software validation if applicable
• Design transfer
• Design changes

In addition to these components, including a description of the file with the product it pertains to, the documents that are included in the file, and the complete history of the design. Include all relevant elements such as:

• Device development
• Accessories
• Major components
• Labeling
• Packaging
• Manufacturing process

Because the DHF is the collection of this documentation showing the evolution of the design, it must be assembled and updated properly because it will be referenced throughout the life of the product. When maintaining a DHF, medical device companies must assess it for changes even beyond the development phase to ensure it accurately represents the product being delivered.

Activities and Deliverables by Design Controls Stage

Concept development

There are no specific deliverables at this stage, but any animal or clinical studies should be documented in case they are included in a future 510(k). Develop and document a clinical trial strategy if needed for verification and validation testing. The risk management team should research complaints about similar devices and identify any initial hazards that could influence the design process. At this stage, a pre-IDE meeting with the FDA is also encouraged. 

Design and development planning

Design control activities officially begin at this stage. Create a design and development plan that describes all of the activities that will be completed as part of design controls and that demonstrates that adequate resources and time will be committed to these activities to ensure the development of a safe and effective product. Periodically update the plan throughout product development. It should tell the story of the product’s development, from design input through transfer to manufacturing. In an FDA audit, the plan is typically one of the first documents to be requested and provides the auditor with a road map of design and testing. Solidify marketing requirements and other inputs, including user needs which will link to formal product requirements.  And keep in mind that every design change requires a plan, and design change plans are often reviewed in FDA inspections.

Design input

Design input includes development and formal documentation of product requirements and system architecture design and software development planning. Consider using a design trace matrix that will eventually connect user needs with design inputs and outputs, verification, and validation references. Document product requirements and have them formally reviewed and approved by a cross‐functional team. Establish a solid set of requirements before proceeding to a detailed design. The design input set should be complete, unambiguous, not in conflict, and able to be verified or validated.

Safety risk management per ISO14971 begins in this phase with a safety risk management plan and initial identification of patient or user harm that could result from proper use and foreseeable potential misuse of the product/system. Control of any significant risks should be included as design inputs. Begin documentation of the human factors plan and associated activities, including the definition of device user profiles (patient, family member, nurse, technologist, or physician), use environment, typical and atypical device use, and usability objectives.

Design output

At this stage, product requirements are translated into detailed design specifications, drawings, code, labeling, and so on, with the final design output being the product itself. This also includes software requirements specification, software design specifications, design and code reviews, detailed hazard analysis, and the verification and validation plan. The verification plan identifies the required tests and analysis, a preliminary trace to requirements, resources needed, the timeline, and risk areas or concerns. The validation plan identifies the methods to ensure that user needs have been adequately satisfied and should be done with a product representative of the final configuration/system.

Verification and validation testing

The stage includes the development and review of individual test protocols, verification of product requirements, and safety risk management controls. Reports are documented and include details of deviations and software anomalies. Deliverables at this stage also include the validation of manufacturing equipment and software.

Design transfer

The design history file for the product is complete and the design is transferred to manufacturing. The device master record (DMR)—the comprehensive recipe for manufacturing the product and includes drawings, software, procedures, work instructions, test plans, and so forth—must be complete before the start of production.

Post-market surveillance

At this stage, you must document and analyze customer complaints and reported product failures. Conduct design changes to correct issues and follow a design change procedure including, if necessary, design and development planning through to design transfer and any regulatory compliance steps.

Best Practices for Preparing a Design History File

By following a few best practices, you can help ensure that your DHF is always audit-ready. 

Use FDA resources

Review the FDA’s Guide to Inspections of Quality Systems to learn what the agency is specifically looking for in terms of management, design, production and process controls, and corrective and preventive actions (CAPAs). Look in the design controls section for guidance on DHF, which identifies 15 steps for verifying compliance with design control requirements in 21 CFR 820.

Perform a gap analysis for every product 

FDA can choose any DHF to review, so all of them should always be audit-ready. A gap analysis should be performed by a party that understands the device, design controls, and what regulators look for.

Go digital

If you currently use a paper-based process, consider upgrading to a digital system that enables easier tracking and updating. Inspectors will appreciate the ease of use and better organization.

Start early and be consistent

Don’t wait until late in the design process to create your DHF. Start it in predesign and follow quality system regulation (QSR) design controls. This saves time on document remediation and is more efficient than retroactively creating the file. Being consistent and adding documents as development occurs also ensures that your DHF is more complete and accurate. Gather input from production, regulatory, and quality functions early for a smoother transition to final production release.

Document as much as possible

More information is better, so be sure to include:

• Initial sketches
• Reasoning for material selection
• Prototypes
• Testing protocols
• Failures
• Bench testing and other preclinical work
• Validation and verification activities
• Design changes

Plan your timeline

When the project schedule is tight due to overruns along the way, there is a tendency to compact the verification and validation schedule at the end of the development process. Consider this in the planning stage and have contingencies for overruns built-in.

Remember the business benefits

Rather than viewing DHF creation and maintenance as a regulatory chore, think of the benefits it offers your business. Having a thorough and complete DHF provides a long-term memory for future designers to reference and the reasoning behind decisions in the design process. Failure studies also help avoid future mistakes and can be referenced in the event of issues with the device.

Consider participating in MDSAP

The Medical Device Single Audit Program (MDSAP) provides a prescriptive process that is easy to follow and a predictable audit schedule so you can always be prepared. The audit time is also predictable and based on the scope of your quality management system. One of the primary benefits of having MDSAP certification is that it allows you to forgo other FDA inspections, except for cause.

How RQM+ Helps with DHFs

RQM+ has subject matter experts, former regulators, and medical device auditors on staff, so we know what FDA looks for in a design history file. We provide business-balanced strategies that consider your goals and expert implementation to keep you in compliance. We also have experienced design quality engineers who understand your devices and can actively participate in new product development teams.

If you would like help remediating a design history file or starting one early in the development process, contact us to schedule a consultation.