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:

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.

Medical Device Design Control Traceability Using UniDoc

If you are familiar with medical device product development, I’m guessing you’ve seen the FDA Design Control Waterfall diagram. FDA describes Design Controls in a linear fashion: user needs, design inputs, design process, design outputs, design verification, medical device, design validation.

Chances are your product development and design control processes do so as well.

But do medical device projects really follow this linear path?

What if you had the ability to take each individual component through of your medical device product development project through the entire design control process at its own pace? What if you could do this and ensure all Design Controls for that component were documented, traceable, and so on? You don’t have a tool that can do this right now.

UniDoc does this.

The Ability to Zig Zag Through Medical Device Product Development

If you have been a part of medical device product development, there is a good chance you are somewhat familiar with the image below:

Most refer to this as the FDA Design Control waterfall diagram (the origin is actually Health Canada) and is referenced in FDA Design Control Guidance document.

Since starting my career as a product development engineer for a medical device company and my first exposure to this image, I have been fascinated by it. In many respects, the image is pretty good at showing the progression of Design Controls during product development. Many interpret and infer that Design Controls = Product Development. There is definitely a dependent relationship of sorts. Design Controls are generally part–albeit a huge part–of medical device product development. Many companies have implemented a phase approach to product development. Often times these phases coincide with the Design Control diagram shown above.

What I continue to find interesting about medical device product development and Design Controls is that we continue to express this process as a linear progression. Yes, when I write procedures for product development and Design Controls, I use phases to describe the process. But do phases really make sense?

Let’s use the image above to evaluate a little more. I interpret that in order to establish Design Inputs, I first need to establish User Needs (and so on). By a strict interpretation, you cannot finalize Design Inputs until you have first finalized User Needs.

Is this how medical device product development works in your organization? I speculate that the answer is no.

In practice, you likely have a fuzzy list of User Needs. The list is rarely complete before you start to define Design Inputs. In fact, you might even begin creating Design Outputs before you have even officially finalized the list of all User Needs.

Doesn’t it make more sense to get as much as of your medical device to Design Verification and Design Validation as quickly as possible? I speculate yes.

This type of approach is more logical but complicated by a few things, including:

  • Your procedures dictate product development phases
  • Your organization may require you to complete one phase before proceeding to the next
  • You likely do not have good tools in place to allow you to effectively manage this type of approach

But what if you did have a tool that would allow you to manage the more natural way of product development? What if you have a software solution to capture all Design Controls which provided clear, easy to follow linkage for each element in one place? Do you think this tool exists? In my experience and research, not really. At least not until now.

This is why Creo Quality is launching UniDoc. UniDoc is the collaborative way to manage design history for all your medical device projects.

It’s time to use a tool to help you manage your Design Controls and product development efforts in a more logical, efficient way. Contact us to put UniDoc in place at your company.

What Comes First: Design Input Requirements or Prototype?

Okay, this is kind of a trick question. Actually, what should come first the the unmet clinical need. But once you’ve identified the unmet clinical need, what do you do next? Do you define the product’s design inputs? Or do you proceed to building some type of prototype?

I’ve taken both approaches. And I’ve often wondered which is best–which is correct.

I think I now know which approach makes the most sense. Build the prototype first.

Why? A prototype is so much better at communicating than words can ever be. Put a prototype in the hands of end-users, and they can tell you everything that is right about it. More importantly, they can tell you everything that is wrong too.

Capturing and documenting design input requirements becomes so much easier when end-users are able to conceptualize the product, especially if they can hold and manipulate it in their hands.

So go build the prototype. It doesn’t have to be perfect. It doesn’t have to be made using production materials or processes. It has to be good enough to communicate a solution to others.

Then take the information you learn with this prototype and document the design input requirements. And refine the prototype to learn more and more until you have the product design right.

It’s important, though, to not get too stuck in this cycle. It’s easy to do, especially for engineering types. Don’t try to make the perfect product with all the bells and whistles. Know when the product is good enough to address the unmet clinical needs and get it to the market as quickly as possible. Be sure you’ve proven its safety and efficacy, and of course be sure to document all of this along the way.

Ideas vs. Execution

I came across this blog by Seth Levine in which he encourages usage of some of the same principles that we try to persuade you to instill with our Building The Business Case document.

Mr. Levine states, “Ideas are great. But they’re not as valuable as most people make them out to be, and by correlation, execution is almost universally underrated and in hindsight taken for granted as a given once a company has become successful (and rarely given the credit it deserves).”

