Validation Training: Resources

For those you in the Validation arena or hoping to join the Validation club, you may have come to the quick realization that there isn't a grand amount of quality training out there. Once you attend a single Computer System Validation class, all the rest seem to be identical material with new instructors and different cities. I guess this repetitive instruction is sufficient if you are truly trying to travel the United States under the guise of TRAINING.

But.....

If you are looking for some fresh companies and organizations here are some:

Institution of Validation Technology
PTI
International Society of Pharmaceutical Engineers
Parental Drug Association
University of Wisconsin Madison in Las Vegas (Good Courses)

These are the resources I found valuable in developing my knowledge and not stagnating with yet another CSV course.

Have a nice weekend.

Equipment Qualification versus Process Validation

Confusion.

ISPE's Baseline Guide Commissioning and Qualification clearly states that Equipment Qualification is not the same animal as a Process Validation.

I understand that Process Validation covers and verifies the repeatability, accuracy, and precision of a process while Equipment Qualification focuses on an individual piece of equipment.

But....

Other than the scope of the protocols, they are the exact same template. Why not then throw Equipment, Utilities, etc under the umbrella of Process Validation?

This many seem as a trivial complaint but it does not seem so small when there are six or seven different templates floating around.

BD

Vendor Generated Validation Toolkits

*This may come across as a blatant rant against incompetency but there are some valuable tips in here if you can wade through to the end.

What you can expect from your company's $3000 - $7000 dollar investment:

1. Internal software testing scripts from developers which have headers just slapped on them.
2. Bad scripts that incorporate tribal knowledge only their validation team possesses so it is virtually impossible to qualify with local resources.
3. Bad scripts that the vendor secretly hopes you will refine through deficiencies and deviation reports so they can offer a better product to their next victim (client.)

This would be an interesting blog if I stopped at this point but it would be rude of me not to offer up some possible solutions.

1. Don't buy vendor toolkits, spend the time learning the system and write your own test scripts.
2. Negotiate in the front end that you will not pay for bad scripts, purposely N/A pages, or functions that do not apply to your environment or version of the installation.
3. Ask for a type of Abstract of the final product. Twenty pages of the toolkit. Evaluate the writing style, ease of execution, and professionalism. This will allow for an educated decision and you may have grounds for discount when the final product is nothing like the 20 (twenty) page excerpt they offered.
4. Take a risk based validation approach and only take from the toolkit those processes that are deemed medium to critical in nature in your risk assessment. DO NOT TEST WINDOWS FUNCTIONALITY. *This is important even if you are generating your own scripts for an internally coded system.
   

Vendor validation toolkits should NEVER be used as validation documents. A toolkit is a template or starting point, make the validation unique to your company or process.

BD