Contradictions in Medical Device Verification vs. Validation - ISO 13485

[MikeL]

A valid point

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)

 

[BZGeorge]

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.

 

[Le Chiffre]

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 ...
A little primitive but okay if you're writing an Ada

 

[tata347]

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

 

[Weiner Dog]

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.

 

[Weiner Dog]

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.

 

[Ajit Basrur]

Hi geochaz,

Thanks for the very informative post

 

[tata347]

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???

 

[Weiner Dog]

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.

 

[tata347]

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.