Hi, i am currently writing the SOPs for design control and am at a stuck with verification and validation. i have found lots of good sites with great definitions, inlcuding this forum but when i go to practically apply it I get confused. For example...validation is supposedly testing that the user requirements are satisfied...where eslewhere a verfication process will say convert user needs/ req to specs, develop a test protocol from this to verify design input to output. Isnt this a contradiction in terms as its essentially doing the same thing!?

Or could i look at it this way-requirements are composed of 3 aspects...functional, performance and interface requirements. These in turn are converted into engineering specfications. The testing of the functional components completes the validation, and the testing of the performance and interface requirements, as well as other means such as code walkthroughs etc completes the verification.

If anyone else could shed some light it would be greatly appreciated!!

Thanks

Tania :-)

Verification:
The act of reviewing, inspecting, testing, checking, auditing, or otherwise establishing and documenting whether products, processes, services, or documents conform to specified requirements. The process of evaluating a system or component to determine whether the products of the given development phase satisfy the conditions imposed at the start of that phase.

Validation:
The process of evaluating software at the end of the software development process to ensure compliance with software requirements. The techniques for validation is testing, inspection and reviewing. Determination of the correctness of the products products, processes, services with respect to the user needs and requirements.

cuadra

If anyone else could shed some light it would be greatly appreciated!!

Thanks Tania :-)

Tania, in simple words,

Verification simply is the process where you come to know if its OK or not OK, while

Validation is the process to ensure that the steps when performed under the predetermined conditions give a satisfactory product. In short, this stands for reproducibility and can ensure an acceptable product over a given period of time.

Hope this clarifies.

If you are talking about ISO9001:2000 use the definitions in ISO9000:2000.

im trying to harmonise our certified ISO 13485 to the FDA QSR...needs a much more detailed design control procedure, and im just trying to make sure I do it right!

im trying to harmonise our certified ISO 13485 to the FDA QSR...needs a much more detailed design control procedure, and im just trying to make sure I do it right!

I really am no expert in 13485, but the definitions stated in ISO9000:2000 are a good place to start. Does 13485 have a series that has definitions?

i think the definitions are pretty similra. i think my problem is that intellectually i understand the definitions...it is when i come to applying it to how things are run in my company that im having problems...ie is this a verification document or validation document.For example, we have gone through and tested all the functions of the software program ie does file open when you hit file open, does file close etc...is this validating the functionality...or verifying the specfication that this is what must happen when a user hits file open..

this is why i am a bit confused...

Tania,

I will give you the example:

Consider a mechanical part, like a sheet metal bracket. Here are the differences of verification and validation:

Verification:
I will inspect the part against the drawing, which includes material, dimensions, dimensional & geometric tolerances, finish. I am not bothered whether this part is performing well in the assembly or not, which is ultimately the user's needs.

Validation:
I will assemble the part onto the system; check for fitment and function. This is validation. Here, I don't have any drawings, but I have user needs in my mind.

I believe this example can be extrapolated to any extent.

Let me know if you have any queries beyond this.

Thanks & Regards,
Kiran

thats a really good mechanical example !

does anyone have similar examples for software?

Let's look at the definitions:

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

For example, we have gone through and tested all the functions of the software program ie does file open when you hit file open, does file close etc...

This example, in my opinion would fall under validation. The objective evidence would be the testing of opening and closing the file.

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 alternate calculations,

- comparing new design specification (3.7.3) with similar proven design specification,

- undertaking tests (3.8.3) and demonstrations, and

- reviewing documents prior to issue

In my opinion, when you compare any other existing software programs to see if it does what the other proven software has done, you have verified the program.

These are in my opinion, and someone else might have a better understanding of the differences.

ok , now its getting a bit clearer...

The previous person had placed the validated testing documents as verification, and it just didnt seem to fit the definitions i was reading.

If anyone else has some good sofwtare examples it would be appreciated...not only for me as im sure there are many others who have/are pondering these questions!!

:)

The confusion stems from the fact that validation requires verification, and the writers of the standards failed to anticipate the problems inherent in the definitions. It's similar to the idea that preventive action and corrective action are separate entities under the standards, but corrective action requires preventive action. :frust: :bonk:

In the case of software, you probably have some standards for coding: requirements for naming of variables, logic flow, branching, etc. If you were to undertake a review of a coded module or complete program to determine whether or not the requirements for program structure were met, that would be verification. On the other hand, the testing and debugging that's done in order to determine whether or not the program actually works as intended (i.e., whether or not design intent has been satisfied) would be validation.

If you look at your processes and see that the line between verfication and validation is blurred, it could be because your processes aren't structured the way the standards expect them to be.

