I am working on a outsourcing project. I have to prepare a content for SAP Hardware validation process. I Need IQ,OQ, PQ templates, statements of works, roles and responsibilities content for Unix Hardwares and SAN storage environment. This is related with SAP ERP environment. Could you please share me IQ, OQ, PQ templates that you used for FDA Validation for such an IT environment
Hi Erol
IQ/OQ/PQ templates will be of limited value to you as a lot of IT projects are very different from each other.
The document that you need is the projects DQ (i.e. URS/FRS/Design). This will show you exactly what the hardware and software and its configuration is supposed to be. From this using experience and risk based evaluation you will compile the IQ/OQ/PQ.
I am very new to creating IQ\OQ\PQ documents, and have done a lot of reading over the past month to try and get my head around what needs to happen.
I need to create an IQ\OQ\PQ for a Citrix environment, running under Windows 2003 R2. Can anyone provide an example of what these should look like – mainly the IQ. I know my environment is different to yours, and that it would have limited value, but as I have never seen an IQ and have no idea what form is should take, and how detailed it should be.
All the books I have read seem to gloss over the actually content of the IQ.
One big issue I have is that there wasn’t (or I can’t seem to find the it ) a true DQ for the system. There is a QD\IQ for the application that runs within Citrix, but not for the hardware, operating system, and Citrix themselves.
Lastly, as I never actually witnessed the installation of the hardware, OS and Citrix, can I still developed the IQ and have a validated system?
I agree with most of the content of the article but not entirely with the statements of Operational Qualification.
The expected ranges should have been written into the URS (e.g. derived from the product portfolio for manufacturing equipment) and as such should be tested in the PQ. The OQ (which is equivalent to a commissioning exercise) should test the basic operation, e.g the system boots up shuts down, you can establish a network session etc. This cuts out a lot of duplication of testing between OQ and PQ and is really what we do in the field when we set up systems.
Just to clarify, there used to be statements in qualification literature that said the outer ranges of the equipment should be probed and tested in OQ but this can lead to equipment destruction or permanent damage of rotating equipment (not a problem with software as it does not usually break, but what is the outer limit of a particular software function??). And also only the equipment designers really have the data on where those outer limits are. We do not need to go here and this is not really in the real world.
To get a one stop , fits all qualification approach the basic operational testing during OQ akin to commissioning will do the trick. Then you can move onto PQ equivalent to UAT. Then you can move onto proper PV Process Validation for drug formulations.
If you have no DQ how was a solution provided that will meet the requirements of the users (URS) ?
Unfortunately it seems that like a lot of people the message that validation starts with the “Need” we have a business need. Then you write the requirements that will satisfy the need (URS) then it all unfolds like a flower from there.
The IQ will confirm that the system has been installed as per the requirement of the system (that why you need the design solution in the DQ), system interconnection / peripherals, connection to power (UPS ?) (set the voltage switch), environmental temperature, software installed etc. Identify the SOPs that will be required to operate the system also are being written. Have appendices to store the BOM and delivery notes etc. Get this approved by QA, Eng / IT / End Users.
The OQ should confirm that the system is operational, It boots up shuts down, connects to the server or clients sessions etc. Ping a few boxes across the network what ever. Also get it approved.
The PQ will confirm that each critical user requirement has been met (User acceptance Testing UAT). Also get it approved. The SOPs should be in an advanced state of draft at this point. Have sections for deviations comments etc in all protocols.
The maintenance or administration backup frequency should all be in the SOPs. If you are complying to 21 CFR Part 11 you need to look at how the end user will use the system and manage audit trails and the like.
It now sounds like you are doing a retrospective qualification / validation and this must be because your company has not managed the project and validation prospectively as required. Please understand that validation is not tacked on at the end it begins at day 0 what is the “Need” does it have a compliance element, YES then begin the validation by compiling the DQ..
To answer your question on how in depth you need to consult with your QA dept and ascertain a risk model for this system and find out where the critical aspects are. Certainly any system needs to be correctly installed or it will no doubt fail very quickly.
You must talk to the people who have put you in this position and say NO, validation begins at day 0, DQ & User Requirements etc, else you will always be left flailing around like a fish out of water
03-31-06 03:32 AM - 