GOOD LABORATORY PRACTICE (GLP) GUIDELINES FOR THE VALIDATION OF COMPUTERISED SYSTEMS. Working Group Information Technology (AGIT)

Transcription

1 GOOD LABORATORY PRACTICE (GLP) GUIDELINES FOR THE VALIDATION OF COMPUTERISED SYSTEMS Working Group Information Technology (AGIT) Release Date : 22 June 2000 Version : 01 m:\daten-glp-winword-agit-validierungen-csv2000-val (version 01).doc

2 AGIT - Validation of Computerised Systems 2/28 TABLE OF CONTENTS 1 PROLOGUE INTRODUCTION Regulatory Background Definition General Principles Inventories (hardware, software, computerised systems) Source Code Commitments COMPUTERISED SYSTEMS Software Equipment VALIDATION POLICY RESPONSIBILITIES AND DOCUMENTS VALIDATION PLAN VALIDATION REPORT DOCUMENTATION Basic GLP Documentation Standard Operating Procedures Application Specific Documents ARCHIVING RETROSPECTIVE EVALUATION GLOSSARY REFERENCES...21 APPENDIX 1: VALIDATION PLAN...22 APPENDIX 2: VALIDATION REPORT...23 APPENDIX 3: VALIDATION DOCUMENTATION...24 APPENDIX 4: GENERAL PRINCIPLES OF VALIDATION...25 System Development Life Cycle The System Life-Cycle at the User s site WORKING GROUP INFORMATION TECHNOLOGY (AGIT)...28

3 AGIT - Validation of Computerised Systems 3/28 1 PROLOGUE These guidelines give an interpretation and specification of the OECD consensus document No.10 prepared by AGIT (Arbeitsgruppe Informationstechnologie). AGIT is a working group consisting of representatives from Swiss industry and Swiss authorities with the aim to propose procedures which might be applied conveniently in the test facilities fulfilling the regulatory requirements. The present document tries to specify more precisely the procedures to follow in carrying out validations of computerised systems. It intends to give guidance and help to test facilities and to promote a common standard to be used. The present guidance document is preliminary and will depend on the experience gained during the next few years and possibly on the interpretation of other OECD Member countries. However, it is open to the test facility management to use different approaches, as long as they are in compliance with the OECD consensus document No.10. The extent of a validation may vary depending on the complexity of the computerised system. In any case the validation should demonstrate that the computerised system is suitable for its intended purpose. 2 INTRODUCTION 2.1 Regulatory Background The validation of computerised systems is required by the Swiss ordinance on Good Laboratory Practice which is in force since 1 March This Ordinance is based on the OECD Principles of Good Laboratory Practice, as revised in 1997 and adopted November 26 th, 1997 by decision of the OECD Council [C(97)186/Final].[1] A more detailed description of the application of the principles of GLP to computerised systems was already published in 1995 based on discussions at an OECD consensus workshop. It is basically in line with the new GLP principles of OECD but has not yet been adapted until now. This GLP consensus document No.10 [2] - in addition to the above mentioned requirements - specifies what is needed for the operation of computerised systems in a GLP regulated environment. The present document is a preliminary interpretation of the OECD principles regarding computerised systems and the corresponding consensus document and has the status of a discussion paper between Swiss industry and Swiss authorities. 2.2 Definition The OECD GLP Principles as well as the OECD Consensus document No.10 define validation as The demonstration that a computerised system is suitable for its intended purpose. The validation process provides a high degree of assurance that a computerised system meets its pre-determined specifications. US FDA (1995) is in line with this definition by stating: Validation is establishing documented evidence which provides a high degree of assur-

4 AGIT - Validation of Computerised Systems 4/28 ance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes. Thus, it is important to define the suitability for the intended purpose, and to define specifications and quality attributes of the computerised system under consideration before the system is developed or purchased. Therefore, the documentation of the user requirements and system specifications is essential. 2.3 General Principles The GLP principles allow some flexibility in carrying out validations. For many reasons it seems reasonable to conduct the validation formally in a similar way as an experimental study. The GLP principles are quite precise with regard to the specifications of study plan, conduct of a study, and reporting of study results. Furthermore, they require the definition of responsibilities, the availability of standard operating procedures, and define the requirements for storage and retention of records. All these principles can conveniently be applied to the validation of computerised systems. Therefore, validations should be carried out analogous to the performance of GLP studies. This should guarantee compliance with the principles of GLP and facilitate the general understanding of the procedures by the involved parties. In any case a validation has to be carried out at the users site with his local computerised system. A vendor-supplied validation performed at the vendor s site is not sufficient. However, in order to make use of synergies the same test plans, procedure descriptions or checklists may be used for validations at different locations adapted to the specific situation. 2.4 Inventories (hardware, software, computerised systems) Inventories of hardware, software and computerised systems including analytical instruments and measuring devices being used under GLP should be available and regularly up-dated. Furthermore, the architecture of the hardware and the network should be described. 2.5 Source Code The source code of application software should be accessible for at least 10 years after the first use of the software at a test facility. It is not necessary that it is available at the test facility, but the test facility has to ensure that the vendor of the software keeps the source code at a save place so that it is available to GLP authorities if necessary. 2.6 Commitments The user of software or computerised systems has to make sure that the system was developed according to a recognised quality standard. For vendorsupplied systems it is likely that much of the design and test documentation created during the development is retained at the vendor's site. In this case, evidence of formal assessment and/or vendor audits should be available at the test facility.

