While the FDA has very clear design and manufacturing control standards, many organizations are challenged to reach the required standard. This is particularly true when commercializing new products, causing expensive rework and delays in product launch.

With this in mind, many years ago, I attended a three-day, executive-level workshop on FDA regulations for IVDs and medical devices. The workshop had a profound influence on my understanding of the requirements of the FDA, their status in law and expectations for leaders. What I found particularly valuable was the workshop’s central principle: a quality system is an asset to an organization and, as a by-product, meets regulatory requirements.

The facilitator of that workshop was John Malloy, principal consultant for Malloy & Associates, with whom I have the great pleasure of speaking with today. John is a thirty-year veteran of the medical device industry, from time as an Investigator for the U.S. Food and Drug Administration, to industry management positions in regulatory, quality, marketing and operations, with broad product line experience. John provides consulting on Quality System Regulation, European Directive and ISO standards; auditing; training; strategic planning services to organizations of all sizes; and also regularly serves as an expert witness regarding Quality System Regulation requirements.

Given the importance of meeting the FDA’s quality system requirements in launching new medical products, I am very pleased to be catching up with John today as part of Invetech’s Executive Series on Growth.

Colin: John, good afternoon, thank you for your time, it is great to speak with you again.

John: It’s always a pleasure, Colin, and thank you for that nice introduction. I also want to emphasise one of the things that you said: an effective quality system is an asset to the company that meets regulatory requirements as a by-product.

Colin: By way of background, could you give an overview of Malloy & Associates? How you help clients, what services you offer, and how you are operating.

John: Generally, I work with clients to establish and maintain quality systems. Those quality systems need to fulfill USA Food and Drug Administration Regulation and ISO Standards if you want to market in the United States, Europe, and many other countries. Specifically, I help companies in mock FDA inspections, training programs, and consultations. Occasionally, the consultations relate to responding to FDA warning letters for those companies that have had a negative inspection.

Colin: Often the FDA gets a bad rap as being overly bureaucratic and slow. I personally think their intent is worthwhile—I have no doubt the processes they demand have positively impacted patient outcomes and, at the extreme end, have saved lives. At a high level, what do you think the FDA is trying to achieve with the various standards and regulations?

John: Well, their ultimate objective is ensuring that safe and effective medical devices are being provided to the patient and user populations. The regulation standards and guidance documents help define what is required for safe and effective products. It is also worth mentioning that in some cases—such as the quality systems regulation—the FDA regulates the processes of designing, manufacturing and servicing medical devices, instead of setting individual product specification for medical devices.

Colin: I think that is an excellent point. It seems obvious to me that understanding and meeting the FDA process requirements is a prerequisite for launching new medical products. However, in many cases, the gaps in process requirements seem to mount the closer to launch a project becomes. From your experience why do you think this is?

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.

I have noticed that my clients who have placed more emphasis and time on the development of design inputs are actually getting to market faster, because they understand what market needs they are trying to fulfill. When the designers and developers understand the end point, it is much easier for them to reach that end point. They can come up with solutions to design issues. I think companies struggle with design inputs because it requires early decision-making, which often requires early agreement on what would constitute an acceptable new product. As you well know, it can be difficult to get marketing, product development, manufacturing, quality and regulatory representatives to even talk to each other, let alone agree on the necessary product design inputs. However, for an effective and efficient design input process, it’s an actual necessity.

I also mentioned risk management. Risk management is not only a requirement—it’s an ethical responsibility. We are not designing and manufacturing paper clips; we are designing and manufacturing medical devices that have health related impacts on patients and users. Of course it is a valuable business practice. A well-defined risk management process helps designers identify and mitigate injury and death.

I am not a liability attorney, but mitigating and limiting injuries and death related to a medical device is certainly good business practice. Medical device companies are required to report injuries and deaths to the FDA, per the medical device reporting requirements (another section of the regulations, part 803). If these reports end up being investigated and it is determined that they relate to the device, it is likely to result in corrective or removal actions against the product (recalls). Those can be rather expensive, and of course they will result in closer FDA scrutiny.

