How to Define and Decode Your Design Inputs and Design Outputs

We’re looking at a topic that confuses a lot of medical device developers.

How well have you defined your design inputs and design outputs? I see some common mistakes happening there so it’s time to “decode” the two and take a look at what you can do to make your job easier down the line, especially when you’re putting together your device master record.

Free Bonus Giveaway: Need help defining your user needs? Grab our free tips here.

A Common Mistake with Design Inputs and Design Outputs

A common mistake that we’ve seen many times is that the person capturing and documenting design inputs and design outputs doesn’t create independent, accurate descriptions for each.

What do I mean by that?

Let’s look at a basic example: Say your input is “the length of the device should be between 5 and 10 centimeters.” The mistake is to just rehash this statement when documenting the design output, for example “the device is between 5 and 10 centimeters in length.” This is incorrect as the output really should be something that actually describes the device itself in more detail, such as a drawing or specification.

You can save yourself a whole lot of rework or extra hassles later on if you clearly understand the difference between design inputs and design outputs and know how to write them well. Let’s look at the differences between the two:

Design Inputs

Design inputs have been described by the FDA as the most important part of the entire design control process. From the FDA design control guidance:

"Design input is the starting point for product design. The requirements which form the design input establish a basis for performing subsequent design tasks and validating the design. Therefore, development of a solid foundation of requirements is the single most important design control activity."

The requirements are the most critical aspect of the overall medical device product development effort. Why? They determine functional and performance criteria, which defines everything that your device needs to do.

Where a device that is already on the market has issues, you can almost guarantee there will be an underlying cause within design inputs. It’s often the case that they simply weren’t sufficiently defined. Essentially, they provide the foundation for your device.

You might hear different terms like requirements, design inputs, or design requirements; these are all synonyms for the same idea. One of the key things to remember is that, while you are probably keen to get a product to market as soon as possible, there are some parts of the development process that are worth spending extra time and defining design inputs is one of these areas. In fact, there’s a common school of thought which says that design inputs should take up around 30% of your project timeline.

This is because building that strong foundation will help you to have a smoother path to market for your medical device.

Well-crafted requirements are stated in a way that are measurable and provides clear objective criteria. You will use this later to demonstrate that these requirements have been met.

Goals of design inputs

There are a few key goals that your design inputs need to address. These might include:

• Being clear and objective
• Being stated in a measurable way so that you can prove or disprove them later during design verification
• Building upon your user needs and intended use
• Capturing all performance, regulatory, functional, and safety requirements

You need to give careful consideration to how your define your inputs and for that, you might use a few different references. For example, you could look at regulations, end-users, competitor products, industry standards, and/or prototypes. The best place to start will always be with your user needs.

Thinking ahead

It’s important to think ahead when you determine design inputs. Think about the design verification process (even though that may be months ahead). You’ll do yourself a huge favor if you consider how you will need to verify the requirements later in the development process. This doesn’t mean you need to go ahead and design all of your testing protocols early, but just be aware of creating clear, objective criteria.

Let’s go back to our earlier example of device length. If I’m thinking ahead as I establish this design requirement, I’m automatically thinking about how I can prove and demonstrate that I’ve met the requirement for device length. Design verification is about proving your device meets those design inputs. In this case, a simple proof is to actually measure the device. It doesn’t have to be complicated!

Note, this design input example is very simple. Many other design inputs will be more complicated and will require thought about exactly how you plan to verify before you finalize the requirement.

Keeping it simple and thinking ahead is good practice. Many companies define great design inputs but don’t think about design verification. Months down the track, they’ve painted themselves into a corner because they realize that they can’t prove some of their inputs or it’s going to involve extensive testing. Of course, the more complicated or extensive the testing, the more costly the exercise becomes, too. Your boss will appreciate knowing this sooner rather than later. So will your project manager!

Design Outputs

When defining design outputs, I like the analogy of a recipe. Design outputs describe all of the ingredients that go into your device. These could include drawings, components, materials, parts, pieces, specifications, manufacturing instructions, and inspection procedures.

You could think of your outputs as the documentation you would need should you be tasked with assembling a medical device from scratch.

All of these things can be proof of your stated inputs, but none of them are simply a re-worded statement like, “the device is 5 centimeters long.”

Your design outputs should refer to “acceptance criteria” and design verification will compare those outputs against your inputs.

Relationship with the Device Master Record

If you’re thinking ahead to when you’re going to launch your device into manufacturing, you have to think of the device master record (DMR). This is also a recipe for your device. The difference is that this is post-development, once you’ve completed the design transfer activity. Your DMR will contain everything you need to know to build and test your device.

Your design outputs are a preliminary round for your DMR. Design outputs are captured and documented initially during the design and development process as you’re figuring out parts, pieces, materials, and how you’ll manufacture the product.

As an engineer, I want to get value out of every step I take in the process. I want to make sense of each step. This is one reason why it’s important to understand the distinction between inputs and outputs and their relationship with the work you will need to do during design transfer.

The way we close the loop on all of these from a design input / design output relationship is through design verification. This is a set of objective activities (tests, analysis, or inspections), which demonstrate your design outputs meet your design inputs.

Free Bonus Giveaway: Need help defining your user needs? Grab our free tips here.

Final Thoughts

If there is a particular key point to take from this, it’s that all medical device developers should take the time to carefully come up with the design inputs that they will use throughout the design phase of the project.

Design inputs form the foundation of the device and are a key factor in whether or not you produce something that is safe and effective. Your design outputs are there to describe the actual device and should include the “recipe” or any documentation that goes into manufacturing your device. You’ll use the design verification phase to prove your outputs meet your inputs.

These all impact your post-development phase by forming a basis for your device master record. Put the right amount of time into getting inputs and outputs right early on and you’ll have a simpler task during that post-development phase.

Looking for a design control solution to help you bring safer medical devices to market faster with less risk?  Click here to take a quick tour of Greenlight Guru's Medical Device QMS software →