While most professionals working in the pharmaceutical industry have thorough understanding of process validation, the validation of computer systems in process applications is less widely understood.

The problem is, of course, that microprocessors are now built into equipment throughout the pharmaceutical facility. They’re in formulation, stock control, integrated manufacturing, environmental monitoring, laboratory analysis, vision inspection systems, and even in chart recorders and temperature controllers. To ensure process integrity, each one of these devices must be properly calibrated as part of the larger validation process.

Simply having an understanding of computers and software systems isn’t enough: it’s not only essential to fully understand the process, but the equipment being validated as well. This can be difficult because those who best understand the equipment are the manufacturers, but often they may know little or nothing about validation.

This article addresses only one critical aspect of computer-based systems validation: the validation of Facility Monitoring Systems (FMS).

FMSs are normally used only for cleanrooms and associated areas. Such systems cannot be used to classify an area or facility; they perform a monitoring function only, providing evidence that the environmental conditions in the monitored area have been maintained within specified limits. FDA and other regulatory bodies do accept, however, that for users of an FMS, the period of reclassification can be extended (see ISO 14644-2).

An FMS will typically include several monitoring devices: temperature, humidity, and pressure sensors or transducers, and perhaps velocity sensors and particle counters as well. It may also include digital devices for monitoring vacuum pumps or machine running states and feature digital outputs for alert/alarm indicators such as lights or sirens, and for other control functions.

Documentation

The most important document for any proposed system is the User Requirement Specification (URS). Without this document, it is impossible to validate a system. This may come as a surprise to some, but validation is defined as no more—or less—than the process of generating documented evidence to provide a high degree of assurance that a system will consistently fulfill its stated function.

The URS states the required functions of the system. It need not be lengthy, but it must state the functions the system is to fulfill. Despite its name, it is not necessary for the user to generate the URS; the supplier can generate the document, but the URS must be authorized by the user. Its purpose is to ensure that both the user and the supplier understand what is required. The document should have a list of must-haves, want-to-haves, and would-be-nice-to-haves. The supplier must provide all the must-haves, but not necessarily the want-to-haves and the nice-to-haves.

From the URS, all other validation documents and stages then follow. This progression is normally shown in the form of the practical Validation Model (V-model) described in this article. These documents and processes are referred to as the Life Cycle Documents.

After the URS, the next step is for the supplier to generate a Functional Specification (FS). This document, which must address all the user’s must haves, want to haves, and would be nice to haves, should be generated before order placement. If some requirements cannot be met, as will inevitably be the case, the non-compliances must be listed within the FS. Quite often the requirement can be fulfilled in a different way; sometimes, the requirement is not even essential. The FS should include a cross-reference matrix so that the user can easily see how the supplier proposes to meet each requirement.

At this stage, the user should require the supplier to produce a Quality Plan (QP) or Master Validation Plan (MVP) in which the supplier specifies how the project will be controlled, who will be responsible for each project stage, and the time scale for each project stage.

Once the system has been fully specified and agreed upon in the FS, the design of the system must be specified within an Overall Design Specification (DS). This specification should be a top-level document that clearly states what items are required and how mechanical and software items are to be connected together to meet the function specification requirements.

Design Qualification (DQ) is linked to the URS, FS and DS. It is essential to check that all items listed within the preceding document have been addressed (not fulfilled, but addressed). DQ prevents missing a requirement.

Next are Module Specifications (MS). A “module” may be a control panel or a program. It make no difference. If something has to be built, or programmed, the requirements of the module must be clearly defined.

The Testing Phase

The final action of the first part of the V-model is to actually build the panels, order the particle counters and associated equipment or instrumentation, then write and/or configure the software. But as this V-model shows, this is only half the project. Once all hardware has been built or delivered to the supplier’s site, and its software written and configured, the system must be connected together and tested to ensure it all works.

Module tests must be drawn up against the module specifications to ensure each module functions as stated. In the case of a panel, it is important to ask whether all the equipment has been installed, whether it has been wired correctly, and whether it meets all relevant standards.

With software, it is common for module specifications to be wider than the user requires. This allows modules to be reused on other projects. But it is important to be sure that the module, as specified, functions as stated. Again, the module specification is used to draw up a set of tests that verify that all functions have been completed and work as specified. This set of tests must include stress testing of the software to ensure that normal error conditions have been correctly handled.

After completion of module tests, the system must then be brought together, with another set of tests (Software Quality, SQ) applied to the completed system to ensure that it functions as detailed within the overall DS. Some companies do this on site, but if there is a problem, they then incur the added costs of staff working on site—and, typically, the design engineers are not on site. When it is difficult or impossible to build the system on the supplier’s site, simulators should be used.

Users may state that they wish to perform a Factory Acceptance Test (FAT). This is very common with delivery of machinery, but less so with FMS. The purpose of a FAT is for the user to be able to see how the system functions before allowing it to be delivered to site (this is also normally a payment stage). The simplest way to perform a FAT is to use the system’s Installation Qualification (IQ), Operational Qualification (OQ), and Production Qualification (PQ) documents and to state on the tests that simulators have been used as applicable or that the test is not possible. Again, if there are any test failures, it is far simpler—and less expensive—to solve problems on the supplier’s site than on the user’s.

After either SQ or FAT, the system is then shipped to site, installed, and commissioned. Once the system has been commissioned, I strongly recommend that user training be conducted before and after the final validation tests (IQ/OQ/PQ). There are two reaýons for this: There will inevitably be minor differences between what has been asked for in the URS and how the operators actually use the system. Performing training before IQ/OQ/PQ allows these small differences to be addressed under change control, with other documents being revised. Also, within IQ, there must be a test to confirm that users have been trained.

From this moment on, any change to the system must be very carefully considered. Change control must be applied. (In fact, change control should be applied before this stage, because any change may have an effect on specification documents and previous tests; in the extreme, a single, seemingly innocuous change can actually cause failure, in that a “bug” may be introduced.)

The supplier’s module tests and SQ tests can be quite informal. By this I mean that the tests don’t have to be proscriptive. This allows the engineers to really test the system without spending an excessive amount of time generating test documents. The purpose of the test, however, must be clear and there must be documented evidence that the test has been conducted. During IQ/OQ/PQ, the tests must be very proscriptive to enable the user to perform the tests. The test evidence should be more than just a mark in a check box: physical evidence of the test (printouts, screenshots, photos, etc.) should be supplied. It is primarily this test evidence that will be presented to an MCA or FDA inspector to show that the function performed as required. Suppliers are all responsible for ensuring that they provide the user with sufficient documented evidence to pass an inspection.

Tests within Installation Qualification (IQ) may vary. IQ tests should verify that all the items listed in the functional specification have been delivered and that they are of the correct type. The FS may have stated that a differential pressure transducer 0-100 Pa is to be used with 1% accuracy. Has it?

The IQ test should check and verify that:

• All hardware installed on site is as stated—or better.
• All support systems are in place (user manuals, technical manuals, system diagrams, etc.).
• All instruments have been calibrated and the calibration is still valid.
• All software system discs (CDs) are available and have been properly filed.
• A “footprint” (system files, dates and sizes) of the software has been taken at this point.

A system must be able to be re-validated at a later date. IQ tests to ensure that all inputs/outputs of a data collection unit are operational and that must be conducted to ensure that all switches, lights, transducers, and such are functional. These tests can be regarded as operational tests; some companies include such tests in the Operational Qualification (OQ) test document. Once it has been documented that the system has been supplied as detailed within the FS, OQ can begin. The purpose of OQ is to verify that the system functions (operates) as stated within the FS. There must be a test to show that each of the items listed within the FS have been tested, but the tests should go further than this, especially with FMSs—or for that matter, with any other data collection system. There must be clear tests that show data is being collected correctly and that manipulations are being correctly applied, and that data is being stored correctly and can be retrieved correctly.

Tests to check that colors and font sizes on a system are correct can be performed, but they add little to building assurance.

The final part of testing is Performance Qualification (PQ). Normally PQ tests are designed to ensure that the machine operates at the correct rates with the users’ product. With facility monitoring systems, however, this does not apply and in many cases PQ is not performed. With sites where manual methods were previously used to monitor the facility (with portable particle counters, for example, and other instruments), a comparison of the portable particle counters and the FMS particle counters is performed. This can quite often cause test failures due to differences between particle counter optics, electronics, and testing methods. When this happens, I recommend that the manufactures of the particle counters be contacted for guidance.

Other documents should also be generated for a full validation. The main one is a Project Completion Report (PCR) or Validation Review Report (VRR). A summary of the validation of the project, the VRR should list all the documents that have been generated along with the outcome of the tests and should include a clear statement of the system’s suitability for use.

Supplier audits are also common for user to perform. These should be conducted prior to order placement to ensure the supplier has good quality systems and is capable of supplying the required system.

21 CFR, Part 11 Regulation

21 CFR, Part 11 regulation by the FDA relates to electronic signatures and electronic records. Most facility monitoring software systems do not use electronic signatures to approve batch release information. But all facility monitoring software systems hold electronic data, so the regulation applies. In general, facility monitoring systems are closed systems, with access to the system and system data restricted by a control method. In this case, although providing electronic signatures is not applicable, Subpart B, Paragraph 11.10 is applicable.

Subpart B, Paragraph 11.10 states, in part, that the following must be addressed:

• The system must be validated.
• The system must be able to generate accurate, complete copies of data.
• Data records must be protected.
• System access must be restricted.
• Audit trails must be applied to all data.
• Operating system protection methods should be used where possible.
• Authorization checks must be applied.
• Data input/collection verification must be applied.
• Users must be trained.
• Standard Operating Procedures (SOPs) for the use of the system must be in place.
• Documents must be controlled.
• Change control must be applied.

Tests should be included within IQ and OQ to establish that the system does indeed fulfill the above requirements. Many should already be part of any test, but some are outside the scope of the supplier.

Here are some simple methods to make the above process easier and to ensure that a system will pass a validation:.

• Ensure that all transducers, particle counters, and other devices are suitable for the purpose and have valid calibration certificates.
• Do not use complex data collection devices such as programmable logic controllers (PLCs) if they are not required. If a PLC is used, it will have a program, and additional validation will be required.
• When designing a system, consider how things can be tested and how documented evidence can be generated.
• Consider 21 CFR, Part 11 requirements and how these will be fulfilled.
• Use qualified people and reputable suppliers.
• Follow the steps listed within this V-model diagram.