Is all software GAMP5

hi
do all software packages start life as GAMP5 programs?

my company is buying configurable off the shelf software from a canadian supplier and i have to go audit them. the supplier said the configured application is validated to GAMP4 but should the original validation be GAMP5.

my query is:

the software may be configurable off the shelf and used in numerous companies today so it is true to say it’s a GAMP4 product now.
but when i ask for the development life documentation of the software package should the documentation reflect a GAMP5 level program?

hugh

[quote=hugh8]hi
do all software packages start life as GAMP5 programs?
[/quote]

No GAMP 5 was only released 6 months ago

Validated to GAMP 4 to what extent, GAMP 4 & 5 are guidelines, does this company have it’s own Quality System when it comes to developing software that would be my first question. I have recently audited a software company that had a very poor quality system for the software development side of things. This has to be in place before you even think about the validation aspect.

I dont understand, do you mean that they can provide you with a start-up validation pack of this system.

Validation from your end will include training, SOP’s, Internal Controls.
No company can provide a fully validated system! Be careful.

[quote=hugh8]
my query is:

the software may be configurable off the shelf and used in numerous companies today so it is true to say it’s a GAMP4 product now.
but when i ask for the development life documentation of the software package should the documentation reflect a GAMP5 level program?

hugh[/quote]

Not at all true to say that it is a GAMP 4 product, there is no such thing.

The SDLC may reflect a GAMP program but this needs to be documented in the vendors Quality Management System as to the level of compliance they are adhereing to.

Be very careful with your audit, have it prepared well before hand and ask the hard questions.

Hope this helps

Sorry should use the word categories instead of just GAMP levels. So for each category does it not reflect the type of software program it is for eample

GAMP Category3 is for non-configured product
GAMP Category4 is for configured product
GAMP Category5 is for a custom application.

Is the configured off the shelf product seen as a category5 custom application when it is first developed.

No Category 5 is for bespoke software applications that are custom builds specific for a certain task.

If you make not alterations to the package it is Cat 3 if you do make some configuration changes then it is Cat 4

hi gokeeffe
Thanks for the reply. I will start with their QMS and work from there.

But food for thought:

The software package is a configurable ERP system.

Scenario 1
Company Z is the 26st company to buy the configurable ERP system for use in its factory. So therefore it is a category 4 product…. A COTS

Scenario 2
Company A is the first company to by the ERP system and it is configured for Companies A use. …… (is it as bespoke program or a COTS)

As no other company has ever validated it does this make it a bespoke software program for Company A because it does not exist in any other configuration!
Or is it a category 4 product from the start.

[quote=hugh8]
As no other company has ever validated it does this make it a bespoke software program for Company A because it does not exist in any other configuration!
Or is it a category 4 product from the start.[/quote]

It’s a configurable COTS cat 4 from the start in my opinion. It has not been designed specifically for Company A but it has been configured differently for company A

Your question spans two different issues. The first is categorization and it’s association to risk, and the second is product maturity and it’s association to risk.

Categorization
A single system can span all categories (including 1 and 2), so don’t get too caught up in this. The fundamental issue here is who bears the burden of risk.

  • For a Cat 3 system, the Manufacturer/Supplier bears the burden of risk in that they warranty their product. Your testing focuses on your use. (GAMP 5 figure 4.2)
  • For a Cat 4 system, Manufacturer/Supplier bears the burden of risk for the core functionality, as well as the functionality that allows the configuration to be performed. You bear the burden of risk for the act of configuring the system. So, your testing should focus on your use and what you did to the system. That is to say what you configured. If you configured field lengths, workflow, or security, then you specifically test it, usually as black box. (GAMP 5 figure 4.3)
  • For a Cat 5 system, you are the Manufacturer/Supplier and bear the burden of risk for all the functionality. Your testing focuses on what you built, both white and black box testing. (GAMP 5 figure 4.4)

Maturity
Maturity has a lot to do with Risk Aversion and the Manufacturer (bleeding edge v. cutting edge).

  • Bleeding Edge - If the Manufacturer has just released version 1 of the software and you are the first to implement, then if there is a problem, you will most likely be the first/only one to find it. The risk averse approach would be to extensively test the system, including standard functionality. This would apply to situations in which audit findings indicate questionable manufacturing practices.
  • Cutting Edge - If the Manufacturer has been in business for 5+ years and is on version 3 of the same software, then you should look at the release notes to determine the overall changes in the system. As an example, if it’s an update to the GUI, but the backend database has not been changed. The risk neutral approach would be focus your testing on the new element. This example, there is not a large installed user base for the latest version, but there is for pervious versions.
  • Trailing Edge - If the Manufacturer has been in business for 20 years and is on version 8 of the same software, which has been on the market for a year or two and has a large installed user base. The system would most likely have reached a high degree of stability and thus your risk burden should be reduced. The risk seeking approach would be focus your testing high-level elements.

Cautionary Note: The above information is provided in generalities to illustrate the point in a simplified way. At the end of the day, you need to define your comfort level, both individually and organizationally and proceed accordingly.

Nice response RTMcFadden, I see your point in terms of maturity - it’s very valid

Apologies: I posted in an after-holiday haze, I have figured it out!