Design Input Requirements: 3 Common Errors
The author reviews three common errors related to design input requirements and uses examples to illustrate compliance.
I have been directly involved in dozens of design projects throughout my career, and during the past three years, I have audited 50+ Design Dossiers for CE Marking of Medical Devices. Throughout most of these design projects, I have noticed one common thread—a misunderstanding of design inputs.
ISO 13485 identifies design input requirements. These requirements are:
- Functional (7.3.2a)
- Performance (7.3.2a)
- Safety (7.3.2a)
- Statutory/Regulatory (7.3.2b)
- Previous and Similar Designs (7.3.2c)
- Essential Requirements (7.3.2d)
- Outputs of Risk Management (7.3.2e)
- Customer Requirements (7.2.1)
- Organizational Requirements (7.2.1)
Design Input Requirements: 3 Common Errors Reviewed
The most common error seems to be the failure to include the outputs of risk management. For those of you that have used design FMEA’s—that’s what the right-hand columns are for. When you identify suggested actions to mitigate risks with the current design, these actions should be translated into inputs for the “new and improved” model.
The second most common error seems to be a failure to consider regulatory requirements. There are two ways this mistake is frequently made: 1) Canadian MDR’s were not considered as design inputs for a device intended for Canadian medical device licensing, and 2) an applicable ISO Standard was not considered (i.e., – “State of the Art” is Essential Requirement 2 of the Medical Device Directive (MDD)).
The third most common error, and the one that drives me crazy, is a confusion of design outputs and design inputs. For example, an outer diameter of 2.3 +/- 0.05 mm is not a design input for a 7 French arterial catheter. This is a design output. The user need might be that the catheter must be small enough to fit inside the femoral artery and allow interventional radiologists to navigate to a specific location to administer therapy. Validation that the new design can do this is relatively straight forward to evaluate in a pre-clinical animal model or a clinical study. The question is, “What is the design input?”
Design Input Examples
Design inputs are supposed to be objective criteria for verification that the design outputs are adequate. One example of a design input is that the catheter outer diameter must be no larger than a previous design that is an 8 French catheter. Another possible design input is that the catheter outer diameter must be less than a competitor product. In both examples, a simple measurement of the OD is all that is required to complete the verification. This also gives a design team much more freedom to develop novel products than a narrow specification of 23 +/- 0.05 mm allows for.
If you are developing a Class II medical device for a 510(k) submission to the FDA, special controls guidance documents will include design inputs. If you are developing a Class IIa, Class IIb, or Class III medical device for CE marking, there is probably an ISO Standard that lists functional, performance, and safety requirements for the device. Regulatory guidance documents and ISO Standards usually reference test methods and indicate acceptance criteria. When you have a test method and acceptance criteria defined, it is easier to write a verification protocol. Therefore, design teams should always strive to document design inputs that reference a test method and acceptance criteria. If this is not done, verification protocols are much more difficult to write.
In my earlier example, the outer diameter of 2.3 +/- 0.05 mm is a specification. Unfortunately, many companies would document this as an input and use the final drawing as the output. By making this mistake, “verification” is simply to measure the outer diameter to verify that it matches the drawing. This adds no value, and if the specifications are incorrect, the design team will not know about it.,
A true verification would include a protocol that identifies the “worst-case scenario,” and verifies that this still meets the design input requirements. Therefore, if the drawing indicates a dimensional tolerance of 2.3 +/- 0.05, the “worst-case” is 2.35 mm. The verification process is to measure either a previous version of the product or a competitor’s catheter. The smallest previous version or competitor catheter tested must be larger than the upper limit of the design output for the outer diameter of the new catheter.
Posted in: Design ControlLeave a Comment (3) ↓
I believe your guidance regarding design inputs does not align with the FDA guidance document Design Control Guidance For Medical Device Manufacturers (http://www.fda.gov/RegulatoryInformation/Guidances/ucm070627.htm#_Toc382720786).
Please review the sections CONCEPT DOCUMENTS VERSUS DESIGN INPUT and ASSESSING DESIGN INPUT REQUIREMENTS FOR ADEQUACY. It is pretty clear that a dimension with a tolerance IS a design input.
The guidance you provided a link to is much better than most design control procedures, but it’s still too vague. For example, the FDA specifies that for quantitative limits you should provide specifications with tolerances. Although this is correct, it’s not the whole story. The specifications are for a design verification test and acceptance criteria–not a design output specification with tolerance. The output would be a drawing with a dimension and tolerance. The method of testing may have much broader acceptance criteria than tolerances on a drawing. For example:
1. User Need = must be mobile
2. Design Input = must be < 60 pounds and must have wheels 3. Design Output = 30 +/-1 pound and 4 wheels p/n 123 The FDA used an example of 3.5mm as an incomplete specification, but they suggested 3.500mm +/- 0.005mm is needed. However, this implies more than the FDA really means. A design team needs to know if a 3.5mm diameter is a minimum, maximum and what the purpose of the hole really is. It might be possible to develop a design that doesn't need a hole, it might be that the hole is a port in a minimally invasive surgical device and the leak rate is critical. If the design team specifies an input in terms of dimensions instead of leak rate for a port the device may meet the specification and still fail validation.