The path of a medical device from idea to final application can seem quite long. However, first and foremost, the most important feature is that medical devices are designed and developed safely. Therefore, regulatory agencies, such as the FDA, the European Commission and others, require assurance that the manufactured medical device is safe and fulfills its purpose according to specified standards. Only then can it be placed on the market. And this is what Design Controls are all about – proving that a medical device is safely and effectively designed and meets the necessary requirements. Therefore, Design Controls are a set of quality methods and procedures to control the process and ensure that the device meets the user needs, intended purpose and specific requirements.
Design Controls
The term design controls originates from the FDA regulations, but is also mentioned in a modified form in ISO 13485. Almost the same terms are used there. But whether you meet the requirements of the FDA or the ISO, both sets of regulations require complete documentation throughout the entire process and are very similar to each other. The main goal is to create and maintain procedures to guide the development of the device. In this context, “create” means to define, document, and implement the procedures. These should guide the development process to ensure that all medical devices meet user needs, their intended purpose, and specific requirements.
Under FDA, the QA regulations, including the Design Controls portion, went into effect on June 1, 1997. Design Controls is part of the 21 CFR 820 quality system regulation, more specifically it is described in subpart C. Part 820.30 on Design Controls consists of several different phases in which requirements are made.
Development Planning / Design and Development Planning (corresponds to chapter 7.3.2 of ISO 13485)
Development input / Design Input (corresponds to chapter 7.3.3.3 of ISO 13485)
Development result / Design Output (corresponds to chapter 7.3.4 of ISO 13485)
Development Evaluation / Design Review (corresponds to chapter 7.3.5 of ISO 13485)
Design Verification (corresponds to chapter 7.3.6 of ISO 13485)
Design Validation (corresponds to chapter 7.3.7 of ISO 13485)
Transfer of development / Design Transfer (corresponds to chapter 7.3.8 of ISO 13485)
Control of development changes / Design Changes (corresponds to chapter 7.3.9 of ISO 13485)
The results of the activities in these phases are summarized in the Design History File (DHF).
However, not all devices are subject to the Design Controls process. While all Class III or II medical devices are subject to Design Controls, for Class I devices it is only appropriate for those devices that are automated with computer software, tracheobronchial suction catheters, surgical gloves, fixation belts, manual radionuclide applicator systems, and radionuclide teletherapy sources.
Development Planning – Design and Development Planning
To begin the process of design controls, it is necessary to create a plan. Development planning includes systems that describe or relate to development activities, define responsibilities for implementation, identify and describe interfaces with various groups or activities, and also include procedures for reviewing, documenting, updating, and approving plans as design and development evolves.
Development Input – Design Input.
Design Input refers to both the physical requirements and performance requirements for a device that are used as the basis for device design. In addition, a set of procedures must be established and maintained for this purpose and to address the requirements. These procedures must ensure that the requirements are adequate and consistent with the intended purpose of the product. They must also address, document, review, and approve incomplete, ambiguous, or conflicting requirements. Sources of development input include the application specification including the definition of intended use, MDR or other legal and regulatory requirements, process and product related standards, collected complaints, service reports, CAPAs from previous products, feedback from customers, focus groups, and other interested parties. There are several examples of development inputs, such as requirements for device functions, physical characteristics, performance, safety, reliability, environmental limits, sterilization, standards, regulatory requirements, labeling and packaging requirements, human factors, maintenance, or compatibility with other devices.
Development Results – Design Output
Development outputs refer to results of a development activity at each stage of development and at the end of the entire development activity. Design Output in its complete form consists of the device, its packaging and labeling, and the product master record (Device Master Record). This means that design output must illustrate the specifications of the design and meet the requirements of the design input. This is confirmed in design verification and validation and ensured in development evaluation. Procedures should be in place that define and document development outputs in a manner that allows adequate evaluation of conformance to the design inputs, referencing acceptance criteria, identifying development outputs that are essential to the safety and proper functioning of the device, and reviewing and approving development outputs prior to release. The development outcomes are included as part of the device specifications in what is called a premarket submission if FDA approval is sought.
Development Assessment – Design Review.
The development review must be a documented, all-inclusive, and systematic review. It should evaluate the adequacy of the development requirements, the ability to meet the requirements, and identify problems. In addition, each development review must include an adequate representation of all functions involved.
Development Verification – Design Verification
Verification describes the process of confirming by reviewing and providing objective evidence. It indicates that the specified requirements have been met. It also confirms that the development results meet the requirements of the development inputs. Development verification is also reviewed, approved, and documented in the Design History File.
Development Validation – Design Validation
Unlike development verification, development validation demonstrates that the device specifications meet the user needs and intended purpose. This is demonstrated by objective evidence. Development validation must be performed under defined operating conditions, under actual or simulated conditions of use, and on initial production units, lots or batches, or their equivalents (not prototypes!).
There is often confusion when it comes to the distinction between verification and validation. But there are two simple questions that can be a quick help here. “Did I develop the device correctly?” asks about development verification. It asks whether the development results match the development inputs. In contrast, the question for development validation aims to determine whether the development results meet user needs and purpose. “Did I develop the right device?” is the correct question here.
Transfer of development – design transfer
It can be stated that the part of transferring the development is the core part of the whole design controls process. To do this, it is necessary to have a detailed plan and implement it consistently. This plan must ensure that all parts of the design are transferred correctly so that the device can be manufactured without any obstacles arising. Finally, the pilot run of the product can be released for mass production. Appropriate procedures are required for this step. Finally, it is very important that all the results are appropriately transferred to the manufacturers and suppliers. The results of the activities are consolidated in the product master record (Device Master Record / DMR).
Control of development changes – Design Changes
Before design changes are made, several procedures must be established. These include procedures for identifying, documenting, validating, or verifying as appropriate, reviewing, and approving development changes. Depending on the scope and impact of the change, new regulatory documents may be required depending on the requirements of the authority having jurisdiction. It is very important that the changes are communicated to the FDA or other relevant Competent Authorities if the product is undergoing premarket review or IDE review at the FDA, for example.
Design History File
The final step in the development process is the completion of the Design History File (DHF). This consists of a compilation of records that describe the development history of a finished medical device. It must also include information demonstrating that the design was developed in accordance with the development plan and the requirements of 21 CFR 820.
Looking for support?
With this article, we are simply providing a brief introduction to the topic of design controls. If you need assistance throughout the process, we, seleon gmbh, can help you with extensive expertise at every step of the design controls process. Do not hesitate to contact us!
Please note that all information and listings do not claim to be complete, are without guarantee and are for informational purposes only.