5 AGIT - Validation of Computerised Systems 5/28 3 COMPUTERISED SYSTEMS Computer systems can vary from a programmable analytical instrument, or a personal computer to a laboratory information management system (LIMS) with multiple functions. Whatever the scale of computer involvement, the GLP Principles should be applied. (GLP Consensus Doc #10, Scope). Consequently, the aim of the validation remains the same for all systems, namely to demonstrate the suitability of the system for its intended purpose. However, depending on the complexity of a system the extent of testing and documentation may differ. 3.1 Software According to the complexity of the systems three types of software can be differentiated. Widely distributed standard software also called layered software or Industry Standard Software - such as operating systems (Windows NT, UNIX, VMS), programming languages and compilers (Fortran, C, visual Basic), ORACLE, SAS or Excel is supposed to be adequately validated based on a quality assurance system of the provider. Therefore, no further validation has to be performed at the user s site. However, user applications written within or by means of these systems, such as SAS procedures, ORACLE applications, Fortran or C programs, or Excel macros should be validated. The extent of testing and documentation should be based on an functional risk assessment. Individual spreadsheets need a documented quality control. Laboratory Information Management Systems (LIMS) should be fully validated with validation plan, test raw data and validation report as well as adequate system documentation. The extent of documentation can vary according to the complexity of the LIMS. Table 1: Categories of Computerised Systems : Software Category Definition Examples Validation LIMS (Laboratory Information Management Systems) Application Software Complex application/system Small amount of software distribution Medium to large systems Macros / Procedures Compiled or not compiled Software Limited complexity PATHDATA ARTEMIS PLACES SQL*LIMS etc. EXCEL macros SAS procedures Visual Basic or C programs etc Validation plan Validation test raw data Validation report Full validation documentation Extent of testing and documentation should be based on a functional risk assessment Industry Standard Software Widely distributed standard software/ layered software Published quality or validation status EXCEL ORACLE SAS Operation systems (NT, VMS) etc. None Documented quality control for individual spreadsheets

6 AGIT - Validation of Computerised Systems 6/ Equipment The spectrum of instruments driven by software as well as instruments which use software for evaluation and calculation of data cover a wide range of use e.g. simple systems such as ph-meters and balances up to complex systems like HPLC, MS and NMR. In many cases the computer is a major, integral part of the system which is dependent on the computer software to function. If this is the case the system should be validated. As major differences between the different apparatus exist it might be appropriate to build categories bearing in mind that each computerised system has to be assessed individually to demonstrate the suitability for its intended purpose. The following classification is a first attempt to classify these systems and may have to be revised based on future practical experience. The three categories are characterised as follows: Category: Complex Complex computerised systems are characterised by the use of an extended amount of functionality software and extended customisation. Typical examples are Automated Sample Processing Systems, Liquid chromatograph (LC, HPLC) and Gas chromatograph (GC) incl. Autosampler and Detection Systems, Spectrometer (UV, VIS IR, MS, NMR etc.), Radioactivity or Fluorescence Monitor, Biological analyser, ECG, etc. Prior to the first productive use the suitability of a complex computerised system should be demonstrated for its intended purpose by carrying out a full validation. A validation plan, test raw data, a validation report and full documentation should be used as specified in this document. Further validations might be necessary after significant changes e.g. new hardware or software, exchange of important components of the system. In such a situation a functional risk assessment should be carried out taking into account the impact on the computerised system. Based on this assessment the extent of an additional validation to be performed should determined. The procedure should be documented and reasons for the decision should be given. If a test facility puts several complex computerised systems of the same type at the same time into operation it might be adequate to validate one of these systems on behalf of others. The suitability of the other computerised systems should be tested with appropriate suitability tests. In such a case a functional risk assessment should be carried out and documented justifying the exceptional procedure. Such a procedure is only acceptable within a test facility at a defined site. The responsibility is with the test facility management. After the first installation a system suitability test might be appropriate to guarantee a correct function of the system over a distinct period or during a series of analyses. Results to be expected and acceptance criteria have to be specified and recorded prior to carrying out the test. Test results should be evaluated and documented. In case components of the system are exchanged and a full validation is considered unnecessary adequate tests e.g. a system suitability test should be carried out based on a justified and documented functional risk assessment. Furthermore all components to be used should be described in an appropriate document e.g. in the raw data or logbook.

7 AGIT - Validation of Computerised Systems 7/28 The frequency of testing, testing procedure, objective of the test procedure and the definition of acceptable deviations should be specified in a SOP. The test procedure should cover relevant hardware and software functions which may influence the intended purpose. In general the calibration procedure and/or the use of reference standards is part of the analysis and should be described in a SOP or in the corresponding study plan. A logbook should be established recording all actions e.g. inspections, cleaning, maintenance or calibration of all components of a computerised system over the whole live cycle. The logbook should also include or reference a detailed system description, a responsible person of the system, and a SOP for the operation of the system which includes the intended use of the system. Category: Simple For instruments with limited complexity such as liquid scintillation counter, balance, ph-meter a calibration procedure followed by a periodically performed function control might be adequate. Calibration and function control should be documented in a logbook. The calibration procedure, the function control and maintenance process of the instrument should be described in a SOP. Category: Exempted Standard equipment such as calculators is considered well established with a reliable history. Therefore validation is not needed. The same is true for instruments as camera, microscope, water bath, rota vap. Table 2: Categories of Computerised Systems : Equipment Category Definition Examples Validation Complex Extended amount of functionality software Extended customisation Automated Sample Processing Systems, Liquid chromatograph (LC, HPLC) and Gas chromatograph (GC) incl. Autosampler and Detection Systems, Spectrometer (UV,VIS,IR, MS,NMR etc.), Radioactivity or Fluorescence Monitor etc Biological analyser, ECG etc. Validation plan Validation test raw data Validation report Full validation documentation Simple Small amount of software Limited customisation Exempted Cannot be calibrated Particle sizer, Microplate Counter, Liquid Scintillation Counter, Image Analyser (X- Ray), ph-meter, Balance, Recorder for Temperature and Humidity, el. Pipette, Titrator, Refrigerator, Freezer, Polarimeter, Incubator, Autoclave, Tablet press, Reactor, Sample Oxidizer, Microwave oven etc. Calculator, Camera, Microscope, Water bath, Rota Vap etc. SOP (operation) Function control (Calibration) Logbook None

8 AGIT - Validation of Computerised Systems 8/28 4 VALIDATION POLICY According to OECD GLP Consensus document No. 10 there should be written management policies, inter alia, for validation. This policy should regulate the whole life cycle of a computerised system during development and its productive use starting with the specification of user requirements and ending with the retirement of the system. It is recommended that this policy covers and defines all general validation aspects. In this way, the volume of the documentation of an individual validation can be reduced. It seems worthwhile to differentiate between validation policy and validation master plan. While a validation policy defines the general principles of validation to be followed within a company, a validation master plan is dedicated to a particular system describing the entire life cycle of the system from the point of user requirement definition up to system retirement. In this sense, the validation master plan is the application of the validation policy to a particular system. The validation master plan can be perceived as an umbrella covering all aspects of the validation of a particular computerised system during the full life cycle. Depending on the complexity of a computerised system an adequate description is necessary. For complex systems a validation policy/master plan describing the whole life cycle might be necessary. An example is given in Appendix 4. 5 RESPONSIBILITIES AND DOCUMENTS The responsibilities for a validation are extensively described in the OECD GLP consensus document No. 10. The main responsibilities can be summarised as follows: Management of the test facility has the overall responsibility for compliance with the GLP Principles. In particular it has to establish procedures to ensure that computerised systems are suitable for their intended purpose, and are validated, operated and maintained in accordance with the principles of GLP. Study directors are responsible for the overall conduct of their studies and should ensure that computerised systems used in their studies have been validated. Personnel are responsible for performing activities with computerised systems in accordance with the GLP Principles and recognised technical standards. Quality Assurance (QA) responsibilities for computerised systems must be defined by management and described in written policies and procedures. It should be assured that established standards are met for all phases of validation. The following table gives an overview of the responsibilities, the relevant documents of a validation and the persons who should sign the corresponding documents.

9 AGIT - Validation of Computerised Systems 9/28 Table 3: Responsibilities and documents for validation Document Signatures Responsibilities Validation plan 1) Test facility Management Sponsor System owner 4) Responsibility for the application / coordinator Validation director Overall responsibility for the conduct of the validation according to GLP, checks according to application IT Responsible 4) IT relevant checks, functioning of hardware and software Quality assurance inspector: Verification of validation plan Test plans 2) 4) Validation director Amendments to validation plan Raw data Validation team (visa) Conduct of tests Validation report Validation director Overall responsibility for compliance with GLP System owner 4) Responsibility for the application / coordinator IT Responsible 4) IT matters Further Responsibles 4) Quality assurance inspector: Audit of validation report GLP statement 3) Validation director Overall responsibility for compliance with GLP QA statement 3) Quality assurance inspector Assurance of the GLP compliant conduct of the validation: Validation plan, validation report, inspection 1) 2) 3) 4) The whole life cycle should be described in an appropriate document e.g. policy, concept, master plan and retirement report To be treated analogous to amendments to the validation plan if not part of the validation plan Part of validation report if applicable

