Introduction to Design Controls

FDA investigators will evaluate your design control process and procedures. Are you ready?

Learn about Omnica

Kathryn Kukulka,Regulatory Affairs

Approximately 75% of our clients hire us to design and engineer medical devices. They represent companies that range from small start-ups to large Fortune 500 corporations and all have two things in common: to see their ideas realized and to overcome the challenges of incorporating the design and development process into their Quality Systems as defined by the FDA Quality Systems Regulation (QSR).

Intrinsic quality, safety, and effectiveness of a device are known to be established during the design phase yet, statistics show, a significant percentage of all medical device recalls are due to design problems. A device recall can result in unplanned development costs, lost revenue for the manufacturer, and can significantly affect the end-user. Considering the   relatively short life-cycle for market viability, it is in everyone’s interest to “do it right the first time”.

In 1996, the Good Manufacturing Practice (cGMP) requirements were revised to include the area of  Design Control and have become a part of the Quality System Regulations (QSR) with which all medical device manufacturers must comply. It is incumbent on the manufacturer to demonstrate compliance with the QSR and (as of 1996) with Design Control requirements as well.

Design Controls are an integrated set of management practices (policies, processes and procedures) which are applied to control design activities while assessing quality and correcting errors through an iterative process of development. As a result, the end user benefits from a safe and effective product and the manufacturer benefits from a successful return on investment.

Design controls should be in place for a new product prior to approval of the system-level requirements document and after completion of the feasibility phase. However, a pivotal debate ensues when trying to determine the end of feasibility and beginning of development. To alleviate confusion, a manufacturer should look back into their management practices and policies and their comprehensive Product Development Process to define specific milestones and development phases. Once they have determined the product is feasible and the decision has been made to transition into development, the Design Control process begins.

At Omnica, our design and development team is highly experienced with this process and can provide guidance to ensure the transition from feasibility, through development, and into production while   following FDA guidelines.

Design Controls are made up of ten elements with documented procedures. However, the FDA places great emphasis on Risk Management and, although it is woven into the validation process, this author believes it deserves its own category.

These requirements affect most medical device manufacturers.

The following are brief descriptions of the sections of Design Controls as they relate to requirements defined in the Code of Federal Regulations 21 CFR 820.30

1) Design Control – States that when manufacturers or suppliers develop a product subject to design controls, they shall establish and maintain the proper documentation to ensure the specified design requirements are met.

2) Design and Development Plan – Describes the overall development plan and defines design activities and responsibilities. It establishes roles of all contributors to the development process including marketing, purchasing, manufacturing, R&D, Regulatory Affairs, and others. The Plan also defines design elements, intended use, and interfaces associated with the overall design process.

3) Design Input – Establishes the requirements that will ensure the device will meet the needs of the intended users. This is often in the form of a Product Requirements document or a Device Specification document; et al. Design input does not come in a box and is not a tangible entity, but is a process of gathering all available information about how a device might fulfill one or more user needs, while defining requirements which characterize the device. A requirements document is the tangible embodiment of user needs and is “the” document that comprises all fundamentals to help decide how to implement the design. Requirements should specify what is needed, not the solution, and act as a basis for verification of the design. It is not a trivial document and requires time and effort.

4) Design Output – Applies to all stages of the design process. These are the final technical documents that constitute the Design History File (DHF). This information shows that the device was developed according to the Design Plan and Design Inputs. It ensures that the Design Output meets the Design Input requirements and specifications. Design output is the accumulated information and instructions for building and maintaining the product. If followed, the result will be a device that consistently meets specified user need(s).

5) Design Review – These are planned, formal, and documented reviews of the design results conducted at appropriate stages of the device’s design development. Formal Design Reviews (minimum of two) require the participation of representatives of all functions concerned with the design stage being reviewed and an individual(s) who does not have direct responsibility for the design stage being reviewed, as well as any specialists needed. The formal reviews ensure that Design Outputs are meeting the Design Input requirements and are being recorded.

6) Design Verification – Assesses conformance to the requirements and confirms and documents (in reports) that the design output has met design input requirements. It verifies that the product was “made right”.

7) Design Validation –Validation follows successful Verification and is performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. It shall determine, by objective evidence, 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. It confirms that only safe and effective devices are produced for their intended use and therefore validates the “right product” was made.

8) Design Transfer – Ensures that the design specifications of the device is correctly translated into production specifications.

9) Design Changes – Design Changes are to be documented and validated or where appropriate, verified (again). They are also to be reviewed and approved again before their implementation.

10) Design History File (DHF) – Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate the design was developed in accordance with the approved design plan and the requirements of this part (21CFR820.30). It is a collection all outputs derived from the previous categories listed above.

*Risk and Hazard Analysis activities are required during most phases of development.

The standard for the application of risk management is ISO 14971 Medical devices – Application of risk management to medical devices. The extent of testing and evaluation is proportional to the risks associated with the product. If risks are unacceptable, the manufacturer may need to redesign the device or establish appropriate warnings for use. If the Risk and Hazard Analysis procedures are found unacceptable or incomplete, FDA reviewers will question the “safety and effectiveness” of the device. It is therefore essential that any risks and hazards are mitigated to “acceptable” levels. Literature review shows that appropriate risk analysis procedures are always a challenge and fall short in more than half the cases studied. For these reasons, this author suggests that manufacturers establish a specific Risk Management section of their Design Control system.

When all these subjects have been addressed and documented, you have the makings of the Design History File which can support a company’s 510(k) Pre-Market Notification and / or Pre-Market Application (PMA).

When reviewing the design control requirements, FDA investigators will not determine if a design is appropriate, or safe and effective. They will evaluate the design control process, make recommendations based on whether the manufacturer has the required checks and balances in place, and verify implementation of the design control guidelines.

Who We Are

Omnica Corporation is a privately-held design, engineering, and medical product development firm located in Irvine, California. The 28-person company is staffed with full-time employees and has been in operation since 1984. Our speciality is custom product development for the medical industry and industrial fields.

Our expertise is developing complex medical devices.Technical personnel at Omnica includes designers, mechanical engineers, electronic and software engineers, advanced R&D specialists, regulatory staff (for FDA documentation), machinists and model makers.

Learn MoreOmnica Corporation

Leave a Reply

Your email address will not be published. Required fields are marked *