Don Farrall/Getty Images
|
Pharmaceutical manufacturers often depend on third parties for the supply of automated systems and other manufacturing equipment.
Manufacturers must demonstrate to regulatory agencies that their production processes — including any third-party elements
and systems — meet the necessary standards. As a consequence, any third-party systems built to purpose must comply with documented
procedures embodied in, for example, GAMP 5 and ASTM E-2500.1,2
The approach to system validation defined in GAMP guidelines can be symbolized by a model that was originally created for
software development: the V model. The V model demonstrates the relationships between each phase of the development life cycle
and its associated phase of testing. The model deploys a well-structured method in which each phase can be implemented by
the detailed documentation of the previous phase. Using this model and its associated documentation can control risk during
system validation, which is the main focus of this article.
The V model
Figure 1: The V model.
|
Figure 1 illustrates the V model. The left-hand arm represents the succession of specification documents. This begins with the user
requirement specifications (URS) against which a functional requirement specification can be generated. In turn, a set of
implementation specifications can be defined that embody how a specific solution will be engineered.
The system provider is usually responsible for producing and maintaining these documents, including the URS, which will have
been reviewed and agreed by both parties. Against each level on the left-hand side of the V, there is a corresponding test
specification on the right arm. As the elements of the solution are implemented and brought together, the tests demonstrate
that the intended functions are achieved and that the end-user requirements are satisfied.
To the test
The author says...
|
The testing process includes installation qualification (IQ), to demonstrate that the installed system is complete, correctly
configured and has the right services supplied to it; and operational qualification (OQ), which ensures that the installed
system functions safely and to specification as a subsystem.
Occasionally, factors may vary from when they are qualified; for example, ambient temperature. In tropical or semitropical
locations, the indoor temperature can soar late in the day once the air conditioning switches off, allowing, for example,
embedded computers to overheat and causing the system to suddenly fail. In this situation, the system provider is best placed
to define the IQ and OQ test protocols because these require detailed knowledge of system behaviour and the service requirements.
For a substantive system, the provider should supply a building and services specification that enables the site to be properly
prepared before installation. By contrast, the performance qualification (PQ), which assesses compliance with the user process
requirements, must be the responsibility of the user.
Where the third-party element is a standard product, the purpose of the validation is to confirm that the system meets process
needs, and that the supplied version is installed and working as intended. In these instances, the documentation can be standardized;
for example, the OQ test protocol could be a standard document for the product and the IQ could be a checklist generated from
a generic template. The manufacturer may also request copies of generic or type approval documentation.
Automated systems, however, must be designed for purpose, and the project to supply the final system must adhere to necessary
standards and generate all documentation, including system-specific specifications and test protocols. A system provider that
is already familiar with these standards can add a great deal of value in helping to draw up these documents.
