If you are engaged in medical device product development, then you likely know about the importance and requirement to establish and document Medical Device Design Controls.Not to scare you too much, but Design Controls are required by FDA for medical devices (I hesitate to say “all” because there are a few cases where this is not required).
FDA has a pretty good guidance document on the topic of medical device Design Controls.
Further, I’d like to recommend a blog post from Medical Device Academy – “10 Steps to Implementing Design Controls” which does a decent job providing an overview of Design Controls.
The “10 Steps . . .” post lists the following as the 10 steps to implement Design Controls:
- Establish a thorough and complete Design Plan.
- Design Inputs need to be requirements verified through the use of a verification protocol.
- Design Outputs are drawings and specifications.
- Design Reviews should have defined deliverables.
- Design Verification protocols should be standardized, instead of being project-specific.
- Design Validation should be more than bench testing.
- Design Transfer is not a single event in time.
- Do not keep the DHF open after commercial release.
- Your DMR Index should perform a dual function of also meeting technical documentation requirements for other countries.
- Audit your Design Control process.
Yes, these 10 steps are definitely important and critical to ensuring you are documenting and capturing Design Controls.
And I think if you followed these 10 steps for your medical device product development efforts, your Design Control documentation and records would be in pretty good shape.
However, I think there is one pretty significant step that is missing from the list.
First, let me ask you a few, quick questions. Why are you developing a medical device? Are you trying to save lives? Does your product improve the quality of life?
What I’m getting at is this: You are developing a device to address a medical need of some kind.
Because of this, the first step in Design Controls is to establish the intended use of your medical device.
Describe what your device is intended to do. Describe who will use your medical product and for what types of procedures. Capture the User Needs for your device. In fact, if you notice the very first box listed in the classic Design Control waterfall diagram, it states “User Needs”.
User Needs get the Design Control process going. And User Needs are necessary in order to fully validate the medical device design prior to going to production and the market.
Without them, how do you know what to design? Without them, how do you know what’s important to the eventual users of your medical device?
Surprisingly, I’ve seen many, many cases throughout my career where the product development team did not formally capture and document User Needs.
Most of these teams were aware of User Needs and definitely gave the topic lip service. Yet, few actually spent enough time to write the User Needs down.
Most assumed that they had a clear understanding of User Needs in their heads as they proceeded through product development.
Don’t fall into this trap. Document your User Needs and get consensus from your team that they are right.
I advise this even if your project is mid-stream in the product development process. There is definitely value in having solid User Needs defined and understood by the team.
As the waterfall suggests, User Needs feeds directly into Design Inputs.
You need User Needs in order to define Design Inputs. As you approach the launch of your product, you also need to complete Design Validation, which demonstrates your product meets User Needs.