Originally Published MDDI April 2003
Making Design Controls Useful for R&D
Identifying constraints explicitly in the design-input document facilitates project management and reduces risk.
by Gerald E. Loeb and Frances J. R. Richmond
|Figure 2. Display window containing diagrams (a2)–(d2) for cycle 1. (Click to enlarge).|
FDA now requires design controls as part of the development process for regulated medical devices and diagnostics. Understanding how to apply such a system can be difficult, however, because implementation details are largely unspecified in the regulation and because the available guidance documents are inconsistent. Further, little is known about how companies are actually meeting these obligations, since the information contained in most design history files constitutes highly confidential, often strategic, corporate planning. The design process for truly novel products includes substantial R&D that may be buried in concept development, which is exempt from regulation. Thus, the formulation of design input is relegated to a set of specifications whose basis may be a mystery to many of those involved in creating the design output.
Perhaps the most important phase of the design process is reconciling the needs and desires of patients and clinicians with various constraints imposed by science, technology, business, and other factors. Documenting these constraints explicitly in the design input can improve both the results and validation of the design process in a manner that is consistent with the original intent of design controls.
Design controls were first proposed for inclusion in FDA's GMP regulation in November 1993. At that time, researchers expressed concern that such controls might be an unwarranted intrusion on and an obstacle to the creative process of new product development. The design control regulation was not finalized until October 1996, and did not become effective until June 1, 1998. This lengthy promulgation phase consisted of a design control guidance released on March 11, 1997, followed by a designated “learning year” leading up to the effective date. Since then, FDA has released only a “Guide to Inspections” (August 1999), leaving the details of design control implementation largely to individual organizations.
The Global Harmonization Task Force (GHTF), on the other hand, published a design control guidance dated June 29, 1999, that is substantially different from FDA's, but is actually considerably closer to the apparent intent of the design control regulation as stated in Subpart C (21 CFR 820.30).
As mentioned earlier, little information is available about how design controls have been implemented by companies, since design history files are highly confidential. In at least some organizations, research leading to new product development remains separate from the controlled process, which is performed as a regulatory exercise rather than an integral part of the creative process. The available guidance documents and trade journal articles describe how to compile design history files that comply with the regulations, but they do not provide scientists and engineers with any other incentive for doing so––thus perpetuating a generally hostile attitude toward the process. We argue here that the design and documentation practices of researchers are naturally aligned philosophically with the design control regulation. The elements of the process required by the regulation, however, need to be defined in terms that reflect the thought processes of scientists and engineers, rather than regulators.
Defining Design Inputs
The purpose of design controls is to ensure that products meet the needs of their users. This is a goal that is readily accepted by applied researchers, who often contribute to both the design of the product and its validation. Section (c) of the regulation defines design input as a statement of product requirements that will meet the needs of patients and clinicians for the intended use. Thus, it is surprising to find that the design input examples provided in FDA's design control guidance consist largely of detailed specifications for a product whose basic form and function seem to be taken for granted. A basis for excluding the analysis of form and function can be found in section (b), which provides for a “concept phase” that lies outside the controlled design process mandated by the regulation. Such a narrow approach may work for a derivative product that incorporates a simple improvement suggested by users, but it begs the question of how to validate specifications that are not so evident.
For truly novel products, a major part of the design process consists of specifying a product whose form and function are not so obviously based on the requirements of the users. This process may involve substantial research into alternative approaches and designs that are never incorporated into products. Some of the research may be done by parties other than the regulated entity, including academic scientists and engineers who may not even be aware of the application of their findings to product design.
In the process of designing a novel product, the engineering team frequently must grapple with the need to make trade-offs among conflicting needs, according to the constraints of available scientific knowledge and technology. Engineers may make trade-offs and changes among specifications well into the product development stage. If fairly advanced sets of engineering specifications are considered design input (the first stage in the process), then subsequent deviations from them will be difficult to justify. Changes will have to be revalidated by going back to a possibly disorganized or unsystematic accumulation of user-related materials to see if the new specifications remain responsive to identified user needs. In fact, the users themselves may not understand how these specifications relate to their needs.
For innovative products, the first step, or input, of the process might better take the form of a set of absolute and relative interests that might be met in many different ways. Ideally, these requirements should be no more specific than necessary; otherwise, they risk handicapping the design team. This more-general approach would place both the product concept and the detailed specifications intended to meet the requirements as a later step, more closely aligned with the design output rather than the design input. Section (d) of the regulation defines design output in terms of a process for defining, documenting, and accepting an output; it makes no mention of specific content requirements.
One reason for excluding the concept phase from the controlled design process is that it is more difficult to verify that a given design concept meets user requirements than it is to verify that a given product meets specifications. In order to evaluate the design concept before it is actually validated by field experience, the reviewers must consider the background information and thought processes that led to selecting (and rejecting) various strategies and technologies. These are the types of information that researchers normally incorporate into their scholarly publications as “review of the literature” and “discussion,” but they have no obvious place in the design history file. These elements can and should be incorporated into the design input along with the requirements, because both constrain the set of valid design outputs.
Constraints differ from the requirements, however, because they cannot be derived from (nor validated against) the needs of users; rather they stand alone as independent facts, subject to change over time as science and technology advance. Defining the constraints explicitly is a powerful tool for unifying the design team and identifying risk factors in product development.
A Complete Design and Development Process
The process described herein (and illustrated in Figure 1) is derived from the final draft of “Design Control Guidance for Medical Device Manufacturers,” released June 29, 1999, by the Global Harmonization Task Force (GHTF.SG3.N99-9). In particular, it employs a specific version of the waterfall design process as described originally by the Medical Devices Bureau of Health Canada and now widely accepted by industry.
The design process starts with the needs of users (patients, clinicians, caregivers, customers) and ends in a medical device system (hardware, software, manufacturing documentation, instructional material, labeling, etc.) that meets those needs. The process can be divided into a set of orderly steps, each of which can be examined to see if it is actually consistent with the results of the previous step (this is the verification process).
The overall design process must also be responsive to various external constraints, such as the scientific understanding of bodily functions, the limits of currently available technology, and the commercial reality in which businesses operate. In the end, the experiences of real users with the product itself must be analyzed to determine if their needs have been met, thereby validating the design process.
The top and bottom items in the process are outside of the control of the project team and can only be observed, influenced, and documented indirectly. The middle three levels constitute the actual design process. The first of these steps is to convert user needs into a statement of requirements for the product. The second is to develop quantitative specifications for a product that would meet the requirements. The third is to construct the actual product, i.e., an implementation that meets the specifications. It is then possible to observe users' experience with the product in the field.
One common problem in implementing such a stepwise design process is the temptation to incorporate details early on that are more properly relegated to a later step of the process. This usually occurs because the designer knows (or thinks he or she knows) the implications of a constraint that will eventually force such a detail to be incorporated into the product.
For example, consider the functional requirements for a neural stimulator (see Table I). Typically, an engineer specifies a range of stimulus pulse widths and currents that will be required when, in fact, the requirement is simply that a particular class of neurons be adequately stimulated. Stimulus strength tends to depend on the product of these two parameters, so the range and resolution of each need to be considered together in the context of the application at hand.
Meeting more-detailed specifications may overly complicate the design. In this situation, the information that constrains the eventual selection of stimulus parameters comes from well understood principles of biophysics. These principles are likely to play out differently for different configurations and placements of electrodes, which are likely to be constrained, in turn, by other requirements, such as the desired clinical procedure for placing the electrodes.
By including this constraint information explicitly in the statement of requirements, the designers charged with generating the next level of the process––the specifications––will be free to consider all valid strategies in the context of the information that constrains their choices. This is preferable to foreclosing certain strategies by assigning specifications based on unstated and perhaps erroneous assumptions. The sample outline in Figure 1 provides an overview of the main elements of the structure recommended herein; the actual design history file will contain many additional elements.
It is a general goal of the design process to minimize the need to go back and make changes at a higher level in order to deal with unanticipated problems or trade-offs that emerge later in the development process. Such iterative changes generally reflect a wasteful dead-end. Designers cannot make them without reconsidering the implications for all other elements at the higher levels. Consequently, the lower-level output must be reverified for consistency with the goals of the revised input from the next higher level. Integrating the concept phase with the controlled design process reduces the temptation to over-specify the design input and decreases the likelihood that it will need modification later in the project.
The Value of Constraints
From the discussion above, it is obvious that constraints can (and probably should) be expanded beyond those that are normally considered in scholarly analyses of biomedical engineering problems. As depicted in Figure 1, constraints tend to cross the various levels of the product development waterfall.
Clinical constraints tend to include important facts about the patients that the engineering team may tend to overlook—for instance, the incidence of cognitive impairment in stroke patients who will be using a neuromuscular stimulator.
Scientific constraints can provide the information required to anticipate competing treatment modalities and to design clinical outcome measures that will identify the relative merits of the proposed product.
Engineering constraints describe the candidate technologies that might be employed in the product. They provide the information required to perform trade-offs among such specifications as size, weight, durability, and cost. They may also interact with nonmedical regulations, such as limits on electromagnetic emissions or radioactivity.
Regulatory constraints arise from the feasibility of various clinical study designs that might be used during the premarket investigational phase. The business rationale for developing a new product tends to relate closely to the claims that will be used to market that product. The ability to support those claims depends on the design of both the product and the clinical trials.
Business constraints affect every level of the design process. Among these constraints are sales presence in specific clinical markets, plans to develop core competencies in particular areas of science and technology, economies of scale in procuring and supporting components and technologies common to many products, the ability to provide clinical training and field support for complex products, and others.
Because constraints are not derivable from user needs, the usual processes for verification do not apply. Instead, constraints should almost always be supported by reference to external documents, such as textbooks, journal articles, existing product literature, and strategic directives from corporate management. Compiling such references formally is particularly useful in building teams of individuals whose areas of expertise and depth of experience vary greatly. The design team tends to expand during the implementation phase of the project, and such well-documented design input can be used to bring new members up to speed efficiently.
A formal statement of constraints exposes areas where information is contradictory or rapidly changing—such areas are likely to coincide with product development risks. For example, if neural stimulation at several different sites in the body has been reported to treat successfully a given clinical disorder, then the designers will have to make a difficult choice among a general-purpose device that is cumbersome, a dedicated device that may become obsolete, or a compromise that combines the best of both approaches but may take longer to design. Such a decision requires parallel consideration of all types of constraints. That, in turn, will require input from clinicians, scientists, engineers, and marketing and regulatory specialists, each of whom is likely to be knowledgeable about only one or two types of constraints.
The drafting of the design input provides the opportunity to identify constraints, evaluate their reliability, and explain them to project management and to diverse members of the design team. Including this step in the controlled process and documenting it in the design history file can transform design controls from a sterile exercise in regulatory compliance to a powerful tool for managing the team and inventing better products.
The incorporation of constraints can also help identify and delimit risks and hazards to product users. Much of the scientific and engineering information required to understand the nature and magnitude of failure modes is likely to be included in these constraints. In the example of the neural stimulator, the selection of electrode dimensions interacts with the range of available stimulus parameters because of the well-recognized safe charge-density limits for various electrode materials. It may be possible to show that the specifications, as developed through this analysis, effectively limit the device to an intrinsically safe operating range regardless of how it is used by clinicians. Such specifications are obviously the result of the design process, not an input to it.
Currently, risk management activities are often conducted as a separate activity that is part of the planning phase for the design input. However, risk analysis extends directly from a consideration of requirements and constraints. By drawing up a formal statement of these elements, it will be easier to tie the risk management exercise directly into the design control process and perhaps even to develop novel approaches to minimizing risk through better design.
The development of novel medical products requires the needs of users to be integrated with the many constraints imposed by science, technology, regulation, and business. Identifying those constraints explicitly in the design input facilitates project management and reduces risk. Shifting detailed product specifications into design output can motivate innovation within the framework of the product requirements and constraints. Such a design process will be more attractive to research-oriented scientists and engineers, while still complying with the regulatory requirements.
The authors thank Allen Hans, quality systems consultant, for many helpful discussions of these issues. The Alfred Mann Institute for Biomedical Engineering and two NIH grants support the authors' research.
Many documents and Web sites detail the requirements of the design control process and its documentation according to various jurisdictions and standards. A sampling is provided on the next page.
“Design Control.” American Society of Validation Engineers, 2001. www.asove.org/design1.asp.
“Design Control Guidance for Medical Device Manufacturers.” Global Harmonization Task Force Study Group 3, June 29, 1999. www.ghtf.org/sg3/inventorysg3/sg3-n99-9.pdf.
“Design Control Guidance for Medical Device Manufacturers.” Rockville, MD: U.S. Food and Drug Administration, March 11, 1997. www.fda.gov/cdrh/comp/designed.html (An early draft [March 1, 1996] of this document is available at www.thompson.com/libraries/fooddrug/xray/special_reports/xrayguidance.html]; Web site links to the guidance are also available at www.biomed.tamu.edu/Student%20Projects/DeviceDesign/Design_Controls.htm.)
Life Sciences Branch of Industry Canada. “Quality System Requirements for Medical Devices, Reference Guide for Manufacturers Selling Med-
ical Devices in Europe, Canada, and the United States.” Orion Canada, 2001. http://strategis.ic.gc.ca/SSG/hi01545e.html#_1_33.
When design controls were proposed, Medical Device & Diagnostic Industry published a series of articles covering their requirements. These include:
Campo, Jose A. “Design Transfer.” 16, no. 2 (1994), 53–56, 102.
Link, David. “Executive Management's Role in Implementing Design Control.” 16, no. 3 (1994), 66–70.
Link, David. “Design and Development Planning.” 15, no. 10 (1993), 72–76.
Link, David. “New Challenges for Device Design: FDA's Revised GMP.”15, no. 9 (1993), 64–67.
Reilly, Susan C. “Design History Files: The Why, What, and How.” 17, no. 5 (1995), 162–168.
Sandberg, Jim. “Design Output.” 15, no. 12 (1993), 32–38.
Stevens, Lawrence J. “Design Verification.” 16, no. 1 (1994), 93–97.
Wurtzel, Robert D. “Design Input: Listening to the Marketplace.” 15, no. 11 (1993), 76–80. n
Copyright ©2003 Medical Device & Diagnostic Industry