Design History Files
Section 820.3(e) in the QSR defines Design History File (DHF) as “a compilation of records which describes the design history of a finished device.” This definition is vague and therefore creates an opportunity for compliance issues. To avoid this, you should focus on two aspects of the definition. First, you should define which records comprise the DHF.
The list below is what your FDA inspector will be looking for:
Tracking of design changes in the DHF
- Design plan
- User needs
- Design inputs
- Design outputs
- Risk analysis, including hazard identification
- Human factors analysis
- Design verification, with acceptance criteria
- Design validation, with acceptance criteria
- Design changes
- Software validation—if applicable
- Design reviews
- Design transfer
Tracking design changes is a common weakness in most companies—regardless of the stage of the design process. One of the key reasons for closing the DHF after transfer has occurred is to facilitate tracking of changes. The DMR Index is first created when the DHF is closed. At this stage the revision of the DMR is revision “A” or “1”—depending upon your revision system. If the DMR is an index, then you will have a couple of pages of index followed (or preceded) by the revision history. Every time a design change is made, one of the documents in the DMR will need to be revised. Therefore, the revision history of the DMR Index will identify each change. If your system is paper-based, the length of the revision history will quickly become longer than the DMR Index. However, if you are using Master Control to manage your DMR then the length of the revision history is irrelevant.
During the design process, most design teams make minor changes throughout the development process prior to verification activities. However, many of these minor changes fail to be captured in the DHF because the documents are not yet under document control. Typically, the only changes I see captured during the development process are those changes made to drawings at the later stages of development—often after verification activities are well under way.
Not every change is worthy of documenting in your DHF.
I recommend the following criteria for deciding if a change should be documented in the DHF:
- Did the design plan change?
- Did a design input change?
- Did a design output change?
- Was the risk analysis affected?
You cannot have a change that affects verification or validation activities that doesn’t meet at least one of these four criteria. If any of these criteria are met, the change is significant enough that I recommend documenting it in the DHF. If all four documents are under engineering revision control during the design process, then you can document the change by changing the engineering revision.