SECTION I. DESIGN CHANGES FOR MEDICAL DEVICES

SECTION I. DESIGN CHANGES

I. REQUIREMENTS

§ 820.30(i) Design changes.

• Each manufacturer shall establish and maintain procedures for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation.

Cross-reference to ISO 9001:1994 and ISO/DIS 13485 section 4.4.9 Design changes.

II. DISCUSSION AND POINTS TO CONSIDER

There are two principal administrative elements involved in controlling design changes:

• Document control-enumeration of design documents, and tracking their status and revision history. Throughout this section, the term "document" is used in an inclusive sense to mean all design documents, drawings, and other items of design input or output which characterize the design or some aspect of it.
• Change control-enumeration of deficiencies and corrective actions arising from verification and review of the design, and tracking their resolution prior to design transfer.

For a small development project, an adequate process for managing change involves little more than documenting the design change, performing appropriate verification and validation, and keeping records of reviews. The main objectives are ensuring that:

• corrective actions are tracked to completion;
• changes are implemented in such a manner that the original problem is resolved and no new problems are created; or if new problems are created, they are also tracked to resolution; and
• design documentation is updated to accurately reflect the revised design.

For projects involving more than two persons, coordination and communication of design changes become vitally important. In other words, manufacturers should take steps to avoid the common situation where, for example, Jon and Marie agree to a make a change but neglect to inform Pat of their decision.

Medical device manufacturers are usually quite comfortable with the processes of document control and change control with respect to managing manufacturing documents. The principles of these processes are reviewed in the following paragraphs. Subsequently, we will explore how these may be applied to design activities.

DOCUMENT CONTROL. The features of a manufacturing document control system typically include the following:

• Documents should be identified (i.e., named and numbered) in accordance with some logical scheme which links the documents to the product or component they describe or depict and illuminates the drawing hierarchy.
• A master list or index of documents should be maintained which presents a comprehensive overview of the documentation which collectively defines the product and/or process.
• Approval procedures should be prescribed which govern entry of documents into the document control system.
• A history of document revisions should be maintained.
• Procedures for distributing copies of controlled documents and tracking their location should be prescribed.
• Files of controlled documents should be periodically inventoried to ensure that the contents are up to date.
• A person or persons should be assigned specific responsibility to oversee and carry out these procedures. It is desirable that the document control system be administered by a person who is not directly involved with developing or using the documents. For a small manufacturer, document control might be a part-time job for a technician or clerical staff person. More typically, one or more librarians or full-time clerical or paraprofessional employees are required to administer the system.
• There should be a procedure for removal and deletion of obsolete documents.

CHANGE CONTROL. Manufacturing change control is usually implemented using a set of standardized procedures similar to the following:

• A change request might be originated by a developer, manager, reviewer, marketing representative, user, customer, quality assurance representative, or production personnel, and identifies a design problem which the requester believes should be corrected. Change requests are typically reviewed following the manufacturer's prescribed review process, and the request might be rejected, deferred, or accepted.
• If a change request is accepted and corrective action is straightforward, a change order might be issued on the spot to implement the change. The change order pertains to an explicitly identified document or group of documents, and specifies the detailed revision of the document content which will fix the identified problem.
• Often, the change request results in an assignment to developers to further study the problem and develop a suitable corrective action. If the change is extensive, wholesale revision of affected documents may be warranted in lieu of issuing change orders.
• Change requests and change orders should be communicated to all persons whose work might be impacted by the change.
• It may not be practical to immediately revise documents affected by a change order. Instead, the common practice is to distribute and attach a copy of the change order to each controlled copy of the original document.
• Change control procedures should incorporate review and assessment of the impact of the design change on the design input requirements and intended uses.
• A mechanism should be established to track all change requests and change orders to ensure proper disposition.
• Change control procedures are usually administered by the document control staff.

APPLICATION OF DOCUMENT AND CHANGE CONTROLS TO DESIGN. The design control system has to be concerned with the creation and revision of documents, as well as the management of finished documents. Additional mechanisms are required to provide needed flexibility while preserving the integrity of design documentation. These additional mechanisms are embodied in the procedures for review and approval of various documents.

It is important that the design change procedures always include re-verifying and re-validating the design. Fortunately, most design changes occur early in the design process, prior to extensive design validation. Thus, for most design changes, a simple inspection is all that is required. The later in the development cycle that the change occurs, the more important the validation review becomes. There are numerous cases when seemingly innocuous design changes made late in the design phase or following release of the design to market have had disastrous consequences.

For example, a manufacturer encountered problems in the field with a valve sticking in a ventilator due to moisture in the breathing circuit. The problem was resolved by slightly increasing the weight of the disc. Since the change was minor, minimal testing was performed to verify the change. Subsequently, when the revised valves entered production, significant numbers of valves began failing. Investigation revealed that the heavier disc was causing the valve cage to separate due to higher inertia. This failure mode was more serious than the original sticking problem, and resulted in a safety recall.

SECTION J. DESIGN HISTORY FILE (DHF)

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.