COTS (commercial off-the-shelf) Validation FDA Requirements

[Sarath9000]

Hello All,

This question may have been asked before but I couldn't find appropriate answer.If any Commercial off the shelf application is being used in a FDA regulated industry, can we leverage the testing performed by the vendor? If not why do we need to do additional testing at the site if the vendor has already tested the software functionality?

 

[Marcelo]

Re: COTS software validation

Because he has not tested your use of the software. But depending on what he did, you can use any testing as part of your validation testing.

 

[yodon]

Re: COTS software validation

Marcelo is right, of course, but let me add on a bit.

The software was not tested for your use (as Marcelo points out) NOR was it tested in your environment. I don't know if it's your case, but a lot of software has security features which you have to tailor for your needs, back-end databases which are user-provided, custom forms / routing, etc. These can only be assessed on your installation in your environment.

And one additional point: you should assess the list of known issues to determine if any might impact your operations.

So while you may be able to leverage a lot of the testing the vendor did (presuming you can establish equivalence) you will still probably need to take some efforts to complete validation.

 

[Sarath9000]

Re: COTS software validation

Thank you Marcelo and Yodon for your quick responses. I am sorry that I haven't got a chance to reply until today. The COTS application I was asking is image analysis software which is used to measure thickness and porosity of samples. This software also has the capability to be configured by using VB script. But I am not sure at this point if that is the case at my company. So I already checked with the vendor and they told me that they would not be able to provide their validation documentation. Also it isn't that the software used at my company was never validated. In fact it was validated here as part of the process without much focus on the software (which includes microscope calibration along with basic software testing ex: Intended use was tested). We also have a procedure here on how to measure the thickness and porosity. Now I want to make sure that adequate testing was performed in the past validation. I have the following questions:

Would it suffice if we can prove that work flow written in the procedure was tested?

Further, the software may have a lot of functionality and my company may not be using all of it. So I am thinking to gather the list of only areas/functionality (through user manual) used at my company and verify that they were tested in the past validation. Any thoughts?

 

[c.mitch]

Hi Sara,
The validation of the vendor won't be useful (perhaps food for thought if you had it).
The validation of software is a classical IQ OQ PQ.
IQ is verifying installation and configuration (the VB script may be seen as part if the configuration),
OQ is verifying sw functionalities one by one,
PQ is verifying sw with real use scenarios.
OQ sometimes is done on a testing platform, different from the target platform used for PQ.

Testing the workflow in your procedure sounds more like PQ.

Before PQ you need an OQ. To do so write a Software Requirement Specification document (many templates are on the internet) containing the functions you use of the software and probably the custom features of the VB script. So when you're thinking of gathering only the functions used at your company and test them, you're right.

Btw, don't forget in you SRS to write the functions used by technicians who maintain the software (eg: backup/restore, calibration ...).

In terms of documentation, you'll have at minimum a SRS, IQ/OQ/PQ protocols and IQ/OQ/PQ reports. One very important thing is to record in your reports which version of software you tested (consequence: the VB script should probably be version controlled).

Bye.