It's hard to believe I've been in the medical device industry since 1998.
I have learned so much and time has flown by.
But I can still vividly remember the first real medical device project I was given as a new product development engineer.
This first real project was the Enk Oxygen Flow Modulator. Prior to this project, I worked on a few others, but more in a supporting role. The Enk medical device project was the first one where I was the project leader.
I was in charge of doing and overseeing all aspects of that project. And I didn't realize at the time, but I was very fortunate with the Enk project.
Why?
It was really all about how that medical device project got started.
The project "champion" was an anesthesiologist from Germany, Dietmar Enk. Dr. Enk's primary language was German, and his English was very good. We were six time zones apart, and email was actually a pretty new thing for the company I was working for at the time. But Dr. Enk did a fantastic job of communicating to me.
He communicated, not only in words, but also with prototypes. He did a great job of teaching me of the clinical and user needs of the device.
At the time, FDA Design Controls regulations were still pretty new to the industry. The company had procedures and forms in place to address Design Controls.
One of these early forms was called the "Design Plan". It was a four-page bi-fold form that we completed by hand. I wish I still had a copy of this document--it really was a pretty decent overview of all the stuff a product development engineer needs to consider when starting a new medical device project.
The Enk Oxygen Flow Modulator was my first real exposure to the importance of capturing solid user needs and design planning.
I'd like to sit here and tell you that every project since built upon this foundation. I think the main reason these concepts took so long to stick with me is that I just didn't realize while it was happening what Dr. Enk was teaching me about medical device product development.
A medical device project can definitely feel like a race of sorts. However, the "race" is more like a marathon. Or maybe a whole series of marathons.The trouble is, we often treat medical device product development like a sprint.
If your experience is anything similar to mine, the powers that be often have the due date in mind when assigning a new medical device project. How can that be? It just is.
Your job, though, shouldn't change. Yes, that deadline your boss assigned to this new project you were just assigned to seems unrealistic. It may be.
It's not enough for you to complain about it every chance you get. It's also not enough for you to just accept the due date as etched in stone.
Once you get this new medical device project you need to do 2 things ASAP:
You can determine which comes first. Maybe both should happen in parallel.
If you look for the term "user needs" in the FDA Design Controls regulations, it is mentioned a couple times. The first time is buried in under 820.30(c) Design Input:
Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient...
The second time is in 820.30(g) Design Validation:
. . . Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions...
Never fear! FDA also has a really good guidance document for Design Controls. The term "user" shows up over 30 times in the guidance with most pertaining to User Needs. In fact, it's in this guidance document where the famous FDA Design Controls waterfall diagram (which is actually from Health Canada) shows up.
And there you see starting the whole waterfall is User Needs.
User Needs capture what is important about the medical device from the perspectives of the end user and patient.
You also need to consider the clinical application and use of your medical device. You need to write these User Needs down.
User Needs are likely to be somewhat vague and often times a bit ambiguous. And that's okay.
Some questions for you to consider when capturing User Needs should include:
There are many, many more questions you should be asking when capturing User Needs, but hopefully this helps illustrate how to capture User Needs.
Capturing and documenting User Needs is so important for 2 very important reasons:
When most medical device professionals hear the term "design plan", they usually think of one thing: project schedule. However, a Design Plan is much more than just a schedule.
You can go to FDA regulations on Design & Development Planning (820.30(b)) for help and you'll read the following:
Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed, updated, and approved as design and development evolves.
Boy, that's clear, right? Not to oversimplify, but the purpose of a Design Plan for your medical device project is to identify what needs to be done, who needs to do it, and when it needs to be done.
It's hard not to include a schedule with your Design Plan. After all, you are probably under a decent amount of pressure to ensure your medical device project gets done by a certain date.
And spending too much time planning is often viewed as a non-value add activity. But you have to have an understanding of what needs to happen. The only way to do this is to have a clear understanding of what clinical need you are trying to solve.
This is why I think there is a strong relationship between User Needs and Design Planning.
Know your User Needs and be able to figure out what problem you are trying to solve with your medical device project. Then you can establish a Design Plan for your medical device project.
When you establish a Design Plan, you should also identify when to have Design Reviews. The timing and frequency of Design Reviews is dependent on the scope and complexity of your medical device project.
Despite your best efforts early on in your project and despite how many times you've done this before, the best Design Plan will probably be out of date and need to be updated several times throughout the medical device project.
That's okay. It's actually encouraged. Many medical device companies have product development stages or phases to follow for a medical device project.
My advice to you for a Design Plan is to embrace this phase approach. Your Design Plan should be fairly specific and detailed for the phase you are in and the next phase immediately following.
Future phases should be included--especially the major milestones and anticipated deliverables. But going into too much detail for future phases is usually a futile cause. Because these details are usually impossible to layout in an accurate plan.
As you approach the end of a phase of your medical device project, this is the time to revisit your Design Plan. This is the time to add details for that next chunk of work.
Jon Speer is a medical device expert with over 20 years of industry experience. Jon knows the best medical device companies in the world use quality as an accelerator. That's why he created Greenlight Guru to help companies move beyond compliance to True Quality.