I was especially interested when, in referring to what we consider market leaders, he states “Many weren’t the first or only ones to come up with the idea that made their company. What separated them from their competitors was their ability to out execute everyone else in a way that took a good idea and made it a great company. Often, in fact, another company was the early market leader only to have their leading position overtaken by an upstart who was hungrier, more nimble, and more focused on the basics of executing a great business.”

He ends with, “My point isn’t that ideas aren’t important. It’s just that execution of those ideas is far more critical. And it’s worth thinking about that as you consider the operations of your own business.”

This is where Building the Business Case can really make a difference.  Keeping the principles we discuss in mind will “keep you focused on the basics of executing a great business” and therefore help to ensure that your business becomes and remains successful.

I remember when I was in elementary school one of the girls had a Cricket doll instead of a Barbie doll.  Mr. Levine’s musings got me to wondering, “Whatever happened to Cricket?” I’m sure Cricket was basically the same unrealistically perfectly proportioned, flawlessly coiffed doll as Barbie.  Perhaps poor Cricket didn’t have the advantage of having people behind her who were focused on executing a great business. Otherwise she too might still be popular and successful after over fifty years.

Other blogs on Building the Business Case:

Building a Business- The First Step- Know Your Product

The Second Step to Building the Business Case- Know Your Market

Part Three of Building the Business Case – Location, Requirements, and Market Size

The Final Steps- Know Your Competitors

Simplifying Medical Device Design Controls

If you are like most medical device companies, the term “design control” is usually met with a cringe or two. I also suspect your product development process and design control deliverables might be more cumbersome and quirky than you’d like–especially since you are expected to complete your medical device product development efforts as quickly as possible.

And what happens once the product development project is complete? Do you file the design control records away in a design history file (DHF) and archive them in some file cabinet or electronic record system? How easy are these to retrieve and access for future projects? Do other groups, such as regulatory affairs have access to DHFs in order to compile regulatory submissions such as 510(k)s and technical files?

What if you had a software solution to document design controls as they happen? What if this same solution could be a living repository for all design control and product development activities? What if this same solution could also pre-populate regulatory submissions?

Don’t think this product exists? Think again. Creo Quality’s UniDoc software is the solution you need to streamline your medical device product development efforts.

UniDoc is developed from proprietary database platform software and be mapped to match your current product development and design control processes. The software is 21 CFR part 11 compliant and meets FDA, EU, and Canadian regulations for medical device design controls. UniDoc contains modules for key regulatory submissions, including FDA 510(k), FDA IDE, EU technical file, and Canadian submissions.

If you are interested in learning more about UniDoc and how you can get this product at your company, contact us: or 765 315 2736.

Enhanced by Zemanta

How Do You Explain Regulatory Compliance?

When I was writing the last blog post for Building a Business Case, I really struggled with how to emphasize the importance of understanding regulatory and certification requirements ahead of time so that you could design your product around any codes or standards you need to meet.  Afterwards, I came across “Designing for Regulatory Compliance”.  It really goes into detail on the subject and explains how essential this concept is.

“Let’s start by understanding the goals of the regulatory processes. In general, they exist to ensure that safe and effective products are delivered into the market place with appropriate risk-benefit ratios. Every manufacturer, designer, regulatory professional, medical practitioner, and consumer has this as a common goal. However, if this is the case, why are there continually issues?  The issues originate in the way regulatory compliance is treated during the development process. It is often seen as an afterthought or a necessary evil to be tested for and sometimes gamed at the end of the process when negative regulatory feedback is very frustrating and expensive. Even one request for additional information can be devastating to a company’s plans and financial well-being. Funding for start-ups and small companies is often tied to regulatory milestones.

So what can you do? With existing ‘design for …’ processes, teams consist of the stakeholders who ensure successful execution of the plans. Similarly, companies can incorporate regulatory affairs professionals (or those with extensive regulatory experience) directly into their design teams to ensure that the regulatory concerns and requirements are addressed in planning and subsequent design phases. This approach encourages the team members to use their experience and expertise to design products and test programs that will allow the creation of regulatory-ready products.

Design for regulatory is a valuable concept, regardless of future changes to agency requirements or processes. Other ‘design for…’ paradigms have shown that up-front, early consideration of tasks that are usually performed at the end of the product development process reduces time to market and costs associated with redesign.
The development of a solid regulatory strategy and the incorporation of regulatory resources into the design process will ensure fewer surprises and allow for more efficient and potentially easier FDA submissions. This paradigm can also yield better competitive information and product positioning and potentially create a competitive advantage in the marketplace.”

