Design Controls
Design Controls
Inspectional Objectives
- Select a single design project.
Note: If the project selected involves a device that contains software, consider reviewing the software's validation while proceeding through the assessment of the firm's design control system.
- For the design project selected, verify that design control procedures that address the requirements of Section 820.30 of the regulation have been defined and documented.
- Review the design plan for the selected project to understand the layout of the design and development activities including assigned responsibilities and interfaces.
Note: Evaluate the firm's conduct of risk analysis while proceeding through the assessment of the firm's Design Control system.
- Confirm that design inputs were established.
- Verify that the design outputs that are essential for the proper functioning of the device were identified.
- Confirm that acceptance criteria were established prior to the performance of verification and validation activities.
- Determine if design verification confirmed that design outputs met the design input requirements.
- Confirm that design validation data show that the approved design met the predetermined user needs and intended uses.
- Confirm that the completed design validation did not leave any unresolved discrepancies.
- If the device contains software, confirm that the software was validated.
- Confirm that risk analysis was performed.
- Determine if design validation was accomplished using initial production devices or their equivalents.
- Confirm that changes were controlled including validation or where appropriate verification.
- Determine if design reviews were conducted.
- Determine if the design was correctly transferred.
Design Controls
Narrative
The purpose of the design control subsystem is to control the design process to assure that devices meet user needs, intended uses, and specified requirements. Attention to design and development planning, identifying design inputs, developing design outputs, verifying that design outputs meet design inputs, validating the design, controlling design changes, reviewing design results, transferring the design to production, and compiling a design history file help assure that resulting designs will meet user needs, intended uses and requirements.
1. Select a single design project.
Note: If the project selected involves a device that contains software, consider reviewing the software's validation while proceeding through the assessment of the firm's design control system.
The design control requirements of Section 820.30 of the regulation apply to the design of Class II and III medical devices, and a select group of Class I devices. The regulation is very flexible in the area of design controls. The type of design control system and the precise details of implementation are left for each firm to decide based on the complexity and risks associated with their devices.
If design control requirements are applicable to the operations of the firm, select a design project. Unless the inspection assignment directs the inspection of a particular design project, select a project that provides the best challenge to the firm's design control system. This project will be used to evaluate the process, the methods, and the procedures that the firm has established to implement the requirements for design controls.
Do not inspect a device under design control requirements to determine whether the design was appropriate or safe and effective. This is precluded under Section 520(f)(1)(A) of the Act. However, if based on information obtained during an evaluation of the firm's design controls, it appears that the device is unsafe or ineffective, then report those findings in the EIR.
The requirement for software validation is included in Section 820.30(g) Design Validation. However, if the project selected involves a device that contains software, consider reviewing the software's validation while proceeding through the assessment of the firm's design control system.
If the firm has not completed a design project, has no ongoing or planned design projects, and has not made a design change, proceed to the narrative discussion under Objective 2 and limit your review of design controls to those instructions.
2. For the design project selected, verify that design control procedures that address the requirements of Section 820.30 of the regulation have been defined and documented.
Firms, including small firms and those who design simple devices, who are subject to Section 820.30 of the regulation, are required to define, and document, either in writing or electronically, procedures which address the requirements of the regulation. These procedures serve to set the structure for the firm's design control system.
However, if the firm has not completed any design projects, has no ongoing or planned design projects, and has not made a design change, it is only required to maintain a de-fined and documented design change procedure.
Review the firm's design control procedures and verify that they address the specific requirements of the regulation. As examples, determine if the design input procedures include a mechanism for addressing incomplete, ambiguous, or conflicting requirements; the design output procedures ensure that those design outputs that are essential for the proper functioning of the device are identified; and the design review procedure ensures that each design review includes an individual(s) who does not have direct responsibility for the design stage being reviewed.
In order to determine if the firm's design control procedures have been implemented, use the selected design project to exercise the firm's procedures and accomplish the following objectives.
3. Review the design plan for the selected project to understand the layout of the design and development activities including assigned responsibilities and interfaces.
Note: Evaluate the firm's conduct of risk analysis while proceeding through the assessment of the firm's Design Control system.
The firm's development of concepts and the conduct of feasibility studies are not subject to the design control requirements of the regulation. However, once the firm decides that a design will be developed, a design plan must be established. A firm will determine when it will begin to apply design controls. However, design controls must be applied no later than the time the firm approves its first set of inputs.
Utilize the firm's design plan as a road map for the selected design project. Plans include major design tasks, project milestones, or key decision points. It is not necessary for plans to show starting or completion dates for activities covered by the plan. Plans may vary depending on the complexity of the project and the degree of risk associated with the device. Plans may take the form of a simple flow chart for less complex projects or may be expressed as Program Evaluation and Review Technique (PERT) or Gantt charts for larger projects. However, plans must define responsibility for implementation of the design and development activities and identify and describe interfaces with different groups or activities.
While the requirement for the conduct of risk analysis appears in Section 820.30(g) Design Validation, a firm should not wait until they are performing design validation to begin risk analysis. Risk analysis should be addressed in the design plan and risk should be considered throughout the design process. Risk analysis must be completed in de-sign validation.
When conducting risk analysis, firms are expected to identify possible hazards associated with the design in both normal and fault conditions. The risks associated with those hazards, including those resulting from user error, should then be calculated in both normal and fault conditions. If any risk is deemed unacceptable, it should be reduced to acceptable levels by the appropriate means, for example by redesign or warnings. An important part of risk analysis is ensuring that changes made to eliminate or minimize hazards do not introduce new hazards.
Common tools used by firms to conduct risk analyses include Fault Tree Analysis (FTA), and Failure Modes and Effects Analysis (FMEA).
4. Confirm that design inputs were established.
Inputs are the requirements of a device. They must be documented. Review the sources used to develop inputs. Determine that relevant aspects were covered. Examples of relevant aspects include: intended use, performance characteristics, risk, biocompatibility, compatibility with the environment of intended use including electromagnetic compatibility, human factors, voluntary standards, and sterility.
5. Verify that the design outputs that are essential for the proper functioning of the device were identified.
Design outputs are the work products or deliverables of a design stage. Examples include, diagrams, drawings, specifications and procedures. The outputs from one stage may become inputs to the next stage. The total finished design output consists of the device, its packaging and labeling, and the device master record.
Important linkages to consider are Sections 820.80 Receiving, in-process, and finished device acceptance, 820.120 Device labeling, and 820.130 Device packaging.
Design projects can produce a large volume of records. Not all of the records generated during the project are design outputs and as such do not need to be retained in the design history file. Only approved outputs need to be retained.
Outputs must be comprehensive enough to characterize the device design to allow for verification and validation. Also, design outputs which are essential for the proper functioning of the device must be identified. Typically a risk analysis tool such as FTA or FMEA is used to determine essential outputs. For the selected project, verify that essential outputs have been identified. In addition, review the firm's process for determining how the essential outputs were identified and determine if it was done in accordance with their design output procedures.
Important linkages to consider are Sections 820.50 Purchasing controls, and 820.100 Corrective and preventive action.
6. Confirm that acceptance criteria were established prior to the performance of verification and validation activities.
Verification and validation activities should be predictive rather then empiric. Acceptance criteria must be stated up front. Review the documentation associated with a sample of verification activities and a sample of validation activities as determined using the Sampling Tables. If possible, select activities that are associated with outputs identified as essential to the proper functioning of the device. Confirm that acceptance criteria were established prior to performance of the verification or validation activity.
7. Determine if design verification confirmed that design outputs met the design input requirements.
Design verification activities are performed to provide objective evidence that design output meets the design input requirements. Verification activities include tests, inspections, analyses, measurements, or demonstrations. Activities should be explicit and thorough in their execution. It is the firm's responsibility to select and apply appropriate verification techniques. Complex designs can require more and different types of verification activities than simple designs. Any approach selected by the firm, as long as it establishes conformance of the output to the input, is an acceptable means of verifying the design with respect to that requirement.
Review the documentation of the verification activities associated with a sample of inputs and outputs as determined using the Sampling Tables. If possible, select activities that are associated with outputs identified as essential to the proper functioning of the device. Confirm that design outputs met design input requirements.
8. Confirm that design validation data show that the approved design met the predetermined user needs and intended uses.
Design validation is performed to provide objective evidence that device specifications (outputs) conform with user needs and intended use(s). Design validation must be completed before commercial distribution of the device.
Design validation involves the performance of clinical evaluations and includes testing under actual or simulated use conditions. Clinical evaluations can include clinical investigations or clinical trials, but they may only involve other activities. These may include evaluations in clinical or non-clinical settings, provision of historical evidence that similar designs are clinically safe, or a review of scientific literature. Validation activities must address the needs of all relevant parties (i.e. patient, health care worker, etc.) and be performed for each intended use. Validation activities should address the design outputs of labeling and packaging. These outputs may have human factor implications, and may adversely affect the device and its use.
If possible, review the evaluations (clinical or other activities) performed to assist in validating the device design.
9. Confirm that the completed design validation did not leave any unresolved discrepancies.
Design validation may detect discrepancies between the device specifications (outputs) and the needs of the user or intended use(s) of the device. All discrepancies must be addressed and resolved by the firm. This can be accomplished through a change in design output or a change in user need or intended use.
10. If the device contains software, confirm that the software was validated.
As previously noted, design validation includes the requirement for software validation. If the selected device is software controlled its software must be validated.
11. Confirm that risk analysis was performed.
As previously noted, risk analysis must be completed in design validation.
12. Determine if design validation was accomplished using initial production devices or their equivalents.
Initial production units, lots, or batches, or their equivalents are to be used in design validation. Confirm that such production devices or their equivalents were used by reviewing the design validation documentation. If production devices were not used, the firm must demonstrate equivalency to production devices. When the so called "equivalent" devices are used in design validation the manufacturer must document in detail how the device was manufactured, and how the manufacturing is similar and possibly different from initial production. Where there are differences, the manufacturer must justify why design validation results are valid for production units, lots or batches. The regulation is flexible and it does allow for the use of equivalent devices, but the burden is on the manufacturer to document that the units were indeed equivalent.
Process validation may be conducted concurrently with design validation. Production devices used in design validation may have been manufactured in a production run during process validation.
13. Confirm that changes were controlled including validation or where appropriate verification.
Change control is not a new requirement. The 1978 GMP regulation Section 820.100(a)(2) required approval of changes made to specifications after final design transfer (post-production changes). The Quality System regulation clarified and relocated the requirement into Section 820.30(i). It expanded the requirement to include changes made during the design process (pre-production changes).
The documentation and control of design changes begin when the initial design inputs are approved and continues for the life of the product. Examples of the application of change control include: changes made to approved inputs or outputs such as to correct design deficiencies identified in the verification and validation activities; labeling changes; changes which enhance the device's capabilities or the capabilities of the process; and changes resulting from customer complaints.
Product development is inherently an evolutionary process. While change is a healthy and necessary part of product development, quality can be ensured only if change is controlled and documented in the development process, as well as in the production process.
The degree of design change control is dependent on the significance of the change and the risk presented by the device. Manufacturers may use their routine post-production change control procedure for pre-production design changes. However, most post-production change control procedures may be too restrictive and stifle the development process. Firms may use a separate and less stringent change control procedure for pre-production design changes.
Post-production design changes require the firm to loop back into the design controls of Section 820.30 of the regulation. This does not mean that post-production changes have to go back to the R&D Department for processing. This track is dependent on what the firm specifies in their change procedure. It is acceptable for the manufacturing department to process the entire design change and to implement the controls of Section 820.30.
The design change control section is linked to and is redundant with Section 820.70(b) Production and process changes of the regulation.
All design changes must be verified. Design changes must also be validated unless the performance of only verification can be justified and documented by the firm. Where a design change cannot be verified by subsequent inspection and test, it must be validated. For example, a change in the intended use of the device will require validation. However, if a firm was making a design change in the material used in the device, then verification through analysis may only be required. The burden is on the firm to justify and document why verification only is appropriate in lieu of validation.
Review a pre-production and a post-production design change.
14. Determine if design reviews were conducted.
Formal design reviews are planned and typically conducted at the end of each design stage or phase, or after completion of project milestones. The number of reviews is dependent on the complexity of the design. A single review may be appropriate at the conclusion of the design project for a simple design or a minor change to an existing product. Multiple reviews are typically conducted for projects involving subsystems or complex designs.
Design reviews should provide feedback to designers on existing or emerging problems, assess the progress of the design, and confirm the design is ready to move to the next phase of development. Reviews should focus on the ability to produce the design and whether the design meets the input requirements.
The design review process should account for risk analysis and change control where relevant.
Full convened meetings with an agenda, minutes, etc. need not take place for all design reviews. Meetings may not be necessary for reviews involving simple designs or minor changes. In these cases desk reviews and sign-offs by the various organizational components including an individual not having direct responsibility for the design stage being reviewed may be appropriate. However, such reviews must still be documented and covered by defined and documented procedures.
Review the records of one design review and confirm that the review included an individual without direct responsibility for the design stage being reviewed. Also, confirm that outstanding action items are being resolved or have been resolved.
15. Determine if the design was correctly transferred.
The transfer process must be a part of the design plan. It is not uncommon for the design to be transferred in phases. Production specifications typically consist of written documents such as assembly drawings, inspection and test specifications, and manufacturing instructions. However, they can also consist of electronic records, training materials such as video tapes or pictures, and manufacturing jigs and molds.
Review how the design was transferred into production specifications. Review the device master record. Sample the significant elements of the device master record using the Sampling Tables and compare these with the approved design outputs. These elements may be chosen based on the firm's previously identified essential requirements and risk analysis.