The design control struggle is real.What is the struggle, you ask?
Design controls are not being used as an aid during medical device product development. Design controls are being viewed as a checkbox item — something you have to do, and seldom something you want to do.
Okay, I get it. I’ve been there.
You’re trying to meet aggressive deadlines.
Focusing on that new prototype, getting ready for testing, or preparing for your animal study is not only a better use of your time, it’s what your boss expects.
“Make sure you document all those design controls,” said maybe no boss ever.
Design controls have been part of my profession since I started my career in 1998.
At that time, design controls were still viewed as new (FDA QSR was implemented in 1996), and everyone in the industry was getting up to speed.
But design controls have now been in place for nearly 20 years, and med device companies should have a grasp on both their purpose and how best to implement them into product development.
Yet, year after year, design controls remain one of the top issues cited during FDA inspections (536 in 2015).
Where is the disconnect?
Over the past 20+ years, I have observed and discussed various design control-related topics with thousands of people.
Here are some general sentiments I have gleaned from those discussions:
Design controls are an impediment to product development.
Design controls should not be started until after a working prototype has been established and proven.
Documenting design controls is too rigid.
Design controls are viewed as optional.
Rather than hold onto these (inaccurate) sentiments that slander design controls as obstacles to MedTech product development, let’s dismantle these myths.
Myth #1: Design Controls Impede Product Development
If you view design controls as an impediment to product development, why is this?
You likely view medical device product development as a series of steps to get an idea from concept to market.
You probably have some sort of defined product development process, or at least define the major milestones.
Scale to production
You interpret that design controls are not an integral part of this flow, and actually make the process of bringing a device to market more difficult and time-consuming while adding little to no value.
Truth: Design Controls Aid Product Development
I propose that the goal of medical device product development is to design and develop a product that addresses a specific intended use.
As part of that goal, the product needs to be proven safe and effective. Do you agree?
If so, then medical device product development aligns perfectly with design controls. Some even postulate that design controls are a product development process.
Think about the major milestones of your product development: Aren’t these items all about proving your product is safe and effective for the intended use?
Design controls consist of the evidence to support claims that your medical device performs as designed and meets needs of the end-user, safely and effectively.
Myth #2: Design Controls Should Be Delayed Until After A Working Prototype Has Been Established
Ah, yes. Stay in “research” or “feasibility” for as long as possible.
Do not enter into formal design controls until you have confidence that the device you are developing has some level of proof that it will meet the end user’s needs.
Continue to design, prototype, test, and iterate until you know with some certainty.
After you believe the prototype is going to work — then, and only then — begin documenting your design controls.
Do so quickly, especially since you have a working prototype.
Make a mad dash to compile all the user needs, design inputs, design outputs, design verifications, and design validations ASAP. Have a giant design review that includes all design controls, all at once.
Do you really believe you can catch up your design controls later?
Truth: Design Controls Should Start During Prototyping
I’ve been asked plenty of times, following a product launch, to come in and “clean up” design controls.
In fact, I was recently asked to conduct a gap analysis and to remediate design controls for a product that already has received FDA 510(k) clearance.
Now, to be clear, it is never too late to get your design controls in alignment. But doing so after the fact misses the intent.
I advise using and capturing design controls as you prototype and design. Each prototype you develop serves a purpose, be it to demonstrate proof-of-concept or to help define what the product must do.
In all cases, prototypes offer learning that should be captured and documented. Handily, design controls provide a means to do so throughout your prototyping efforts.
Myth #3: Documenting Design Controls Is Too Rigid A Process
Do you believe that design controls restrict medical device product developers’ flexibility during design and development?
Perhaps you believe that starting design controls too early means documentation will be burdensome throughout product development.
Below is an image that is likely burned into your brain: the classic design controls “waterfall” diagram.
Is your interpretation of this diagram as follows?
- Define all user needs = Have a design review.
- Define all design inputs = Have a design review.
- Complete the entire design process = Have a design review.
- Define design outputs = Have a design review.
- Complete design verification = Have a design review.
- Complete design validation = Have a design review.
- Finalize the medical device = Have a design review.
If this is your interpretation of how design controls are supposed to be, then I can definitely understand why you feel design controls are rigid.
Truth: The Design Controls Process Should Be Flexible
Do not interpret the “waterfall” as a rigid approach.
Instead, understand that design controls are all about iterating and adjusting based on what you learn throughout design and development.
That said, there are some design control absolutes you definitely should consider:
Design verification demonstrates that design outputs meet design inputs. This means you have to define design inputs and outputs before verifying. You cannot conduct a verification activity and then determine, after the fact, whether the criteria have been met.
Design validation demonstrates that the product meets user needs. You have to know your users’ needs before you demonstrate whether your product meets them.
Design reviews are necessary for all design controls at appropriate times throughout product development. Design reviews serve as checks and balances.
If you feel as though your design controls process is too rigid, then maybe it is.
Maybe, instead of ignoring design control documentation, it would make some sense to re-evaluate your overall approach.
Myth #4: Design Controls Are Optional
You’ve determined that your product’s path to market involves an FDA 510(k) submission.
You capture and address what you believe FDA expects in a 510(k).
You submit an application and receive clearance from FDA.
You didn’t document design controls, and FDA did not ask about them during the 510(k) review process.
Sounds like documenting design controls may be optional, and it probably doesn’t apply to you.
Truth: Design Controls Are Required
FDA expects that you follow 21 CFR part 820; design controls regulations are defined in 820.30.
Just because FDA did not ask to see your design controls as part of 510(k) review does not mean these regulations are optional.
In fact, so much of a 510(k) is actually based on design controls.
But here’s the catch: FDA assumes you will follow 21 CFR part 820, and the agency will confirm that this is the case when they show up for an inspection.
I realize that doing something just because it’s the law may not be reason enough, but consider that, one day, your medical device is going to improve and possibly save lives.
Design controls provide the objective evidence to support your claims and to demonstrate that you’ve tested and proven the product.
Design controls are the documents and records that others, FDA among them, will review to ensure the product meets the needs of patients and end-users.