Medical Device Design Verification and Validation Differences

D

dweebie

Hi,

I am slightly confused about the difference between design verification and validation, and was hoping that someone could tell me the difference between design validation and verification in connection with the following example (i.e. user need):

The product shall tolerate being dropped onto floors typical of the use environment (as this is a part of the expected use)?

When simulating the product being dropped, is this design validation? I am compelled to say yes, because the test establishes that the product is suitable for its everyday use.

However, such a need, once quantified (e.g. 15 meters onto x surface), could potentially be used as a design input (in a Product Requirement Specification), and hence, I guess, be subject to design verification. And what about the analysis supporting the test (hardness of typical surfaces, typical fall-heights...)? Could the analysis be the design validation, or is it simply a means of justifying the test e.g. 15 meters (i.e. that it is representative of the actual use) because we simulate the dropping in contrast to giving it to the users and "asking" them to drop it?

:thanx:

BR
dweebie
 
Last edited by a moderator:

Randy

Super Moderator
Re: Difference between verification and validation?

Simply put,

Verification = Does it look like it is supposed to

Validation = Does it work like it is supposed to


There are some veriables but that's a simple as it gets.
 
S

samsung

Re: Difference between verification and validation?

Hi,

I am slightly confused about the difference between design verification and validation, and was hoping that someone could tell me the difference between design validation and verification in connection with the following example (i.e. user need):

The product shall tolerate being dropped onto floors typical of the use environment (as this is a part of the expected use)?

When simulating the product being dropped, is this design validation? I am compelled to say yes, because the test establishes that the product is suitable for its everyday use.

However, such a need, once quantified (e.g. 15 meters onto x surface), could potentially be used as a design input (in a Product Requirement Specification), and hence, I guess, be subject to design verification. And what about the analysis supporting the test (hardness of typical surfaces, typical fall-heights...)? Could the analysis be the design validation, or is it simply a means of justifying the test e.g. 15 meters (i.e. that it is representative of the actual use) because we simulate the dropping in contrast to giving it to the users and "asking" them to drop it?

:thanx:

BR
dweebie

ISO 9000:2005 definitions of Verification and Validation are:
3.8.4
verification
confirmation, through the provision of objective evidence (3.8.1), that specified requirements (3.1.2) have been fulfilled

NOTE 1 The term “verified” is used to designate the corresponding status.
NOTE 2 Confirmation can comprise activities such as
— performing alternative calculations,
— comparing a new design specification (3.7.3) with a similar proven design specification,
— undertaking tests (3.8.3) and demonstrations, and
— reviewing documents prior to issue.


3.8.5
validation
confirmation, through the provision of objective evidence (3.8.1), that the requirements (3.1.2) for a specific intended use or application have been fulfilled
NOTE 1 The term “validated” is used to designate the corresponding status.
NOTE 2 The use conditions for validation can be real or simulated.
 

Marcelo

Inactive Registered Visitor
Hello dweebie and welcome to the Cove.

Please see the attached waterfall model in the following thread (Design Input & Output in Stages - Overkill?) which represents the difference between verification and validation.

Verification is related to your project and means to determine if the device was projected as planned.

Validation is related to the user and means to determine if the final device satisfies user needs.
 
Last edited:

yodon

Leader
Super Moderator
Everybody's response so far is quite correct; however, I'm not sure if your question was answered. You as a good question: is a particular test a verification or a validation. Without intending to be flippant, the answer is yes.

Actually, I've not seen a case where anyone gets too concerned over whether something is called a verification or a validation. Clearly, if you have a requirement (design input or output), you are expected to show conformance. This is typically verification. For example, if you specified your product to use a certain type of plastic casing that was necessary to tolerate the drop test you mention, the requirement is satisfied by using that plastic (or a plastic that meets those specifications).

The drop test COULD be a verification if you specified it as a design input but typically, that's more of a validation - showing that it meets the standards of safety required for medical devices.

I would like to hear others' feedback on where they draw the line between verification and (product) validation. Here's kind of a breakdown I've seen:

Verification:
specific tests showing requirement are met (functional tests, risk mitigation effectiveness tests, etc.)

Validation:
Compliance testing (e.g., 60601 <-- which includes drop testing!)
Likely misuse tests
Focus group studies
trace matrix showing that all requirements were verified

We specify what we plan to do for Verification and for Validation in the V&V Plan. Again, I don't think you'll have many arguments over whether or not something is called verification or validation as long as you have a solid plan and the intent of each is met (succinctly put by Randy!)
 

Marcelo

Inactive Registered Visitor
Yodon

You are quite correct, the answers do enlighten the difference, but did not aster the original question.

Anyway, commenting your comments:

´The drop test COULD be a verification if you specified it as a design input but typically, that's more of a validation - showing that it meets the standards of safety required for medical devices´ - testing that the device meets safety standards is generally verification, not validation. This is because safety standards generally deal with safety characteristics and requirements, not performance ones (the new 6060 series deals with essential performance, but not overall performance).

