Medical Device Design Controls: Following The Regulation Vs. Understanding Its Intent
By Michael Drues, Ph.D., President, Vascular Sciences
When it comes to design controls, one of the most common problems I see medical device companies make is focusing on following the regulation rather than understanding its intent. In other words, they focus on what the words say, and not what the regulation is trying to accomplish.
A literal interpretation is next to impossible when it comes to FDA’s design control regulation, outlined in Section 820.30 of 21 CFR 820 and a guidance document. The regulation is extremely vague, containing scant details about what manufacturers must actually do to meet the requirements — at least mechanistically. But if you understand the intent of the regulation, most of it is common sense, what some might call prudent engineering.
This lack of specificity is common in most regulation because it must apply to a wide range of medical devices. Some manufacturers make very simple medical devices, while others are much more complicated. Some create devices that never come in contact with a patient’s body, and others remain inside the patient’s body for the rest of their life. Yet, all of these manufacturers must conform to, essentially, the same basic set of design controls.
Instead of providing specific steps for device makers to follow in establishing and maintaining design control procedures, the FDA regulations offer more of a framework within which manufacturers must work. This gives each company the flexibility it needs to develop a design control system that not only complies with the regulation, but more importantly, helps to ensure we all do what we should do as prudent engineers.
After all, when I started out in this industry as an R&D engineer over 20 years ago, we had no design controls, and yet somehow we were able to get pretty good medical devices to market that helped many people. (I have no idea how that happened — sarcasm intended!) Today, we have thousands of pages of regulation, but are our devices really any better? I’ll leave that as a rhetorical question.
Verification And Validation
By way of example, let’s look at the terms “verification” and “validation” — often referred to collectively as “V&V” — which are important components of any design control system.
In a simple sense, design verification asks, “Did we design the device right?”, whereas design validation asks, “Did we design the right device?” The conventional approach to testing V&V is to compare design outputs to design inputs — to ensure that the device was made correctly. Although this what the regulation requires, it is not enough.
As I often say, answers are only as good as the questions that we ask. What good is getting the right answer if we’re asking the wrong question? What good is designing the right device if it solves the wrong problem? Unfortunately, this happens a lot in medicine and in medical device technology. Ironically, nowhere in the design control or any other regulation does it instruct us to ask the question, “Did we solve the right problem?”
To be fair, the design controls try to address the question of solving the right problem by making sure our devices meet the user’s needs — another governing principle of the design controls. But that raises another problem: Why would anyone assume that the user knows what they really need, especially when it comes to physicians and surgeons?
Most device development is evolutionary, i.e., you come out with one device, tweak it a bit to make a new device, and so on. I understand the advantages of evolutionary development from a technology perspective, from a regulatory perspective, and even from a psychology perspective. But here’s the problem: The lightbulb did not evolve from the candle. The car did not evolve from the horse. You can tweak a horse as many times as you want but you will never end up with a car! This is what Harvard Business School professor Clayton Christensen calls a disruptive technology — a new technology that “unexpectedly” displaces an established technology.
To illustrate, consider this simple example. Today, cars are ubiquitous, but back in the day, there were no cars. Suppose you lived in those days, and you wanted to develop a new mode of transportation. Following the design controls, you would ask your users (the people riding horses) what they wanted in a new mode of transportation. Most would say a stronger horse, a faster horse, or a bigger horse — but every solution would still involve horses. How many would say, “A horse is ok, but what I really need is a car.”?
Understanding the design controls from a mechanistic perspective, as most do, actually encourages evolutionary product development while simultaneously discouraging revolutionary product development. On the other hand, understanding the design controls from a philosophical perspective is technology agnostic — that is, equally applicable to evolutionary and revolutionary product development.
If you understand the meaning of these questions — and they are not nearly as simple as they seem — the V&V regulation should make sense. This is the crux of what the regulation is trying to accomplish.
Consequences Of Insufficient Design Controls
Inadequate design control procedures are commonly cited in many FDA warning letters, CAPAs (corrective and preventive actions), and product recalls. In fact, about 44 percent of all quality problems that result in recall actions are attributed to deficiencies that probably could have been prevented by having a solid design control process. And approximately 30 percent of warning letters over the last several years highlighted inadequate design control procedures.
While FDA design control regulation applies to all Class II and Class III devices, and also some Class I devices (many, but not all, Class I devices are exempt from design controls), every single medical device company should have design control systems in place. Yet having a design control system in place is clearly not enough, as evidenced by the high level of citations.
One suggestion I’ve made to companies and regulators over the years is to actually introduce a problem on purpose in order to test the efficacy of your systems — not just design controls, but quality, CAPA, complaint handling, and so on. Intentionally introducing a bug in your system, so to speak, can help you determine if your system is capable of detecting potential problems, before you get a message from the FDA.
Isn’t it ironic that we must validate our design and manufacturing processes but not our other processes? What good is having a process that doesn’t work? Or worse, being lulled into a false sense of security because we have a system in place and we assume it works but we never test it?
Process Controls In The Context Of Design Controls
Different sections of 21 CFR 820 require us to validate the design of the product and to validate the process used to manufacture that product. However, the regulations do not require us to validate both simultaneously.
As medical devices get more and more complicated, it is becoming nearly impossible to separate the design of the product from the process that is used to make it. I’m aware of several instances — and I think it will probably happen more often in the future — where companies have validated product and manufacturing process separately, and everything looks fine. But when they put the two together, it’s not so fine anymore.
This, in my opinion, is just prudent engineering. Concurrent design and process validation is not in the design control requirements, but perhaps it should be, especially for a complicated product.
When I started out in this business as an R&D engineer over 20 years ago, I thought if I could make three or four medical device prototypes that worked, it was somebody else’s job to make 3 or 4 million of them that worked. This was back when the concept of throwing things over the wall from R&D to manufacturing was prevalent. Design control regulations did not exist at the time — they came into existence in about 1998.
Today, design controls remind us of something that Socrates taught a long time ago: that you should know the difference between what you know and what you don’t know. R&D engineers are not manufacturing engineers. As an R&D engineer, I did not know the best way to manufacture my device. Bringing a manufacturing person — and others with complementary expertise (regulatory, etc.) — onto the team as early as possible makes a lot of sense.
Modifying A Design Or Process
One of the most common areas where companies get themselves in trouble is in changing the design of a device, or in some cases the manufacturing processes used to make the device. They fail to understand when it is appropriate to manage the change internally, by simply doing a letter to file, and when they need to notify the FDA in the form of a special 510(k) or a PMA (premarket approval) supplement. FDA has issued a number of guidance documents on this subject, but it is still an area of confusion for many medical device companies.
You need to ask yourself the question, “What possible impact does this change of the design or the manufacturing process have on the safety, efficacy, performance, etc. of the medical device?” You will have to do some thinking, and you might have to do a little benchtop testing. I’m not talking about doing a Ph.D. dissertation or months of study, but you need to do some amount of information gathering, and perhaps some experimental work, in order to demonstrate that the change that you’re making is not going to have an appreciable impact.
Only when you can sufficiently answer that question can you decide what to do with that information. Do you simply stick it in a folder, or do you package it up and send it to FDA? Really, this is not so much a regulatory decision — it is a business decision, and I could spend a whole other article talking about it.
What FDA Looks For In A Design Control System
At a very high level, FDA wants to see that you have design procedures and plans established, that you have the appropriate documentation, that you have your design inputs or your design requirements identified, that you have your outputs or your specifications identified, and that you’ve done your verification and your validation.
In addition, they want to make sure that you have done the appropriate risk analysis. In the design controls, it’s called a risk management plan, and on the regulatory submissions side, it’s called a risk mitigation strategy. But at the end of the day, it’s exactly the same information. You’re just presenting it or packaging it in a slightly different way.
They also want to make sure that you have conducted periodic design reviews. One of the requirements is having an independent design review. The question is what does “independent” mean? In the larger companies, what often happens is they take an engineer from a different group and ask them to review a device that they don’t have anything to do with. But is that really independent? After all, are they not getting paid by the same organization?
In other cases, a company will bring in someone from the outside, like me, to do an independent review. Can that even be considered independent? Isn’t the consultant also getting paid by the same organization?
When I do independent design reviews, I want an ironclad consulting agreement, basically saying that no matter what I say, I’m going to get paid. If you have somebody come in and give you an independent design review and basically just tell you that you’re doing a wonderful job, then with all due respect, you’re not accomplishing the intent of the design control regulation.
Asking an engineer to critique their own design is like asking a parent to critique their own child. It’s inherently biased. Again, are you interested in just simply meeting the regulatory requirement by ticking off a box on a checklist, or are you actually interested in meeting the intent of the requirement?
Finally, FDA is interested in the transfer from R&D to manufacturing, which I mentioned earlier. This is a real challenge with more complex medical devices. For example, many devices have multiple components. Some of them are mechanical, some of them are electrical, and some of them might even be software. In this new era of combination products, where you have products that are not just devices but also incorporate drugs or biologics, scaling up to large-scale manufacturing is not a trivial thing.
If You Don’t Have A Complete Design Control System
What should you do if you find yourself in a situation where you don’t have a complete design control system in place? Perhaps you have walked into a new project, or maybe your company has acquired a technology from a small or a startup company. This is a very common problem, where you don’t have a complete system in place.
First, be honest about the situation. Acknowledge that you don’t have a complete system or that some of your documentation is missing. Do a gap analysis first. Figure out what is in place and where there are holes. Initiate a training program. Start a CAPA based on the inadequate design control systems. There’s no reason why you couldn’t do that. Create a retrospective design history file, so that you can start getting your documentation in order.
Most importantly, don’t act like an ostrich and stick your head in the sand, pretending that the design control system exists or that you actually have documents when you don’t. Identify what is missing and create what is necessary. The bottom line is, if you own up to the issues and try to correct them properly, regulators will be much more reasonable with you. On the other hand, if you take the head-in-the-sand approach (or worse), it will eventually come back to bite you in the you-know-what. This is, in fact, is the way the CAPA system is supposed to work.
Beyond Regulatory Requirements
Simply reading the design control regulation is not enough. Having a design control system in place is not enough. Clearly, the vast majority of companies have such systems in place, and yet they continue to get in trouble.
The textbook understanding of the design control regulation is to manage the design process so we can ensure that our devices meet user needs and our specified requirements, but that view is way too simple.
One of my favorite medical metaphors is: The surgery went perfectly, but the patient died anyway. Well, the regulatory equivalent of that is that we followed the regulation perfectly — that we did everything the FDA asked us to do — and yet the patient died anyway. The engineering equivalent is that we designed a medical device perfectly, and yet the patient died anyway.
Unfortunately, these problems happen over and over and over again, and I believe one of causes is that people get hung up on following what the regulation says instead of asking themselves, “What is it that we’re trying to accomplish in the real world here?”
I don’t like to think about design controls as a hard and fast set of rules, because as I said earlier, the regulations are very nebulous, and for good reason. Rather, my design control philosophy is about understanding the intent of what we’re trying to accomplish, and approaching the process in a more logical and a more systematic fashion.
For those of you who have worked in R&D, you probably would agree that R&D tends to be a fairly chaotic environment. In some ways, that’s the way it’s supposed to be, because design is about creativity and thinking outside the box. Well, control is the antithesis of that. Even without talking about the details of the design control requirements, here’s a question for you to ponder: Do we want to take these two words, “design” and “control”, and even put them together? Some people might argue that having this design control system in place is really holding us back in terms of medical device innovation. Again, the horse did not evolve into a car!
Don’t just blindly follow the rules — think. If the rules make sense, then by all means, follow them. But if they don’t make sense, and we admit that they don’t make sense and yet we continue to follow them anyway, is that a problem with the system or a problem with us?
I’m not trying to advocate anarchy here. I want to be crystal clear on this. If it makes sense to follow the rules, than I will be the first one to walk into FDA with my PowerPoint slides in 72-point font, saying, “I’m doing what the people did before me, end of discussion.”
On the other hand, if it doesn’t make sense to follow in somebody else’s footsteps, or if it’s impossible to follow in somebody else’s footsteps, I’ll be the first to try to work with FDA to carve out a new path. If you are following in somebody else’s footsteps, there’s one thing that I can guarantee, and that is you’ll never go anywhere new. That philosophy is something that we can apply to product development, to regulatory affairs, and also to design controls as well.
Editor’s Note: Mike will be teaching an online course called Design Controls 101: Beyond the Regulatory Requirements on January 29, 2015, at 1:00 p.m. EST. In it, he will go into much greater detail about this topic, providing additional case studies and examples. If this is an area where you feel like your organization may be lacking, I would certainly encourage you to check out the course.