10 AGIT - Validation of Computerised Systems 10/28 6 VALIDATION PLAN The validation plan should provide documented evidence that the validation activities for a specific system are carried out systematically and under management control. Since the validation plan consists of many subdivisions and sub-documents it is important to keep the documentation concise and well indexed. Document titles as well as the headers of the documentation should clearly indicate the name and version of the software under validation. The validation plan should be prepared and approved prior to conducting the validation tests. As summarised in appendix 1 the following topics should be covered by the validation plan: Purpose Scope It should be defined how the project will produce a validated computerised system which operates consistently and reliably and complies with all applicable regulatory requirements. It should be specified, whether this is the first validation of the system or a re-validation. This indication is particularly true for a new version of the system. The scope of the validation plan should describe which systems are covered and what is the relation to other connected systems. The boundaries of the system should be defined so that it is clear what is and what is not included as part of the system being validated. Furthermore it should be indicated where the system will be located. System description The system description is to provide an introduction to the system showing what the system is supposed to do and in which environment it will be employed. The main system functions should be specified. Responsibilities Test environment The responsibilities for validation related activities associated with the system should be defined. The organisation of the people associated with the system, responsible for development, validation, use and maintenance, quality assurance should be defined. For details see table 3. The system must be summarised in terms of hardware and software components. Hardware and Software components should be specified for the test and production environment including Hardware: supplier, model, serial number, components, network, and location Software : supplier, name, version, source code, and location. Validation method It should be specified whether it is a process or data validation, whether black box or white box testing meth-