that makes so much sense what you have just said! We are a very small company...only 4 people...and I feel that standards are simply not writen for small companies. As thus it does seem to be the process where verfication and validation are blurring, that and no-one really understanding what is required of the standards....of which is now my goal.

Thanks again for what you wrote...has definately helped 'shed more light' :)

Let's look at the definitions:





This example, in my opinion would fall under validation. The objective evidence would be the testing of opening and closing the file.



In my opinion, when you compare any other existing software programs to see if it does what the other proven software has done, you have verified the program.

These are in my opinion, and someone else might have a better understanding of the differences.Coury, you have it reversed. I think Jim has the right idea.

from how i read it both courys and jims points conferred...

Just because the the file opens when you command it to (verification), doesn't meet the requirement of the end user (validation).

what would you define as validating something like that then? Would it be a validation to say the user was able to open a real file as the correct file appeared on the screen..or something liek that. This is why i am confused!

what would you define as validating something like that then? Would it be a validation to say the user was able to open a real file as the correct file appeared on the screen..or something liek that. This is why i am confused!Yes, or did the file need to be opened?

ISO/TR 14969 (Guidance on the application of 13485) does a good job of
explaining validation requiements for both the design/development stage and production processes.

Attached is an image of the V & V waterfall that expalins the two visually.

Regards,

John Minier

I like the waterfall as it gives a good sense of the relationships between customer needs and validation.

I always thought that verification relates to meeting a spec and that validation is checking fitness for purpose. A spec is only our trying to quantify customer needs so the fact that our product meets specs is no guarantee that the customer will be happy.

Validation is often customer approval.

I am currently working with a software provider.

In very basic terms

customer wants a program for providing decision making info from financial data

we write a spec for a database with reports

<program furiously>

we check that all the routines are working properly (verification)

we demo the program to the customer and they are delighted with all the buttons and charts and pretty colours (validation)

Think of it this way.

Verification answers the question: Did I make the product correctly? (Correctly=Conformance to the established product specification or Process parameters). Testing/Inspection Related

Validation answers the question: Did I make the correct product. A Fitness for Use focus. Correct=Meets User Needs. Satisfies some identified User Need.

im trying to harmonise our certified ISO 13485 to the FDA QSR...does anyone have similar examples for software?
Since you mention the FDA and no-one else pointed at this document, take a look here:
General Principles of Software Validation; Final Guidance for ... (http://www.fda.gov/cdrh/comp/guidance/938.html)
A little primitive but okay if you're writing an Ada :lol:

I know this is an older thread, but in case anyone ever reads these posts in the furture, there is another guidance doucment that should be used for software. it is specifically for the off the shelf stuff, like excel if you use it for reports, or data collection etc..

www.fda.gov/cdrh/ode/guidance/585.pdf

TATA :read:

Hi. I worked as an FDA investigator (Level II Certified International Medical Device Investigator) for over 21 years- primarily in the medical device arena. Currently, I am a contract international medical device consultant.

I want to comment about process validation v. verification philosophies in general.

As an example, I will first compare and contrast process validation pertaining to pharmaceutical and medical device operations. I will also show the differences between process validation and verification. I believe these examples will clarify validation v. verification (a concept many people are confused).

Basically, certain operations (such as change control, process validation, and acceptance testing) are "black or white" in the pharmaceutical area (no matter which manufacturing site or process is involved), where similar operations can be "gray" in the medical device area (even from product to product or process to process at one site).

For example, in the pharmaceutical area, one has to validate a quality or manufacturing process (traditionally via a IQ/OQ/PQ prospective validation scheme)- be it a new process or changed process. However, in the medical device area, one has to first determine whether the new or changed process can be fully verified by subsequent inspection and test. The key word is "fully"- because certain tests will cause product destruction or not be cost beneficial. If the process cannot be fully verified, then the process has to be validated (either by prospective validation-IQ/OQ/PQ/PPQ [PPQ is a step not required by the pharmaceutical industry], retrospective validation, or concurrent validation).

Sterilization is a prime example. If one is to fully verify the sterilization operation, every unit will have to undergo sterilization testing. This is great quality-wise because this acceptance testing will show that each unit has passed or failed applicable firm specifications, but the firm will have no products to sell because each unit in each batch (i.e. 100% testing) will have to be opened and tested (thus compromising the sterile barrier).

Here are some basics regarding validation and verification

CONFUSING TERMS

Specification means any requirement with which a product, process, service, or other activity must conform.

Validation 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.

Process validation protocol: a document stating how validation will be conducted, including test parameters, product characteristics, manufacturing equipment, and decision points on what constitutes acceptable test results.

Qualification: establishing by objective evidence that a process produces a result or product meeting its predetermined requirements.

Installation qualification (IQ): establishing by objective evidence that all key aspects of the process equipment and ancillary system installation adhere to the manufacturer’s approved specification and that the recommendations of the supplier of the equipment are suitably considered.

Operational qualification (OQ): establishing by objective evidence process control limits and action levels which result in product that meets all predetermined requirements.

Performance qualification (PQ): establishing by objective evidence that the process, under anticipated conditions, consistently produces a product which meets all predetermined requirements.

Product Performance qualification (PPQ): establishing by objective evidence that the process does not adversely affect the product to meet all predetermined requirements.

OPERATIONS REQUIRING PROCESS VALIDATION OR VERIFICATION

(1) Processes which should be validated

Sterilization processes Clean room ambient conditions
Aseptic filling processes Sterile packaging sealing processes
Lypholization process Heat treating processes
Plating processes Plastic injection molding processes

(2) Processes which may be satisfactorily covered by verification

Manual cutting processes
Testing for color, turbidity, total pH for solutions
Visual inspection of printed circuit boards
Manufacturing and testing of wiring harnesses

(3) Processes which may need to be validated

Cleaning processes Certain human assembly processes
Numerical control cutting processes Filling processes

I hope this helps. :)

