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
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
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.