What Are Design Inputs?

Overview

Design inputs is the general term used in the regulation which refers to requirements and user needs that should be used to drive the preliminary concept design through final detailed design. Design inputs are what the users want, what is required by regulation or what is needed for a device to be safe and effective. Design inputs do not specify the details of how a device is designed but rather act as boundaries that must be maintained while filling in the gaps of the design details.

To further illustrate the concept of design inputs, the analogy of designing and building a house can be used. A future home owner wants a house designed such that it can be kept at a constant 71 +/- 0.25 F° all year round. For this user need to be achieved there are certain lower level requirements that must be specified by the architect and sub-contractors to ultimately meet the 71 +/- 0.25 F° higher level requirement (user need).  For example,

• The heating and cooling contractor must specify the correct size furnace, air conditioner, and duct work to allow the adequate air flow to each part of the house. Other considerations would be the number and location of air vents in each room and sources of heat generation such as the refrigerator, lights, windows and oven.
• The correct insulation rating for the wall, ceiling and floor insulation must be specified in order to minimize heat transfer through the house walls and ceilings.
• The electrical contractor has to specify the power requirements into the home to operate the furnace and air conditioner (as well as other power requirements to operate appliances and lights in the house). This includes specifying the correct wire gauge sizes, correct relay ratings, and breaker box components.
• A thermostat must be specified that has the correct resolution and accuracy to hold the temperature at the 71 degree requirement.
• The house has to meet local building codes which also become inputs to the design of the house.

The take away from this example is that there are many sources and levels of inputs that will guide the design of a medical device. This example also illustrates how many lower level technical requirements can be generated from relatively few user needs (in this case one user need 71 +/- 0.25 F°) .

The most important thing to keep in mind while developing design requirements is to ensure that requirements are identified which will lead to a safe and effective device. Requirements should not be burdensome, but on the contrary, they should be a valuable tool used to bring clarity to the design process. The initial development of design requirements may seem burdensome and a waste of time, but the time and resources invested up front in the design process to develop robust requirements will more than pay for itself in later development phases or after product launch by preventing costly rework or re-design due to inadequate design requirements. The FDA preamble states the following concerning this topic:

Quality Systems Regulation Preamble:

Comment 82

“All the requirements are essential to assuring the safety and effectiveness of devices. FDA does not believe that these requirements place undue burden on designers or require additional documentation with no value added. These basic requirements are necessary to assure the proper device performance, and, therefore, the production of safe and effective devices, and are acknowledged and accepted as such throughout the world.” (FDA Preamble, 2015)

