SECTION C. DESIGN INPUT

I. REQUIREMENTS

§ 820.30(c) Design input.

• Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient.
• The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements.
• The design input requirements shall be documented and shall be reviewed and approved by designated individual(s).
• The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.

Cross reference to ISO 9001:1994 and ISO/DIS 13485 section 4.4.4 Design input.

II. DEFINITIONS

§ 820.3(f) Design input means the physical and performance requirements of a device that are used as a basis for device design.

III. DISCUSSION AND POINTS TO CONSIDER

Design input is the starting point for product design. The requirements which form the design input establish a basis for performing subsequent design tasks and validating the design. Therefore, development of a solid foundation of requirements is the single most important design control activity.

Many medical device manufacturers have experience with the adverse effects that incomplete requirements can have on the design process. A frequent complaint of developers is that "there's never time to do it right, but there's always time to do it over." If essential requirements are not identified until validation, expensive redesign and rework may be necessary before a design can be released to production.

By comparison, the experience of companies that have designed devices using clear-cut, comprehensive sets of requirements is that rework and redesign are significantly reduced and product quality is improved. They know that the development of requirements for a medical device of even moderate complexity is a formidable, time-consuming task. They accept the investment in time and resources required to develop the requirements because they know the advantages to be gained in the long run.

Unfortunately, there are a number of common misconceptions regarding the meaning and practical application of the quality system requirements for design input. Many seem to arise from interpreting the requirements as a literal prescription, rather than a set of principles to be followed. In this guidance document, the focus is on explaining the principles and providing examples of how they may be applied in typical situations.

CONCEPT DOCUMENTS VERSUS DESIGN INPUT In some cases, the marketing staff, who maintain close contact with customers and users, determine a need for a new product, or enhancements to an existing product. Alternatively, the idea for a new product may evolve out of a research or clinical activity. In any case, the result is a concept document specifying some of the desired characteristics of the new product.

Some members of the medical device community view these marketing memoranda, or the equivalent, as the design input. However, that is not the intent of the quality system requirements. Such concept documents are rarely comprehensive, and should not be expected to be so. Rather, the intent of the quality system requirements is that the product conceptual description be elaborated, expanded, and transformed into a complete set of design 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 both appropriate and practical. This is often not the case for a document to be used as a basis for design. Even the simplest of terms can have enormous design implications. For example, the term "must be portable" in a concept document raises questions in the minds of product developers about issues such as size and weight limitations, resistance to shock and vibration, the need for protection from moisture and corrosion, the capability of operating over a wide temperature range, and many others. Thus, a concept document may be the starting point for development, but it is not the design input requirement. This is a key principle-the design input requirements are the result of the first stage of the design control process.

RESEARCH AND DEVELOPMENT. Some manufacturers have difficulty in determining where research ends and development begins. Research activities may be undertaken in an effort to determine new business opportunities or basic characteristics for a new product. It may be reasonable to develop a rapid prototype to explore the feasibility of an idea or design approach, for example, prior to developing design input requirements. But manufacturers should avoid falling into the trap of equating the prototype design with a finished product design. Prototypes at this stage lack safety features and ancillary functions necessary for a finished product, and are developed under conditions which preclude adequate consideration of product variability due to manufacturing.

RESPONSIBILITY FOR DESIGN INPUT DEVELOPMENT. Regardless of who developed the initial product concept, product developers play a key role in developing the design input requirements. When presented with a set of important characteristics, it is the product developers who understand the auxiliary issues that must be addressed, as well as the level of detail necessary to design a product. Therefore, a second key principle is that the product developer(s) ultimately bear responsibility for translating user and/or patient needs into a set of requirements which can be validated prior to implementation. While this is primarily an engineering function, the support or full participation of production and service personnel, key suppliers, etc., may be required to assure that the design input requirements are complete.

Care must be exercised in applying this principle. Effective development of design input requirements encompasses input from both the product developer as well as those representing the needs of the user, such as marketing. Terminology can be a problem. In some cases, the product conceptual description may be expressed in medical terms. Medical terminology is appropriate in requirements when the developers and reviewers are familiar with the language, but it is often preferable to translate the concepts into engineering terms at the requirements stage to minimize miscommunication with the development staff.

