Good Automated Manufacturing Practice (GAMP) – Test Example
Testing Process Automation Systems
This article cover the first part of our Good Automated Manufacturing Practice (GAMP) test example.
Definitions
This section provides brief descriptions of three different types of process control systems.
Configurable Equipment
Configurable Equipment is the collective name given to simple configurable instruments/ devices, such as 3-term controllers, check scales, bar code readers, etc. Their functionality depends on that their configuration setup meets the process requirements. The software (SW) components of these systems are typically defined as GAMP SW Category 2.
Embedded Systems
Embedded Systems is the collective name for systems with a greater degree of configuration and programmability. Devices such as Integrated Circuits (ICs) with configuration setups and Programmable Logic Controllers (PLCs), which are supplied as an integral part to an item of process equipment, e.g., PLCs controlling a centrifuge or packaging machine, or IC embedded in High Performance Liquid Chromatography (HPLC) systems. Embedded Systems typically contain SW components belonging to multiple GAMP categories.
Stand-Alone Systems
Stand-Alone Systems is the collective name for large programmable control systems having distributed functionality across a network, e.g., Distributed Control Systems (DCSs), and Supervisory Control and Data Acquisition (SCADA). They are engineered as an entity to control a complete plant. Stand-Alone Systems typically contain SW components belonging to multiple GAMP categories.
Testing and the GAMP Life Cycle
Stand-Alone Systems
A process automation system developed for a new application typically requires some or all of the following test phases:
Suppliers Module Testing
Suppliers Module Integration Testing
Suppliers Integration Testing
Factory Acceptance Test (FAT)
Site Acceptance Test (SAT)
Installation Qualification (IQ)
Operation Qualification (OQ)
Performance Qualification (PQ)
The exact combination of testing required for a particular system should reflect its complexity, the maturity of its underlying SW and hardware (HW) elements, and the risk impact on product quality, patient safety and data integrity. Collectively these will determine the risk priority. The phrase 'low risk' should be understood as 'having a low risk priority, as determined by a formal risk assessment'.
Testing of modifications, patches or upgrades should be related to the risk priority of the change. For example, it may be appropriate for parameter changes to be applied directly to the production environment, assuming that the system have been range checked for such parameter.