SECTION J. DESIGN HISTORY FILE (DHF)

Posted on January 26, 2012. Filed under: Uncategorized |


I. REQUIREMENTS
§ 820.30(j) Design history file.
  • Each manufacturer shall establish and maintain a DHF for each type of device.
  • The DHF shall 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.
Cross-reference to ISO 9001:1994 and ISO/DIS 13485 section 4.16 Control of quality records.
II. DEFINITIONS
§ 820.3(e) Design history file (DHF) means a compilation of records which describes the design history of a finished device.
III. DISCUSSION AND POINTS TO CONSIDER
There is no specific requirement in ISO 9001 or ISO 13485 for a design history file. However, in order to market a medical device in the United States, a manufacturer must comply with the U. S. Food and Drug Administration (FDA) quality system regulation, which requires a design history file. For this reason, some guidance is provided on the U. S. FDA design history file.
Other national regulations require some form of documentation and records. Product documentation required by Canada, Europe, and Japan contain certain elements of the U. S. FDA design history file requirements without requiring all the elements to be compiled in a file.
Virtually every section of the design control requirements specifies information which should be recorded. The compilation of these records is sometimes referred to as the design history file. Throughout this guidance document, suggestions are made when warranted as to the form and content of documents contained in the design history file.
The primary beneficiary of the device history file is the device manufacturer. For example, in one case, a microprocessor-controlled enteral feeding pump was reported to be behaving erratically in the field. Some of the symptoms pointed to software problems. But the manufacturer admitted that they did not possess a copy of the software source code for the product. The software had been developed by a contractor who had delivered only a master EPROM (memory chip) which was duplicated by the manufacturer to install the software in each machine. The contractor had subsequently withdrawn following a contractual dispute, leaving the manufacturer with no rights to the source code developed by the contractor, and no practical way to maintain the software. For this and other reasons, the product was the subject of a mandatory recall and all known units were collected and destroyed.
This is admittedly an extreme case, but many similar cases have been documented in which the manufacturer lacked design information necessary to validate a design and maintain it throughout the product life cycle. This occurs for the most innocent of reasons-contracts expire, companies reorganize, employees move on to new projects or new jobs. Even when the designer is available, he or she may forget why a particular decision was made years, months, or even weeks before. Since design decisions often directly affect the well-being of device users and patients, it is to the manufacturer’s benefit to maintain the knowledge base which forms a basis for the product design.
Except for small projects, it is unusual for all design history documents to be filed in a single location. For example, many design engineers maintain laboratory notebooks which are typically retained in the engineers’ personal files. In addition, the design history may include memoranda and electronic mail correspondence which are stored at various physical locations. Quality system plans applicable to a development project may reside in the quality assurance department, while the chief engineer may be responsible for maintaining design and development plans. These diverse records need not be consolidated at a single location. The intent is simply that manufacturers have access to the information when it is needed. If a manufacturer has established procedures for multiple filing systems which together satisfy that intent, there is no need to create additional procedures or records.
As an example of the level of detail which may be entailed, some manufacturers have policies covering laboratory notebooks. Manufacturers typically find that without such written procedures, a breakdown in communications eventually occurs, resulting in a loss of control. These procedures might address the following points.
  • Laboratory notebooks are the property of the manufacturer, not the individual.
  • A separate notebook is to be maintained for each project, and surrendered to the engineering librarian at the conclusion of the engineer’s active participation in the project.
  • Laboratory notebooks are to be surrendered if the employee leaves the company.
  • Product development supervisors shall review employees’ laboratory notebooks at specified intervals to ensure that records are complete, accurate, and legible.
There are no requirements on the location or organization of the design history file. In some cases, especially for simple designs, the designer will assemble and maintain the entire design history file. For larger projects, a document control system will likely be established for design documents, and these files will likely be maintained in some central location, usually within the product development department.
Based on the structure (or lack thereof) of the product development organization, more or less extensive controls will be required. For example, company policy should state unequivocally that all design history documentation is the property of the manufacturer, not the employee or contractor. Design and development contracts should explicitly specify the manufacturer’s right to design information and establish standards for the form and content of design documentation. Finally, certain basic design information may be maintained in a single project file in a specified location. This may include the following:
  • Detailed design and development plan specifying design tasks and deliverables.
  • Copies of approved design input documents and design output documents.
  • Documentation of design reviews.
  • Validation documentation.
  • When applicable, copies of controlled design documents and change control records.

Make a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Liked it here?
Why not try sites on the blogroll...

%d bloggers like this: