The benefits of risk-based analyses during system validation

By: Peter Woods, David BealePharmaceutical Technology Europe

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,2The 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.