Introduction

This document aims to review the Good Automated Manufacturing Practice Guide (GAMP®) for the Validation of Automated System (GAMP® 4), December 2001, published by the ISPE. To learn more about GAMP® or to place an order, visit www.ispe.org. The content of this summary hopes to identify the top level requirements of the steps undertaken to validate an automated manufacturing process, this includes environmental particle monitoring systems, autoclaves, filling lines, and any other process governed by electronic control rather than a manual process.

In the late eighties and early nineties the validation of automated system in pharmaceutical manufacturing assumed a much greater importance than had previously been the case. Although regulatory guidelines concerning the use of such automated systems had been available for some time, the systems had been subject to less regulatory scrutiny than other areas of production and were deemed to be less mature than more conventional areas.

An industry group was set up to promote the understanding of the industry requirements. That group was made up of several major pharmaceutical manufacturers and become the GAMP® Forum. In 2000, GAMP® became formally affiliated with ISPE as a technical sub-committee within the organization.

Figure 1 (Download this paper for all tables and figures) (730.0 KB)

The guide has been broadened to incorporate a closer relationship with the ideals of system validation. The following sections identify the top-level features of the GAMP® guide.

Validation Overview

Validation is applied to many aspects of pharmaceutical manufacturing, including instrumentation, systems cleaning etc. In each case the objective is to produce "documented evidence, which provides a high degree of assurance that all parts of a facility will consistently work correctly when brought on-line". Traditionally, validation has consisted of the following:

Design Qualification (DQ) - Documented evidence that the design of the system meets requirements
Installation Qualification (IQ) - System has been installed correctly
Operational Qualification (OQ) - System operates according to design
Performance Qualification (PQ) - System meets design criteria, and operates according to requirement

Traditionally, each of the 'Qualification' sections has contained both the specification and the test protocols aimed at verifying that each stage is completed. The term Validation Protocol is often used when referring to these documents.

The guide recommends the use of supplier documents, if suitable. Documents provided by the supplier will simplify the overall validation process. Many of the tests performed by suppliers meet (or exceed) the site requirements for IQ and OQ, and often become reference documents for the User to direct a testing matrix toward.

System Documentation

The documentation for an automated system should follow the "V" model. This model shows how the three main qualification activities can be linked back to the design process. The V model principle works well for smaller straightforward systems, such as a monitoring system, which has little or no integration into site wide services.

The document which initiates the validation process is the User Requirement Specification (URS). This describes the equipment or system as it is supposed to work and is normally written by the system user. The original version issued for quotation should normally contain the essential requirements (musts) and the desirable requirements (wants). The final version then accommodates all the musts, which can be met, and any of the wants, which also can be satisfied. The URS is now a standard document required for companies to meet the ISO9001: 2000 standards.

The Function Design Specification (FDS or FS) is normally written by the supplier and describes the functions of the equipment or system. The FDS links to the OQ as each major parameter stated should be tested. The FDS is also a standard output document required by ISO 9001: 2000.

The documentation then includes the system build and testing of the installed components. These documents are the testing qualifications IQ, OQ and PQ. At given stages during the lifecycle of the project, planned and systematic reviews should be performed. The design reviews evaluates the deliverables against standards and requirements. The overall validation lifecycle is therefore: (See pdf for Table 1)

Maintaining the Validated State

When a system is validated and in operation, measures should be taken to ensure that the system remains in a validated state. This maintenance not only involves the integrity of the hardware and software, but also the documentation. The maintenance of a validated system includes many activities, which the User is responsible for.

System Operational Procedures (SOPs)

SOPs should be established to define the use and support of the automated system. SOPs should be approved prior to use.

Training

Training plans should be established for use and support of the system. These plans need to consider the training of all users, technical and support.

Problem Management & Resolution

How the faults in the software / hardware are initiated, reviewed, prioritize, and closed.

Service Agreements

All service agreements should provide a formal approach to the support of an automated system. It should be unambiguous, define how the service is to be provided and provide a means of measuring the performance of the support.

Backup and Recovery

How the system is backed up, where the copies go, and at what frequency the archives are made.

Configuration Management

Procedures to establish the baseline system (close of Validation), control of configuration (workarounds and patches), ensure the completeness of changes, control and storage of the revised items.

Operational Change Control

All changes proposed during the operational phase should be subject to formal change control processes.

Security Management

Automated systems and data should be protected against willful or accidental loss or damage. The regulations for 21 CFR 11 surpass the outlines given in GAMP® 4.

Performance Monitoring

The impact of system failure will vary depending on the criticality of the automated system. Where possible, monitoring of the performance of the system should be done to capture problems in a timely manner.

