GAMP Good Practice Guide for Validation of Laboratory Computerized Systems.docx

1、GAMP Good Practice Guide for Validation of Laboratory Computerized SystemsGAMP Good Practice Guide for Validation of Laboratory Computerized Systems, Part 1Guidance to help validation of computerized systems used within regulated laboratories is always welcome but is it always helpful? In the first

2、part, I present an overview of the Guide, different approach to life cycle validation and system classification.Over the past years I have not spoken in any great detail about guidance documents on computer validation for chromatographic systems and chromatography data systems (CDS) but concentrated

3、 on a specific topic from the regulations themselves. This is because most guidance has concentrated largely on computerized manufacturing and corporate systems, rather than laboratory systems. This has changed now with the publication of the Good Automated Manufacturing Practice (GAMP) Forums Good

4、Practice Guide (GPG) on Validation of Laboratory Computerized Systems.1 However, this publication needs to be compared and contrasted with the AAPS publication on Qualification of Analytical Instruments (AIQ).2 Both publications have been written by a combination of representatives from the pharmace

5、utical industry, regulators, equipment vendors and consultants. This will be a two-part discussion of the guide and where we should go to cover adequately both equipment qualification and validation of chromatography-based laboratory systems. Overview of the GuidePublished in 2005, the stated aim of

6、 the GPG is to develop a rational approach for computerized system validation in the laboratory and provide guidance for strategic and tactical issues in the area. Section 5 of the GPG also notes that .the focus should be on the risk to data integrity and the risk to business continuity. The Guide a

7、ssumes that these two factors are of equal importance.1The GPG notes that companies need to establish their own policies and procedures based on their own risk management approaches. Of interest, the inside page of the GPG states that if companies manage their laboratory systems with the principles

8、in the guide there is no guarantee that they will pass an inspection therefore caveat emptor! Table 1: Contents of the GAMP GPG on validation of laboratory systems.The guide consists of a number of chapters and appendices as shown in Table 1. As you can see, the order of some of the chapters is a li

9、ttle strange. For example, why is the validation plan written so late in a life cycle or why is the chapter on training of personnel positioned after the validation report has been written? However, at least the main computer validation subjects are covered in the whole life cycle including system r

10、etirement. The GPG also cross references the main GAMP version 4 publication for a number of topic areas for further information where appropriate.3One major criticism is that the nine references cited in Appendix 5 are very selective and, therefore, the GPG ignores some key publications in this are

11、a such as: Furman et al. on the debate of holistic (or system) versus modular validation or qualification of computerized equipment.4 This paper was written by three FDA personnel about the validation of computerized chromatographic equipment; ignoring it is not an option as it provides a scientific

12、 rationale for this two-level approach. PDA Technical Report 18 on validation of computer-related systems that contains a more specific computer validation definition than the FDA process validation definition quoted in Section 3.1 of the GPG.5,6 AAPS Analytical Instrument Qualification white paper

13、published in 2004, which was the outcome of a joint FDA-AAPS conference from 2003.2Ignoring these papers biases the approach that this guide has taken and is a fatal flaw as we shall discuss later in this article. Overall, the problem with this GPG is that you have to cherry pick the good bits from

14、the bad. As with any performance appraisal system, lets start with the good news first and work our way downhill afterwards. The Good NewsFigure 1: System development and system implementation life cycles (adapted from the GAMP laboratory GPG).The best parts of the GAMP laboratory system GPG are the

15、 life cycle models for both development and implementation of computerized laboratory systems.1 The writers of the guide are to be congratulated for producing life cycle models for development and implementation that reflect computerized systems rather than manufacturing and process equipment presen

16、ted in the original GAMP guide.3 The latter V model life cycle is totally inappropriate for computerized and laboratory systems as it bears little comparison with reality. The problem with the GAMP V model was that immediately after programming the system it undergoes installation qualification (IQ)

17、. Unit, module and integration or system testing is conveniently forgotten, ignored totally or implied rather than explicitly stated. The two models illustrated in the laboratory GPG are shown in Figure 1. The left-hand side shows the system development life cycle (SDLC) that is intended for more co

18、mplex systems and the right-hand side which shows the system implementation life cycle (SILC) for simpler systems. This reflects the fact that we can purchase a system, install it and then operate it as shown on the right-hand of Figure 1. The vast majority of equipment and systems in our laboratori

19、es are similar to this, but consider the question: has the SILC oversimplified the implementation process for all spectroscopy and other laboratory computer systems? The argument for the SILC: For most computerized chromatographs and CDS in a post-Part 11 world, you will need to add user types and u

20、sers to the system that will need to be documented for regulatory reasons, for example, authorized users and access levels required by both predicate rules and 21 CFR 11. However, after doing this for simpler systems, such as an integrator, we can go into the performance qualification stage; this is

21、 not mentioned specifically in the SILC. The argument against the SILC: The software used in some laboratory computerized systems may need to be configured this is a term for either selecting an option in the software to alter its function within limits set by the vendor. This can be as simple as se

22、lecting which function will be used from two or three options or, in more complex systems such as a laboratory information management system (LIMS), using a language to set up a laboratory procedure or method. This factor is not accommodated specifically in either of the life cycle models. However,

23、regardless of the approach taken, the system configuration must be documented partly for your business to allow reconfiguration of the system in case of disaster but also for performing the validation. Figure 2: Modified system implementation life cycle options and macro development.In my view, the

24、concept of the SILC is good but the scope and extent of it can be taken further than the Laboratory GPG suggests. Furthermore, it can also be aligned with the existing software categories contained in Appendix M4 of the current GAMP Guide.3The rationale is that many laboratory systems are configured

25、 rather than customized; therefore we need more flexibility than the simple SILC presented in the Laboratory GPG. This is where the GAMP software categories, outlined in Version 4 Appendix M4, come in and where the Laboratory GPG makes computer validation more complex than it needs to be. Figure 2 i

26、s my attempt to take the SILC principles further than the GPG and align them with the existing GAMP software categories. A user requirements specification is the entry point for all variations illustrated in Figure 2, the exit from this figure is the route to the qualification and configuration of t

27、he system. The definitions of the different types of GAMP software are GAMP 3 software: This is commercial off-the-shelf software (COTS). The SILC for this type of software is shown on the right-hand side of Figure 2 In essence, this is a modification of the GPG implementation cycle where the docume

28、ntation of security, access control and any other small software configurations for run time operation are substituted for the design qualification. GAMP 4 software: This is configurable commercial off-the-shelf software (configurable COTS). Once the software functions have been understood, an appli

29、cation configuration specification can be written that will state what functions in the software will be used, turned on, turned off or modified. After the software has been installed and undergone the IQ and operational qualification (OQ) has been performed, then the software can be configured acco

30、rding to the configuration specification documents. GAMP 5 software: Although this is usually a unique and custom application. However, in the context of CDS software, this is typically a custom calculation, a macro or custom program that is written to perform a specific function. Therefore both GAM

31、P 4 and GAMP 5 software can exist in the same system and the GAMP 5 aspects are typically an addition to the normal functionality of the software rather than a substitute. Therefore, the life cycles for a CDS in this category will be the GAMP 4 software (central flow in Figure 2) plus the additional

32、 steps for GAMP 5 macros or calculations (pictured on the left-hand side of the same diagram). Here, there needs to be a specification for the macro (name plus version number), the calculation or the programming or recording of the macro. Against this will be formal testing to ensure that the functionality works as specified. Once this has been performed, then the macro is installed with the application and it is tested under the performance qualification (PQ) phase of validation as an integral part of the overall system. The Bad NewsHere, in my view, is where the GPG creates problems