In an earlier post, I commented about validation and verification in general. Now, I'd like to comment about design validation and verification.

In simple terms, design verification answers the question- "Did I make the device right?"; whereas design validation answers the question- "Did I make the right device?".

Basically, design verification is similar to product acceptance testing, in that you are testing a product to see if it meets predetermined specifications. Design verification takes it one step further, because you have to make sure you have the correct specifications defined before the tests can be conducted.

For example, if your written specifications (think design output) state to make sure that the product is 5" in length and is red and you transfer this specification to production, you will be making and testing a product that is 5" in length and is red in color. However, what if the customer actually wanted you to design a product that is 6" in length and is purple in color? You would be making the wrong product. This is why you have to confirm that the intended uses and user needs (i.e. final design inputs) are contained in the written procedures, labeling, packaging, etc (i.e design outputs) before any verification testing can be conducted.]

On the other hand, design validation shows if the product has met user needs and intended uses (i.e. final design inputs). In this case, if you are able to design an automated swing (due to technology, etc.), whereas the customer actually wanted a tire on a rope tied to a tree, you have not made the product per the customer needs and intended uses.

I stress- design validation is not process validation. Process validation may need to be performed during the design process, but is not design validation. For process validation, you are seeing whether your process is always under control. During this process, you will be conducting various verification tests (using sampled products), taking into consideration worst case scenarios. For design validation, you may need to conduct clinical studies (i.e. having products being used under actual use conditions by outsiders), simulated use conditions, review other product labels/specs/design files, etc., or a combination of these various activities. You will not be sampling product to test against predetermined specifications under worst case conditions, but be conducting actual or simulated use tests, risk analyses, et al. instead.

Hi geochaz,

Thanks for the very informative post :applause:

Thanks Geochaz,

In your professional opinion, from an FDA stand point.. is there a "requirement" that the protocol for a validation be givin a number / controlled prior to the validation (process) being completed?
For example: We are a contract MFG for a class II non sterile device (accessory) and do not perform final testing or packaging. We have generated a protocol and validation report witht he results; but our customer is suggesting that all of the sites perform the same validation & the protocol should have been numbered. We do number these two documents but only after they have been completed and accepted. the protocls are process in general but are specific to each site due to the differences in equipment (models).. We are working on a general procedure (SOP) previously we only had a design procedure that was under the control on Eng (not quality) until design phases were completed.

Well forum??? :frust::confused:

Hi.

First of all, who is responsible for approving the process validations at your site? Design validations are usually the responsibility of the spec developer/ packager/ labeler (i.e. your customer). What is stated in the contract?

I am assuming we are talking about prospective validation. If so, what exactly are you validating- a process or product? (I know that it is process, but how could the customer require each validation protocol to be the same for each contract site?) If the customer supplies you with specs- are they product specs (i.e. product drawings, etc.) or production equipment specs (i.e. such as computer programs for CNC machines)? Unless the customer worked with you (and all other contract sites) during the design project (assuming the product underwent design controls), how could your customer possibly know about the actual workings at your site (i.e. variances in personnel, equipment/calibration tolerances/accuracies, shift, etc.)? These differences have to be taken into effect when conducting a validation study. It is not just "let's make a widget per drawing X". Worst case scenarios.

Validation protocols have to be approved before any validation work takes place. The QSR does not have any requirement that validation protocols are numbered.

Yes, I guess I left out a bit of information. We were previously a spec designer, MFG.. Now striclty a design MFG w/2 other sites reporting into us. We have a strong tie with this customer who we assist in the design of some of their products. Their previous vendor had a much better yeild but also apparently had some processes that our customer was unaware of and unable to transfer to us. We must also supply yeild data with each shipment, that includes failure breakdowns.