Record Retention & Archiving

SOPs for the retention archiving and retrieval of data should be established and documented.

Business Continuity Planning

This is aimed at disaster recovery and contingency plans should a system fail. Topics include catastrophic failure of either the software or hardware and alternative means of manufacturing.

Periodic Reviews & Evaluation

These are done to verify that a system remains in a validated state and is being operated in accordance with SOPs.

System Retirement

Due to the volume of data, decommissioning a system can be a major task. Considerations should be given to a procedure to replace the system, retained records, which GxP records are required, migration of data to new systems, retention of old hardware to be able to read the records and system archiving.

Validation Lifecycle

Any system requires cooperation between suppliers and users. It is beneficial if the supplier uses a formal management system to control documentation, including the production of the software package. Users should verify that the documentation supporting the project lifecycle meets the company expectations; this is usually done via a supplier audit.

Each company should have a defined policy regarding automated systems. A site wide Validation Master plan should identify the following User Responsibilities.

Identify System

Each system should be assessed and GxP systems identified

Produce URS

This should clearly define precisely what the user wants from the system.

Determine Validation Strategy

Includes sections on:

• Risk Assessment: Does the system require validation? How much validation is required? What aspects of system or product safety are at risk? What aspects of the system are critical to business?
• System Components Assessment: The categorization of the software and hardware components.
• Supplier Assessment: A formal assessment of each supplier; company audit. The audit may establish that a supplier has a quality system ISO9000 and in which case this may be given as reason not to perform a site audit.

Validation Plan

Document defines activities, procedures and responsibilities of the project, and identifies the areas for Risk Assessment. Also included are Quality Plan and Project Plan.

Review/Approve Specifications

The user must review and approve all specifications from the supplier, including the Functional Specification and detailed hardware and software specifications.

Particle Monitor System Development

The user should monitor the project in line with milestones.

Review Source Code

Source Code should be adequately reviewed. This includes reviews of all development tools, policies and procedures, programming rules and testing.

Review/Approve Test Plans

The user must approve test plans prior to formal testing.

Perform Testing

The user may be used as a witness or tester for the software module & integration testing and the Hardware & System acceptance testing.

Review Test Reports

The user should approve the test outputs from the formal testing.

Product Validation Report

The Validation Report should summarize all the deliverables and activities and provides evidence that the system is validated.

System Retirement

The user should manage the replacement or withdrawal of the system from use. Two types of system are identified in the guide are:

IT Systems Database packages, such as LIMS and MRPII fall into this category, it is where data is stored either fixed analytical or documentation.

Process Control Systems Control systems, Monitoring systems and analytical systems fall into this category.

Figure 2: (Download this paper for all tables and figures) (730.0 KB)

Lifecycle Validation

The guide differentiates between Embedded and Standalone process control systems.

Embedded systems are microprocessor based systems such as programmed Integrated Circuits (IC), Programmable Logic Controllers (PLC) or PC with the sole purpose of controlling or monitoring a piece of manufacturing or analytical equipment; examples are filling machines, packaging machines and particle counters.

Standalone systems are either custom or configured, self-contained systems, which are components of an automated manufacturing process application. They are delivered as free standing computer systems, separate to the plant equipment. Examples of standalone systems are:

• Multi-loop controllers or PLCs controlling part of a process
• Supervisory Control and Data Acquisition (SCADA) systems (Pharmaceutical Net fits here).
• Distributed Control Systems (DCS)
• Building Management Systems (BMS)

The pre-requisites for validation at minimum costs for both types of system are the same, following the same basic principals to system lifecycle.

Planning

Figure 3 (Download this paper for all tables and figures) (730.0 KB)

During the planning phase the user assesses the supplier's quality system. The supplier should develop a Quality and Project Plan. The planning phase may include or relate to mechanical and electrical activities as well as automation. The supplier should assist with the Risk Assessment, reviewing the potential impact of system failures.

Specification and Design

User Requirements Spec (URS)

The URS for large systems may involve the development of separate URSs, which cover all the different elements of the project. The manufacturing parameters to be controlled or monitored and the data to be generated should be clearly documented. The design and testing of hardware and software components affecting product criticality should be assessed.

Functional Spec (FS)

The FS is normally written by the supplier and describes the detailed functions of the entire system, what the system will do. The FS is a contractual document and should be subject to change control.

Detailed Design Spec (DSS)

The detailed design includes the production of the hardware, software and instrumentation. It should specify equipment schematics, Process & Instrument diagrams (P&ID), Loop schedules, Process sequences and interconnection drawings.

Hardware Design Spec

