Design controls

From Self-sufficiency
Jump to: navigation, search

Design Controls is a system of procedures that the Food and Drug Administration (FDA) requires that medical device developers establish to validate, verify, and control the development process of medical devices. Formulated in 1996, Design Controls (21 CFR 820.30) has 9 parts:

  • Design planning
  • Design input
  • Design output
  • Design review
  • Design verification
  • Design validation
  • Design transfer
  • Design changes and
  • Design history file

The objective of Design Controls is to demonstrate compliance to the various "tests" imposed by the Code which would then suggest a minimal, but acceptable, level of medical device efficacy and safety.

Design Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interface with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed, updated, and approved as design and development evolves.

Design Control is intended to be a prospective activity in the development process. Companies that use a planning period in their development projects realize the benefits of on-time delivery and reduced risk of project failure.

An important part of the Design and Development Plan is the assignment of tasks and activities to responsible parties and the means of communication between them. The plan also must be a documented process with its own set of reviews and approvals.

Design Input

Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The design input requirements shall be documented and shall be reviewed and approved by a designated individuals. The approval, including the date and signature of the individuals approving the requirements, shall be documented.

Design input is defined as the physical and performance requirements of a device that are used as a basis for device design. Some manufacturers mistakenly assume that the user needs as gathered by marketing are sufficient as design input requirements. While these inputs may serve as a good starting point for developing design inputs, they are insufficient. These types of input tend to be qualitative and do not provide the detail necessary to serve as the basis for the design. It is important that the design input requirements be quantitative in nature; they must be easily measured and have quantitative limits.

Common sources of design input include: customer complaints, medical device reporting, service reports, corrective action/preventive action, sales feedback, marketing surveys, user conferences, competitor products, standards, and journal publications. It is important to note that once the design input requirements are defined, any changes must be implemented according to the change control procedures in place.

Design Output

Each manufacturer shall establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements. Design output shall be documented, reviewed, and approved before release. The approval, including the date and signature of the individuals approving the output, shall be documented.

The design output clearly refers to the finished device at the end of the development cycle. However, it is not limited to just the finished device. The design output includes all documentation of the activities performed during the development process that verify that the design input requirements were met. Further, any item that serves as a basis for the finished device specifications are considered design output. It is not uncommon that the design output from one phase of development serves as the design input for the next. The culmination of the design output is the completed Device Master Record that fully specifies the device, its packaging, and labeling. Per the Quality System Regulation, the Device Master Record is subject to formal change control.

Design Review

Each manufacturer shall establish and maintain procedures to ensure that formal documented reviews of the design results are planned and conducted at appropriate stages of the device’s design development. The results of a design review, including identification of the design, the date, and the individuals performing the review, shall be documented in the Design History File.

Formal design reviews are critical to the efficacy of Design Control, and ultimately, the market success of the device. They should be planned for up-front in the Design and Development Plan. Changes late in the design cycle are much more costly than those made early on. Design reviews can play an important role in identifying changes in a timely manner so as to prevent costly, non-optimal redesigns close to the launch date.

The Quality system Regulation specifies the need for an independent reviewers. This individuals must be far enough removed from the design so as to be able to provide an objective review.

Design Verification

Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, methods, date, and the individuals performing the verification, shall be documented in the Design History File.

Design verification is the process by which design outputs are compared to design input requirements to determine whether they have been met. Design verification may take a number of different forms. Risk analysis is often considered to be part of design verification and will commonly take the form of a Failure Mode and Effects Analysis. Bench-top tests and quality inspections are also common forms of verification and may serve as mitigating actions as part of the Failure Mode and Effects Analysis. A design matrix (a table in which the design inputs are matched with the design outputs) is another tool used in design verification.

Design verification precedes design validation and is not a substitute. The two are distinctly different and should be treated as such. The Quality System Regulation defines design verification as confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.

Design Validation

Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate. The results of the design validation, including identification of the design, methods, the date, and the individuals performing the validation, shall be documented in the Design History File.

According to the Quality System Regulation, validation testing must be performed on actual production units or their equivalents. When equivalents are used, the manufacturer must provide documentation that clearly demonstrates the equality. There can be a tendency to manufacture test units under special conditions that do not mimic actual production. An example would be the manufacturing engineer performing final assembly on a device where this would normally be done by a manufacturing operator. The manufacturing engineer’s skill level and knowledge base are most likely different from those of the operator. Companies should strive to produce their test units in an environment as close to the final production environment as possible.

Design Transfer

Each manufacturer shall establish and maintain procedures to ensure that the device design is correctly translated into production specifications. At minimum, the design transfer procedures must in some way assess the completeness and correctness of the production specifications. Furthermore, the specification must be reviewed and approved and placed under the formal change control process. Perhaps most importantly, the procedures must ensure that product is manufactured only to the latest, approved revision of the Device Master Record.

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. Once the design input requirements have been finalized and approved, any changes to the input requirements are subject to formal change control. Furthermore, once the design output specifications have been verified and validated, any changes also require formal change control. This entails documenting and evaluating every design change that occurs. This does not mean that all design changes are handled with the same level of scrutiny, but it does mean that some level of documentation and evaluation is required with every change.

Design History File

Each manufacturer shall establish and maintain a Design History File for each type of device. The Design History File shall contain or reference the necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements part. The Design History File is intended to serve as a repository for all of the documentation generated as a result of following the Design process. In each of the preceding sections, an element of Design Control was discussed. Each element produces one or documents that should reside in the Design History File.

The Design History File, when assembled properly, serves as a complete record of the design and will likely be referenced throughout product. Manufacturers that fail to adequately document the design and maintain the Design History File are likely to face a heavy burden question arises about the design integrity long after the product has launched.

References and external links