- Email: [email protected]
Control system validation in multipurpose biopharmaceutical facilities
Journal of Biotechnology 59 (1997) 53 – 61
Minireview
Control system validation in multipurpose biopharmaceutical facilities Brian Glennon * Department of Chemical Engineering, Uni6ersity College Dublin, Belfield, Dublin 4, Ireland Received 2 October 1996; accepted 25 July 1997
Abstract In the biopharmaceutical industry, validation requirements have significant implications in almost every engineering aspect of the production process. Strict demands from the US Food and Drug Administration (FDA) and from the European Commission regulatory authorities for validated systems in bulk pharmaceutical manufacturing facilities have raised both the profile and the importance of this aspect of the design and production process. Successive rulings, particularly by the US FDA, have served to focus an increased amount of time and energy on the development of validation strategies in most manufacturing sites. In some areas, such as the validation of the manufacturing process itself and of the associated production equipment, the requirements have tended to concentrate on the formal documentation of many aspects of the commissioning and production processes which previously were typically checked but not necessarily recorded in detail. The validation of vessel cleaning has, on the other hand, generated a large amount of work (and documentation) which was, in many cases, not previously required such as for example, swab testing or the cleaning of vessels between campaigns of the same product. The validation of computer systems has tended to set a requirement for documentation and verification somewhere in between. In many areas of the validation process there is simply a formal recording of work which would also be completed for an unvalidated computer system. In other areas, new and extensive verification is required above that which would be completed otherwise. In this paper, the details of the validation requirements for computer control systems are reviewed. Particular emphasis is placed on the implications for a multipurpose biopharmaceutical facility. Each step is discussed, from the development of a validation plan, through the definition and design of the software and hardware, to the installation and qualification of the complete system. © 1997 Elsevier Science B.V. Keywords: Validation; Control systems; Multipurpose facilities
* Tel.: +353 1 7061954; fax: + 353 1 7061177. 0168-1656/97/$17.00 © 1997 Elsevier Science B.V. All rights reserved. PII S 0 1 6 8 - 1 6 5 6 ( 9 7 ) 0 0 1 6 4 - 8
54
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
1. Introduction As regulatory control over bulk pharmaceutical and biopharmaceutical manufacturing plants approaches levels previously accorded to finished dosage-form production facilities, the requirements for quality control over the entire design and production process have increased accordingly. While there are very often different interpretations of what constitutes the Good Manufacturing Practices (GMP) to be applied in these facilities, the fundamental recognition exists that complete validation of more aspects of the production process is becoming widely required (Baird and De Santis, 1994). Both the US Food and Drug Administration (FDA) and the European Commission advise manufacturers to ensure that critical steps of the manufacturing processes and significant changes to the process are validated (Commission of the European Communities, 1992). A computer system is considered to be a critical part of the manufacturing process, requiring validation when it is directly involved in the control, measurement, monitoring or recording of a critical process step. There are a number of definitions for this term, but essentially it refers to the point in the production process where the final active molecule, or significant portion thereof, is first formed. For a bioprocess, this point may extend back to include the bioreactor, or may only involve the later isolation steps, especially if significant chemical conversion is required. While parts of the process with which the computer system interacts may not be critical, it is typically not possible to delineate between critical and non-critical components within the control system. For example, a particular piece of vendor software may control the action of devices on both critical and non-critical vessels in a process. Therefore, once the requirement for validation has been established, the entire system must usually be fully validated. It is worth noting that this need for validation should not be viewed as a disadvantage; rather it ensures that the specification, evaluation and installation of the computer control system is supervised in a well-documented and systematic manner, satisfying the fundamental re-
quirement of the validation exercise, namely the assurance that the system consistently performs as specified. In this paper the implications of this requirement for validation are reviewed in depth. The specific implications for multipurpose biotechnological facilities are indicated as appropriate.
2. Computer system validation The basis of the computer validation effort is the supply of documented evidence which provides a high degree of assurance that a control system will consistently operate according to predefined specifications. In this context, the term ‘control system’ normally refers to all the software and hardware which constitutes the computer system, along with all the communications and interfaces to process equipment and other computers, if any. Importantly, it also includes the so-called ‘controlled function’, or process equipment items and the procedures for operating them. The significance of this definition for multipurpose facilities is, that as the process changes, the control system must be revalidated to reflect the changes. The extent of revalidation necessitated by process changes is discussed further on in this paper. The documented evidence required for full validation should, as implied above, address all hardware, including interfaces to process equipment and other computers and both system and applications software. The inherent complexity of a control system can present significant challenges in meeting this objective. To overcome these challenges, the Pharmaceutical Manufacturers Association (PMA) developed the ‘life-cycle’ approach to computer system validation. The basic premise of this approach is that quality assurance cannot be guaranteed by testing alone, but must be inherent in all aspects of the process. In practical terms, this means that every stage of the specification, design, development, installation, commissioning and subsequent operation of the computer system should be fully integrated and documented. Each stage of the process must be viewed as leading on to the next stage in a coherent and consistent manner. So, for example, the specifica-
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
tion step must take the implications and practicalities of installation and testing into account when developing the requirements of the system. This
55
‘life cycle’ approach to the validation ensures that the integrity of the computer control system is constantly and consistently maintained (O’Murchu, 1995). Fig. 1 represents the typical ‘life-cycle’. The key phases are: (i) specification and design; (ii) build and test; and (iii) operation. During the initial phase, the requirements of the computer system are developed. The specifications contained in the resulting design documentation form the basis for the subsequent build and test phase. Finally, having proven that the system performs as designed, it can then be operated as intended. During operation, the previous design and test phases are continually reappraised and updated to ensure that the status of the computer system is always under control.
3. Specification and design
Fig. 1. The ‘life-cycle’ approach to computer system validation.
At the heart of the validation activity is the generation of documented evidence to support the use of the control system in the manufacture of medicinal products. The documentation requirements reflect the three phases of the ‘life-cycle’. The framework in which these requirements are satisfied is provided by the Validation Master Plan. This fundamental document (also referred to as the Validation Master Protocol, or Quality Assurance Plan) summarises the strategy to be adopted for the ensuing project. Responsibility for key tasks, including review and approval of protocols and procedures, is assigned. A broad description of what is required of the computer system, from a process point of view, is typically included. Finally, the master plan should outline, even on a preliminary basis, the criteria which the system is required to meet if it is to be regarded as fully validated. Obviously, as the design and test phases proceed, these acceptance criteria may evolve as more information on the system and its requirements becomes known. As stated above, the Validation Master Plan is prepared to specify the requirements for subsequent validation documentation. The key specification and design documents and their role in the validation exercise, are described below.
56
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
3.1. Functional Requirement Specification This is the cornerstone of the computer system specification and the foundation for all subsequent design and validation documents. The Functional Requirement Specification (FRS) is prepared by the customer and outlines what is required of the system. Its generation may involve many iterations, as all related departments in the plant must have an input. The input from potential vendors may also be needed — there is little merit in producing a series of requirements which cannot be met by any available technology. There are a large number of items which are typically required for the FRS. Table 1 indicates one potential contents list. The format will undoubtedly change from one company to the next, but the general substance will be similar — process descriptions, software and hardware requirements, alarms handling, system failure strategy and operator interface. With regard to a batch biopharmaceutical plant and especially a multipurpose facility, the number and type of equipment items and basic generic operations may be quite significant. Control philosophies may also vary from one process to the next. It is important that each is described and appropriately quantified in some detail in the FRS, to ensure that the resulting design properly addresses the processing requirements. The quantification of the system requirements also ensures that the subsequent testing phase has clearly defined acceptance criteria. As a cautionary warning however, it is should be recognised that software can be notoriously difficult to quantify and a poor specification will lead to an inaccurate estimate and potential cost and schedule problems for the project. It is worth noting that the preparation of the FRS can be a particularly time-consuming activity, especially with respect to the definition of system functionality. The requirements of a multipurpose biological facility can increase the complexity of the task with potentially competing priorities from different processes. For example, the system failure strategy for a bioreactor may be fundamentally different from that for a chromatographic unit or for a simple extraction vessel. For the bioreactor, it may be preferable for the system
Table 1 Typical contents of Functional Requirement Specification Introduction
Scope of project Expected project goals Site description Outline of processes to be controlled Outline of control philosophy
Operating procedures
Description of control room operation Description of operating modes Description of plant equipment Details of required process control operations Interface requirements
System description Input signal types Output signal types Data checks Data processing and storage requirements Control loop requirements Alarm management system Interlock handling system System security Console functionality Information display requirements System redundancy System capacity Power backup requirements Software requirements
Database management requirements Batch reporting Graphics construction Sequence modification Recipe management requirements Software access control
Miscellaneous
Validation requirements Customer/vendor responsibilities Training requirements System maintenance Documentation requirements
to revert to manual control in the event of computer failure, with agitation speed, air and coolant flow at their last setting. For an extraction vessel, on the other hand, the preferred strategy may be to stop all processing and revert to a safe state, an approach which could lead to the loss of a sterile batch in the case of the bioreactor. Despite their complexity, these and many other questions must be answered during the development of the FRS, if the subsequent validation (and indeed, design)
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
stages are to have a solid foundation on which to build. It will be difficult to assess a prospective vendor, for example, if no one is sure what exactly the system is required to do.
57
are integral to the validation effort and their thoroughness may eliminate the need for excessive repeat testing during the subsequent system qualifications.
3.2. General Design Specification 4. Build and test phase This document can take a number of forms and may be known by different names (System Specification, Engineering Specification or Purchase Specification). However, its basic purpose is the same: the documentation of the response of the vendor (or prospective vendor) to the FRS. In the General Design Specification (GDS), the vendor should outline how the details of the FRS will be implemented. The GDS should, at a minimum, include a list of all hardware and software requirements, software development procedures, descriptions of interface design, proposed system integration procedures and details of system redundancy and capacity. In fact, the requirements for the GDS may be fully met by the vendors bid proposal and no further development of that document may be necessary to satisfy the validation effort.
3.3. Detailed Design Specification The Detailed Design Specifications (DDS), or computer system specifications, are contained in a document (or collection of documents), which clearly present the proposed design and operation of the computer system in full detail (PDA Committee on Validation of Computer-Related Systems, 1995). It is generally prepared after consultation between the vendor and the customer (For a small system, the details of the GDS may be more efficiently incorporated into the DDS). The DDS will typically include detailed descriptions of the items listed in Table 2. Along with these major documents, the vendors quality assurance programme for hardware and software development should be considered as part of the validation process. Included are design specifications, change control and hardware and software test procedures. Regular audits are normally performed by the client to ensure conformance with all requirements. These audit reports
The validation documentation generated up to this point in the project has been concerned with specifying what the system is required to do and how it is going to do it. The build and test phase is concerned with establishing documented evidence that the system can, in fact, do what is required of it, and in the manner intended. For example, during a programmed steam sterilisation sequence, this means ensuring that not only is sufficient steam introduced to allow the specified temperature to be reached, but also that all the relevant steam inlet valves and bleed valves are positioned as specified. In more specific terms, all the requirements of the Functional Requirement Specification should be both addressed and satisfied during the test phase. The testing is performed as outlined in the Validation Master Plan. There are normally three main test steps. The objective of each step is the same: to ensure that the subsequent operation of Table 2 Typical contents of Detailed Design Specification Hardware Inventory
Controllers Memory devices System wiring diagrams Operator consoles Communications devices
Software inventory
Applications software Operating system User-configurable software
Information interfaces
System database design Loop configurations Graphic displays design
System functions
Alarm handling Interlock design Redundancy capability Failure strategy Security access Reports management
58
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
the control system proceeds with no problems or expensive shutdowns. The tests are performed at key points in the design and construction of the control system.
4.1. Pre-shipment Qualification The Pre-shipment Qualification (PSQ) or Factory Acceptance Test (FAT) is performed to test each module of the control system, along with their subsequent integration to form the completed system. The test is performed by the client, or by the vendor under the supervision of the client, at the vendors site prior to shipping and ensures that the system conforms to all of the required specifications. It is not the intention of the PSQ to repeat all the module and integration testing previously performed by the vendor. In a well-planned and properly audited project, the results of this testing should be acceptable. Rather, it is intended to test the performance of the integrated system against predefined specifications. To facilitate testing of the database for tag channel allocation, wiring to I/O termination racks and loop range checks, it is common to use a customised panel of switches, LEDs and variable resistances to simulate the field connections as they are configured in the plant. So, for example, an on/off switch may be used to simulate an open or closed sensor on an automatic valve or an on/off sensor on a pump, while the variable resistance can allow the simulation of a position sensor on a control valve or an analog signal from an instrument. The LEDs indicate the presence of a digital output signal. Analog output signals can be measured at the appropriate termination points. The availability of a simulation mode on software loops can minimise the use of the light and switch test panel for a significant portion of the remaining software testing, including alarm handling, interlock functionality and programming operation. The absence of actual field connections allow for a rigorous test of the system, without impacting on plant activities. A major advantage in completing a thorough PSQ is that any potential difficulties with the operation of the system are highlighted at an early stage and addressed prior to installation.
Table 3 Typical activities for Installation Qualification Check of bill of materials, including all hardware and software Checkout of environmental conditions of control system locations Check of power sources, including back-up power Confirmation of proper grounding and shielding Check of controller redundancy capability Repeat of portion of PSQ to demonstrate that system functionality is unchanged by installation Check of wiring to field devices Completion of appropriate hardware diagnostic tests Verification of user manuals, wiring diagrams and operating and maintenance procedures
Along with a test of the operation of all hardware and software, the PSQ should include complete checks on all hardware and software inventory to ensure that the system tested is the system which will be ultimately installed in the plant. Also required are reviews of vendor test data and change control reports of construction quality and of power distribution within the system. For a large system, the effort required to complete a PSQ with this level of detail can be significant. However, as stated above, the opportunity for early identification of potential problems minimises the risk of costly field corrections. It should also be stressed that factory acceptance testing is a cornerstone of GMP and evidence of its completion is likely to be requested by the regulatory authorities.
4.2. Installation Qualification On completion of the PSQ testing, the system can be accepted for shipment and installation. Following installation of the system on site, the Installation Qualification (IQ), or Pre-commissioning Testing, is completed under the supervision of the client. The test specification is prepared prior to installation and has, as its objective, the provision of documented evidence that the installation of the computer system has been satisfactorily completed, in accordance with design. Table 3 contains some of the important checks to be completed during the IQ.
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
4.3. Operational Qualification Following a satisfactory conclusion to the Installation Qualification, the software can then be fully integrated with the computer hardware and the system interfaced to the field devices. The Operational Qualification (OQ), or Commissioning Testing, should now be completed by the client. The objective of this phase of the testing is to provide evidence that the system can function as designed, in real operating scenarios. This is typically achieved through the use of water and/or process materials. Prior to the start of these placebo, or dummy, batches, a number of system checks should have been completed and appropriately documented. These include full instrument loop checks to verify the interface between field devices and system database, full functional testing of alarm and interlock operation and handling, and testing of batch sequence operations. The OQ offers the first real opportunity to test many software sequences that are subject to plant performance. Heating, cooling, pressurisation and material charging are just a few such operations. Full tuning of all control loops is also a critical function for completion during the OQ step. The operating performance and capacity of the system hardware should also be challenged during the OQ, to confirm its compliance with specifications.
5. System operation Once the operation of the computer system has been fully qualified in the plant environment, it is now necessary to show that it can operate normally, consistently producing an acceptable product. This Performance Qualification (PQ) or Demonstration step is normally completed over a number of consecutive production batches, typically three. For full validation, there should be no process abnormalities associated with the control system over the course of these batches; if there are, then it is difficult to support the contention that the system has been completed according to the functional requirements. Obviously, the pro-
59
cesses under the control of the computer system must themselves be fully validated if the computer validation is to be meaningful—if the process does not operate consistently, then it will be impossible to show that the computer system consistently controls it. On successful completion of the validation batches and collation, review and approval of all associated validation documentation, the system is now ready for normal operation. However, to ensure that it remains in a validated state, an on-going validation program is required. This program should include a formal change control procedure, periodic performance reviews and regular quality audits. A fully audited and rigorously enforced, change control procedure ensures that the status of the control system is always known and always in agreement with the supporting validation documentation. This procedure should control the manner in which changes are made to the computer system, ensuring that the impact of any change is fully considered prior to its approval. Details of the change to be made, the reasons for it, its likely impact on the process and the revalidation requirements, if any, are the main items to be addressed by the change control procedure. Qualified persons in both technical and quality functions should approve the change prior to its implementation. Clearly, there are occasions when immediate changes to the control system are required for personnel and process safety reasons. The change control procedure should, nevertheless, ensure that the impact of these changes is reviewed subsequently. The regular performance reviews and system audits ensure that there is no deterioration in system operation. The frequency of these reviews should be in accordance with an established plan. Finally, it is critical that all personnel associated with the operation and maintenance of the control system are provided with a regular, structured, training programme. The effectiveness of the training programme should be assessed and its implementation should be clearly documented. From a validation point-of-view this provides the evidence that the people operating the system are qualified to do so.
60
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
6. Multipurpose biopharmaceutical facilities
7. Existing facilities
The requirements demanded for full validation of a computer control system have been described above. While the focus of this paper is on biopharmaceutical facilities, in fact, the specific details of the validation effort rarely depend on the type of process to be controlled. The hardware and software required to control temperature in a bioreactor are identical to that employed for temperature control in a batch chemical synthesis reactor. Similarly, the use of the same process equipment and associated control system for the production of a number of different products, does not generally place any unique demands on the approach to validation beyond those outlined above. Perhaps the only area in which the multipurpose nature of the production facility can influence the validation exercise is during the Performance Qualification and in the subsequent continuous evaluations. Because of the requirement for a three batch PQ for each new process, the effort associated with the validation of a multipurpose facility is clearly significant. Also, some form of qualification may be required prior to each subsequent campaign of a particular process, if some changes have been made to the system since the process was previously run. A final point, with respect to biotechnological facilities, is that proposals to use new sensor and analytical technology for on-line bioprocess control should take the implications of validation into account. This is especially true if the technology is to be used for primary process control with decisions, which may influence the critical quality attributes of the product, made on the progress of the batch on the basis of these measurements. As an integral part of the overall control system, these sensors must be amenable to full validation, with documented and sustainable calibration procedures and valid preventative maintenance programmes. What is acceptable in a research laboratory during the development of a new procedures may not be readily acceptable to the regulatory authorities in a fully validated production facility.
The validation strategy outlined above is equally applicable to a completely new facility, or to a new control system installation in an existing production plant. Where an existing unvalidated system is to be validated retrospectively, many of the steps described here are redundant. However, the development of a functional requirement specification is still essential to define what is the basic function of the system and what are the expectations for its performance. The next step is to qualify the system. This can be achieved through a documented review of historical system performance, or through documented testing where insufficient, or unsatisfactory historical data exists. The final step is to establish an on-going validation program with appropriate change control, performance review and system audit procedures. It should, however, be stressed that retrospective validation is a difficult task to complete fully, without running into the type of problems associated with the lack of a proper system specification and of rigorous change control procedures, that validation is designed to eliminate in a new project.
8. Summary The completion of a successful computer system validation program depends on the recognition that it is not simply a paper-generating exercise, but rather an integral part of any wellrun computer project. In fact, it can be argued that the documentation demands for validation are only slightly different from those required by Good Engineering Practice, which recommends that all aspects of a design project are documented in a controlled and meaningful manner, with a clearly identified document hierarchy, established at the outset of the project. A well-documented system is especially necessary to accommodate the stringent demands of multipurpose operation for rapid changeover from one process to the next. The life-cycle approach to
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
computer system validation provides a successful operating structure in which the requirements of the regulatory authorities and the demands of an efficient pharmaceutical industry can both be accommodated. A well-planned and rigorously implemented validation program will ensure a good product at the end of the project, provide a stable production platform for the plant and will facilitate the project management through the presence of adequate documentation of requirements and expectations.
.
61
References Baird, R., De Santis, P., 1994. Validation of biopharmaceutical facilities. In: Lydersen, B.K., Delia, N.A., Nelson, K.L. (Eds.), Bioprocess Engineering: Systems, Equipment and Facilities. Wiley, New York, pp. 745 – 781. Commission of the European Communities, 1992. Guide to good manufacturing practice for medicinal products. O’Murchu, C., 1995. Validating a pharmaceutical control system. InTech 42, 58 – 61. PDA Committee on Validation of Computer-Related Systems, 1995. Validation of computer related systems. Technical Report No. 18. PDA. J. Pharm. Sci. Technol. 49, S1 – S17.
Minireview
Control system validation in multipurpose biopharmaceutical facilities Brian Glennon * Department of Chemical Engineering, Uni6ersity College Dublin, Belfield, Dublin 4, Ireland Received 2 October 1996; accepted 25 July 1997
Abstract In the biopharmaceutical industry, validation requirements have significant implications in almost every engineering aspect of the production process. Strict demands from the US Food and Drug Administration (FDA) and from the European Commission regulatory authorities for validated systems in bulk pharmaceutical manufacturing facilities have raised both the profile and the importance of this aspect of the design and production process. Successive rulings, particularly by the US FDA, have served to focus an increased amount of time and energy on the development of validation strategies in most manufacturing sites. In some areas, such as the validation of the manufacturing process itself and of the associated production equipment, the requirements have tended to concentrate on the formal documentation of many aspects of the commissioning and production processes which previously were typically checked but not necessarily recorded in detail. The validation of vessel cleaning has, on the other hand, generated a large amount of work (and documentation) which was, in many cases, not previously required such as for example, swab testing or the cleaning of vessels between campaigns of the same product. The validation of computer systems has tended to set a requirement for documentation and verification somewhere in between. In many areas of the validation process there is simply a formal recording of work which would also be completed for an unvalidated computer system. In other areas, new and extensive verification is required above that which would be completed otherwise. In this paper, the details of the validation requirements for computer control systems are reviewed. Particular emphasis is placed on the implications for a multipurpose biopharmaceutical facility. Each step is discussed, from the development of a validation plan, through the definition and design of the software and hardware, to the installation and qualification of the complete system. © 1997 Elsevier Science B.V. Keywords: Validation; Control systems; Multipurpose facilities
* Tel.: +353 1 7061954; fax: + 353 1 7061177. 0168-1656/97/$17.00 © 1997 Elsevier Science B.V. All rights reserved. PII S 0 1 6 8 - 1 6 5 6 ( 9 7 ) 0 0 1 6 4 - 8
54
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
1. Introduction As regulatory control over bulk pharmaceutical and biopharmaceutical manufacturing plants approaches levels previously accorded to finished dosage-form production facilities, the requirements for quality control over the entire design and production process have increased accordingly. While there are very often different interpretations of what constitutes the Good Manufacturing Practices (GMP) to be applied in these facilities, the fundamental recognition exists that complete validation of more aspects of the production process is becoming widely required (Baird and De Santis, 1994). Both the US Food and Drug Administration (FDA) and the European Commission advise manufacturers to ensure that critical steps of the manufacturing processes and significant changes to the process are validated (Commission of the European Communities, 1992). A computer system is considered to be a critical part of the manufacturing process, requiring validation when it is directly involved in the control, measurement, monitoring or recording of a critical process step. There are a number of definitions for this term, but essentially it refers to the point in the production process where the final active molecule, or significant portion thereof, is first formed. For a bioprocess, this point may extend back to include the bioreactor, or may only involve the later isolation steps, especially if significant chemical conversion is required. While parts of the process with which the computer system interacts may not be critical, it is typically not possible to delineate between critical and non-critical components within the control system. For example, a particular piece of vendor software may control the action of devices on both critical and non-critical vessels in a process. Therefore, once the requirement for validation has been established, the entire system must usually be fully validated. It is worth noting that this need for validation should not be viewed as a disadvantage; rather it ensures that the specification, evaluation and installation of the computer control system is supervised in a well-documented and systematic manner, satisfying the fundamental re-
quirement of the validation exercise, namely the assurance that the system consistently performs as specified. In this paper the implications of this requirement for validation are reviewed in depth. The specific implications for multipurpose biotechnological facilities are indicated as appropriate.
2. Computer system validation The basis of the computer validation effort is the supply of documented evidence which provides a high degree of assurance that a control system will consistently operate according to predefined specifications. In this context, the term ‘control system’ normally refers to all the software and hardware which constitutes the computer system, along with all the communications and interfaces to process equipment and other computers, if any. Importantly, it also includes the so-called ‘controlled function’, or process equipment items and the procedures for operating them. The significance of this definition for multipurpose facilities is, that as the process changes, the control system must be revalidated to reflect the changes. The extent of revalidation necessitated by process changes is discussed further on in this paper. The documented evidence required for full validation should, as implied above, address all hardware, including interfaces to process equipment and other computers and both system and applications software. The inherent complexity of a control system can present significant challenges in meeting this objective. To overcome these challenges, the Pharmaceutical Manufacturers Association (PMA) developed the ‘life-cycle’ approach to computer system validation. The basic premise of this approach is that quality assurance cannot be guaranteed by testing alone, but must be inherent in all aspects of the process. In practical terms, this means that every stage of the specification, design, development, installation, commissioning and subsequent operation of the computer system should be fully integrated and documented. Each stage of the process must be viewed as leading on to the next stage in a coherent and consistent manner. So, for example, the specifica-
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
tion step must take the implications and practicalities of installation and testing into account when developing the requirements of the system. This
55
‘life cycle’ approach to the validation ensures that the integrity of the computer control system is constantly and consistently maintained (O’Murchu, 1995). Fig. 1 represents the typical ‘life-cycle’. The key phases are: (i) specification and design; (ii) build and test; and (iii) operation. During the initial phase, the requirements of the computer system are developed. The specifications contained in the resulting design documentation form the basis for the subsequent build and test phase. Finally, having proven that the system performs as designed, it can then be operated as intended. During operation, the previous design and test phases are continually reappraised and updated to ensure that the status of the computer system is always under control.
3. Specification and design
Fig. 1. The ‘life-cycle’ approach to computer system validation.
At the heart of the validation activity is the generation of documented evidence to support the use of the control system in the manufacture of medicinal products. The documentation requirements reflect the three phases of the ‘life-cycle’. The framework in which these requirements are satisfied is provided by the Validation Master Plan. This fundamental document (also referred to as the Validation Master Protocol, or Quality Assurance Plan) summarises the strategy to be adopted for the ensuing project. Responsibility for key tasks, including review and approval of protocols and procedures, is assigned. A broad description of what is required of the computer system, from a process point of view, is typically included. Finally, the master plan should outline, even on a preliminary basis, the criteria which the system is required to meet if it is to be regarded as fully validated. Obviously, as the design and test phases proceed, these acceptance criteria may evolve as more information on the system and its requirements becomes known. As stated above, the Validation Master Plan is prepared to specify the requirements for subsequent validation documentation. The key specification and design documents and their role in the validation exercise, are described below.
56
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
3.1. Functional Requirement Specification This is the cornerstone of the computer system specification and the foundation for all subsequent design and validation documents. The Functional Requirement Specification (FRS) is prepared by the customer and outlines what is required of the system. Its generation may involve many iterations, as all related departments in the plant must have an input. The input from potential vendors may also be needed — there is little merit in producing a series of requirements which cannot be met by any available technology. There are a large number of items which are typically required for the FRS. Table 1 indicates one potential contents list. The format will undoubtedly change from one company to the next, but the general substance will be similar — process descriptions, software and hardware requirements, alarms handling, system failure strategy and operator interface. With regard to a batch biopharmaceutical plant and especially a multipurpose facility, the number and type of equipment items and basic generic operations may be quite significant. Control philosophies may also vary from one process to the next. It is important that each is described and appropriately quantified in some detail in the FRS, to ensure that the resulting design properly addresses the processing requirements. The quantification of the system requirements also ensures that the subsequent testing phase has clearly defined acceptance criteria. As a cautionary warning however, it is should be recognised that software can be notoriously difficult to quantify and a poor specification will lead to an inaccurate estimate and potential cost and schedule problems for the project. It is worth noting that the preparation of the FRS can be a particularly time-consuming activity, especially with respect to the definition of system functionality. The requirements of a multipurpose biological facility can increase the complexity of the task with potentially competing priorities from different processes. For example, the system failure strategy for a bioreactor may be fundamentally different from that for a chromatographic unit or for a simple extraction vessel. For the bioreactor, it may be preferable for the system
Table 1 Typical contents of Functional Requirement Specification Introduction
Scope of project Expected project goals Site description Outline of processes to be controlled Outline of control philosophy
Operating procedures
Description of control room operation Description of operating modes Description of plant equipment Details of required process control operations Interface requirements
System description Input signal types Output signal types Data checks Data processing and storage requirements Control loop requirements Alarm management system Interlock handling system System security Console functionality Information display requirements System redundancy System capacity Power backup requirements Software requirements
Database management requirements Batch reporting Graphics construction Sequence modification Recipe management requirements Software access control
Miscellaneous
Validation requirements Customer/vendor responsibilities Training requirements System maintenance Documentation requirements
to revert to manual control in the event of computer failure, with agitation speed, air and coolant flow at their last setting. For an extraction vessel, on the other hand, the preferred strategy may be to stop all processing and revert to a safe state, an approach which could lead to the loss of a sterile batch in the case of the bioreactor. Despite their complexity, these and many other questions must be answered during the development of the FRS, if the subsequent validation (and indeed, design)
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
stages are to have a solid foundation on which to build. It will be difficult to assess a prospective vendor, for example, if no one is sure what exactly the system is required to do.
57
are integral to the validation effort and their thoroughness may eliminate the need for excessive repeat testing during the subsequent system qualifications.
3.2. General Design Specification 4. Build and test phase This document can take a number of forms and may be known by different names (System Specification, Engineering Specification or Purchase Specification). However, its basic purpose is the same: the documentation of the response of the vendor (or prospective vendor) to the FRS. In the General Design Specification (GDS), the vendor should outline how the details of the FRS will be implemented. The GDS should, at a minimum, include a list of all hardware and software requirements, software development procedures, descriptions of interface design, proposed system integration procedures and details of system redundancy and capacity. In fact, the requirements for the GDS may be fully met by the vendors bid proposal and no further development of that document may be necessary to satisfy the validation effort.
3.3. Detailed Design Specification The Detailed Design Specifications (DDS), or computer system specifications, are contained in a document (or collection of documents), which clearly present the proposed design and operation of the computer system in full detail (PDA Committee on Validation of Computer-Related Systems, 1995). It is generally prepared after consultation between the vendor and the customer (For a small system, the details of the GDS may be more efficiently incorporated into the DDS). The DDS will typically include detailed descriptions of the items listed in Table 2. Along with these major documents, the vendors quality assurance programme for hardware and software development should be considered as part of the validation process. Included are design specifications, change control and hardware and software test procedures. Regular audits are normally performed by the client to ensure conformance with all requirements. These audit reports
The validation documentation generated up to this point in the project has been concerned with specifying what the system is required to do and how it is going to do it. The build and test phase is concerned with establishing documented evidence that the system can, in fact, do what is required of it, and in the manner intended. For example, during a programmed steam sterilisation sequence, this means ensuring that not only is sufficient steam introduced to allow the specified temperature to be reached, but also that all the relevant steam inlet valves and bleed valves are positioned as specified. In more specific terms, all the requirements of the Functional Requirement Specification should be both addressed and satisfied during the test phase. The testing is performed as outlined in the Validation Master Plan. There are normally three main test steps. The objective of each step is the same: to ensure that the subsequent operation of Table 2 Typical contents of Detailed Design Specification Hardware Inventory
Controllers Memory devices System wiring diagrams Operator consoles Communications devices
Software inventory
Applications software Operating system User-configurable software
Information interfaces
System database design Loop configurations Graphic displays design
System functions
Alarm handling Interlock design Redundancy capability Failure strategy Security access Reports management
58
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
the control system proceeds with no problems or expensive shutdowns. The tests are performed at key points in the design and construction of the control system.
4.1. Pre-shipment Qualification The Pre-shipment Qualification (PSQ) or Factory Acceptance Test (FAT) is performed to test each module of the control system, along with their subsequent integration to form the completed system. The test is performed by the client, or by the vendor under the supervision of the client, at the vendors site prior to shipping and ensures that the system conforms to all of the required specifications. It is not the intention of the PSQ to repeat all the module and integration testing previously performed by the vendor. In a well-planned and properly audited project, the results of this testing should be acceptable. Rather, it is intended to test the performance of the integrated system against predefined specifications. To facilitate testing of the database for tag channel allocation, wiring to I/O termination racks and loop range checks, it is common to use a customised panel of switches, LEDs and variable resistances to simulate the field connections as they are configured in the plant. So, for example, an on/off switch may be used to simulate an open or closed sensor on an automatic valve or an on/off sensor on a pump, while the variable resistance can allow the simulation of a position sensor on a control valve or an analog signal from an instrument. The LEDs indicate the presence of a digital output signal. Analog output signals can be measured at the appropriate termination points. The availability of a simulation mode on software loops can minimise the use of the light and switch test panel for a significant portion of the remaining software testing, including alarm handling, interlock functionality and programming operation. The absence of actual field connections allow for a rigorous test of the system, without impacting on plant activities. A major advantage in completing a thorough PSQ is that any potential difficulties with the operation of the system are highlighted at an early stage and addressed prior to installation.
Table 3 Typical activities for Installation Qualification Check of bill of materials, including all hardware and software Checkout of environmental conditions of control system locations Check of power sources, including back-up power Confirmation of proper grounding and shielding Check of controller redundancy capability Repeat of portion of PSQ to demonstrate that system functionality is unchanged by installation Check of wiring to field devices Completion of appropriate hardware diagnostic tests Verification of user manuals, wiring diagrams and operating and maintenance procedures
Along with a test of the operation of all hardware and software, the PSQ should include complete checks on all hardware and software inventory to ensure that the system tested is the system which will be ultimately installed in the plant. Also required are reviews of vendor test data and change control reports of construction quality and of power distribution within the system. For a large system, the effort required to complete a PSQ with this level of detail can be significant. However, as stated above, the opportunity for early identification of potential problems minimises the risk of costly field corrections. It should also be stressed that factory acceptance testing is a cornerstone of GMP and evidence of its completion is likely to be requested by the regulatory authorities.
4.2. Installation Qualification On completion of the PSQ testing, the system can be accepted for shipment and installation. Following installation of the system on site, the Installation Qualification (IQ), or Pre-commissioning Testing, is completed under the supervision of the client. The test specification is prepared prior to installation and has, as its objective, the provision of documented evidence that the installation of the computer system has been satisfactorily completed, in accordance with design. Table 3 contains some of the important checks to be completed during the IQ.
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
4.3. Operational Qualification Following a satisfactory conclusion to the Installation Qualification, the software can then be fully integrated with the computer hardware and the system interfaced to the field devices. The Operational Qualification (OQ), or Commissioning Testing, should now be completed by the client. The objective of this phase of the testing is to provide evidence that the system can function as designed, in real operating scenarios. This is typically achieved through the use of water and/or process materials. Prior to the start of these placebo, or dummy, batches, a number of system checks should have been completed and appropriately documented. These include full instrument loop checks to verify the interface between field devices and system database, full functional testing of alarm and interlock operation and handling, and testing of batch sequence operations. The OQ offers the first real opportunity to test many software sequences that are subject to plant performance. Heating, cooling, pressurisation and material charging are just a few such operations. Full tuning of all control loops is also a critical function for completion during the OQ step. The operating performance and capacity of the system hardware should also be challenged during the OQ, to confirm its compliance with specifications.
5. System operation Once the operation of the computer system has been fully qualified in the plant environment, it is now necessary to show that it can operate normally, consistently producing an acceptable product. This Performance Qualification (PQ) or Demonstration step is normally completed over a number of consecutive production batches, typically three. For full validation, there should be no process abnormalities associated with the control system over the course of these batches; if there are, then it is difficult to support the contention that the system has been completed according to the functional requirements. Obviously, the pro-
59
cesses under the control of the computer system must themselves be fully validated if the computer validation is to be meaningful—if the process does not operate consistently, then it will be impossible to show that the computer system consistently controls it. On successful completion of the validation batches and collation, review and approval of all associated validation documentation, the system is now ready for normal operation. However, to ensure that it remains in a validated state, an on-going validation program is required. This program should include a formal change control procedure, periodic performance reviews and regular quality audits. A fully audited and rigorously enforced, change control procedure ensures that the status of the control system is always known and always in agreement with the supporting validation documentation. This procedure should control the manner in which changes are made to the computer system, ensuring that the impact of any change is fully considered prior to its approval. Details of the change to be made, the reasons for it, its likely impact on the process and the revalidation requirements, if any, are the main items to be addressed by the change control procedure. Qualified persons in both technical and quality functions should approve the change prior to its implementation. Clearly, there are occasions when immediate changes to the control system are required for personnel and process safety reasons. The change control procedure should, nevertheless, ensure that the impact of these changes is reviewed subsequently. The regular performance reviews and system audits ensure that there is no deterioration in system operation. The frequency of these reviews should be in accordance with an established plan. Finally, it is critical that all personnel associated with the operation and maintenance of the control system are provided with a regular, structured, training programme. The effectiveness of the training programme should be assessed and its implementation should be clearly documented. From a validation point-of-view this provides the evidence that the people operating the system are qualified to do so.
60
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
6. Multipurpose biopharmaceutical facilities
7. Existing facilities
The requirements demanded for full validation of a computer control system have been described above. While the focus of this paper is on biopharmaceutical facilities, in fact, the specific details of the validation effort rarely depend on the type of process to be controlled. The hardware and software required to control temperature in a bioreactor are identical to that employed for temperature control in a batch chemical synthesis reactor. Similarly, the use of the same process equipment and associated control system for the production of a number of different products, does not generally place any unique demands on the approach to validation beyond those outlined above. Perhaps the only area in which the multipurpose nature of the production facility can influence the validation exercise is during the Performance Qualification and in the subsequent continuous evaluations. Because of the requirement for a three batch PQ for each new process, the effort associated with the validation of a multipurpose facility is clearly significant. Also, some form of qualification may be required prior to each subsequent campaign of a particular process, if some changes have been made to the system since the process was previously run. A final point, with respect to biotechnological facilities, is that proposals to use new sensor and analytical technology for on-line bioprocess control should take the implications of validation into account. This is especially true if the technology is to be used for primary process control with decisions, which may influence the critical quality attributes of the product, made on the progress of the batch on the basis of these measurements. As an integral part of the overall control system, these sensors must be amenable to full validation, with documented and sustainable calibration procedures and valid preventative maintenance programmes. What is acceptable in a research laboratory during the development of a new procedures may not be readily acceptable to the regulatory authorities in a fully validated production facility.
The validation strategy outlined above is equally applicable to a completely new facility, or to a new control system installation in an existing production plant. Where an existing unvalidated system is to be validated retrospectively, many of the steps described here are redundant. However, the development of a functional requirement specification is still essential to define what is the basic function of the system and what are the expectations for its performance. The next step is to qualify the system. This can be achieved through a documented review of historical system performance, or through documented testing where insufficient, or unsatisfactory historical data exists. The final step is to establish an on-going validation program with appropriate change control, performance review and system audit procedures. It should, however, be stressed that retrospective validation is a difficult task to complete fully, without running into the type of problems associated with the lack of a proper system specification and of rigorous change control procedures, that validation is designed to eliminate in a new project.
8. Summary The completion of a successful computer system validation program depends on the recognition that it is not simply a paper-generating exercise, but rather an integral part of any wellrun computer project. In fact, it can be argued that the documentation demands for validation are only slightly different from those required by Good Engineering Practice, which recommends that all aspects of a design project are documented in a controlled and meaningful manner, with a clearly identified document hierarchy, established at the outset of the project. A well-documented system is especially necessary to accommodate the stringent demands of multipurpose operation for rapid changeover from one process to the next. The life-cycle approach to
B. Glennon / Journal of Biotechnology 59 (1997) 53–61
computer system validation provides a successful operating structure in which the requirements of the regulatory authorities and the demands of an efficient pharmaceutical industry can both be accommodated. A well-planned and rigorously implemented validation program will ensure a good product at the end of the project, provide a stable production platform for the plant and will facilitate the project management through the presence of adequate documentation of requirements and expectations.
.
61
References Baird, R., De Santis, P., 1994. Validation of biopharmaceutical facilities. In: Lydersen, B.K., Delia, N.A., Nelson, K.L. (Eds.), Bioprocess Engineering: Systems, Equipment and Facilities. Wiley, New York, pp. 745 – 781. Commission of the European Communities, 1992. Guide to good manufacturing practice for medicinal products. O’Murchu, C., 1995. Validating a pharmaceutical control system. InTech 42, 58 – 61. PDA Committee on Validation of Computer-Related Systems, 1995. Validation of computer related systems. Technical Report No. 18. PDA. J. Pharm. Sci. Technol. 49, S1 – S17.