The GAMP (Good Automated Manufacturing Practice) guide version 5 was released in March 2008 and one of the changes was that
the classification of software was revised again. This column will look at what the changes mean for the laboratory and whether
all of these should be implemented.
R.D. McDowall
|
Version 5 of the Good Automated Manufacturing Practice (GAMP) guide (1) was released last year. This publication has been
available since 1994, when version 1 was informally published in the UK, and since its inception it has always contained a
classification of software. This is one of the best parts of the guide as it has an in-built risk assessment, as we shall
see in this column. We will explore version 5 of the software classification and see what changes we need to make to ensure
that it can be implemented practically and effectively in any laboratory.
However, before we continue much further I should also declare a vested interest: I have a love–hate relationship with the
GAMP guide. I love the classification of software outlined in Appendix M4 and hate the life cycle V model. My rationale for
this position is that versions 1–4 of the guide presented a single life cycle V model that was really only applicable to process
equipment and manufacturing systems. It had very little to do with computerized systems, especially laboratory ones. Therefore,
every validation was shoehorned into an inappropriate model because there was little thought and intelligence applied and
the model followed blindly. For example, when a commercially available laboratory system was validated, functional and design
specifications were written for virtually no gain but at a great cost in time and resources. The problem lay in the origins
of the GAMP guide. The first version was written by a group of volunteers in the UK in the early 1990s as a mechanism to control
suppliers of process equipment to the pharmaceutical industry, and this legacy survived through to version 4. However, the
model does not make it into version 5 of the Guide, which is a shame; as mentioned above, the model is very good for process
equipment.
However in GAMP version 5, I'm very pleased to say that the "one size fits all" approach has been replaced by a breath of
fresh air with different life cycles depending on the classification of the software being implemented. The key message is
that now a single size life cycle model does not fit all systems. Note that GAMP is a guide and you can deviate from it —
all that is required is the application of thought and intelligence coupled with effective risk management that is well documented.
OK, perhaps this is a step too far . . . . Software Classification Categories
Table I: Comparison of software categories in GAMP 4 and GAMP 5
|
As I mentioned earlier, the software categories in GAMP 5 have been revised (1). To appreciate the scope of these changes
fully we need to look at the classification of software from GAMP 4 (2) and compare this with GAMP 5, as shown in Table I.
In the beginning, or at least in GAMP 4, there were five categories of software:
- Category 1: Operating systems
- Category 2: Firmware
- Category 3: Standard software
- Category 4: Configured software
- Category 5: Custom software
The constituents of each category are outlined in Table I; however, there was always a debate about some commercial software
packages — were they category 3 or 4? Many spectroscopists would argue that an application should be classified as category
3 and not 4, as it should be less work to validate and evade the real classification. To help resolve this debate, in GAMP
5 the software categories have been revised and refined — most for the better and one for the worse. This is a natural evolution
of this approach to software classification. So we now have the following four categories:
- Category 1: Infrastructure Software
- Category 3: Nonconfigured products
- Category 4: Configured products
- Category 5: Custom applications
Refer to Table I as we discuss the changes in the software classification in more detail in the next section.
