For a sterilization that is software controlled. It it acceptable to take for granted the manufacure’s validation of the software or do we need to validate it again?
Cheers
Mary
This is a question of what the word “validation” means. The supplier of your sterilizer would have tested their software through its development and this process is essentially “Good Software Development Practices”. The software industry coins the term “Validation” / “Verification” for this process. Validation as described by the ISPE (GAMP4)and the PICs, WHO the ICH and nearly everyone else is a V model approach using DQ,IQ,OQ,PQ PV SOP, Maintenance, Cleaning, Training, Change Control to mean “Validation”.
It is your responsibility, based upon your perception of risk, to carryout these processes of qualification and validation. Be aware that supplier validation of their software and what is being discussed by the PICs convention and the ISPE are different. I have raised this “jargon” issue at length. You are just the latest victim.
Read up on the V model and the GAMP guide.
Regards
I’ve found that one of the best ways to do this is to Audit the vendors/suppliers QMS/CSV methodology against the applicable ‘Predicate Rule(s) and Part 11’ requirements; verify the vendor deliverables produced against that methodology; and then take a ‘Risk Based Approach’ to any outstanding CSV activities/deliverables as defined by GAMP (or your own policies and procedures) and justified within your own Validation Plan i.e. fill the gaps as defined by your own policies and procedures, and refer back to the Vendors ‘original and signed documentation’ as part of your protocol test execution for the rest.
The idea being that in front of a regulatory auditor, you can justify that the ‘risk based approach’ you took for your CSV activities were based on the output of a formal Vendor Audit (make sure you have the original signed-off vendor audit report), and therefore your own CSV methodology expectations. It would not be acceptable to just accept whatever the vendor says. I would also suggest you re-execute the sterilization tests in-situ at the PQ stage (HTM2010 (if applicable))
For new ‘projects’ more and more companies are now turning to ‘integrated commissioning and validation’ testing activities (risk based) to reduce timelines (and therefore cost) i.e. referring back to suitably prepared and signed original vendor documentation from your protocols, backed up by a formal vendor/supplier audit, and justified within your own CSV methodology and subsequent Validation Plan.
Note: Some vendors/suppliers use Life Sciences terminology e.g. IQ/OQ/PQ and some do not. Others may talk about FAT and SAT, Acceptance Testing, Commissioning etc. it’s important that you are clear as to where these “fit” within your methodology when justifying which gaps you intend to fill as documented in your Validation Plan.
Dave
Excellent points, that seems like a very slick way to do it.
Regards
Mary,
I think the vendor’s documentation is a good start. I would recommend evaluating it for adequacy. Typically, you would have procedures on validaiton of an autoclave. If this documentation meets the requirements then by all means leverage it. Get QA buyin of course.
Since a sterilizer PLC is an interface between a HMI and real world outputs, I think you would require some sort of commissioning and/or IQ. First, do you have to dismantle the sterilizer prior to shipping? How is the wiring verified on site. For instance, simply accepting the autoclave without verifying wiring could cause the vacuum pump to actuate when you press the open valve 12 button.
Even with their package, you still have to OQ with your utilities. Your steam may be a bit more saturated thus changing ramp times, cold spots, etc. But software wise, no I wouldn’t think you would need to do much more.