11 AGIT - Validation of Computerised Systems 11/28 Functional Risk Assessment Tests Schedule Procedure Documentation Archiving ods will be applied. The procedure should be described as necessary. The basis for the tests should be given e.g. specific user requirements or a user manual. A validation of a computerised system should be based on a functional risk assessment taking into account the likelihood of an event and the severity of consequences. Technical risk and user risk should be addressed. The extent of documentation to be produced may be minimal or extensive based on necessity, usefulness and reproducibility. The category of the computerised system (software or equipment) should be taken into consideration. Test cases should principally be based on the user requirement specifications. Furthermore, the functional risk assessment should be considered, wherein system functions have been individually analysed for the likelihood and consequences of failure. Functions deemed high risk must be challenged thoroughly, including testing of boundary values and invalid inputs. Relevant real as well as extreme challenges of the system should be selected. The expected results as well as the acceptance criteria have to be defined in the test plan. The details of error logging should be specified as well as the procedure for documentation of the test results; for instance, screen dumps,logfiles,printouts,etc. Since the test results (raw data) need to be signed and dated, there must be a record which equates any signatures, initials, or other marks which appear on the test record with printed identification of the persons involved. Approximate start and end dates of the test phase have to be specified. Guidance should be provided for the conduct of the tests, the evaluation of the results as well as the contents of the report, if not already defined in the validation policy. An index of all documentation relating to the computerised system, including but not limited to SOPs, user developed documentation, and vendor/provider developed documentation should be provided. For details see chapter 8 and appendix 3. A list of records to be retained should be given.

12 AGIT - Validation of Computerised Systems 12/28 7 VALIDATION REPORT The validation report summarises the results of acceptance testing and presents a conclusion that all requirements of the validation guidelines have been addressed. The execution of the planned activities, the results obtained and deviations from expected results must be described in the validation report. Following items need to be addressed in the validation report : Summary Purpose Scope System Description Documents and SOPs Facilities, Personnel and Responsibilities Dates : effective starting and completion dates of the test phase Procedure Results of tests starting and completion dates of validation (plan/report) Expected results and acceptance criteria should be recorded in advance of starting the test usually in the validation plan or amendments. Results obtained should be documented as well as deviations from expected results, if appropriate with comments. The results of the tests should be evaluated and discussed. Recommendations should be given, in particular whether the application can be released. GLP compliance statement, Quality assurance statement Archiving: The location where the documents will be archived should be mentioned. The validation director is responsible for the GLP compliant conduct of the validation; thus, he will sign the GLP compliance statement. The Quality assurance unit (QAU) should audit the validation plan, raw data, and report; consequently, the QAU has to prepare and sign the QA statement. Management is responsible for the release of the system for its operational use. An overview of the items to be covered in the validation report is given in appendix 2, responsibilities are shown in table 3.

