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.

Design Controls: A 17-Year Learning Curve

The Safe Medical Devices Act of 1990 (SMDA) amended the Food, Drug and Cosmetic Act and gave FDA the authority to add preproduction design controls to the cGMP regulation. This change was based on findings that a significant proportion of device recalls were attributed to faulty product design.

Specifically, in January 1990, FDA published results of an evaluation of device recalls that occurred between October 1983 and September 1989, in a report titled, “Device Recalls: A Study of Quality Problems.”

FDA found that approximately 44 percent of quality problems that led to voluntary recall actions during this sixyear period were attributed to errors or deficiencies that were designed into devices, and may have been prevented by adequate design controls. 

With respect to software used to operate medical devices, the data were even more striking. A study of software-related recalls for years 1983 through 1991 indicated that more than 90 percent of all software-related device failures were due to design errors—generally, the failure to validate software prior to routine production. 

Officially, design controls have been part of 21 CFR, Part 820 for just under 17 years and there have been many lessons learned by both industry and FDA during this tumultuous period. My reminiscence is based upon the initialization of design controls and how industry couldn’t fathom the idea that the Federal government was going to invade the creative parts of “our research” efforts (when they really had no intention of doing so). This imposition was compounded by the fact that the final rule for this QS Regulation was published approximately one year before it became effective and that FDA would additionally give industry a one-year grace period (until June 1, 1998), during which official agency action would not be initiated, including FDA Form 483 observations, warning letters or enforcement cases based upon the failure to comply with Part 820.30.

That year was compounded with denial and disbelief. Even though there were promises that no regulatory actions would be taken against companies with compliance issues related to design, the Establishment Inspection Report would reflect how the new inspection strategy for 820.30 was working at company X. Industry and FDA were full of apprehension. Handling FDA inspections is part of my business. I recall that some FDA inspections were proving grounds and, in some cases, catalyzed long and tension-filled “discussions.” Frankly, both sides didn’t know what they were doing.

Enough with the historical stage setting. Where are we going?
Because design controls apply to a variety of devices, the regulation, by definition, does not prescribe the practices that must be used. Instead, it establishes a framework that manufacturers must use when developing and implementing design controls. The preamble to 820 has a wealth of information, as does the guidance document, “Do It By Design.” The framework provides manufacturers with the flexibility needed to develop design controls that both comply with the regulation and are most appropriate for their own design and development processes.

That’s the good news, and the bad news. It became complicated when this open-ended part of the overall regulation did not (could not) prescribe particular methods of implementation. FDA simply said that manufacturers should seek out technology-specific guidance on applying design controls to their particular situation and learn to appreciate the intrinsic value of design controls in the same breath, i.e. it was a wellestablished fact that the cost to correct design errors is lower when errors are detected early in the design and development process. There are still companies that repeat that sentence over and over again at management meetings, design reviews, strategic planning sessions, etc., but in the reality of day-to-day, still don’t get it. As a linked process in the quality management system, design controls don’t stand alone like research does.

If I were to pick out one over-arching, negative aspect of this QS Regulation in relationship to design over the past 16 years, it would be that companies fail to link Part 820.30 with the rest of Part 820. They manage design controls separately rather than incorporating the inter-relational architecture into the grand scheme of the whole regulation. Words escape me when I sit in one of the many FDA inspections I attend and watch management tap dance around the fact that the design and manufacturing processes were not in synch. This has not changed in 16 years.

When there are proposed process changes in manufacturing, or when quality data from the field necessitates an investigation of the device itself, design controls must be officially approached to consider a possible redesign.

Risk management has changed the way we look at design. Yet, we’re not even close to understanding why.
I’ll bet you think that I’m going to talk about design validation. It’s the only place where risk is mentioned in all of 21 CFR, Part 820. Risk analysis is important before and during design validation, but risk is also an input into the design controls Subsequently, the design process must provide an opportunity to evaluate how the organization will utilize risk management activities to ensure that design inputs are comprehensive and meet user needs, to confirm that risk control measures that were planned have been implemented in the design, and to verify that risk control measures are effective in controlling or reducing risk of the device and support processes. As a bonus jammed-packed with variables, design and development activities will directly affect the organization’s purchasing controls process, because suppliers whose components and/or activities are associated with higher risk to the product or whose activities are critical to the essential design outputs must act like “an appendage” of your risk evaluation activities.

Verify that any risks and risk mitigation measures identified during the risk management process are used as an input in the design and development process. Design outputs are subsequently impacted, even before they become part of the Device Master Record (DMR).

When the design input has been reviewed and the design input requirements are determined to be acceptable, the process of transforming those requirements into a device design begins. So, if you don’t get the input part right, the rest of your efforts could end up being skewed. The first step is conversion of the requirements into system or high-level specifications. Thus, these specifications are a design output. Upon verification that the high-level specifications conform to the design input requirements, they become the design input for the next step in the design process.  This basic technique is used repeatedly throughout the design process.

Each design input is converted into a new design output; each output is verified as conforming to its input; and it then becomes the design input for another step in the design process. In this manner, the design input requirements are translated into a device design conforming to those requirements. The Design History File (DHF) is the basis for the DMR.

The goal is to verify that management has committed to and has responsibility for overall risk management planning, including ongoing review of the effectiveness of risk management activities ensuring that policies, procedures and practices are established and documented for analyzing, evaluating and controlling product and process risk during product realization.

4 COMMENTS

Security code
Refresh