Mr. Saltzstein, being an actual product designer, explains the process much better than I could ever hope to.

Design Input Requirements Are Living

Tiger Buford recently posted about the need to revise and keep Design Inputs up to date and current. He’s absolutely correct. Design Inputs must represent the current product design.

Tiger also suggests that Design Inputs be blessed and endorsed by the entire project team. If the Design Inputs are not comprehensive, then there is still work to be done. It’s important to review and revise the Design Inputs often. Good times to do this are as part of Design Reviews and project phase reviews. It may help to use a simple checklist from time to time. Go here for some questions to consider.
As discussed previously (“Foundation . . . part 1″ & “Foundation . . . part 2″), Design Inputs are the foundation of product development. Be sure that the foundation is always as strong as possible.

Understand the End-User Needs

Design Input Requirements are the foundation of product development. Design Inputs should be derived from user needs and a specific intended use. Design Inputs should be objective and verifiable.

So what happens once a product is introduced into the market and the end-user provides feedback that the device is difficult to use? Should your objective be to prove that the product in question meets the Design Input Requirements? If so, and the device meets the requirements, are the end-users wrong?

Listen to the end-users. Don’t try to prove them wrong. What are the end-users trying to tell you? What has changed since introducing the product into the market? Is the device being used by end-users for which the device was originally developed?

Often during product development, end-users provide input and feedback to the process. However, only a small sampling of end-users are involved in the product development efforts. And in my experience, these end-users are usually the tops in their field and sometimes even the ones who helped develop the product idea.

Then it happens. The product usage grows. More and more end-users begin using the product–and these end-users don’t always have the same skill as those involved with original product development efforts. Other business units may see areas of application for the device and add the product to their portfolios, exposing additional end-users to the device.

This issues happen often. But what continues to amaze me is when people are surprised that there are device issues. I hope this scenario does not describe products involving you. If so, do yourself a favor. Understand the end-user needs. If the end-user tells you the device is difficult to use, find out why. Determine what will make the device easier to use.

Sources for Design Input Requirement

Where does one go to discover, uncover, and determine Design Input Requirements? Here is a mind map of sources to consult:

Sources for Design Input Requirements

    29SEP2006 – I apologize for the tweaking of this post. I noticed after the fact that the image size affected the rest of the site. If you want the image in a more readable form, let me know (

Design Input Requirements – 15 Questions to Answer

As discussed in the Foundation of Product Development series, establishing Design Input Requirements for a medical device is crucial. Here are 15 questions to help you down the path towards defining Design Inputs for a medical device:

  1. What is the real need for the medical device?
  2. What are the possible ways the device can be misused and/or used off label?
  3. Where will the device be used?
  4. Who will use the device?
  5. How will the medical device be used?
  6. What other devices / products will be used in conjuction with the device?
  7. How will these devices interact?
  8. How long will the device be used?
  9. What are the operational limits of the medical device?
  10. In what countries will the device be sold?
  11. Where will the device be manufactured?
  12. What are the regulatory and legal requirements?
  13. How will the device be packaged?
  14. What does the patent landscape look like?
  15. What competitive devices exist?

Can you think of more questions?

Foundation of Product Development: Design Input Requirements – Part 2

As mentioned in part 1 of this series, design input requirements are the foundation of medical device product development efforts. A set of poor requirements will make product development efforts difficult and challenging. Establishing a good foundation of solid, objective, and comprehensive design input requirements takes time and effort of a cross-functional team. Device safety and efficacy are the primary focus of product development. Design input requirements are the key to achieving this focus.

Prior to developing design input requirements, there should be a need. The “need” includes user needs and details regarding intended use(s). The need will likely be somewhat vague and ambiguous. Often times, a need is expressed in the form of a prototype. While the prototype appears to be close to a finished solution, realize that it is critical to take a few steps back in order to define and fully understand the need. The prototype should not be accepted as the solution. This can present difficult situations, however, because of the pride and ownership one attaches with a prototype design. Regardless, before establishing detailed, objective design input requirements, the user needs, intended uses, and the use environment must be understood.

Design input requirements should be comprehensive. All aspects of the medical device should be captured and defined within the list of design inputs. All aspects–including packaging, labeling, and instructions for use. I draw attention to packaging, labeling, and instructions because these aspects are often forgotten or saved until late in the product development process.

Design input requirements need to address intended uses. However, medical devices are sometimes used “off-label” and/or incorrectly. The design inputs should reflect off-label and incorrect usage of a device. Design input requirements should consider:

  • regualtions
  • industry standards
  • interactions with other devices and equipment
  • use environment
  • storage and shipping
  • end user (i.e. physician, home care)
  • similar devices
  • feedback and input from a cross-functional team
  • feedback and input from end users
  • patents
  • prototypes
  • manufacturability

FDA regulations and ISO requirements state that design input requirements must not be ambiguous, incomplete, or conflicting. These terms often cause confusion for product developers. Simply put, a design input requirement must be measurable, verifiable, and objective. Here is an example of an ambiguous and incomplete design input requirement:

The device must deliver adequate fluid for treatment of the disease.

Stay away from using words like adequate, sufficient, approximately, and similarly. Design input requirements using these terms are likely to be ambiguous and incomplete. To improve up the above example, consider this:

The device must deliver fluid at 300 cc/min at 50 psi for 30 minutes for treatment of the disease.

These improvements reduce ambiguity and allow the design input requirement to be verified.

Be sure a design input requirment does not conflict with another or even with itself. I was once asked by a team member to make a flexible stiffener. This should help illustrate an example of a conflicting design input requirement.

A suggestion for making design input requirements unambiguous, complete, and non-conflicting is to consider how the requirements will be verified. Design verification is a design control element and the details will be covered in a future post. Design verification methods include testing, inspection, and/or analysis to prove that design outputs meet design input requirements. When defining design inputs, think about how the requirement will be tested, inspected, or analyzed downstream during design verification. Again, objectivity is critical.

The responsibility for developing design input requirements should not lie with a single individual. Product developers (often engineering personnel) have primary responsibility for design input requirements. However, marketing, sales, regulatory affairs, quality, manufacturing, and end users should all be included during establishment of design input requirements.

Developing design input requirements is time consuming. I’ve worked on many product development projects where there was pressure to move forward. Company management will often push a team to move forward with ambiguous, incomplete, and conflicting requirements. Moving forward with poor design inputs is false progress. Design input requirements that are ambiguous cannot be objectively verified. It may be a battle to convince management the importance of fully defining clear and complete design input requirements. As stated earlier, design inputs represent the foundation of product development.

Future posts will address design input requirements and other design control issues. Creo Quality has the experience and ability to help with your challenges with design input requirements. Contact for questions and comments.

Foundation of Product Development: Design Input Requirements – Part 1

Design Input Requirements are critical to a product development project. According to the FDA’s Design Control Guidance document, requirements “the single most important design control activity”. Whether this is true or not is debatable and probably a moot point. Design Input Requirements are, however, the foundation of a product development project.

I need to clear upsome terminology before proceeding too much further into this series of posts about Design Input Requirements. According to FDA Code of Federal Regulations (CFR) 820.3(f), Design Input means “the physical and performance requirements of a device that are used as a basis for device design”. Many terms are often used somewhat interchangeably to describe requirements:

  • Design Inputs
  • Design Input Requirements
  • Design & Development Inputs
  • Design Requirements
  • Performance Requirements
  • Product Requirements

There are probably more terms that are used, but for the sake of this post, I will try to stick with Design Inputs and/or Design Input Requirements. Even though the above list may seem like an issue of semantics, do not underestimate how much confusion terminology can cause.


Design Inputs are addressed in the FDA CFR:

820.30(c) – Design Input

  • Each manufacturer shall establish and maintain procedures to ensure that the design input requirements to a device are appropriate and address the intended use of the device, including the needs of the user and patient.
  • The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements.
  • The design input requirements shall be documented and shall be reviewed and approved by designated individual(s).
  • The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.

ISO 13485:2003 – Medical Devices – Quality Management Systems also defines Design Inputs:

7.3.2 Design and Development Inputs

Inputs relating to product requirements shall be determined and records maintained (see 4.2.4). These inputs shall include:

a) functional, performance and safety requirements, according to the intended use,
b) applicable statutory and regulatory requirements,
c) where applicable, information derived from previous similar designs,
d) other requirements essential for design and development, and
e) output(s) of risk management (see 7.1).

These inputs shall be reviewed for adequacy and approved.
Requirements shall be complete, unambiguous and not in conflict with each other.

Simple enough, right? My experience is that defining good, objective, verifiable design input requirements is extremely difficult and challenging. Design input requirements take time, experience, and input from a cross-functional team. I will go into more details about the art of defining design inputs in part 2 of this series.