“The answers are only as good as the questions we ask!”
The aim of any medical device company is always to create safe, effective solutions to real problems, yet unfortunately, this doesn’t always go to plan. “We designed the medical device perfectly, but the patient still died” - this can sometimes be attributed to designing the right medical device, but solving the wrong problem.
What good is getting the “right” answer if we asking the wrong question?
Bridging user needs and design requirements is an important piece of the puzzle when it comes to creating the right medical device and solving the right problem. Greenlight Guru partner, Mike Drues, President of Vascular Services co-hosted a webinar with me recently, where we aimed to break down that important bridge.
I’m looking at some key takeaways in this guide:
What are design inputs?
First of all, it’s good to check out how the regulations describe design inputs. Here is an extract from 21 CFR 820.30(c).
(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 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 a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.
Let’s pull out some key terms from the text and examine them more closely:
- “Appropriate” - we generally take this to mean that the requirement is relevant and useful for the particular device. One thing to be clear on here is that the regulation leaves itself open to interpretation by the company.
- “Intended use” - This is a commonly used, yet often misunderstood phrase at both industry and FDA levels. It often gets mixed up with “indications for use.” Submissions to FDA are often wrong in this respect. While “indications for use” focus on the patient (the condition or symptoms being treated), “intended use” focuses on the product. What does the device do? What is its mechanism of action?
- “Needs of user and patient” - historically, medical devices have been operated by physicians or other trained professionals; however, these days the user and patient can be one and the same. This presents further challenges for things like human factors and usability testing. You need to consider users that are trained professionals vs. those who are not.
- “Mechanism for addressing incomplete, ambiguous, or conflicting requirements” - the assumption is that we recognize this in the first place! In many situations we find, they have arisen because no one identified the problem before it occurred.
An important note here is that most medical devices are not limited to on-label use - people often aren’t reading the labels! Where a patient is injured and the case goes to court, the company can find themselves liable, even if the use was off-label. This is particularly when counsel for the patient can show that the action the patient took should have been classed as “anticipated use” by the manufacturer.
As Mike says:
“Regulation is all about the interpretation of words, AND your ability to defend your interpretation.”
Would you assume FDA’s interpretation is any better or any more accurate? We interpret things differently depending on what we are trying to accomplish. It’s often a matter of being able to convince FDA why your interpretation is good. FDA has been known to make mistakes too ever once and a while.
Relationship between design inputs and user needs
Typically, we collect our user needs first, then translate those into design inputs. An important point here is to ensure that you’re getting those needs from actual users, rather than simply relying on internal brainstorming.
If you’re not the ideal user, how will you know that you’ve truly identified “user” needs? Even if you can make some assumptions internally, it’s important to verify those with people who fit your criteria as an ideal user.
The intent behind the regulation for this is to ensure we start out with the needs of the user, before translating those into engineering terms. Interestingly, there is no definition for “user need” in the regulation though.
The closest thing we get is this, from CFR 820.30 (g):
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.
The assumption seems to be made that the user already knows what they really need, but years of development prove this is not the case. They might think they know, but it’s up to us to be able to look beneath the surface and carefully define those needs.
Again, it’s up to us to interpret the regulation and to be able to defend our position on it. A key point is that it is not rigid or specific, particularly due to the range of devices it covers. FDA themselves state that it is to be used as a framework.
If a rule doesn’t make sense, then it’s important to question it. There are always exceptions to rules...
How to translate user needs into a viable (right) product
When you’re translating those user needs into design inputs, it’s important that you’ve clearly defined the meaning behind what people are telling you.
Let’s say, for example, a doctor says “the device must be portable”; in engineering terms, what exactly does that mean? You might be looking at the maximum weight of the device, it’s size or volume, and where it’s needed to fit (on a cart, for example). You would need to know if it needs to connect to power, or use wifi - what does “self-contained” mean?
Your design inputs need to be specified in very significant detail. It’s okay if your user needs are more fuzzy, as long as those inputs are clear! You should have sampled a wide enough range of your customer base so that you can be sure you’re headed in the right direction.
Mike even suggests sampling people who don’t think there’s a need for your device. If you can convince them that there is a real need, you’re probably onto something.
All of this is required because the designer is not (usually) the end user! The regulation recognizes that most designers are not physicians, or using the devices in real-world settings.
Mike provides a list of potential design inputs below. Check out his recommendations on the slide for identifying those design inputs:
An important point to remember is that, much like your risk management plan, design inputs should be a “living” document, to be revisited over time. It’s up to you how frequently, but this is in the spirit of the regulation - things change and it’s important that appropriate updates are made.
Realistically, this is common sense and prudent engineering, and should be done regardless of regulation.
Here’s a key bottom line that isn’t mentioned in the regulation: what is the clinical problem we’re trying to solve? Or put another way, what is the root cause?
Final thoughts on PART I
I’d leave you with two important, key takeaways here:
- Make sure your user needs are interpreted clearly into design inputs. What specifically do people mean when they make statements about weight, size, or shape, for example?
- Don’t just blindly “follow regulations.” As FDA regulations are written to cover a large range of possible devices, people often don’t realize that they are deliberately broad and aren’t prescriptive. It’s up to you to interpret what they mean, and to be able to defend your interpretation.
Continue down into Part II of this conversation on bridging the gap between user needs and design inputs.
How do you make that leap from user needs to design requirements?
This is a bridge that often proves to be a rocky one to cross for medical device manufacturers. In this guide, Part II, we’re exploring future challenges and some commonly asked questions on the topic:
One of the most fundamental significant limitations of Design Controls is that fundamental tenant - meet the needs of your user. Of course, the problem is that users think they know what they need but may not know what they really need.
Assume that they don’t know. When you look around, you see that there is a lot of evolutionary product development - as in, we ideate devices that already exist. While this is necessary and can bring many advantages, it means we don’t get so many revolutionary products.
A horse didn’t evolve into a car. Imagine you were a device developer back in the days of transportation by horse. Users are going to tell you what they think they need, based on what they already know (a bigger, faster horse!). If you were to simply take what users said at face value, those revolutionary inventions, such as the motor car, would never come about.
EXAMPLE: BARE METAL CORONARY STENT
Let’s say you’re working on a device to open up diseased or impeded coronary arteries. You talk with coronary surgeons to gather user needs, and most of them are going to explain that they need a tube stent to hold open the artery. They’re telling you what they think the need is, based on what they know already.
There’s a saying that comes into play here:
“If the only tool you have is a hammer, all of your problems look like nails.”
What solutions have you not looked at? What questions have you not asked? For example, the question could be reframed from “how do we open up that artery?” to “how do we get a healthy supply of oxygen and glucose to that myocardial tissue downstream?”
We now open ourselves up to a whole bunch of other solutions. For example, in this case, mechanical angiogenesis could be an option, essentially lasering the myocardial tissue and creating new arteries. We mechanically create new blood vessels.
The answers are only as good as the questions we ask.
Remember that if you’re a stent manufacturer, your competition isn’t just other stent manufacturers - that would be a myopic approach. Your competition includes companies prepared to assess user needs comprehensively early on and to develop disruptive technology to meet them. This principle can be applied to any other type of medical device manufacturer.
Interestingly, with regard to stents, around 200,000 patients per year have them inserted to relieve chest pain. A recent study found that, while stents can be effective for preventing heart attacks, they are often actually useless for relieving chest pain.
“The new study, published in the Lancet, stunned leading cardiologists by countering decades of clinical experience. The findings raise questions about whether stents should be used so often — or at all — to treat chest pain.”
This example goes right back to clearly defining those user needs. What is the issue? The heart attack prevention or the chest pain? Questioning the status quo is important - treatments are often based on rules or traditions, rather than objective, scientific evidence.
PERSONALIZED MEDICINE AND MEDICAL DEVICES
Another future challenge is the demand for more personalized treatment and devices. Sticking with the stent example, there is currently technology being worked on for 3D printing of stents, customizing not only the size and shape, but the drug combination for patients.
For technologies like this, how do concepts like quality and user needs translate?
COMMON QUESTIONS about User Needs and Design Requirements
During the recent webinar, Mike Drues and I recently held on bridging user needs and design requirements, it prompted several questions from the audience. Here are some common questions:
DO ALL DESIGN INPUTS NEED TO HAVE A USER NEED?
Mike has a counter-question for this - if the design inputs did not originate from a user need, where did they come from? Someone somewhere has identified a particular want or need and translated it.
User needs don’t have to come just from the user - they might come from marketing folks, engineers, physicians, patients, people who assist users… However, the engineer should always go back to the user and verify the need.
A serious example from a couple of years back that fits with this question is issues surrounding the use of a duodenoscope. These were not reprocessed properly after use, which led to infections in patients and even some deaths.
Everyone was asking, why did this problem happen? Do we need new regulation? Mike’s recommendation to the FDA was that new regulation is NOT needed as it’s already contained within the current rules. What it came down to was user needs - making sure that your user can use your device. The question was, who is the user? If your device is designed to be reprocessed, then one of your users is the reprocessor. This must be accounted for in your design - how will you include them and ensure that safe practices are clear?
Fundamentally, manufacturers need to understand the spirit of the regulation and take all of these things into account when gathering user needs, and translating into design inputs.
SHOULD YOU LET ENGINEERS WRITE THE DFU?
If I go and get a piece of furniture from IKEA and read the assembly instructions, it becomes clear that they were written by someone with technical expertise!
The thing with writing Directions for Use for a medical device product is that they must be in plain language that people will understand.
Mike takes it a step further; “If I have to read the instructions to operate the device, then some engineer somewhere hasn’t done their job.” Many people live in a theoretical bubble where they assume people read directions - in the real world, people often don’t!
WHAT ABOUT DESIGN INPUTS FROM RISK ANALYSIS OUTPUTS?
So as a result of your risk analysis, you’ve identified some risks of the device, and you’re using them as design inputs in order to mitigate or eliminate future risk. This is a great example of design inputs that don’t originate from user needs (or you could argue that risk mitigation is like a user).
This is a great approach to look at design in a more holistic fashion, and account for other areas that make your device safer.
CAN DESIGN INPUTS INCLUDE BUSINESS NEEDS? (E.G. COLOR, COSMETICS, COST)
One thing Mike strongly believes is that all elements of your quality system should be defined and attached to the product and company. You can define user needs to include these “non-conventional” categories if you like.
If you have a wonderful device, but no one can afford to buy it, how many people can you help? Things like cost can definitely come into the equation.
Sometimes people prefer to cite the source of their user needs, and there’s nothing wrong with saying “this is a business need” or that it came from inside the business somewhere. Some companies are hesitant to include non-traditional things in their QMS, thinking on inspection it will cause them to get questioned. However, we would encourage companies to do it anyway. We’d welcome discussing it with an inspector; for example, “this is an example of how we are going above and beyond to make the best product possible.”
If you’re simply documenting your design controls to meet a regulatory need, then you’ve missed the point of their purpose. These are a way for you to collaborate and communicate within your company. The DHF becomes a record identifying why these decisions were made.
Mike cautions that sometimes it does backfire, depending on the particular inspector who comes to visit. He knows a company that developed a better way of manufacturing a product but the process fell outside of current standards (or traditions). When this was explained to the inspector, they basically said; “that’s great, here’s a 483 anyway.”
HOW STRONG SHOULD YOUR JUSTIFICATION BE FOR CHANGING DESIGN INPUT OR USER NEED?
Frankly, it has to be strong enough to justify making a change to your device. The biggest risk is a business risk - is it worth the time and money to do it? In terms of the FDA, ultimately they’re concerned with the safety and efficacy of the product, and that it does what it says on the label, so it shouldn’t be a concern for them.
To document a design change, as with any other change you need to explain the rationale and ensure you’ve done proper due diligence. You should also take into account upstream and downstream activities that could be affected. Document why the change was made, and determine whether anything else needs updating to support the change.
DO YOU HAVE AN OPINION ON TRACEABILITY OF INFORMATION ON A TRACEABILITY MATRIX? WHAT IS THE BEST METHOD OF TRACKING?
Mike’s strong opinion is that it is absolutely necessary. It’s a basic tenant of good manufacturing practice. You need traceability to connect the dots between everything.
As for the best method of tracking, “show the flow.” How did things progress through the design and development process? Everything we do changes, as much as we might not like that! You have to know how the dots join up.
This is the biggest reason Greenlight Guru's QMS Software Platform exists - it makes it easy to show that flow and keep a handle on traceability. It is specifically built with medical device manufacturers in mind.
(P.S. You can learn more about Greenlight Guru's Design Control software and traceability matrix here.)
This concludes our guide on bridging user needs and design requirements. Realistically, you have a lot of flexibility as a designer and within the regulations, as long as you follow a robust process and are able to justify your interpretation of the rules.
As with anything in medical device development, the regulations are prone to flux as technologies are discovered and new ways of doing things are tested out.
Remember, as Mike Drues is fond of saying, the answers are only as good as the questions we ask...