“Level” Up Your Design Inputs!

Is there only one way to design a medical device?  Of course not.  And don’t let anyone tell you otherwise! In a previous post I talked about User Needs, and I’m going to touch on the same topic today: Do you need a User Need for every Design Input Requirement?  Well, it depends…

For medical device development, it is good to understand that there are two very important, but very different design activities going on at the same time.  There is the traditional methodology to talk with users, understand how the product is going to be used, and then creation of design input requirements to help fulfil those User Needs.  I’ll refer to this as the traditional design process. 

The other activity, which is often the brunt of the design verification work, relates to the compliance requirements for medical devices.  This includes FDA regulations, QMS and product specific standards.  I’ll refer to that as the compliance design process.  Honestly, I’m not really a fan of the word compliance here, as it kinda implies that it is just a check the box activity, but it’s absolutely not.  And if you do your design work correctly, your compliance and traditional process can align well with each other.

For the first example in the traditional process, you start with User Needs, and then cascade those into Design Input Requirements, and then further cascade those down into things like system requirements, sub-system requirements, component requirements, etc… This is a good moment to point out that for me, words don’t matter, but concepts matter.  However, when creating these multiple levels of requirements, the design team also needs to complete the compliance design process to link their work back to the regulations and standards. That is where understanding the concepts and how they relate to the regulations and standards allows design teams to function very efficiently.

For medical device design, a core concept is the System V.  This is not a medical device concept but a general design and systems engineering concept and it aligns very well with medical device regulations and standards.  You can see from the chart on the left that I have labeled the different levels of requirements, but those names don’t matter.  What really matters is understanding where within the requirement hierarchy a requirement sits. 

The level of detail and how a requirement is written for a top-level requirement (User need in my example) needs to be consistent, as well as the lower-level requirements (Component in my example).  For that component level requirement, or 4th level requirement, it should be very specific, and not at all as broad as a User Need, or a 1st level requirement.  Those lower-level requirements get so specific, that they act as design outputs at the same time.  But yes, something can be both a design input and a design output!  Think of it like “Hot Ice.”

This duality of Design Inputs and Design Outputs comes from the FDA definition of a Design Output:

21CFR 820.3 (g): “Design output means the results of a design effort at each design phase and at the end of the total design effort.”

That definition is probably a lot broader than you remembered …  but essentially to create any requirement that cascades from a higher lever requirement, that is a result of a design effort.  According to the FDA definition, it is then a design output.  As an example to see how this can manifest, I’ve put together a couple different ways to lay out a cascade of requirements for a tongue depressor, focusing on requirements relating to size.  This example is good to show that you can do the same design work in a different way, and it is still acceptable.  It also goes to demonstrate the “art” that goes into creating design inputs.

In the example to the left, you can see that the same information is captured, just at different points along the requirements hierarchy.  Both options are completely fine, and which one to use honestly comes down to preference.  I prefer the three-level option, as it really gives you more traceability, as you can then directly link the 10.0mm width directly to requirement related to female mouth size, while in the two-level example it is more inferred.  There are other ways to still maintain that linkage, but with the multiple levels it essentially forces engineers to lay it out.

The only downside of more levels of requirements is it becomes more complicated.  Don’t go beyond two levels of requirements if you are using Excel, you’ll break Excel and your patience.  If you are going beyond two-levels, you’ll need a good Application Lifecycle Management (ALM) software to manage your requirements.

This is where when deciding how to manage your requirements, you need to look at:

1.      Types of products: More complicated products will need more levels of requirements.

2.      Tools:  More levels need more robust software tools to manage.

3.      Legacy work:  Be cognizant of what your current state is.

4.      Culture: Design inputs are an art, and engineers are very attached to their art. 

You are probably wondering when I am going to get to the question at the beginning, does every Design Input Requirement need a User Need.  I will now, but I needed to lay out how the different levels of requirements can work.  We will now transfer back into the other design process for compliance development.

I am pretty confident when I say that every medical device has a standard that it needs to meet.  What is the best way to demonstrate conformance to a standard?  You guessed it!  A trace matrix! In the small examples above, they started with a User Need.  A User Need is something that a User is going to Need in order to make the medical device function for its intended purpose.  It kinda defines itself… Is a User going to say, “I need my device to adhere to ISO 10993-1, Biological evaluation of medical devices – Part 1: Evaluation and testing within a risk management process?”  Well maybe some of you will say that, but for most people, the answer is no…

From the systems engineering world, there is a concept known as “Stakeholder Needs.”  I could spend a lot of time talking about these, but the term also defines itself, where they are the needs of groups who have a stake in the medical device.  These could be the business, manufacturing, or even the regulatory agencies.  Often for medical devices, the FDA or other bodies will prescribe specific standards that need to be met.  As we talked before, we want to capture this within the requirements of the device, but we really should not treat them the same way we treat a traditional User Need. 

All requirements need to come from some sort of a top-level requirement, from the traditional design process those will be User Needs.  But for these compliance requirements, you should not cascade them from a User Need.  That is because the FDA QSR and ISO 13485 are very clear that User Needs need to be validated.  Take a look at the two examples to the left:

In both examples, the top-level requirement is to meet the need of the standard, while lower-level design input requirements are created based on the clauses of the standard.  There would normally be many of these, and they might have multiple levels, but the sample above is for example only, so I don’t go to copyright jail.

By calling something a User Need, you must validate it.  Most likely in the example given, you would write a validation by verification memo, or something like that, or some other weird rationale.  But why give yourself extra work and make your DHF more cluttered?  When using a stakeholder need, you don’t need to “validate” the stakeholder need, the design input requirements speak for themselves, as long as you verify them all.

But those requirements from the standard are very much Design Input Requirements that need to be verified.  As long as your traceability matrix can show that you have done all the work to meet the requirements of the applicable standard, you have done your job.

Going back to my original opening question, “Do you need a User Need for every Design Input Requirement,” I hope I have shown you that you do not.  The question itself does not really matter that much, but I want you to understand the concept that you can use multiple avenues to do the same work.  Don’t let someone tell you that something must be done in a specific way, without understanding the why.  Especially auditors … but that’s a different post. 

Don’t be afraid to ask the question why, and really understand where they are coming from.  They might just say, “… because that is the way we have always done it.”  That might be a true answer, and a reason, but it is not a good reason. 

Maybe your company historically only had two levels of requirements, and that was fine because the devices were not that complicated.  But now your devices are becoming electro-mechanical with software, and two levels of requirements are just not going to work.  That’s when the discussion gets hard, and you’ll need to bring in someone like me to help you through the journey.