Another problem is incorrect assumptions. Product developers make incorrect assumptions about user needs, and marketing personnel make incorrect assumptions about the needs of the product designers. Incorrect assumptions can have serious consequences that may not be detected until late in the development process. Therefore, both product developers and those representing the user must take responsibility for critically examining proposed requirements, exploring stated and implied assumptions, and uncovering problems.

Some examples should clarify this point. A basic principle is that design input requirements should specify what the design is intended to do while carefully avoiding specific design solutions at this stage. For example, a concept document might dictate that the product be housed in a machined aluminum case. It would be prudent for product developers to explore why this type of housing was specified. Perhaps there is a valid reason-superior electrical shielding, mechanical strength, or reduced time to market as compared to a cast housing. Or perhaps machined aluminum was specified because a competitor's product is made that way, or simply because the user didn't think plastic would be strong enough.

Not all incorrect assumptions are made by users. Incorrect assumptions made by product developers may be equally damaging. Failure to understand the abuse to which a portable instrument would be subjected might result in the selection of housing materials inadequate for the intended use of the product.

There are occasions when it may be appropriate to specify part of the design solution in the design input requirements. For example, a manufacturer may want to share components or manufacturing processes across a family of products in order to realize economies of scale, or simply to help establish a corporate identity. In the case of a product upgrade, there may be clear consensus regarding the features to be retained. However, it is important to realize that every such design constraint reduces implementation flexibility and should therefore be documented and identified as a possible conflicting requirement for subsequent resolution.

SCOPE AND LEVEL OF DETAIL. Design input requirements must be comprehensive. This may be quite difficult for manufacturers who are implementing a system of design controls for the first time. Fortunately, the process gets easier with practice. It may be helpful to realize that design input requirements fall into three categories. Virtually every product will have requirements of all three types.

• Functional requirements specify what the device does, focusing on the operational capabilities of the device and processing of inputs and the resultant outputs.
• Performance requirements specify how much or how well the device must perform, addressing issues such as speed, strength, response times, accuracy, limits of operation, etc. This includes a quantitative characterization of the use environment, including, for example, temperature, humidity, shock, vibration, and electromagnetic compatibility. Requirements concerning device reliability and safety also fit into this category.
• Interface requirements specify characteristics of the device which are critical to compatibility with external systems; specifically, those characteristics which are mandated by external systems and outside the control of the developers. One interface which is important in every case is the user and/or patient interface.

What is the scope of the design input requirements development process and how much detail must be provided? The scope is dependent upon the complexity of a device and the risk associated with its use. For most medical devices, numerous requirements encompassing functions, performance, safety, and regulatory concerns are implied by the application. These implied requirements should be explicitly stated, in engineering terms, in the design input requirements.

Determining the appropriate level of detail requires experience. However, some general guidance is possible. The marketing literature contains product specifications, but these are superficial. The operator and service manuals may contain more detailed specifications and performance limits, but these also fall short of being comprehensive. Some insight as to what is necessary is provided by examining the requirements for a very common external interface. For the power requirements for AC-powered equipment, it is not sufficient to simply say that a unit shall be AC-powered. It is better to say that the unit shall be operable from AC power in North America, Europe, and Japan, but that is still insufficient detail to implement or validate the design. If one considers the situation just in North America, where the line voltage is typically 120 volts, many systems are specified to operate over the range of 108 to 132 volts. However, to account for the possibility of brownout, critical devices may be specified to operate from 95 to 132 volts or even wider ranges. Based on the intended use of the device, the manufacturer must choose appropriate performance limits.

There are many cases when it is impractical to establish every functional and performance characteristic at the design input stage. But in most cases, the form of the requirement can be determined, and the requirement can be stated with a to-be-determined (TBD) numerical value or a range of possible values. This makes it possible for reviewers to assess whether the requirements completely characterize the intended use of the device, judge the impact of omissions, and track incomplete requirements to ensure resolution.