Our customer also has previously recieved a 483, I believe for controlling the subcontractor (us) and the ability to have current documentation. QA, Eng & Ops must approve protocols.. (in reality this happens mostly after the fact when I insist on the documentation.) I need to get a simple system in place that the Engineering documentation phobic staff can work with. The processes.. UV appication & cure, epoxy application, and belt furnance. Our protocol was specific to our machinery but we will forward the same protocol to the other MFG sites to obtain their results.

Back to devices, rather than processes:

I believe I understand the concept of verification. A specification is prepared and a test is designed that indicates that the device meets this specification (or not as the case may be).

Various people have stated that validation is ensuring that the device meets customer requirements or that the correct device is being built.
1) How is one supposed to do this other than specifying a set of tests, i.e. a means to collect objective evidence. What other sort of objective evidence would be appropriate?
2) If a device is supposed to be validated before being put on the market and used than how does one know if it meets customer requirements?

One way I have thought about this, and I wonder if I am correct is:
1) Specify a device to have certain performance characteristics - these are public specifications rather than internal ones.
2) Verify that these specifications are met.
3) Assuming that the performance specifications were correctly chosen, then validation is complete.

Does this make sense??

If you are the medical device specifier then YOU (your multi-departmental team) are the ones who determine what the specification should be. In the case of a medical device, you may perform clinical testing to make sure (futher) validate the device before submitting the 510K or putting on market.

Many of the posts in this thread refer to the "customer" because we are building products for someone else (OEM) who has specified the verfication (testing) parameters.

If you are the company who designed it, the assumption is that someone / marketing research has shown that the users (may be customers) may want the product. For example you wouldn't just manufacture a round surgical tray unless your sales & marketing group had determined that there was sufficent need.

This however is a common conflicting question.. who are your customers? it could be the doctors & hospital staff or the patient (we call this the end user) or the first person in the line who writes you the PO & check. hope that helps.
tata :frust:

For many of the high-risk devices I see, design verification and design validation are essentially indistinguishable.

Take condoms for example. Under most regulatory schemes condoms are high-risk devices, and thus design control cannot be excluded from the company's QMS.

Condom manufacturers are forever coming out with new presentations of the device. Often this is just packaging, but can often be new shapes, new lubricants, new flavours, etc etc.


But the materials of choice have almost always already been developed (usually natural rubber latex, but there are also polyurethane and a few other materials also used). And the new lubricants and flavours are rarely new either. So there usually isn't much design work required there.

Additionally clinical performance - the oft-quoted example of design validation - has been produced in abundance for condoms. Unless there is something really freaky about the new variant, there won't be a need for additional clinical effectiveness testing.

Finally there are well-established international standards for performance. (e.g. ISO4074:2002.)

So by demonstrating that the prototype of the new device is not much different from existing versions, and that it meets the appropriate physical/chemical requirements, not only is the design verified, but it is pretty much validated also.


Conversely, I see plenty of low-risk devices where it is easy to prove the design is verified - after all, the prototype accurately matches the engineering drawings.

But the information that shows that the new device is safe and effective in actual use - i.e. that the design is validated - well that is often missing....

For many of the high-risk devices I see, design verification and design validation are essentially indistinguishable.

Take condoms for example. Under most regulatory schemes condoms are high-risk devices, and thus design control cannot be excluded from the company's QMS.

Condom manufacturers are forever coming out with new presentations of the device. Often this is just packaging, but can often be new shapes, new lubricants, new flavours, etc etc.


But the materials of choice have almost always already been developed (usually natural rubber latex, but there are also polyurethane and a few other materials also used). And the new lubricants and flavours are rarely new either. So there usually isn't much design work required there.

Additionally clinical performance - the oft-quoted example of design validation - has been produced in abundance for condoms. Unless there is something really freaky about the new variant, there won't be a need for additional clinical effectiveness testing.

Finally there are well-established international standards for performance. (e.g. ISO4074:2002.)

So by demonstrating that the prototype of the new device is not much different from existing versions, and that it meets the appropriate physical/chemical requirements, not only is the design verified, but it is pretty much validated also.


Conversely, I see plenty of low-risk devices where it is easy to prove the design is verified - after all, the prototype accurately matches the engineering drawings.

But the information that shows that the new device is safe and effective in actual use - i.e. that the design is validated - well that is often missing....Interesting choice for an example. What clinical performance is done? :lmao:

Well I think Durex Australia is offering a year's free supply in exchange for participation in a user trial.... :D

There are many serious studies as well of course.

http://www.ncbi.nlm.nih.gov/sites/entrez?Db=PubMed&Cmd=ShowDetailView&TermToSearch=10224546&ordinalpos=1&itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVAbstractPlus