How Do You Capture User Needs for a Medical Device?

Why do you engage in medical device product development? The ultimate purpose is to solve unmet clinical needs. To develop products, technologies, and services which sustain and improve quality of life.

If your experience as a medical device product developer has been anything like mine, starting a new project is often very fuzzy and raises more questions than answers. How you start a project is very important. And this is something that took me many attempts before I truly understood.

What do you need to start a new medical device product development project? If your company is anything like those I’ve worked with, chances are the reason to start a project is often times very vague. Basically, it boils down to someone making a financial commitment to begin the endeavor.

But as a product developer, you want and need more. You want to understand what clinical needs this idea will solve. You are seeking knowledge about how the user will interact, how the patient will interact. You want User Needs.

You go to FDA Design Control regulations to seek some guidance and direction on what User Needs are but are left scratching your head. No real help. You find a couple references to user needs:

820.30(c) Design Input states “. . . 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 . . .”

820.30(g) Design Validation states “. . . Design Validation shall ensure that devices confor to defined User Needs and intended uses . . .”

Not really all that helpful.

You decide to check out the FDA Design Control Guidance and are thankfully provided a few more tidbits of what User Needs are. At least “User Needs” is shown in the classic Design Control waterfall diagram:

FDA Design Controls waterfall

FDA Design Controls waterfall

From the guidance document, you learn that as a product developer, you have to translate User Needs into a set of requirements that can be validated prior to implementation. You finish reading the guidance (and I do recommend doing so–it is a helpful document) and have a little better idea of these things called User Needs. But you still don’t know really what these are or how to capture these.

Maybe I can help you a little. Think of User Needs as a bit of a wish list about what the device does or should do. Some questions for you to consider when capturing User Needs include:

  • Who will use this device?
  • How will the user and patient interact with the device?
  • What type of procedures will the device be used?
  • What type of environment will the device be used?
  • When will the device be used?
  • Is the device used one time or over and over?
  • What other products will the device interact and interface with?

I could go on with the list of questions to consider. But hopefully, you are beginning to understand what User Needs are.

Write them down! Ideally you write them down some time near the beginning of a project. If you are downstream in product development, there is still value in writing them down! At some point you will need to prove that your device meets those User Needs.

User Needs are very important to capture, though as early as possible in a project. Why? User Needs are the precursor to Design Inputs. And Design Inputs are the king of Design Controls. Design Inputs capture specific, measurable, objective details about your device. Their foundation must come from User Needs. In fact, every Design Input does have an origin to at least one User Need, whether stated or not.

As the waterfall diagram above suggests, User Needs gets the Design Control ball rolling.


Related Posts

Comments are closed.