John: My experience tells me that companies do not always accept that meeting the FDA’s requirements is necessary for launching a new product. Fortunately, those companies are in the minority within our industry. The more likely situation is that companies recognize the need to fulfill the FDA’s requirements but succumb to project pressures as the new medical device gets closer to the expected launch date. So the pressures to meet the launch date sometimes overcome the FDA’s requirements—and often the company’s own procedures.
This is an example: a company may have been issued a two-year project starting in June 2013, with a corresponding product launch scheduled for June 2015. During design and FDA requirement verification, the design team identifies issues that have to be corrected. As a result, the design team delays the design validation by three weeks. However, due to pressures to meet the design launch date, the design team shortens the design validation timeframe so as to meet the launch date. This decision often results in a new medical device not being properly validated. In the best-case scenario, the improper design validation might result in multiple design changes shortly after product launch, changes that often affect the purchaser of the device. In the worst case, the medical device causes injury or death to patients/users and cause subsequent negative PR and financial results. So, you can see that often companies intend to conform to regulations, but pressures often change those intentions.
Colin: I certainly have observed that too, but in the end, there is no short cut: proper validation is important to manage the product through the lifecycle. How would you describe the FDA’s top two or three key requirements in designing and launching new products?
John: Each section is actually extremely important, but there are some that are more important than others. If you look at the key requirements, the first is having a design and development plan. If you don’t have a project plan or development plan, you’re doing a poor job of managing the product, let alone not fulfilling the FDA’s requirements. Another important requirement is the design input document, known by different names to different companies: product requirements or marketing requirements. It’s the target for the designers, conveying requirements on the system level. If you don’t have that, you really are putting your designers in a very difficult position. The third one would be risk management, followed by software validation. These are general requirements that must have specific processes in place to ensure that you meet them. I might add that risk management and software validation are one sentence in regulation. Yet, we have expansive four-day programs on risk management, and four-day programs on software validation.
So, my top four are: design and development plan, design input, risk management and software validation. I would also point out that those have to be addressed very early in the project because if any of those four are not well addressed early in the process, the problems caused downstream are significant and expensive. I don’t want to say that the other sectors are not important; for example, if you don’t have a good design validation program, you are going to have problems, and if you don’t have a good design transfer, you are going to have problems. You can do everything wonderfully, but if you haven’t documented it in your design history file, you for sure are going to have a problem with the FDA (e.g., “If you didn’t document it, you didn’t do it”).
Colin: I think that is a great list, John, and in my experience, the FDA is spending a lot more time on risk management and the software piece of a finished device.
John: As part of that risk management, I might add human factors engineering or usability engineering is becoming a very key factor.
Colin: I saw some data from the FDA recently that showed that a large portion of customer complaints or compromised patient outcomes arise from usability issues. Therefore, placing a lot more emphasis on that aspect is important.
John: Absolutely. In fact, when I do mock FDA inspections, if I’m looking at their complaints file and I see a lot of user error complaints, that’s a red flag waving: “Why are we having all these user errors?”
You shouldn’t blame it on your customer—if there is a reoccurring user error, that may be an indication of a serious human factors design issue.
Colin: I would say that the user of the device doesn’t want to make an error; rather, the error is occurring because the product usability is poor.
John: I would agree with that wholeheartedly.
Colin: A question in two parts: first, when it comes to releasing new products, which requirements are typically the most problematic? Second: why do you think organizations are struggling with those particular elements?
John: You know, I would say that the most problematic areas are design inputs and risk management activities. Most companies have design inputs and risk management documents; however, too often the documents focus on the objective of meeting FDA requirements and not the true intent of these documents. I see companies launch long term and rather expensive projects with a limited understanding of what is to be developed. Of course, that should be defined in the design inputs, and needs to happen very early in the development process.