13 AGIT - Validation of Computerised Systems 13/28 8 DOCUMENTATION A full validation package consists of a number of individual documents specifying the functionality of the system, the IT environment in which it operates, and the procedures to be employed for the proper use and maintenance of the system. The extent of documentation has to be established for each individual case. Three types of documentation may be differentiated: 8.1 Basic GLP Documentation Basic documentation is independent of the individual application software under validation and contains the training record, job description, and CV of the users of the system. Furthermore, there should be an inventory of all computerised systems being used in the facility including information about system owner, location, validation status, etc. 8.2 Standard Operating Procedures The OECD consensus document #10 requires a set of standard operating procedures for the development and/or routine use of validated computerised systems; they include SOPs for Operation Security In addition to the User s Manual, this SOP describes how the application will be used in a particular laboratory. When the user has the opportunity to customise a system for his particular needs, this has to be specified. Furthermore, the SOP will contain information on who is the system administrator, and it will reference other pertinent SOPs to be followed when using the system. Three levels of security must be addressed: physical security of the system [server(s) and workstation(s)]; logical access to the application; and logical access to the operating system including access to data and program files for the application. Change Control Effective change management is the single most important factor in maintaining a validate state for a production system. All forms of change must be tracked and managed. This will always include application software updates, operating system updates, and changes to the hardware running the application. Depending upon the type of system being validated, this may include changes to the network or modification to a qualified workstation. Every change, no matter how minor, must be evaluated for its potential impact on the validated application as defined in a change control SOP.

14 AGIT - Validation of Computerised Systems 14/28 Back-up and Restore The SOP specifies the procedures for back-up of the application and the data files. The SOP must describe frequency, period of retention for back-up copies, the method and responsibility for periodic back-up, and the process of restoration. Maintenance and Problem Log Measures used to record and archive all reported problems and maintenance activities with the system should be defined in a SOP. The minimum content of such a log should include the problem, date the problem occurred, action taken, who performed the action, the date the action was carried out, and reference to relevant change management documentation. Monitoring and Auditing The system needs to be monitored regularly for correct operation including device checks, if appropriate. Attempts of unauthorised access to the system should be monitored, and reported to the system owner. Periodic Testing Functionality testing should be performed on a regular basis (e.g. by running automated test scripts). Software Development If software is developed by the user or an internal IT group there should be a SOP defining standards for software design, coding and testing. Important is the method of version control. The SOP should refer to a commonly acknowledged software development life cycle model. Contingency Plan and Disaster Recovery A contingency plan should specify manual procedures to be followed in case of system breakdown or failure. A detailed plan for disaster recovery should be available. Tests should be carried out and results thereof should be documented. Archiving and Retrieval A SOP should describe how data are archived, the period of retention, retrieval mechanism, and storage conditions. An archive index should be specified. The archival and retrieval procedures should be tested and the results documented. The SOP should also address the issue of readability over the entire retention period. Quality Assurance The SOP specifies the procedures how QA will audit the validation process and the IT-infrastructure in a GLP-regulated environment. Apart from the SOP on operation of a system, these SOPs may be as generic as possible; i.e. they must not be written for each application separately.

15 AGIT - Validation of Computerised Systems 15/ Application Specific Documents User Requirement Specifications User requirements specifications is a document generated by the users, which defines the conditions and capabilities needed by business to solve a problem or achieve an objective. Application Description The application description describes the purpose and scope of the application and specifies the functionality of the system in business terms. System Description The system description is a technical document describing the technical features of the application and the environment (Hardware, interfaces, network, etc.) wherein the software will operate. Installation Manual Usually, this is a set of instructions needed to be followed when the system is installed. In addition, it defines the minimum hardware and operating system requirements. User s Manual A vendor supplied document describing how to use the system. Release Notes Release notes are also supplied by the vendor. They contain information upon changes and enhancements of the software compared to a previous version. Vendor Audit Report The vendor audit report describes the software development life cycle (SDLC) and the quality system of the vendor. It includes also information about software design and, in particular, about software testing. Validation Plan See chapter 6 Validation Test Raw Data The test raw data encompass manual notes filled in the test scripts, screen dumps, printouts and electronic records. Validation Report See chapter 7

16 AGIT - Validation of Computerised Systems 16/28 9 ARCHIVING The archiving of the validation package (documents listed in chapter 8) should be analogous to the archiving of documents of GLP studies. The documents to be used, in particular the SOPs, should be referenced. The main documents to be archived are Validation plan Raw data Validation report GLP compliance statement and QA statement SOPs Recordings of QAU The documents to be archived have to be indicated in the validation plan. In the validation report the location where and in which format (paper or electronically) these documents will be stored should be indicated. Adequate facilities should be provided for the secure retention of electronic storage media. Exposure to extreme temperature and humidity, dust, electromagnetic interference and the proximity to high voltage cables should be avoided. When documentation is held electronically it is necessary to provide for long term retention. Continued access to the information has to be guaranteed also in case of hardware or software system changes, and it should be assured that the electronic documentation is available in a human-readable format. 10 RETROSPECTIVE EVALUATION According to OECD consensus document No.10 a retrospective evaluation to assess the suitability of a system should be carried out for systems where the need for compliance with GLP Principles was not foreseen or not specified. Retrospective evaluation begins with gathering all historical records related to the computerised system. These records are then reviewed and a written summary is produced. This retrospective evaluation summary should specify what validation evidence is available and what needs to be done in the future to ensure the suitability of the system for its intended purpose. According to [3] the report on the retrospective evaluation should include information on the degree of stability and maturity of the system as well as the achievement of the user requirements. In particular the following questions should be answered: At what time, from whom and with which tools was the system taken into operation? Is the system based on a quality assurance system? Is the software widely used or was it developed for a specific application (internally or externally)?

17 AGIT - Validation of Computerised Systems 17/28 Which user groups within the test facility work with the system? What is the purpose of the system? Which problems arose during the last few years and how were they managed? Furthermore a collection of the available documentation on the system should be put together as completely as possible. In particular a description of the system, system specifications, manuals for system managers and users and the availability of the source code should be specified. The quality and completeness of the documentation should be assessed. Based on the available documentation a functional risk assessment should be carried out to determine whether the available information is sufficient to ensure the suitability of the system for its intended purpose or whether tests or a validation is necessary. The tests or the validation should be elaborated and performed as described in this document. Reasons for the selected procedure should be given. The retrospective evaluation, the results of the functional risk assessment and the measures taken should be recorded.

18 AGIT - Validation of Computerised Systems 18/28 11 GLOSSARY Term Definition Ref. Acceptance criteria Acceptance testing ANSI Calibration Computerised System GAMP GLP ISO The documented criteria that should be met to successfully complete a test phase or to meet delivery requirements. Formal testing of a computerised system in its anticipated operating environment to determine whether all acceptance criteria of the test facility have been met and whether the system is acceptable for operational use. American National Standards Institute Demonstration that a particular measuring device produces results within specified limits by comparison with those produced by a reference standard device over an appropriate range of measurements. This process results in corrections that may be applied to optimise accuracy. A group of hardware components and associated software designed and assembled to perform a specific function or group of functions. Good Automated Manufacturing Practice Good Laboratory Practice International Organisation for Standardisation OECD # 10 OECD # 10 GAMP [6] PMA CSVC OECD # 10 ISO Quality management and quality assurance standards Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software. IEEE IT LIMS Institute of Electrical and Electronic Engineers Information Technology Laboratory Information Management System NIST National Institute for Standards and Technology FDA [4] PMA CSVC Qualification Installation Pharmaceutical Manufacturers Association: Computer Systems Validation Committee Establishing confidence that process equipment and ancillary systems are compliant with appropriate codes and approved design intentions, and that manufacturer's recommendations are suitably considered. FDA [4]

19 AGIT - Validation of Computerised Systems 19/28 Qualification Operational Establishing confidence that process equipment and subsystems are capable of consistently operating within established limits and tolerances. FDA [4] Qualification Process Performance Qualification Product Performance QA QAU Raw data SDLC SOP Source Code System System life cycle - Software life cycle System Suitability Test Establishing confidence that the process is effective and reproducible. Establishing confidence through appropriate testing that the finished product produced by a specified process meets all release requirements for functionality and safety. Quality Assurance Quality Assurance Unit All original test facility records and documentation, or verified copies thereof, which are the result of the original observations and activities in a study. Raw data also may include, for example, photographs, microfilm or microfiche copies, computer readable media, dictated observations, recorded data from automated instruments, or any other data storage medium that has been recognised as capable of providing secure storage of information for a time period of 10 years. System Development Life Cycle Standard Operating Procedure Documented procedures which describe how to perform tests or activities normally not specified in detail in study plans or test guidelines. An original computer program expressed in human-readable form (programming language) which must be translated into machine-readable form before it can be executed by the computer. People, machines, and methods organised to accomplish a set of specific functions. Period of time beginning when a software product is conceived and ending when the product is no longer available for use. The software life cycle is typically broken into phases denoting activities such as requirements, design, programming, testing, installation, and operation and maintenance. Contrast with software development process. A process of checking out the performance specifications of a system. FDA [4] FDA [4] OECD # 1 OECD # 1 OECD # 10 ANSI NIST Huber [5]

20 AGIT - Validation of Computerised Systems 20/28 Test Test plan Validation Validation plan Verification An activity in which a system or component is executed under specified conditions, the results are observed or recorded and an evaluation is made of some aspect of the system or component. Documentation specifying the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, responsibilities, required, resources, and any risks requiring contingency planning. The demonstration that a computerised system is suitable for its intended purpose. Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes. Written plan stating how validation will be conducted, including test parameters, product characteristics, production equipment, and decision points on what constitutes acceptable test results. Confirmation by examination and provision of evidence that specified requirements have been met. IEEE IEEE OECD #10 FDA [4] Huber [5] Huber [5] For more detailed information please refer to our GLP home page

21 AGIT - Validation of Computerised Systems 21/28 12 REFERENCES [1] OECD Series on Principles of Good Laboratory Practice and Compliance Monitoring No. 1: OECD Principles of Good Laboratory Practice (as revised in 1997). Environment Directorate, OECD, Paris, 1998 [2] OECD Series on Principles of Good Laboratory Practice and Compliance Monitoring No. 10: GLP Consensus Document. The Application of the Principles of GLP to Computerised Systems. Environment Monograph No. 116; Environment Directorate, OECD, Paris, 1995 [3] Einsatz computergestützter Systeme bei GLP-Prüfungen; Vorschläge der Projektgruppe GLP und EDV des Arbeitskreises GLP im Verband der Chemischen Industrie e.v.: Pharm. Ind. 59, 1, , (1997) [4] USA Food and Drug Administration (FDA): Glossary of computerised system and software development terminology; [5] Ludwig Huber : search : glossary [6] Good Automated Manufacturing Practice Forum (GAMP Forum): glossary; GAMP Supplier Guide Version 2.0 (1996): Pharmaceutical Industry Supplier Guide for Validation of Automated Systems in Pharmaceutical Manufacture

22 AGIT - Validation of Computerised Systems 22/28 Appendix 1: VALIDATION PLAN PURPOSE SCOPE SYSTEM DESCRIPTION RESPONSIBILITIES TEST ENVIRONMENT VALIDATION METHOD TESTS SCHEDULE PROCEDURE System, application area Production environment Test facility management, System owner, IT responsible, Validation director, Validation team, QA Hardware (model), Software (version), Network, Test location Process or data validation, tests against user requirements or user manual Test cases/script Test data (real, stress) Acceptance criteria Start and end date of test phase Conduct of tests Evaluation Report DOCUMENTATION ARCHIVING

23 AGIT - Validation of Computerised Systems 23/28 Appendix 2: VALIDATION REPORT SUMMARY PURPOSE * SCOPE * SYSTEM DESCRIPTION * DOCUMENTS, SOPS * FACILITIES, PERSONNEL, RESPONSIBILITIES * DATES Effective start and end dates of test phase PROCEDURE RESULTS OF TESTS Expected results Acceptance criteria Results obtained Deviations from expected results Comments EVALUATION / DISCUSSION / RECOMMENDATION QA AND GLP STATEMENT ARCHIVING * Information already indicated in the validation plan

24 AGIT - Validation of Computerised Systems 24/28 Appendix 3: VALIDATION DOCUMENTATION BASIC DOCUMENTS Personnel documentation Master list of computerised systems Inventory/location of computerised systems SOPs Operation Security Change control Back-up and restore Maintenance Monitoring and auditing Periodic testing Software development Contingency plan and disaster recovery Archiving and retrieval Quality assurance SPECIFIC DOCUMENTS User requirement specifications Application description System description Installation manual User manual Release notes Vendor audit report Validation plan Validation test raw data Validation report

25 AGIT - Validation of Computerised Systems 25/28 Appendix 4: General Principles of Validation System Development Life Cycle The V-model shown in figure 1 below gives an overview on the different phases during a system development life cycle. User Requirements AcceptanceTest Plan Acceptance Test (Performance Qualification) Functional Specification System Test Plan System Test (Operational Qualification) System Design Integration Test Plan Integration Test (Installation Qualification) Software Developer Software Developer User User Module Design Unit Test Plan Module Test Code Figure 1: The V-model describes the system development life cycle In the beginning of a (hardware, software or equipment) development project, there is usually the user s request for a new system that should be capable of doing some specific tasks; e.g. measuring the plasma concentration of drugs within a given sensitivity range. The user compiles formally all his/her requirements in a document called User Requirements; it is part of the design qualification. These user requirements contain scientific and business, regulatory, safety, performance and quality requirements. It is of paramount importance to realise that the user requirements serve as the basis for the user acceptance test, sometimes also referred to as performance qualification. The aim of the user acceptance test is to demonstrate that a computerised system is suitable for its intended purpose in the user s own environment. The next level concerns the functional specifications of the computerised system. In case of a new development, the developer translates the user requirements into functional specifications. However, if the user prefers to purchase an off-the-shelf product, the functional specifications can be obtained

26 AGIT - Validation of Computerised Systems 26/28 from the User s Manual; i.e. the user has to compare the offered functions of the product with his/her user requirements and determine whether the product could in principal fulfil his needs with the given functionality. The functional specifications and the functional risk assessment serve as the basis for the system test, also referred to as operational qualification. The aim of the system test is to demonstrate that all functions needed for the intended purpose are available and operate reliably in the user s environment. On the next lower level, the system design including its system components, layered software, operating system software and network requirements are specified. The system integration test (or installation qualification) builds upon the system design specification. It shows that the system was properly installed in the user s environment and that all components are operative. Module design, module testing and coding of the individual modules is in the responsibility of the developer. Thus, the user is not directly involved, but (s)he has to ensure e.g. by a vendor audit that the software is developed according to commonly accepted development standards (e.g. ISO , IEEE). The System Life-Cycle at the User s site At the user s site, the system passes also through a life-cycle which is detailed in figure 2. Again, the life-cycle starts with the definition of user requirement for a particular system. The system would then either be developed according to figure 1 or purchased. User Requirements Full System Documentation Validation Plan - Report Manuals SOPs etc. Change Requests Additional System Documentation Validation Plan - Report New Manuals updated SOPs Retirement Request Retirement - Plan - Report Validation Vers. 1.0 Vers. 1.0 in Production Validation Vers. 2.0 Vers. 2.0 in Production GLP Archive Software Version 1.0 Technical Enhancement Proposals Software Version 2.0 Documents & Raw Data Software Version 2.0 Figure 2: A model of the system life-cycle at the user s site Before going to production, the system version 1.0 will be fully validated and all documentation about the system, its operation and maintenance would be compiled in a validation package. If the validation passes all acceptance criteria, management would release the system Version 1.0 to production. While working productively with a system, it commonly happens that the users have additional requirements for the improvement of the system which they forward to the system developer in the form of change requests. In addition, developers usually want to keep their system technically up-to-date; i.e. there are also change requests from their site. By implementing these system change (again according to figure 1), a new version 2.0 of the system emerges that will be

27 AGIT - Validation of Computerised Systems 27/28 shipped to the user. Depending on the extent of changes of the system either a completely new validation or only a partial validation has to be performed. The criteria for new or partial validation have to be defined in advance. This cycle of change requests, implementation of changes, validation, release to production may occur several times during the life-cycle of a system. Finally, however, there might be the request to get rid of the old, - may be obsolete system and to purchase a new one. The end of the system life-cycle is the retirement of the system according to a formal retirement plan. The entire system documentation has to be archived, also the electronic raw data and the software code. According to the GLP principles it is imperative that the system - as long as it is in productive use - has to be maintained in a validated state throughout the whole system life-cycle.

28 AGIT - Validation of Computerised Systems 28/28 Working Group Information Technology (AGIT) Working Group Information Technology (AGIT) was founded 27 March 1998 with the objective to discuss relevant problems of Good Laboratory Practice (GLP) in the field of information technology and exchange experience between industry and monitoring authorities. Furthermore it is intended to support test facilities in solving problems while applying information technology in practice. As basis for the discussions OECD Consensus Document number 10 on the application of the principles of GLP to computerised systems is used. Members of AGIT are representatives from the Swiss GLP monitoring authorities (Olivier Depallens, Federal Office of Public Health; Hansruedi Hartmann, Intercantonal Office for the Control of Medicines; Hans Peter Saxer, Swiss Agency for the Environment, Forests, and Landscape) as well as representatives from industry (Bruno Eschbach, Novartis Pharma; Peter Grass, Novartis Pharma; Stephan Hassler, Novartis Crop Protection; Heinrich Urwyler, F.Hoffmann-La Roche). The cooperation started with a stock-taking followed by priority setting. Performing validations in practice and use of electronic records and signatures according to the guideline of US FDA were selected as main topics. Both turned out to be tricky and therefore involve extensive discussions. The present paper intends to give support to perform validations of computerised systems in practice. Based on experience gained during practical application it might be necessary to amend the current version. Attempts to interpret rule 11 of US FDA (21 CFR Part 11) concentrate on the impact on future documentation of raw data, the difference between electronic signatures and electronic visa as well as the management of electronic signatures. Currently available software for the use of electronic signatures helps to simulate the application in practice. Establishing and managing electronic Standard Operating Procedures (SOPs) and archiving electronic raw data are further topics of main interest. Internet Home Page guarantees speedy access to recent information for users. Finalised documents of AGIT will be made available as well as links and references to guidelines, laws and regulations, definitions, relevant literature, training courses, workshops etc.