Why do organizations struggle with this from an industry maturity prospective? I believe that many companies are having difficulties with risk management and getting beyond “I have documented FMEA, therefore I have fulfilled the FDA requirements” approach. Documented FMEA doesn’t mean that you have a good risk management approach. It certainly can be part of it, but it is not risk management.

It’s an ongoing process that requires updating product risk. The lack of maturity is often related to a company not having risk management expertise within the organization, and a device company of any size needs risk management expertise. Small companies may have to use resources from outside the company.

Colin: The contrast is stark and it does take, as you say, some maturity to get to where you are using risk management to actually drive your business, not just to complete a document for the purpose of furnishing it during an inspection.

John: I would agree with you, and I think sometimes it’s a long journey from that document of FDA requirements to making risk management work for you as an asset to the company.

Colin: This gets to the topic of the cost of poor design control or poor maturity in the quality system. Putting aside that these things are simply good practice, the costs of rectifying shortcomings often dwarf the investment that would have been required to get it right in the first place. What is your perspective on the whole economic piece here, the cost of poor design control?

John: The cost of poor design control can impact the product cost throughout the lifecycle of the product. Design control is at the front end of the product lifecycle. Therefore, I would consider it the most important in terms of impacting cost to that product over time. For example, a design error impacts all product types subject to the design project, whereas a manufacturing error likely impacts either a lot of products, or just a few products. The cost can be huge when it’s a design issue. If a design process does not deliver to our expectations, or does not meet customer or compliance needs, you might start noticing an excessive amount of change orders after the product is launched.

I try to get my clients to measure how many change orders did made in the first six months after product launch, as those orders often address problems occurring as the result of poor design control. That’s often the first indication. The second indication is when you have to go into the field and make changes, or bring the product back to make changes. With product recalls, you have to report those to FDA, and compliance activities go up, which are very expensive, much more expensive than doing it right the first time. The other indication is from sales, e.g., marketing has predicted X amount of dollars of sales and all of a sudden the dollars of sales are low and people are asking why it’s not performing as expected. This means we failed in the very early stages of the project in knowing what it was that our customers wanted.

So, low sales, high complaint rates, compliance, end-customer satisfaction issues, the cost of processing the complaint, interfacing with the complainant, investigating the complaint. If I’m getting a whole bunch of those, I have to go into corrective and preventative action, than it may be back to the corrections and removal activities. What happens with a poor design process is that the dominos start to fall, and I don’t think companies are very strong at monitoring what those falling dominos cost.

We are also too emphatic about media launch dates. I’m not saying that companies shouldn’t have a launch date and that you should not strive to meet it, but you sure want to make sure that you hit your target before you launch that arrow into the air. With high complaint rates, you’re going to lose customers, you’re going to lose market share. Excessive complaints are going to lead to corrective and preventative actions, which is a major arena for the FDA in terms of inspections. In fact, 88 percent of all FDA warning letters have a citation for corrective and preventative actions. When you get those 483 FDA warning and observation letters, you start to work for the FDA instead of the company. You also run into problems with excessive manufacturing and service costs, warranty costs, the cost of new a 510K or PMA submissions or—the worst—the loss of company reputation.

Colin: I like the visual that you evoked there by talking about dominos: once you start getting customer complaints from design control related issues, when you add up the cost of investigation, rectification, documentation, revalidation…the costs are extremely dramatic.

John: One of those costs that we often forget about: a person who is working on all these corrective actions is not doing their normal job. Designers aren’t designing, process engineers are not improving processes—the corrective actions impact other things that you are trying to accomplish as well.

Colin: Absolutely, it soaks up the organization’s capacity like nothing else. The opportunity cost is huge.

John: Yes, absolutely.

Colin: I know the FDA is always active in updating and providing new guidance in this area of design and manufacturing control. From what they introduced around 30 years ago, the core requirements are largely unchanged; though, over time, they have provided additional guidance and interpretations. What do you see as the main changes or areas of increased scrutiny and emphasis from the FDA in recent times?

John: Focusing on the design area; certainly risk management and human factors/usability engineering. In the manufacturing area, emphasis continues to be on corrective and preventative action, complaint management, process validation, a newer emphasis on purchasing controls, and the non-conforming product arena. The risk management/human factors area is getting more emphasis because it represents an activity intended to protect the patient and user, which goes back to the FDA’s primary objective. So, risk management is going to come more and more into play. It certainly is one of the drivers in ensuring the development of the medical device, if it’s at an acceptable level of risk.

