Thanks! You've successfully subscribed to the BONEZONE®/OMTEC® Monthly eNewsletter!

Please take a moment to tell us more about yourself and help us keep unwanted emails out of your inbox.

Choose one or more mailing lists:
BONEZONE/OMTEC Monthly eNewsletter
OMTEC Conference Updates
Advertising/Sponsorship Opportunities
Exhibiting Opportunities
* Indicates a required field.

8 Design Control Issues Found During FDA Inspections

Involvement with numerous FDA inspections over the years has given me, I think, a unique perspective on design control trends—specifically, major design issues discovered during FDA inspections. FDA investigators will evaluate a company’s process, methods and procedures established to implement the requirements for design controls.

Here are eight major design issues that I’ve observed over the years.

No. 1. Manufacturers treat design as a separate entity within the Quality Management System (QMS).
Design controls are a major piece of a total quality system that covers the life of a device, i.e. from the development of device requirements (user needs becoming measurable design inputs) through design, production, distribution, use (intended or otherwise), maintenance and eventually, obsolescence. Many companies still treat design as a one-time occurrence during the life of a medical device. That is a major blunder and can be strategically damaging when it comes to tactical decision making, generating the proper objective evidence and when dealing with design changes both near and far-term. It is not only an integral part of the QMS, but it also links with just about every facet of 21 CFR, Part 820. For example, defending acceptance criteria use during the manufacturing phase(s) must include where this criteria and ensuing inspection and testing originated.

No. 2. User needs are not design inputs.
Design control begins with the development and approval of design inputs, and includes the design of a device as well as the associated manufacturing processes. The term “requirement'” is meant in the broadest sense to encompass any internally- or externally-imposed requirements such as safety, customer-related and regulatory requirements. All of these requirements must be considered as design inputs. How these requirements are handled and dealt with is up to the manufacturer. Design inputs are measurable, whereas user needs are commonly aligned with intended use and indications for use. Taking “fluffy” user needs and turning them into measurable inputs is key to the successful design verification steps that must be realized prior to initializing design validation. Not knowing this distinction during the development process and then the inspection could render your data confusing and lacking in a solid engineering and quality systems foundation.

No. 3. Design control does not end with the transfer of a design to production.
Design control applies to all changes to the device or manufacturing process design, including those occurring long after a device has been introduced to the market. Everything having to do with manufacturing product and enabling process management comes from design controls, e.g. when changing a production process or even the device itself, there must be a conscious, documented effort to make this change in a design phase (or not). Making these changes in manufacturing without at least considering re-design can be a compliance issue. This includes evolutionary changes, such as performance enhancements, as well as revolutionary changes, such as corrective actions resulting from the analysis of failed product. The changes are part of a continuous, ongoing effort to design and develop a device that meets the needs of the user and/or patient. Thus, the design control process is commonly revisited many times during the life of a product. During inspections, FDA will commonly look at change control logs or changes to labelling, and then trace the change back to design (or, they are not able to trace it). At least risk-based consideration should be given to all changes and, of course, every step of that decision making process should be documented and readily available.

No. 4. Design history file is the basis for the device master record.
For as long as the device is in commercialization (plus shelf life, of course), these “two brothers will walk down the road together,” each watching his side of the road. They don’t necessarily change “in chorus with each other” but, as with change control above, consideration must be given to each of these special documents to determine whether there will be an impact on either side of the “Design/Manufacturing Road” when a change does occur. Some companies do not have a trigger on their change form that asks the questions concerning re-design or re-validation or re-file (a regulatory submission, for example). Good FDA inspectors will, though; and that will most likely be a 483 if the inspector discovers that the design master record (DMR) has been revised and the design history file (DHF) has been given consideration or conversely. Also, remembering that the finished design output is the basis for the DMR helps when explaining that the DHF was revised, but the output wasn’t necessarily essential to the functionality of the device or to the manufacturing process, i.e. the DMR didn’t require an update.


Security code