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.)
Tuesday, July 6, 2010
Facility Monitoring Systems Validation: A Practical Approach 3
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.
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.
Facility Monitoring Systems Validation: A Practical Approach 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.
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.
Facility Monitoring Systems Validation: A Practical Approach 1
By Mike Gough
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).
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).
Validating Processes For Surface Preparation
Validation of processes for surface preparation is crucial to many industries, including pharmaceuticals, biomedical device and even food preparation. The effectiveness of the methods for surface preparation in these industries should be established, documented and monitored on an on-going basis.
Validation helps ensure that the surface has been cleaned to an acceptable contamination level. This maximum tolerable contamination level may be termed the target level. Sampling and analysis techniques must have the specificity, sensitivity, reliability and robustness to assure that contamination does not exceed the target limit. The areas of surface where contamination is most adherent or where the negative consequences of contamination are greatest must receive special attention. The nature of potential contaminants must also be considered. While much attention is paid to biological debris, microbes, and pyrogens, other organic and inorganic contaminants can potentially impact product quality.
As applied to processes for surface preparation, validation is a quantifiable, structured approach to demonstrate and document process effectiveness and process consistency. The following are suggestions for a comprehensive validation process.
Process efficacy must be evaluated prior to implementing the procedure. The procedure should require re-validation after changes to the processes that may significantly affect the types and amount of contamination left on the surface, or when significant changes are made to the cleaning process and result of re-validation must be documented.
The essence of process validation is documented, scientific proof of consistent successful process performance. Full, detailed documentation is an integral part of the validation process to show that the process consistently performs as expected and yields a result that consistently meets predetermined specifications. Predetermined specifications in this situation refer to the maximum acceptable level of contamination that can be tolerated on the surface. Written procedures must be established detailing the surface preparation processes. Those responsible for performing, approving and documenting the validation study and the acceptance criteria must be included, as should documentation of the frequency of process monitoring. Written procedures on how process changes will be validated and requirements for documentation of validation should also be developed.
Sampling and analysis methods must provide for sample collection and detection of levels of contamination relevant to the target limit. The technique must be suited to the types and the target level of contamination. The detection technique should be reviewed periodically for its effectiveness and relevance to the type and level of contaminants currently encountered. Prior to accepting and implementing a validation procedure, the analytical or surface testing technique itself should be evaluated and successfully replicated at least three times. Where possible, direct surface monitoring is desirable and may be preferred over indirect, extractive methods. Part configuration and test method sensitivity must be considered.
Establishing appropriate target levels of maximum acceptable contamination is a challenge. Generally, the main consideration should be as to how much surface contamination can be tolerated. There are many ways of establishing contamination limits. Cost must be considered in determining the target contamination level. For each level of surface contamination there is an associated cost of achieving that level. In addition, with each level of contamination there is a level of non-conformance or failures. The cost associated with each level of non-conformance must also be considered. The maximum acceptable level (Target Level) is the one where the incremental cost of removing more contamination is not offset by the corresponding reduction in the non-conformance or failure cost. If, however, the cost of non-conformance is a health threatening, or life threatening product failure, then the target contamination level must be adjusted to an appropriately low level.The situation is akin to extrapolating from animal studies to humans using the lowest dose of a drug or chemical at which no adverse effects are seen.The appropriate “safety factor” or risk factor will depend on the nature of the observed problem animals or the anticipated consequence in humans.
Some general considerations in establishing target levels include the effect of different levels of contamination on the success of subsequent operations; the detection capability of the various analytical techniques available; the anticipated end-use and performance requirement of the product; and the economic and social cost of non-conformance or failure.
Validation helps ensure that the surface has been cleaned to an acceptable contamination level. This maximum tolerable contamination level may be termed the target level. Sampling and analysis techniques must have the specificity, sensitivity, reliability and robustness to assure that contamination does not exceed the target limit. The areas of surface where contamination is most adherent or where the negative consequences of contamination are greatest must receive special attention. The nature of potential contaminants must also be considered. While much attention is paid to biological debris, microbes, and pyrogens, other organic and inorganic contaminants can potentially impact product quality.
As applied to processes for surface preparation, validation is a quantifiable, structured approach to demonstrate and document process effectiveness and process consistency. The following are suggestions for a comprehensive validation process.
Process efficacy must be evaluated prior to implementing the procedure. The procedure should require re-validation after changes to the processes that may significantly affect the types and amount of contamination left on the surface, or when significant changes are made to the cleaning process and result of re-validation must be documented.
The essence of process validation is documented, scientific proof of consistent successful process performance. Full, detailed documentation is an integral part of the validation process to show that the process consistently performs as expected and yields a result that consistently meets predetermined specifications. Predetermined specifications in this situation refer to the maximum acceptable level of contamination that can be tolerated on the surface. Written procedures must be established detailing the surface preparation processes. Those responsible for performing, approving and documenting the validation study and the acceptance criteria must be included, as should documentation of the frequency of process monitoring. Written procedures on how process changes will be validated and requirements for documentation of validation should also be developed.
Sampling and analysis methods must provide for sample collection and detection of levels of contamination relevant to the target limit. The technique must be suited to the types and the target level of contamination. The detection technique should be reviewed periodically for its effectiveness and relevance to the type and level of contaminants currently encountered. Prior to accepting and implementing a validation procedure, the analytical or surface testing technique itself should be evaluated and successfully replicated at least three times. Where possible, direct surface monitoring is desirable and may be preferred over indirect, extractive methods. Part configuration and test method sensitivity must be considered.
Establishing appropriate target levels of maximum acceptable contamination is a challenge. Generally, the main consideration should be as to how much surface contamination can be tolerated. There are many ways of establishing contamination limits. Cost must be considered in determining the target contamination level. For each level of surface contamination there is an associated cost of achieving that level. In addition, with each level of contamination there is a level of non-conformance or failures. The cost associated with each level of non-conformance must also be considered. The maximum acceptable level (Target Level) is the one where the incremental cost of removing more contamination is not offset by the corresponding reduction in the non-conformance or failure cost. If, however, the cost of non-conformance is a health threatening, or life threatening product failure, then the target contamination level must be adjusted to an appropriately low level.The situation is akin to extrapolating from animal studies to humans using the lowest dose of a drug or chemical at which no adverse effects are seen.The appropriate “safety factor” or risk factor will depend on the nature of the observed problem animals or the anticipated consequence in humans.
Some general considerations in establishing target levels include the effect of different levels of contamination on the success of subsequent operations; the detection capability of the various analytical techniques available; the anticipated end-use and performance requirement of the product; and the economic and social cost of non-conformance or failure.
Subscribe to:
Posts (Atom)