In the European community, there is also more of a push in terms of this medical device risk management activity, so you might even see more activity from notified bodies out of Europe than you do from the FDA. But they are getting smarter about this, and they are learning and getting training in risk management and human factor areas so you are likely to start getting more attention in those areas during an FDA inspection if you will. Particularly what we talked about earlier, the user area. Be careful if you are talking about the user error: it should be “use” error, and we should be looking at those carefully, particularly if there seems to be a systemic issue relative to the use of the product. Why? When companies have many user errors, it is likely caused by a design issue, perhaps related to human factors. Now, as I said earlier, companies need to have risk management expertise, including its cousin, human factors engineering; that expertise needs to be available within a company or as a contractor/supplier to the company.

On the manufacturing side, Corrective and Preventative Actions (CAPA) is not a new area of emphasis but still receives much attention from FDA. Companies need to make sure that their investigation of CAPA’s, their effectiveness and corrective actions, verifications and validations and implementations are well documented, and in fact, they are working. Companies are having great difficulties in these arenas, particularly the investigation process. It’s not easy. One of the problems is that often the investigation has to be performed by someone other than the quality assurance department (who are usually administer CAPA), but nobody in the other departments ever budgets for CAPA investigations. That means that CAPA investigations are at the expense of the investigators’ primary activity, so that often causes an internal problem relative to ensuring that corrective and preventative actions are implemented.

The same hurdles apply to complaints and non-conformances following that corrective and preventative action arena. The process validation expectations are that the process be more statistically oriented, and some companies are having problems applying statistics. Again, it’s an area where you need some internal subject matter expertise; I would strongly recommend the utilization of the Global Harmonization Task Force guidance document on process validation (IMDRF.org). If you follow that guidance document and establish your process validation processes accordingly, you’ll be ok.

Now purchasing controls: a lot of companies are surprised in this area, and I think it’s because they have not applied the intellectual aspect of the person in controls arena, e.g., “Here’s what regulation says, now what do we have to do?” And again, I want to emphasize that it really makes sense for you to understand your suppliers so they don’t become a thorn in your side instead of a partner in the manufacture of your product. It really comes down to knowing what your requirements are and documenting them for a supplier or services of a product. Evaluating and determining whether or not they conform to the requirements, making your selections accordingly, and documenting those activities. Purchasing controls is an area that I am seeing getting a lot more attention during FDA inspections.

Colin: We have talked a lot about the sort of holes and some of the challenges that companies have, I am sure that you also see the other side of the coin: those companies that are benefiting from a commercially strong quality system, e.g., something that is working for them rather than just something that is managed on the side for compliance. Through that system, they are able to more predictably get business outcomes, meet launch schedules, development budgets and so forth. Have you ever reflected on what it is that sets these organizations apart? What is the kind of “secret sauce” to get to the mature level rather than being in the problematic area?

John: There are a few key characteristics at the higher level that are critical to best practices. There has to be a commitment to a high-level, well-defined process. Too often that leads to much bureaucracy within a medical device company.

Failure to have that defined process certainly leads to bureaucracy because then personnel begin to find their own processes, such as processes that define team efforts that lead the most efficient and effective pathway to a product launch. Personnel now what they have to do and when they have to do it. The process does not have to be extremely detailed, but it must provide for a structured development in terms of that commitment to a well-defined process. I find companies will express their product development process very well, but then say “I don’t see how you could miss with a forty-three-page procedure”—but there is no way that any human is going to follow a forty-three-page procedure successfully. It’s got to be well defined and provide a structure while still allowing personnel to do their job.

Another characteristic is success-based timeframes, particularly when it comes to project management. I’ve seen design and development plans that indicate a product launch time will be in eighteen months, but my question to the personnel is, “How long did it take to launch your last product?” And they will say “36 months”, and I would say, “Well, why do you think you can launch this in 18 months? Have you ever launched a product in 18 months?” and they say “No, we have not.”

The third question I ask is, “Would you be willing to bet your job that you will be able to meet the launch date of 18 months?” and that usually gets a silent response, and then the comeback is, “Well, maybe we better consider best case, worst case, most-likely case,” and I say, “That is probably a good idea.” Because when we put these timeframes on paper, we believe them, executive management believes them, but there are not reality-based. We are making assumptions on the best-case situation, and not what is the most-likely case. So reality-based timeframes are very important in terms of success.

E.g., does it look like we are going to make those dates, and do we really understand what this project relates to in our projected sales for the following year, the following six months, or the following two years. It’s likely that most executive management teams have strong marketing skills, strong financial skills and experience, but lack quality system regulation skills. So, the successful oversight of any project entails understanding the FDA requirements. A lack of understanding of the FDA requirements really works against you.

If you don’t understand these requirements, quite often companies are working on tribal knowledge, e.g., it’s been handed down from generation to generation, and when you look at it, you realize it has no bearing on the FDA requirements. Somebody will say “Well, the FDA requires this,” and I’ll say, “Just show me where it’s required.” And they say, “Well, my boss told me and his told boss him,” and I say, “That’s not what I asked you. Where is it required?”

I’m not saying that the executive management needs to actually know the specifics of the device master records section of the FDA’s quality system regulation, but they have to know the impact on a FDA regulated product. They have to know how they are going to get their commitment across to the rest of the organization, and they have to be able to provide checks for when something is going wrong. When I am doing an executive level presentation, I quite often ask the executives to pull out a piece of paper and write out the two most important quality system problems they have in their organization. If there are eight people and I get 16 different quality issues, the company has a problem. It clearly indicates the quality system is not working, and I can’t tell you how much those little quizzes provide basis for the rest of the executive presentation.

Colin: The thing that very much comes through in listening to those elements is leadership. The commitment to realism and making sure there is appropriate governance as well as the right level of knowledge. These are very much leadership tasks, and I’ve seen organizations where the top-level management is pretty heavily involved in making sure that all those things are in place and driving that into the culture.

John: Yes, the provision of leadership is what all of this comes down to, in all aspects of the company, but of course today we are talking primarily about the FDA quality system regulation side of the business.

Colin: John, as a final question, for those who are inspired by some of the things that you have been saying and have a need to elevate their game around quality system regulation, what is your advice about how they would get started? What should be the first step a person might take if they wanted to strengthen their own muscle in the FDA regulatory area?

John: Probably the most difficult part is getting started. The most important first step is to determine the current state of the existing quality system, as many companies have gone along with quality systems for years and years and haven’t yet recognized that it is not working. So, I think there is a necessity to review the detail. For example, take the quality system departmental structure and how it fits with the rest of the organization. If the quality department is a group that is buried in the organization’s structure and you only occasionally hear a squeak from them, you may have an issue in terms of your overall organizational structure and the structure of that quality system assurance organization. You need to determine the level of independence of that quality department when it comes to key decision-making activities, particularly as they relate to product quality. Are they conscious of the organization when making these decisions? Do they have the independence to allow them to make these types of decisions? Beyond that, you have to look at the leadership within that department and see if they are actually capable. How long have they been there? What have they done? Where do they fit in this organization? Now I don’t want to imply that the quality department is responsible for the quality system, but they certainly need to lead relative to the quality system.

As a second step, you need to ask the question: “Do other departments understand their quality systems responsibilities?” For example, research and development, purchasing, manufacturing, servicing, do they understand their quality systems responsibilities? Or do they think it’s all the quality assurance department’s responsibility? I find that is often a major hurdle within companies, e.g., purchasing will say, “Oh, quality will tell me when I’m doing it wrong,” when they should be saying, “Let me make sure that my processes are in place to get this right”. So I think if management understands the first and second steps, they can define a course of action to make ensure that their quality system is indeed an asset to the company.

Colin: Yes, I like that a lot and it’s very much in-line with the advice that you gave me four or five years ago when we first met.

John, it has been terrific to talk with you today. You continue to be a person in whom I have enormous respect; you combine a deep knowledge of the FDA with a strong business sense and street smarts. So, thank you very much for sharing some of your wisdom with us.

John: Thank you, Colin, and it was a pleasure in connecting with you again. I hope we get to talk again soon.