This document defines the architecture and configuration of the hardware, including computers, hubs, instrumentation, vacuum pumps, alarm devices etc.

Software Design Spec (SDS)

The software design document (SDS) should define how the software implements the requirements of the FS. The SDS should define the logical and physical structure of the software program and the standards for the build.

Instrument Spec

The system components should be organized into a document, which makes it easy to add and move sensors around the system.

Development and Build

The development activities for the system should be based upon the appropriate design documents. There are three main activities, Software Development, System Build, and Production of Engineering drawings.

Design Review

A design review involves planned and systematic reviews of the system design and development throughout the life cycle. It evaluates deliverables against standards and requirements. The process involves verifying that hardware tolerances and performance meet the requirements. The outcome of any review should be documented on a Design Review Report.

Software Development

The supplier should establish and maintain a formal system for controlling software production.

System Build

For a standalone system the software, instrumentation, and regulating devices are shipped to site, inspected and installed, with the manufacturing plant equipment.

Software Review

The supplier should ensure that the software has been properly inspected and reviewed prior to shipment. The version shipped to site should be the final available release. Suitably qualified persons should perform reviews.

Supplier Testing

The tests should demonstrate that the design conforms to the requirements of the system.

Development Testing

This covers four areas, Software Development tests, Hardware Manufacturing Tests, Software and Hardware Integration Tests, and Instrument and Electrical Equipment manufacturing Tests

Acceptance Testing

These tests are normally contractual milestones aimed at proving the correct operation of the system. Testing should be based upon an approved System Acceptance Tests Specification and formally reported and reviewed. The system type and complexity all influence the degree of testing required. Testing at the supplier's facility prior to shipment is referred to as the Factory Acceptance Tests (FAT). For a standalone system the tests are performed without the installed cabling and may include a reduced system capability. Site Acceptance Tests (SAT) are then performed to verify that the system has been shipped without damage and meets the site requirements form functionality.

The SAT may be combined with equipment and plant commissioning; this provides the basis of the IQ/OQ for the plant. This incorporation of SAT into qualification testing is acceptable where the level of detail and documentation of the system meets the site requirements for IQ/OQ.

Instrument Calibration

Calibration and maintenance of instrumentation should be performed to approved procedures.

Qualification

Qualification activities formally verify the suitability of Process Control Systems for use in a facility.

IQ confirms that the software has been installed correctly, specified hardware components have been assembled and installed correctly, power supplies and data communications are installed correctly and basic power up functions operate.

QO confirms the system operates per the FS. Including software and hardware functions under normal load and where appropriate under realistic stress conditions.

PQ confirms that a system is capable of performing or controlling the activities of the process, while operating in a specified environment.

Validation Report

On successful completion of system qualification, a Validation Report confirms that the system is ready for use within the process for which it was originally designed. PQ for a PCS system is usually conducted in conjunction with Process Qualification, i.e. over an extended period of time opt verify integration into other systems.

Maintaining Validation

The User should establish and maintain plans for continued validation. See section 2.3 above.

Retirement

At the end of operational life a system should be decommissioned.

Benefits of Validation

Validation is the formal documentation of good system development practices. The principal benefit of validating a system is Compliance. The information gathered before, during and after validation leads to improved and confirmed compliance as changes are introduced. Other benefits are:

• Systems which are well defined and specified, easier to maintain, resulting in less downtime
• The system delivered is fit for purpose, on time, within budget
• Satisfy the User Requirements
• In-depth understanding of the process
• Improved operational efficiency in a shorter time frame
• Reduced risk of failure
• Maintenance of quality standards
• Operators understanding the systems, leading to improved communications between departments

List of Appendices in GAMP® 4

The appendices of the GAMP® guide is where all the detailed descriptions as to how processes or more detailed guides to particular application exists. The appendices are divided into three sections, Management, Development and Operations. The management appendices are used for project planning and system requirement analysis. The Development appendices are used for the production of documentation allowing for a detailed description, Hardware and Software, of the system to be installed. The Operational appendices are used for the maintained validation of a system. The Development appendices are directed at suppliers where as the other, Management and Operations, are directed at the user. This is a significant development from the original GAMP® guides, which were solely aimed at suppliers.

TABLES 2-4

(Download this paper for all tables and figures) (730.0 KB)

Table 2: Management Appendices

Table 3: Development Appendices

Table 4: Operational Appendices

Author

Mark Hallworth, Particle Measuring Systems

Contact us if you need more information or have questions regarding particle counter systems.

GAMP® is a registered trademark of ISPE. To learn more about GAMP® or to place an order, visit www.ispe.org.