The Leaders in Quality and
Regulatory Training & Consulting

Let's get started

Nov 19, 2018

Medical Device Design Inputs, Outputs, Verification, and Validation. What Do They All Mean?

This is the second post in a 3-part blog series on medical device design control. We cover the basics of design control in our first post and look at DHR, DHF and DMR in our final post. We’ve also combined all three posts into one easy-to-read PDF, plus added some extras. Download it here.

Fixing DevicesEarlier (in a previous post) we addressed the importance and necessity of design control planning. Now let’s talk about the specific design inputs that need to be defined and tracked.

Of all the design control activities, developing a solid foundation of requirements is the most important. Why? The requirements that make up the design inputs establish a basis for performing subsequent design tasks and validating the design. Section 7.3.3 of ISO 13485:2016 and section 820.30 of the FDA QSR talk about design inputs. Essentially, the key requirements include a need to determine:

  • Requirements specified by the customer
  • Delivery and post-delivery activities
  • Procedure for design requirements (intended use, patient and user needs)
  • Functional, performance, and safety requirements for intended use
  • Information derived from similar designs
  • Other requirements essential for design and development
  • Outputs of risk management

All of these inputs must be documented, reviewed, and approved for adequacy, and you need to make sure that the requirements are complete, clear, and don’t conflict with one another. Basically, design inputs should specify what the design is intended to do but they should avoid specific design solutions. Your product developers play a key role (but not the only one) in developing the design input requirements, regardless of who developed the initial product concept. They ultimately bear responsibility for translating needs into a set of requirements that can be validated prior to implementation.

As you define inputs, it is important that you properly identify the customers using your device. Are they lay consumers? Doctors? Medical technicians? This is vital, because all design verifications and validations are matched to customer needs and related technical requirements. Also, while your developers will play a key role in developing inputs, you should also get input from people closest to the customer, such as people in Marketing, Tech Support, and Sales. For complex designs, it is not uncommon for this design input stage to consume as much as 30% of the total project time.

Medical device design outputs

Design control is not just about controlling the design inputs. It is also essential to know whether those design and development inputs result in the right outputs – namely, whether the design you created is safe and functions as planned. Design output requirements are intended to apply to all stages of the design process, and to characterize important aspects of the design.

Design output documents must define the critical outputs (specifications, properties) and reference your acceptance criteria. All of this must be documented, reviewed, and approved before the design is released. The outputs also provide needed important information for purchasing, production, and servicing. Of course, this begs the question: What constitutes design output? Here are some examples:

  • Component, material, production, and process specifications
  • Drawings, CAD files
  • Manufacturing and purchasing procedures
  • Quality assurance specifications, procedures, and acceptance criteria
  • Work instructions, installation and servicing procedures
  • Packaging and labeling specifications
  • Software source code
  • Machine tool programs
  • Development logbooks

Again, all of these outputs must be verified against applicable design inputs. The finished design output documentation is the basis for your device master record (DMR). We will explain more about that later.

Risk management is a critical part of regulatory compliance and has a direct link to design control. It is the systematic application of management policies, procedures, and practices to the tasks of identifying, analyzing, controlling, and monitoring risk. It should be used early and throughout the design and development process and often generates new information that needs to be fed back into the design and development process. We won’t go into detail on risk management in this article, but you can learn more about it here. 

Verifying the final medical device design

In simple terms, design verification proves that you built the device correctly according to all specifications. During this process, you will ensure that all of your design outputs meet the design inputs. Once again, you need to establish a procedure for verifying the device design and maintain records of the results of the verification and any subsequent actions. Verification can be accomplished using one or more of the following:

  • Design reviews
  • Inspection/testing
  • Packaging integrity tests
  • Biocompatibility testing
  • Thermal analysis

Your design verification records, by the way, need to include the date and person who performed the verification as well as methods, acceptance criteria, and any statistical techniques used. This all becomes part of your design history file (DHF). The US FDA likes to see these activities displayed in a traceability matrix.

Don’t conflate verification testing with production testing. Verification testing proves conformance with documented design outputs and inputs, whereas production testing determines whether the unit being tested has been manufactured correctly. Production testing is rarely comprehensive enough to verify the design.

Difference Between Medical Device Verification and Validation (V&V)

In simple terms, verification challenges the design throughout its development to see if you designed the device correctly. Validation is a summation of those efforts to ensure that your design meets user needs and intended uses. In other words: You verify that you designed the device according to spec and you validate that it meets the needs of your users.

Medical device design validation

There are two common types of validation. Process validation uses objective evidence to make sure a process consistently produces the same result. Design validation, on the other hand, ensures that the device meets user needs and intended uses and will therefore become a viable product in the marketplace.

FDA requires you to perform design validation “under defined operating conditions on initial production units, lots, batches or their equivalents.” This includes software. What does “defined operating conditions” mean? Basically, you need to ensure that the conditions under which the product is made for validation purposes are the same conditions anticipated for full-scale production.

As with all other aspects of design control, you need to establish a procedure for validating your design. Your validation activities should address the needs of all stakeholders including patients, health-care workers, installers/servicers, and the physical healthcare environment itself. Your validation needs to be performed based on each intended use.

As for timing, the design validation is completed after clinical evaluation is complete. Your clinical evaluation may include a clinical trial but is more likely to consist of safety testing, literature searches, etc. Also, regulators know that it is not always practical to perform clinical studies on finished products, so you are allowed to use prototypes. However, final design validation must be conducted on actual production devices.

A properly executed validation of design may end up poking holes in your original assumptions, and for this reason you may want to have the validation performed by an independent team familiar with the details of the project but not directly involved in the design. All of your validation activities become part of your design history file (DHF).

Want to learn more about design controls plus DHF, DMR, and DHR?

In our final blog post in this series we explain design history files (DHF), device master records (DMR), and device history records (DHR) and their purpose in design control. Since you’ve made it this far, check out our intensive design control training class.

Our team is here to help. Contact us online


Get answers right now. Call

US OfficeWashington DC


EU OfficeCork, Ireland

+353 21 212 8530