Design Control Guidance - Food and Drug Administration

More documents

Recommendations

Info

Unfortunately, there are a number of common misconceptions regarding the meaning andpractical application of the quality system requirements for design input. Many seem toarise from interpreting the requirements as a literal prescription, rather than a set ofprinciples to be followed. In this guidance document, the focus is on explaining theprinciples and providing examples of how they may be applied in typical situations.CONCEPT DOCUMENTS VERSUS DESIGN INPUT In some cases, the marketingstaff, who maintain close contact with customers and users, determine a need for a newproduct, or enhancements to an existing product. Alternatively, the idea for a newproduct may evolve out of a research or clinical activity. In any case, the result is aconcept document specifying some of the desired characteristics of the new product.Some members of the medical device community view these marketing memoranda, or theequivalent, as the design input. However, that is not the intent of the quality systemrequirements. Such concept documents are rarely comprehensive, and should not beexpected to be so. Rather, the intent of the quality system requirements is that the productconceptual description be elaborated, expanded, and transformed into a complete set ofdesign input requirements which are written to an engineering level of detail.This is an important concept. The use of qualitative terms in a concept document is bothappropriate and practical. This is often not the case for a document to be used as a basisfor design. Even the simplest of terms can have enormous design implications. Forexample, the term “must be portable” in a concept document raises questions in the mindsof product developers about issues such as size and weight limitations, resistance to shockand vibration, the need for protection from moisture and corrosion, the capability ofoperating over a wide temperature range, and many others. Thus, a concept documentmay be the starting point for development, but it is not the design input requirement. Thisis a key principle—the design input requirements are the result of the first stage of thedesign control process.RESEARCH AND DEVELOPMENT. Some manufacturers have difficulty indetermining where research ends and development begins. Research activities may beundertaken in an effort to determine new business opportunities or basic characteristics fora new product. It may be reasonable to develop a rapid prototype to explore thefeasibility of an idea or design approach, for example, prior to developing design inputrequirements. But manufacturers should avoid falling into the trap of equating theprototype design with a finished product design. Prototypes at this stage lack safetyfeatures and ancillary functions necessary for a finished product, and are developed underconditions which preclude adequate consideration of product variability due tomanufacturing.RESPONSIBILITY FOR DESIGN INPUT DEVELOPMENT. Regardless of whodeveloped the initial product concept, product developers play a key role in developing thedesign input requirements. When presented with a set of important characteristics, it is theproduct developers who understand the auxiliary issues that must be addressed, as well asthe level of detail necessary to design a product. Therefore, a second key principle is thatSection C. Design Input 3/11/97 Page 14
the product developer(s) ultimately bear responsibility for translating user and/or patientneeds into a set of requirements which can be validated prior to implementation. Whilethis is primarily an engineering function, the support or full participation of production andservice personnel, key suppliers, etc., may be required to assure that the design inputrequirements are complete.Care must be exercised in applying this principle. Effective development of design inputrequirements encompasses input from both the product developer as well as thoserepresenting the needs of the user, such as marketing. Terminology can be a problem. Insome cases, the product conceptual description may be expressed in medical terms.Medical terminology is appropriate in requirements when the developers and reviewers arefamiliar with the language, but it is often preferable to translate the concepts intoengineering terms at the requirements stage to minimize miscommunication with thedevelopment staff.Another problem is incorrect assumptions. Product developers make incorrectassumptions about user needs, and marketing personnel make incorrect assumptions aboutthe needs of the product designers. Incorrect assumptions can have serious consequencesthat may not be detected until late in the development process. Therefore, both productdevelopers and those representing the user must take responsibility for critically examiningproposed requirements, exploring stated and implied assumptions, and uncoveringproblems.Some examples should clarify this point. A basic principle is that design inputrequirements should specify what the design is intended to do while carefully avoidingspecific design solutions at this stage. For example, a concept document might dictatethat the product be housed in a machined aluminum case. It would be prudent for productdevelopers to explore why this type of housing was specified. Perhaps there is a validreason—superior electrical shielding, mechanical strength, or reduced time to market ascompared to a cast housing. Or perhaps machined aluminum was specified because acompetitor’s product is made that way, or simply because the user didn’t think plasticwould be strong enough.Not all incorrect assumptions are made by users. Incorrect assumptions made by productdevelopers may be equally damaging. Failure to understand the abuse to which a portableinstrument would be subjected might result in the selection of housing materialsinadequate for the intended use of the product.There are occasions when it may be appropriate to specify part of the design solution inthe design input requirements. For example, a manufacturer may want to sharecomponents or manufacturing processes across a family of products in order to realizeeconomies of scale, or simply to help establish a corporate identity. In the case of aproduct upgrade, there may be clear consensus regarding the features to be retained.However, it is important to realize that every such design constraint reducesimplementation flexibility and should therefore be documented and identified as a possibleconflicting requirement for subsequent resolution.Section C. Design Input 3/11/97 Page 15
Page 1: Center for Devices and Radiological
Page 5 and 6: PREFACEEffective implementation of
Page 7: TABLE OF CONTENTSFOREWORD .........
Page 10 and 11: are described in comments received
Page 12 and 13: The importance of the design input
Page 14 and 15: patient. Because the problem was no
Page 16 and 17: III. DISCUSSION AND POINTS TO CONSI
Page 18 and 19: design and development team, and pr
Page 20 and 21: more likely to be made with appropr
Page 24 and 25: SCOPE AND LEVEL OF DETAIL. Design i
Page 26 and 27: • The environment in which the pr
Page 28 and 29: the design and development plan, an
Page 30 and 31: Section D. Design Output 3/11/97 Pa
Page 32 and 33: capabilities. The external focus is
Page 34 and 35: Qualifications. Formal design revie
Page 36 and 37: action. In other cases, the reviewe
Page 38 and 39: manufacturers are encouraged to use
Page 40 and 41: Another self-documenting verificati
Page 42 and 43: III. DISCUSSION AND POINTS TO CONSI
Page 44 and 45: Section G. Design Validation 3/11/9
Page 46 and 47: Historically, shortcomings in the p
Page 48 and 49: DOCUMENT CONTROL. The features of a
Page 50 and 51: Section I. Design Changes 3/11/97 P
Page 52 and 53: software in each machine. The contr

Design Control Guidance - Food and Drug Administration

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?