One way to think is, does this characteristics influence the performance (intended use) of the device? If so, the testing of this characteristic is a validation. If not, it´s a verification.
 
M

MIREGMGR

Since dweebie posted in the 21CFR820 section:

US FDA uses these terms in two ways...generally, in regard to design, and in regard to production.

On the design side:

>Design verification shall confirm that the design output meets the design input requirements.
>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.

These statements are quoted are from http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm070627.htm, which is a guidance for the application of 21CFR830.

On the production side, FDA often (though not always) uses "verification" to refer to a test that is applied to every unit of product, or on a statistically valid sampling basis when the verified characteristic may be achieved with a high likelihood but less than 100%.

"Validation" is used when the available test methods for a given characteristic are inherently destructive. For instance, a sterile-barrier-packaging-system (i.e. sterile pouch) tear-seal peel force cannot be verified, since the pull test required by the applicable standard is inherently destructive. Thus a validated process is used. A validated process is one that has been studied and shown to inherently produce product for which the variation in the characteristic of interest lies entirely within the acceptable bounds of the applicable product specification (or alternately, has an acceptable statistical likelihood of such compliance), as long as critical control-parameters of the process are maintained within process specifications. In the case of a SBPS sealing process, that might involve the use of a validated-design sealer with validated time and temperature settings, in combination with a validated SBPS pouch, a validated work environment and validated bounds on the pouch contents and the physical handling process for sealing.

Sterilization is another type of process that is always validated because verification would be destructive.
 
Last edited by a moderator:
D

dweebie

Thanks for the replies!

:thanks:

The reason I ask about the drop-test is becasuse I see a lot of those kinds of tests as product requirement specifications on the system-level.

Here are my newest thoughts on the topic:
Validation emcompasses verification. Verification is confirming that the product requirements are fulfilled. Validation is verification + ensuring that the requirements we stated, ensure a safe and effective product when used in the real world. In relation to the drop-test, I see the drop-test as verification, and validation as the drop-test + ensuring that what we wrote in the product requirements specification is correct i.e. comforms to the standard (validation method = standards review). If there was no standard, we would probably have to make an analysis, or test the product in the real world (this however, could be slightly impractical).

Validation justifies the product requirements and hence the way we choose to design the product.

When the design control guidance says "validation includes simulation of the expected environmental conditions" it assumes that we know what "expected" is. In my company we always refer to these kinds of tests as verification, and hence, I guess, only half of validation (the remaining part of validation is justifying the "expected"). I think we are compelled to say that these tests are validation, because the analysis of what "expected" is, typically lies before the tests, which makes these tests the final activity.

Does this make any sense? :)
 
G

gholland

Here's my take:

Your specification for environmental conditions should be driven from your 'voice of the customer' type activities and should drive design inputs... 'device must function between 0C and 40C' or something similar. Those are verification activities. Your company should understand the environment that the device will be used in, if not your company hasn't done the proper investigation into the target market.

Our company will have a 'customer needs' type document from which a 'design specification' document is derived from. Very much a waterfall type flow, we get customer needs from the marketing department or sales or wherever, these 'needs' are then distilled down into Inputs/requirements and specifications which are verified. The product along the way is taken in front of the customer and evaluated during Validation. Design Validation is asking 'what is the user need and have we met it?'. These are system level customer satisfaction and in my experience interview type activities.

For example a 'customer need' for us would be 'the user needs the device to have a GUI that is simple for the user to perform xxx task.' We would then ask the customer in survey type format to rate the ease of use of the GUI and any comments they may have. Design Validation is a different animal than Verification, it can be more subjective as you typically don't have hard 'pass/fail' acceptance criteria.

:2cents:
 

jkuil

Quite Involved in Discussions
From the Medical Device Quality Systems Manual - A Small Entity Compliance Guide

DESIGN VERIFICATION AND VALIDATION

Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification [820.30(f)] shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF.

Validation [820.30(g)] means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled.

Process validation means establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications.

Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s).

Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.

Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. 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. Design validation shall include software validation and risk analysis, where appropriate. The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the DHF.

Design verification is always done versus specifications. Therefore, to control the specifications and increase the probability of achieving desired safety and performance characteristics, device, software, labeling, packaging and any other specifications should be complete and thoroughly reviewed before development commences. As the hardware and software designs evolve, they should be evaluated versus their current specifications.

Verification and validation should be done with test equipment calibrated and controlled according to quality system requirements. Otherwise, there is limited confidence in the data.

Verification and validation should also be done according to a written protocol(s). The protocol(s) should include defined conditions for the testing. The protocol(s) should be approved before being used. Test protocol(s) are not perfect for a design, particularly a new design. Therefore, the designers and other verification personnel carefully annotate any ongoing changes to a protocol. Likewise, the verification personnel should record technical comments about any deviations or other events that occurred during the testing. The slightest problem should not be ignored. During design reviews, the comments, notes and deviations may be as important as test data from the formal protocol(s).

The drop test and other packaging tests are simulations of actual transport conditions to validate that the packaging specifications ensure that user requirements for product protection are continuously met.
 
Top Bottom