I am in the process of writing PQ protocols for a data logger alarming and data transfer software (realtime) at my new job. The software came with IQ/OQ protocols.
I am not extremely experienced so i wanted some input on what i have so far. SO far i have a handful of test such as
ensuring the sw can handle multiple alarms from the data loggers for low and high threshold alarm conditions
running actual hard tests ( placing the data loggers in a humidity cabinets and ovens and fridges under real operating/ manufacturing conditions to ensure alarms are given.
Simulating network connection problems buy disconnecting the hubs form the network to ensure communication alarms are received for multiple loggers at the same time.
Data integrity checks by verification of data transmitted over the network against data gathered on another data logger that is to be manually downloaded.
i am also planning to monitor the data over the next week or so to ensure performance. some of these tests(alarms) were part of the OQ but were conducted on the sw side by changing the threshold on the sw to generate immediate responses to the changed temp/ RH values. i thought it would be a good idea to perform these tests using actual conditions.
Any inputs, ideas, comments, criticisms are welcome. am i not doing enough, am i going over kill or completely wrong with my PQ protocols?
for the beginning, perhaps is better to say PQ protocol for datalaloger…not for software!!!
ensuring the sw can handle multiple alarms from the data loggers for low and high threshold alarm conditions
running actual hard tests ( placing the data loggers in a humidity cabinets and ovens and fridges under real operating/ manufacturing conditions to ensure alarms are given.
Simulating network connection problems buy disconnecting the hubs form the network to ensure communication alarms are received for multiple loggers at the same time.
…all mentioned above should be a part of the OQ qualification, because looks like simple I/O tests.
Data integrity checks by verification of data transmitted over the network against data gathered on another data logger that is to be manually downloaded.
…I think (if you use two different logers) you’ll get different T/Rh data on outputs, even they are into same enviroment and T/Rh conditions. On that way, you are not be able to compare collected data with 100% sureness. Can you do that within only 1, at same time collect data in it self and send via network???
How you will approve that noboddy can change existing data into dataloger??? 21CFRpart 11???
You collected data into computer??..or print every day, control and sign??
Once more important…what’s happen when alarm is generated?? Who is response to take an action??? Action exists on non-working day (Hollydays …etc?)???
Don’t forget the IQ. All of the items you listed are OQ requirements.
You are not permitted to start the OQ until the IQ is complete. The IQ is there to ensure you have fully documented the installed condition.
There are several very important details that must be documented in order that maintenance /calibration / user personnel never compromise the validated status of the equipment and to enable recovery from a disaster.
To reiterate what others have said - These tests are OQ. You will also need to verify (validate) the output of the software and any critical calculations performed by the software. E.g. as a basic example, if it is calculating a mean temperature you should either manually calculate the mean temp from the data points taken, compare against the output from the software and document in your report, or use an existing validated piece of software to calculate mean temp based upon the data points taken from your proposed system. Auditors will crucify you if you base your validation upon comparing an unproven system with the same unproven system in a different state (see your point 4).
Print verification? Do you intend printing the data? If so you will need to ensure that a consistent output is generated on the printed report.
Export data? Do you export the data to another piece of software (e.g. Excel?) for any reason - if so you will need to verify consistency/accuracy of export. etc.
The basic message is; assess how the system will be used, which features/functions/devices are critical (i.e. potentially impacting the product) and test those specific functions etc.
Any more detail you can supply would be helpful - If it is Testo loggers you are dealing with I may be able to send you some testing we did last year.
