Advice wanted - retrospective validation or not?

[Cat]

Please help with the following.

During an audit, I’ve found some software which would be GAMP category 4 (configurable) which is involved in a critical GMP activity and I do not consider it wholly validated. The software controls a printer which prints information onto the product - the valdiation I was auditing is for the introduction of the whole process line to make the product, of which this software and printing is a part.

During IQ the software was checked to ensure that it was the specified supplier and version number (it was): back-up was taken and configuration noted as part of that process. Then at OQ, the printing was functionally tested to ensure that it printed the correct information in the right place (it did). During PQ of the line, 3 batches of product were made and the printing (correct information and readability) were checked through sampling each batch in accordance with the normal sampling plans. Each batch only passed (for printing) if each sample was correctly printed and readable (ie zero failures). All batches passed. So I consider this part of the validation as good.

But, although there are basic user needs in the URS, there are no specifications from the supplier (funcational or design) - also there is no evidence that the software supplier was considered - ie no audit of any kind, nor justification for not auditing; and no evidence that the software was written to any kind of standard or quality system. I consider this a problem for configurable software.

In mitigation, the supplier is a large reputable company who supply this software and the type of printer into many companies and industries, in large quantity (probably thousands of units if not tens of thousands). In addition, the whole line has now been operational for about a year, and there are no complaints related to the printed information being in any way incorrect or illegible.

So finally - my question is this. Should the software be retrospectively validated in any way, and if so, what should that consists of? Or can justfication be made to consider it validated, and if so, from when (ie from when the line went into production or from now?) If from now, what are the implications (if any) for product made between line going operational and now? If justification is possible, what should be considered?

Sorry for the long post - hope someone can offer some advice!

Thanks

[gokeeffe]

[quote=Cat]Please help with the following.

During an audit, I’ve found some software which would be GAMP category 4 (configurable) which is involved in a critical GMP activity and I do not consider it wholly validated. The software controls a printer which prints information onto the product - the valdiation I was auditing is for the introduction of the whole process line to make the product, of which this software and printing is a part.[/quote]

Yes this sounds like it’s need full validation

[quote=Cat]
During IQ the software was checked to ensure that it was the specified supplier and version number (it was): back-up was taken and configuration noted as part of that process.[/quote]

Good

@Cat

Then at OQ, the printing was functionally tested to ensure that it printed the correct information in the right place (it did). During PQ of the line, 3 batches of product were made and the printing (correct information and readability) were checked through sampling each batch in accordance with the normal sampling plans. Each batch only passed (for printing) if each sample was correctly printed and readable (ie zero failures). All batches passed. So I consider this part of the validation as good.

Sounds good

[quote=Cat]
But, although there are basic user needs in the URS, there are no specifications from the supplier (funcational or design) - also there is no evidence that the software supplier was considered - ie no audit of any kind, nor justification for not auditing; and no evidence that the software was written to any kind of standard or quality system. I consider this a problem for configurable software.[/quote]

Might be a good idea to retro generate a FDS and DDS document with RTM. Perhaps you could combine the both and generate a FDS.

Supllier Audit is advised before you purchase the software, however you can still go back to the supplier and audit them now. In fact your supplier should be audited on a regular basis to ensure they are compliant and have a good quality system in place. Audit them first of all and give them a copy of your audit report detailing what you want in place.

[quote=Cat]
In mitigation, the supplier is a large reputable company who supply this software and the type of printer into many companies and industries, in large quantity (probably thousands of units if not tens of thousands). In addition, the whole line has now been operational for about a year, and there are no complaints related to the printed information being in any way incorrect or illegible.[/quote]

This is good as I’m sure your not their only customer, ask other companies who use this system if they have audited the company in question. Find out what theri opinion is, if a number of customers come to the vendor and demand an improvement in their system they will have to act on it, otherwise they will loose business and reputation

[quote=Cat]
So finally - my question is this. Should the software be retrospectively validated in any way, and if so, what should that consists of? Or can justfication be made to consider it validated, and if so, from when (ie from when the line went into production or from now?) If from now, what are the implications (if any) for product made between line going operational and now? If justification is possible, what should be considered?

Sorry for the long post - hope someone can offer some advice!

Thanks[/quote]

I think I have answered these questions above.

Hope it helps

[provalidus]

This is an interesting issue, which I come across more and more as I audit customers. Printing equipment is selected and fitted to a production line without adequate validation. The issue with most printing systems is that they typically have a trigger to make the system print, then the print head creates the print, and as such it is impossible to ‘black box’ test the system. The only way to have a high level of confidence that the software does what you want it to, is to verify that the software has been developed in a methodical and risk based way. This is where the vendor audit is essential.
Even if you create a FS or DDS, you would be unable to test against these as this functionality is embedded within the system software and is typically tested at the developer level using special software.
The focus needs to be on whether the software has any bugs that may impact on how you use the software on your production line. You will have to go back to the vendor for this sort of information.
So back to the question of whether to retrospectively validate? It depends! I would carry out a postal audit on the vendor using the GAMP VPCS questionnaire with some additional questions about how many bugs are in the version of software and hardware that you have. Once you have the response you can then carry out a risk assessment on the system. The higher the risk, the heightened inspection level should be on the finished product to make sure that the label has printed correctly.

Jon Davey
Managing Director
Provalidus Ltd
0044 (0)1482 652156