Regulation (21 CFR 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 a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented. (FDA QS Regulation, 2015)

Definition 21 CFR 820.3(f) – Design Input

Design input means the physical and performance requirements of a device that are used as a basis for device design. (FDA QSR , 2014)

Design Control Guidance Document (21 CFR 820.30 (c))

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 manufacturers 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 Inputs

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 [the Design Change chapter].

Any assessment of design input requirements boils down to a matter of judgment. As discussed in [the Design Review chapter], 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. (FDA D.C. Guidance, 2015)

Timing of Design Input Activities and Deliverables

The FDA does not specify at what point in the design and development process when inputs should be defined and approved but the following graphical models give some clarity as to when design inputs typically begin and end relative to research and development activities.

The two humps in Figure 8 depict the relationship and the relative amount of research and development activities performed during the design and development cycle. The shaded area is the typical time when inputs are generated, reviewed, approved and implemented.

Figure 8

Design Input and Output Fundamentals

Before moving on to the detailed interpretation of the design inputs regulation, it is important to establish a fundamental understanding of design inputs. In the simplest terms, design inputs are the most basic information that developers use to initiate and finalize a design.

Figure 9 shows a simple and idealistic process flow of how design inputs feed into the design process.

Figure 9

 

The following examples are provided in Table 6 to more fully understand how design inputs feed into the design process and then how design outputs are generated from that process.

How Design Inputs Result in Design Outputs Through the Design Process

 

                                                                 Table 6

Design Inputs (Requirements)	Design Process	Design Output
The MRI machine’s electrical system shall operate at 120V at less than 16 amps.	Components such as motors, actuators and LEDs rated for 120V that will meet functional requirements will be specified but will not exceed a total of 16 amps during operation. The design process will include design iterations, informal bench testing, feasibility studies and prototyping.	Once a viable design has been identified, the components and configuration of the design will be documented. A bill of materials (list of all components) and an electrical schematic (defines the configuration and layout of the components and wiring) are the design outputs.
The overall size of the MRI machine shall be less than 9’ 6” (long) X 4’ 8” (wide) X 6’ 6” (high)	A 3D design envelope that will be no greater than 9’ 6” (long) X 4’ 8” (wide) X 6’ 6” (high) will be defined in a CAD system. The sub-systems and components will be designed and specified to operate within the required maximum design envelope.	The design envelope will be defined in a 3D CAD system and will be electronically stored as a 3D model.  The details of the design will be stored as a 2D drawing and bill of materials. The CAD files, drawings and bill of materials are the design outputs.
The dialysis catheter shall have a flow rate of 400 ml per minute at 10psi.	An iterative flow analysis to determine the minimum internal cross sectional area required to meet the flow requirement will be performed. Other requirements will also have to be considered that will drive material type, the external diameter and profile of the catheter extrusion.	The final cross sectional geometry and material will be defined in a 3D CAD system and will be electronically stored as a 3D model.  The detail of the design will be stored as a 2D drawing and bill of materials. The CAD files, drawings and bill of materials are the design outputs.
The x-ray machine’s software system shall display features to operate fluoroscopy, still images and deep tissue images from the main interface screen.	The software developers will develop code for the main interface page of the software such that all required image types are available from the main interface screen.	The software code will define the image display information that will meet the image requirement. The software code is therefore the output of the software design effort. Any documentation that supports the software code will also be part of the design output.

 

Table 6 is intended to show how design requirements form the initial framework of the design by putting in place boundaries and constraints that guide developers down the path to the optimal design that will meet user needs. Design requirements are not meant to specify every aspect of the design, but are needed to keep the design on the intended path. There is a critical balance between the design being over constrained and under constrained that should be optimized prior to initiating the design process. If the design is over constrained then the requirements specify too many design details which may lead to a design that is not technically feasible, impossible to manufacture or very costly. If the design is under constrained then there are not enough requirements to adequately enable designers to meet user needs.

As mentioned in the design control guidance, “… development of a solid foundation of requirements is the single most important design control activity”. ^BP1 (FDA D.C. Guidance, 2015) Just as a building constructed on an unstable foundation will eventually crumble and fall, so too will a design that is based on incomplete, ambiguous, or conflicting design requirements.

 

Best Practice Development of solid design requirements is the single most important design control activity. Invest the necessary resources early in the development cycle to ensure appropriate and accurate design inputs are established.

Interpretation & Application (21 CFR 820.30 (c))

 The regulation states, “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” …

Establish” means to define, document (in writing or electronically), and implement. (FDA QSR , 2014)

The FDA is saying that the device manufacturer/developer must have a documented procedure(s) that defines the “what, who, how, why and when” of how design inputs are created and applied. The FDA wants to ensure that a standard design input requirement (DIR) procedure has been created, vetted, reviewed and approved.

The procedure must be “maintained” (or in other words revised and updated) as required to be current with the actual practices being used to develop the design input requirements in the organization. Typically this procedure is maintained by the department that is responsible for new product development such as development engineering or R&D.

The regulation also states that the procedure shall “ensure that the design requirements relating to a device are appropriate…”. The word “appropriate” as mentioned here may sound like a wide open interpretation but the FDA is trying to convey that the manufacturer’s procedure must provide a consistent method of developing design inputs that are applicable for the intended use of the device. The procedure must also guide the generation of workable, accurate, and effective requirements for design teams to use during product development.

The regulation also states that the procedure shall ensure that the design input requirements “address the intended use of the device…”. This phrase in the regulation should prompt developers to take actions which are necessary to fully understand and define how the device will be used. In theory the intended use is straight forward and easily addressed. The medical device intended use is essentially how the medical device manufacturer expects (or intends) a user and/or patient to use the device (see IMPORTANT CONCEPTS* below). Designers will use the intended use as the basis for developing design inputs therefore it is crucial that the intended use is established prior to creating design inputs.

Even though the medical device manufacturer will formally specify how the device should be used in device labeling, the manufacturer should also consider variations of how the users may use the device under typical situations. Manufacturers are not expected to anticipate and mitigate risks for extreme off-label use of the device but they should consider and design the device in anticipation of expected use conditions even though they may not be intended.

As an example of interpreting intended use into requirements, our MRI OnWheels case study from the previous chapter discussed a portable MRI machine that could be transported and used in various rooms in a hospital environment. At first review this intended use would drive requirements like:

• No more than X lbs of horizontal force will be required by the user to transport the machine.
• The machine must be able to function with X voltage and Y power.
• The machine must be able to be transported across standard doorway thresholds less than or equal to Z inches.
• The MRI shall be compliant to ISO XXX.XX to prevent electromagnetic interference with other surrounding equipment.

In a perfect world these design requirements seem reasonable and expected. Unfortunately there are other anticipated scenarios that the device will experience that should be considered.  Less than obvious design inputs will typically come from sales or service representatives in the field that see firsthand day in and day out how similar machines are actually used. As an example, they may see devices similar to the MRI OnWheels that are used as “battering rams” to open swinging hospital doors as they travel to the emergency room. They may also see clinicians try to pull the machine across the floor by pulling the power cord. Obviously the intended use of this device would not have led developers to anticipate these extreme conditions, but the FDA will expect manufacturers to do their due diligence to thoroughly understand and gather all design requirements that can practically and reasonably be identified to ensure the safety and effectiveness of the device. Under these expected conditions, it is possible that the safety and effectiveness of the device would be compromised and therefore it is the responsibility of developers to add design requirements that will lead to design features that will mitigate these anticipated risks. In this example design requirements might be:

• The machine shall function safely and effectively as intended after receiving X number of frontal impacts with a force of Y lbs.
• The machine shall function safely and effectively as intended after X lbs. of tension applied to the power cord Y number of times.

The initial development of these types of inputs may be far, few and in between but as experience with the product (or similar products) increases, the DIR will become more detailed, refined and improved which will eventually result in a highly effective design.