For complex designs, it is not uncommon for the design input stage to consume as much as thirty percent of the total project time. Unfortunately, some managers and developers have been trained to measure design progress in terms of hardware built, or lines of software code written. They fail to realize that building a solid foundation saves time during the implementation. Part of the solution is to structure the requirements documents and reviews such that tangible measures of progress are provided.

At the other extreme, many medical devices have very simple requirements. For example, many new devices are simply replacement parts for a product, or are kits of commodity items. Typically, only the packaging and labeling distinguishes these products from existing products. In such cases, there is no need to recreate the detailed design input requirements of the item. It is acceptable to simply cite the predecessor product documentation, add any new product information, and establish the unique packaging and labeling requirements.

ASSESSING DESIGN INPUT REQUIREMENTS FOR ADEQUACY. Eventually, the design input must be reviewed for adequacy. After review and approval, the design input becomes a controlled document. All future changes will be subject to the change control procedures, as discussed in Section I (Design Changes).

Any assessment of design input requirements boils down to a matter of judgment. As discussed in Section E (Design Review), it is important for the review team to be multidisciplinary and to have the appropriate authority. A number of criteria may be employed by the review team.

• Design input requirements should be unambiguous. That is, each requirement should be able to be verified by an objective method of analysis, inspection, or testing. For example, it is insufficient to state that a catheter must be able to withstand repeated flexing. A better requirement would state that the catheter should be formed into a 50 mm diameter coil and straightened out for a total of fifty times with no evidence of cracking or deformity. A qualified reviewer could then make a judgment whether this specified test method is representative of the conditions of use.
• Quantitative limits should be expressed with a measurement tolerance. For example, a diameter of 3.5 mm is an incomplete specification. If the diameter is specified as 3.500±0.005 mm, designers have a basis for determining how accurate the manufacturing processes have to be to produce compliant parts, and reviewers have a basis for determining whether the parts will be suitable for the intended use.
• The set of design input requirements for a product should be self-consistent. It is not unusual for requirements to conflict with one another or with a referenced industry standard due to a simple oversight. Such conflicts should be resolved early in the development process.
• The environment in which the product is intended to be used should be properly characterized. For example, manufacturers frequently make the mistake of specifying "laboratory" conditions for devices which are intended for use in the home. Yet, even within a single country, relative humidity in a home may range from 20 percent to 100 percent (condensing) due to climactic and seasonal variations. Household temperatures in many climates routinely exceed 40 °C during the hot season. Altitudes may exceed 3,000 m, and the resultant low atmospheric pressure may adversely affect some kinds of medical equipment. If environmental conditions are fully specified, a qualified reviewer can make a determination of whether the specified conditions are representative of the intended use.
• When industry standards are cited, the citations should be reviewed for completeness and relevance. For example, one medical device manufacturer claimed compliance with an industry standard covering mechanical shock and vibration. However, when the referenced standard was examined by a reviewer, it was found to prescribe only the method of testing, omitting any mention of pass/fail criteria. It was incumbent on the manufacturer in this case to specify appropriate performance limits for the device being tested, as well as the test method.

EVOLUTION OF THE DESIGN INPUT REQUIREMENTS. Large development projects often are implemented in stages. When this occurs, the design input requirements at each stage should be developed and reviewed following the principles set forth in this section. Fortunately, the initial set of requirements, covering the overall product, is by far the most difficult to develop. As the design proceeds, the output from the early stages forms the basis for the subsequent stages, and the information available to designers is inherently more extensive and detailed.

It is almost inevitable that verification activities will uncover discrepancies which result in changes to the design input requirements. There are two points to be made about this. One is that the change control process for design input requirements must be carefully managed. Often, a design change to correct one problem may create a new problem which must be addressed. Throughout the development process, it is important that any changes are documented and communicated to developers so that the total impact of the change can be determined. The change control process is crucial to device quality.

The second point is that extensive rework of the design input requirements suggests that the design input requirements may not be elaborated to a suitable level of detail, or insufficient resources are being devoted to defining and reviewing the requirements. Managers can use this insight to improve the design control process. From a design control perspective, the number of requirements changes made is less important than the thoroughness of the change control process.