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

m:\daten-glp-winword-agit-validierungen-csv2000-VAL (version 01).doc

GOOD LABORATORY PRACTICE(GLP)

GUIDELINES

FOR THE VALIDATION

OF COMPUTERISED SYSTEMS

Working GroupInformation Technology (AGIT)

Release Date : 22 June 2000

Version : 01

AGIT - Validation of Computerised Systems 2/28

TABLE OF CONTENTS

1 PROLOGUE............................................................................... 3

2 INTRODUCTION........................................................................ 32.1 Regulatory Background.................................................................................... 32.2 Definition .......................................................................................................... 32.3 General Principles............................................................................................ 42.4 Inventories (hardware, software, computerised systems) ................................ 42.5 Source Code .................................................................................................... 42.6 Commitments ................................................................................................... 4

3 COMPUTERISED SYSTEMS .................................................... 53.1 Software ........................................................................................................... 53.2 Equipment ........................................................................................................ 6

4 VALIDATION POLICY ............................................................... 8

5 RESPONSIBILITIES AND DOCUMENTS ................................. 8

6 VALIDATION PLAN................................................................. 10

7 VALIDATION REPORT............................................................ 12

8 DOCUMENTATION ................................................................. 138.1 Basic GLP Documentation ............................................................................. 138.2 Standard Operating Procedures..................................................................... 138.3 Application Specific Documents ..................................................................... 15

9 ARCHIVING ............................................................................. 16

10 RETROSPECTIVE EVALUATION........................................... 16

11 GLOSSARY ............................................................................. 18

12 REFERENCES......................................................................... 21

APPENDIX 1: VALIDATION PLAN .............................................. 22

APPENDIX 2: VALIDATION REPORT.......................................... 23

APPENDIX 3: VALIDATION DOCUMENTATION......................... 24

APPENDIX 4: GENERAL PRINCIPLES OF VALIDATION........... 25System Development Life Cycle............................................................................ 25The System Life-Cycle at the User’s site............................................................... 26

WORKING GROUP INFORMATION TECHNOLOGY (AGIT) ....... 28


1 PROLOGUE

These guidelines give an interpretation and specification of the OECD con-sensus document No.10 prepared by AGIT (Arbeitsgruppe Informations-technologie). AGIT is a working group consisting of representatives fromSwiss industry and Swiss authorities with the aim to propose procedureswhich might be applied conveniently in the test facilities fulfilling the regulatoryrequirements.

The present document tries to specify more precisely the procedures to followin carrying out validations of computerised systems. It intends to give guidanceand help to test facilities and to promote a common standard to be used. Thepresent guidance document is preliminary and will depend on the experiencegained during the next few years and possibly on the interpretation of otherOECD Member countries. However, it is open to the test facility managementto use different approaches, as long as they are in compliance with the OECDconsensus document No.10. The extent of a validation may vary depending onthe complexity of the computerised system. In any case the validation shoulddemonstrate that the computerised system is suitable for its intended purpose.

2 INTRODUCTION

2.1 Regulatory BackgroundThe validation of computerised systems is required by the Swiss ordinance onGood Laboratory Practice which is in force since 1 March 2000. This Ordi-nance is based on the OECD Principles of Good Laboratory Practice, as revi-sed in 1997 and adopted November 26th, 1997 by decision of the OECDCouncil [C(97)186/Final].[1]A more detailed description of the application of the principles of GLP to com-puterised systems was already published in 1995 based on discussions at anOECD consensus workshop. It is basically in line with the new GLP principlesof OECD but has not yet been adapted until now. This GLP consensus docu-ment No.10 [2] - in addition to the above mentioned requirements - specifieswhat is needed for the operation of computerised systems in a GLP regulatedenvironment.

The present document is a preliminary interpretation of the OECD principlesregarding computerised systems and the corresponding consensus documentand has the status of a discussion paper between Swiss industry and Swissauthorities.

2.2 DefinitionThe OECD GLP Principles as well as the OECD Consensus document No.10define validation as “The demonstration that a computerised system is suitablefor its intended purpose.” The validation process provides a high degree of as-surance 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-


ance that a specific process will consistently produce a product meeting itspre-determined specifications and quality attributes”.

Thus, it is important to define the suitability for the intended purpose, and todefine specifications and quality attributes of the computerised system underconsideration before the system is developed or purchased. Therefore, thedocumentation of the user requirements and system specifications is essen-tial.

2.3 General PrinciplesThe GLP principles allow some flexibility in carrying out validations. For manyreasons it seems reasonable to conduct the validation formally in a similar wayas an experimental study. The GLP principles are quite precise with regard tothe specifications of study plan, conduct of a study, and reporting of study re-sults. Furthermore, they require the definition of responsibilities, the availabilityof standard operating procedures, and define the requirements for storage andretention of records. All these principles can conveniently be applied to thevalidation of computerised systems. Therefore, validations should be carriedout analogous to the performance of GLP studies. This should guaranteecompliance with the principles of GLP and facilitate the general understandingof the procedures by the involved parties.

In any case a validation has to be carried out at the users site with his localcomputerised system. A vendor-supplied validation performed at the vendor’ssite is not sufficient. However, in order to make use of synergies the same testplans, procedure descriptions or checklists may be used for validations at dif-ferent locations adapted to the specific situation.

2.4 Inventories (hardware, software, computerised systems)Inventories of hardware, software and computerised systems including ana-lytical instruments and measuring devices being used under GLP should beavailable and regularly up-dated. Furthermore, the architecture of the hard-ware and the network should be described.

2.5 Source CodeThe source code of application software should be accessible for at least 10years after the first use of the software at a test facility. It is not necessary thatit is available at the test facility, but the test facility has to ensure that the ven-dor of the software keeps the source code at a save place so that it is avail-able to GLP authorities if necessary.

2.6 CommitmentsThe user of software or computerised systems has to make sure that the sys-tem was developed according to a recognised quality standard. For vendor-supplied systems it is likely that much of the design and test documentationcreated 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 thetest facility.


3 COMPUTERISED SYSTEMS

“Computer systems can vary from a programmable analytical instrument, or apersonal computer to a laboratory information management system (LIMS) –with multiple functions. Whatever the scale of computer involvement, the GLPPrinciples should be applied.” (GLP Consensus Doc #10, Scope). Conse-quently, the aim of the validation remains the same for all systems, namely todemonstrate the suitability of the system for its intended purpose. However,depending on the complexity of a system the extent of testing and documenta-tion may differ.

3.1 SoftwareAccording to the complexity of the systems three types of software can be dif-ferentiated.

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 Ba-sic), ORACLE, SAS or Excel is supposed to be adequately validated based ona quality assurance system of the provider. Therefore, no further validationhas to be performed at the user’s site.

However, user applications written within or by means of these systems, suchas SAS procedures, ORACLE applications, Fortran or C programs, or Excelmacros should be validated. The extent of testing and documentation shouldbe based on an functional risk assessment. Individual spreadsheets need adocumented quality control.

Laboratory Information Management Systems (LIMS) should be fully validatedwith validation plan, test raw data and validation report as well as adequatesystem documentation. The extent of documentation can vary according to thecomplexity of the LIMS.

Table 1: Categories of Computerised Systems : Software

Category Definition Examples Validation

LIMS(LaboratoryInformationManagementSystems)

• Complex applica-tion/system

• Small amount of softwaredistribution

• Medium to large systems

• PATHDATA

• ARTEMIS

• PLACES

• SQL*LIMS etc.

• Validation plan

• Validation test raw data

• Validation report

• Full validation docu-mentation

Application

Software• Macros / Procedures

• Compiled or not compiledSoftware

• Limited complexity

• EXCEL macros

• SAS proce-dures

• Visual Basic orC programs etc

Extent of testing anddocumentation shouldbe based on a func-tional risk assessment

Industry Stan-dard

Software

• Widely distributed stan-dard software/ layeredsoftware

• Published quality or vali-dation status

• EXCEL

• ORACLE

• SAS

• Operation sys-tems (NT,VMS) etc.

• None

• Documented qualitycontrol for individualspreadsheets


3.2 EquipmentThe spectrum of instruments driven by software as well as instruments whichuse software for evaluation and calculation of data cover a wide range of usee.g. simple systems such as pH-meters and balances up to complex systemslike HPLC, MS and NMR. In many cases the computer is a major, integral partof the system which is dependent on the computer software to function. If thisis the case the system should be validated. As major differences between thedifferent apparatus exist it might be appropriate to build categories bearing inmind that each computerised system has to be assessed individually to dem-onstrate the suitability for its intended purpose.

The following classification is a first attempt to classify these systems and mayhave to be revised based on future practical experience. The three categoriesare characterised as follows:

Category: Complex

Complex computerised systems are characterised by the use of an extendedamount of functionality software and extended customisation. Typical exam-ples are Automated Sample Processing Systems, Liquid chromatograph (LC,HPLC) and Gas chromatograph (GC) incl. Autosampler and Detection Sys-tems, Spectrometer (UV, VIS IR, MS, NMR etc.), Radioactivity or Fluores-cence Monitor, Biological analyser, ECG, etc.

Prior to the first productive use the suitability of a complex computerisedsystem should be demonstrated for its intended purpose by carrying out a fullvalidation. A validation plan, test raw data, a validation report and full docu-mentation should be used as specified in this document. Further validationsmight be necessary after significant changes e.g. new hardware or software,exchange of important components of the system. In such a situation a func-tional risk assessment should be carried out taking into account the impact onthe computerised system. Based on this assessment the extent of an addi-tional validation to be performed should determined. The procedure should bedocumented and reasons for the decision should be given.

If a test facility puts several complex computerised systems of the same typeat the same time into operation it might be adequate to validate one of thesesystems on behalf of others. The suitability of the other computerised systemsshould be tested with appropriate suitability tests. In such a case a functionalrisk assessment should be carried out and documented justifying the excep-tional procedure. Such a procedure is only acceptable within a test facility at adefined site. The responsibility is with the test facility management.

After the first installation a system suitability test might be appropriate toguarantee a correct function of the system over a distinct period or during aseries of analyses. Results to be expected and acceptance criteria have to bespecified and recorded prior to carrying out the test. Test results should beevaluated and documented.

In case components of the system are exchanged and a full validation is con-sidered unnecessary adequate tests e.g. a system suitability test should becarried out based on a justified and documented functional risk assessment.Furthermore all components to be used should be described in an appropriatedocument e.g. in the raw data or logbook.


The frequency of testing, testing procedure, objective of the test procedureand the definition of acceptable deviations should be specified in a SOP. Thetest procedure should cover relevant hardware and software functions whichmay influence the intended purpose. In general the calibration procedureand/or the use of reference standards is part of the analysis and should be de-scribed 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 computerisedsystem over the whole live cycle. The logbook should also include or referencea detailed system description, a responsible person of the system, and a SOPfor 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, bal-ance, pH-meter a calibration procedure followed by a periodically performedfunction control might be adequate. Calibration and function control should bedocumented in a logbook. The calibration procedure, the function control andmaintenance process of the instrument should be described in a SOP.

Category: Exempted

Standard equipment such as calculators is considered well established with areliable history. Therefore validation is not needed. The same is true for in-struments as camera, microscope, water bath, rota vap.

Table 2: Categories of Computerised Systems : Equipment

Category Definition Examples Validation

Complex • Extended amountof functionalitysoftware

• Extended customi-sation

Automated Sample ProcessingSystems, Liquid chromato-graph (LC, HPLC) and Gaschromatograph (GC) incl.Autosampler and DetectionSystems, Spectrometer(UV,VIS,IR, MS,NMR etc.),Radioactivity or FluorescenceMonitor etc Biological ana-lyser, ECG etc.

• Validation plan

• Validation test rawdata


• Full validation docu-mentation

Simple • Small amount ofsoftware

• Limited customi-sation

Particle sizer, MicroplateCounter, Liquid ScintillationCounter, Image Analyser (X-Ray), pH-Meter, Balance, Re-corder for Temperature andHumidity, el. Pipette, Titrator,Refrigerator, Freezer, Pola-rimeter, Incubator, Autoclave,Tablet press, Reactor, SampleOxidizer, Microwave oven etc.

• SOP (operation)

• Function control(Calibration)

• Logbook

Exempted • Cannot be cali-brated

Calculator, Camera, Micro-scope, Water bath, Rota Vapetc.

• None


4 VALIDATION POLICY

According to OECD GLP Consensus document No. 10 there should be writtenmanagement policies, inter alia, for validation. This policy should regulate thewhole life cycle of a computerised system during development and its produc-tive use starting with the specification of user requirements and ending withthe retirement of the system. It is recommended that this policy covers anddefines all general validation aspects. In this way, the volume of the docu-mentation of an individual validation can be reduced.

It seems worthwhile to differentiate between validation policy and validationmaster plan. While a validation policy defines the general principles of valida-tion to be followed within a company, a validation master plan is dedicated to aparticular system describing the entire life cycle of the system from the point ofuser requirement definition up to system retirement. In this sense, the valida-tion master plan is the application of the validation policy to a particular sys-tem. The validation master plan can be perceived as an umbrella covering allaspects of the validation of a particular computerised system during the full lifecycle.

Depending on the complexity of a computerised system an adequate descrip-tion is necessary. For complex systems a validation policy/master plan de-scribing the whole life cycle might be necessary. An example is given in Ap-pendix 4.

5 RESPONSIBILITIES AND DOCUMENTS

The responsibilities for a validation are extensively described in the OECDGLP consensus document No. 10. The main responsibilities can be summa-rised as follows:

Management of the test facility has the overall responsibility for compliancewith the GLP Principles. In particular it has to establish procedures to ensurethat computerised systems are suitable for their intended purpose, and arevalidated, operated and maintained in accordance with the principles of GLP.

Study directors are responsible for the overall conduct of their studies andshould ensure that computerised systems used in their studies have beenvalidated.

Personnel are responsible for performing activities with computerised sys-tems in accordance with the GLP Principles and recognised technical stan-dards.

Quality Assurance (QA) responsibilities for computerised systems must bedefined by management and described in written policies and procedures. Itshould be assured that established standards are met for all phases of valida-tion.

The following table gives an overview of the responsibilities, the relevantdocuments of a validation and the persons who should sign the correspondingdocuments.


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 vali-dation according to GLP, checks according toapplication

IT Responsible 4) IT relevant checks, functioning of hardware andsoftware

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 thevalidation: Validation plan, validation report, in-spection

1) The whole life cycle should be described in an appropriate document e.g. policy, concept, masterplan and retirement report

2) To be treated analogous to amendments to the validation plan if not part of the validation plan3) Part of validation report4) if applicable


6 VALIDATION PLAN

The validation plan should provide documented evidence that the validationactivities for a specific system are carried out systematically and under man-agement control. Since the validation plan consists of many subdivisions andsub-documents it is important to keep the documentation concise and well in-dexed. Document titles as well as the headers of the documentation shouldclearly indicate the name and version of the software under validation.

The validation plan should be prepared and approved prior to conducting thevalidation tests.

As summarised in appendix 1 the following topics should be covered by thevalidation plan:

Purpose It should be defined how the project will produce a vali-dated computerised system which operates consistentlyand reliably and complies with all applicable regulatoryrequirements. It should be specified, whether this is thefirst validation of the system or a re-validation. This indi-cation is particularly true for a new version of the system.

Scope The scope of the validation plan should describe whichsystems are covered and what is the relation to otherconnected systems. The boundaries of the systemshould be defined so that it is clear what is and what isnot included as part of the system being validated. Fur-thermore it should be indicated where the system will belocated.

System description The system description is to provide an introduction tothe system showing what the system is supposed to doand in which environment it will be employed. The mainsystem functions should be specified.

Responsibilities The responsibilities for validation related activities asso-ciated with the system should be defined. The organisa-tion of the people associated with the system, responsi-ble for development, validation, use and maintenance,quality assurance should be defined. For details see ta-ble 3.

Test environment The system must be summarised in terms of hardwareand software components. Hardware and Software com-ponents should be specified for the test and productionenvironment including

Hardware: supplier, model, serial number, components,network, and location

Software : supplier, name, version, source code, and lo-cation.

Validation method It should be specified whether it is a process or data vali-dation, whether “black box” or “white box” testing meth-


ods will be applied. The procedure should be describedas necessary. The basis for the tests should be givene.g. specific user requirements or a user manual.

Functional Risk A validation of a computerised system should be basedAssessment 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. Theextent of documentation to be produced may be minimalor extensive based on necessity, usefulness and repro-ducibility. The category of the computerised system(software or equipment) should be taken into considera-tion.

Tests Test cases should principally be based on the user re-quirement specifications. Furthermore, the functional riskassessment should be considered, wherein system func-tions have been individually analysed for the likelihoodand consequences of failure. Functions deemed “highrisk” must be challenged thoroughly, including testing ofboundary values and invalid inputs. Relevant real as wellas extreme challenges of the system should be selected.The expected results as well as the acceptance criteriahave to be defined in the test plan. The details of errorlogging should be specified as well as the procedure fordocumentation of the test results; for instance, screendumps,logfiles,printouts,etc.Since the test results (raw data) need to be signed anddated, there must be a record which equates any signa-tures, initials, or other marks which appear on the testrecord with printed identification of the persons involved.

Schedule Approximate start and end dates of the test phase haveto be specified.

Procedure Guidance should be provided for the conduct of the tests,the evaluation of the results as well as the contents ofthe report, if not already defined in the validation policy.

Documentation An index of all documentation relating to the computer-ised system, including but not limited to SOPs, user de-veloped documentation, and vendor/provider developeddocumentation should be provided. For details seechapter 8 and appendix 3.

Archiving A list of records to be retained should be given.


7 VALIDATION REPORT

The validation report summarises the results of acceptance testing and pres-ents a conclusion that all requirements of the validation guidelines have beenaddressed. The execution of the planned activities, the results obtained anddeviations 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

starting and completion dates of validation (plan/report)

• Procedure

• Results of tests

Expected results and acceptance criteria should be recorded in advance ofstarting the test usually in the validation plan or amendments. Results ob-tained should be documented as well as deviations from expected results,if appropriate with comments.

• The results of the tests should be evaluated and discussed. Recommenda-tions should be given, in particular whether the application can be re-leased.

• GLP compliance statement, Quality assurance statement

• Archiving: The location where the documents will be archived should bementioned.

The validation director is responsible for the GLP compliant conduct of thevalidation; thus, he will sign the GLP compliance statement. The Quality as-surance unit (QAU) should audit the validation plan, raw data, and report; con-sequently, the QAU has to prepare and sign the QA statement. Managementis 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 ap-pendix 2, responsibilities are shown in table 3.


8 DOCUMENTATION

A full validation package consists of a number of individual documents speci-fying 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 thesystem. The extent of documentation has to be established for each individualcase.

Three types of documentation may be differentiated:

8.1 Basic GLP DocumentationBasic documentation is independent of the individual application software un-der validation and contains the training record, job description, and CV of theusers of the system. Furthermore, there should be an inventory of all comput-erised systems being used in the facility including information about systemowner, location, validation status, etc.

8.2 Standard Operating ProceduresThe OECD consensus document #10 requires a set of standard operatingprocedures for the development and/or routine use of validated computerisedsystems; they include SOPs for

Operation

In addition to the User’s Manual, this SOP describes how the applica-tion will be used in a particular laboratory. When the user has the op-portunity to customise a system for his particular needs, this has to bespecified. Furthermore, the SOP will contain information on who is thesystem administrator, and it will reference other pertinent SOPs to befollowed when using the system.

Security

Three levels of security must be addressed: physical security of thesystem [server(s) and workstation(s)]; logical access to the application;and logical access to the operating system including access to data andprogram files for the application.

Change Control

Effective change management is the single most important factor inmaintaining a validate state for a production system. All forms ofchange must be tracked and managed. This will always include appli-cation software updates, operating system updates, and changes to thehardware running the application. Depending upon the type of systembeing validated, this may include changes to the network or modificationto a qualified workstation. Every change, no matter how minor, must beevaluated for its potential impact on the validated application as definedin a change control SOP.


Back-up and Restore

The SOP specifies the procedures for back-up of the application andthe data files. The SOP must describe frequency, period of retention forback-up copies, the method and responsibility for periodic back-up, andthe process of restoration.

Maintenance and Problem Log

Measures used to record and archive all reported problems and main-tenance activities with the system should be defined in a SOP. Theminimum content of such a log should include the problem, date theproblem occurred, action taken, who performed the action, the date theaction was carried out, and reference to relevant change managementdocumentation.

Monitoring and Auditing

The system needs to be monitored regularly for correct operation in-cluding device checks, if appropriate. Attempts of unauthorised accessto the system should be monitored, and reported to the system owner.

Periodic Testing

Functionality testing should be performed on a regular basis (e.g. byrunning automated test scripts).

Software Development

If software is developed by the user or an internal IT group there shouldbe a SOP defining standards for software design, coding and testing.Important is the method of version control. The SOP should refer to acommonly acknowledged software development life cycle model.

Contingency Plan and Disaster Recovery

A contingency plan should specify manual procedures to be followed incase of system breakdown or failure. A detailed plan for disaster recov-ery should be available. Tests should be carried out and results thereofshould 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 shouldbe specified. The archival and retrieval procedures should be testedand the results documented. The SOP should also address the issue ofreadability over the entire retention period.

Quality Assurance

The SOP specifies the procedures how QA will audit the validation pro-cess and the IT-infrastructure in a GLP-regulated environment.

Apart from the SOP on operation of a system, these SOPs may be as genericas possible; i.e. they must not be written for each application separately.


8.3 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 tosolve a problem or achieve an objective.

Application Description

The application description describes the purpose and scope of the ap-plication and specifies the functionality of the system in business terms.

System Description

The system description is a technical document describing the technicalfeatures 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 thesystem is installed. In addition, it defines the minimum hardware andoperating 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 informa-tion upon changes and enhancements of the software compared to aprevious 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 informa-tion 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


9 ARCHIVING

The archiving of the validation package (documents listed in chapter 8) shouldbe analogous to the archiving of documents of GLP studies. The documents tobe used, in particular the SOPs, should be referenced. The main documentsto be archived are

• Validation plan

• Raw data


• GLP compliance statement and QA statement

• SOPs

• Recordings of QAU

The documents to be archived have to be indicated in the validation plan. Inthe validation report the location where and in which format (paper or elec-tronically) these documents will be stored should be indicated.

Adequate facilities should be provided for the secure retention of electronicstorage media. Exposure to extreme temperature and humidity, dust, electro-magnetic interference and the proximity to high voltage cables should beavoided.

When documentation is held electronically it is necessary to provide for longterm retention. Continued access to the information has to be guaranteed alsoin case of hardware or software system changes, and it should be assuredthat the electronic documentation is available in a human-readable format.

10 RETROSPECTIVE EVALUATION

According to OECD consensus document No.10 a retrospective evaluation toassess the suitability of a system should be carried out for systems where theneed for compliance with GLP Principles was not foreseen or not specified.Retrospective evaluation begins with gathering all historical records related tothe computerised system. These records are then reviewed and a writtensummary is produced. This retrospective evaluation summary should specifywhat validation evidence is available and what needs to be done in the futureto ensure the suitability of the system for its intended purpose.

According to [3] the report on the retrospective evaluation should include in-formation on the degree of stability and maturity of the system as well as theachievement of the user requirements. In particular the following questionsshould be answered:

• At what time, from whom and with which tools was the system taken intooperation ?

• 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) ?


• 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 man-aged ?

Furthermore a collection of the available documentation on the system shouldbe put together as completely as possible. In particular a description of thesystem, system specifications, manuals for system managers and users andthe availability of the source code should be specified. The quality and com-pleteness of the documentation should be assessed.

Based on the available documentation a functional risk assessment should becarried out to determine whether the available information is sufficient to en-sure the suitability of the system for its intended purpose or whether tests or avalidation is necessary. The tests or the validation should be elaborated andperformed as described in this document. Reasons for the selected procedureshould be given. The retrospective evaluation, the results of the functional riskassessment and the measures taken should be recorded.


11 GLOSSARY

Term Definition Ref.

Acceptancecriteria

The documented criteria that should be met to successfullycomplete a test phase or to meet delivery requirements.

OECD# 10

Acceptancetesting

Formal testing of a computerised system in its anticipatedoperating environment to determine whether all acceptancecriteria of the test facility have been met and whether thesystem is acceptable for operational use.

OECD# 10

ANSI American National Standards Institute

Calibration Demonstration that a particular measuring device producesresults within specified limits by comparison with those pro-duced by a reference standard device over an appropriaterange of measurements. This process results in correctionsthat may be applied to optimise accuracy.

GAMP[6]PMACSVC

ComputerisedSystem

A group of hardware components and associated softwaredesigned and assembled to perform a specific function orgroup of functions.

OECD# 10

GAMP Good Automated Manufacturing Practice

GLP Good Laboratory Practice

ISO International Organisation for Standardisation

ISO 9000-3 Quality management and quality assurance standards –Part 3: Guidelines for the application of ISO 9001 to the de-velopment, supply and maintenance of software.

IEEE Institute of Electrical and Electronic Engineers

IT Information Technology

LIMS Laboratory Information Management System

NIST National Institute for Standards and Technology FDA [4]

PMA CSVC Pharmaceutical Manufacturers Association:Computer Systems Validation Committee

QualificationInstallation

Establishing confidence that process equipment and ancil-lary systems are compliant with appropriate codes and ap-proved design intentions, and that manufacturer's recom-mendations are suitably considered.

FDA [4]


QualificationOperational

Establishing confidence that process equipment and sub-systems are capable of consistently operating within estab-lished limits and tolerances.

FDA [4]

QualificationProcess Per-formance

Establishing confidence that the process is effective andreproducible.

FDA [4]

QualificationProduct Per-formance

Establishing confidence through appropriate testing that thefinished product produced by a specified process meets allrelease requirements for functionality and safety.

FDA [4]

QA Quality Assurance

QAU Quality Assurance Unit

Raw data All original test facility records and documentation, or veri-fied copies thereof, which are the result of the original ob-servations and activities in a study. Raw data also may in-clude, for example, photographs, microfilm or microfichecopies, computer readable media, dictated observations,recorded data from automated instruments, or any otherdata storage medium that has been recognised as capableof providing secure storage of information for a time periodof 10 years.

OECD# 1

SDLC System Development Life Cycle

SOP Standard Operating ProcedureDocumented procedures which describe how to performtests or activities normally not specified in detail in studyplans or test guidelines.

OECD# 1

Source Code An original computer program expressed in human-readableform (programming language) which must be translated intomachine-readable form before it can be executed by thecomputer.

OECD# 10

System People, machines, and methods organised to accomplish aset of specific functions.

ANSI

Systemlife cycle -Softwarelife cycle

Period of time beginning when a software product is con-ceived and ending when the product is no longer availablefor use. The software life cycle is typically broken intophases denoting activities such as requirements, design,programming, testing, installation, and operation and main-tenance. Contrast with software development process.

NIST

System Suit-ability Test

A process of checking out the performance specifications ofa system.

Huber[5]


Test An activity in which a system or component is executed un-der specified conditions, the results are observed or re-corded and an evaluation is made of some aspect of thesystem or component.

IEEE

Test plan Documentation specifying the scope, approach, resources,and schedule of intended testing activities. It identifies testitems, the features to be tested, the testing tasks, responsi-bilities, required, resources, and any risks requiring contin-gency planning.

IEEE

Validation The demonstration that a computerised system is suitablefor its intended purpose.Establishing documented evidence which provides a highdegree of assurance that a specific process will consistentlyproduce a product meeting its pre-determined specificationsand quality attributes.

OECD#10

FDA [4]

Validation plan Written plan stating how validation will be conducted, in-cluding test parameters, product characteristics, productionequipment, and decision points on what constitutes accept-able test results.

Huber[5]

Verification Confirmation by examination and provision of evidence thatspecified requirements have been met.

Huber[5]

For more detailed information please refer to our GLP home page www.glp.admin.ch.


12 REFERENCES

[1] OECD Series on Principles of Good Laboratory Practice and Compliance Moni-toring 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 Moni-toring No. 10: GLP Consensus Document. The Application of the Principles ofGLP to Computerised Systems. Environment Monograph No. 116; EnvironmentDirectorate, OECD, Paris, 1995

[3] Einsatz computergestützter Systeme bei GLP-Prüfungen; Vorschläge der Pro-jektgruppe GLP und EDV des Arbeitskreises GLP im Verband der ChemischenIndustrie e.V.: Pharm. Ind. 59, 1, 24 – 29 . 2, 116-120 (1997)

[4] USA Food and Drug Administration (FDA): Glossary of computerised system andsoftware development terminology;http://www.fda.gov/ora/inspect_ref/igs/gloss.html

[5] Ludwig Huber : http://www.labcompliance.com/ search : glossary

[6] Good Automated Manufacturing Practice Forum (GAMP Forum): glossary;GAMP Supplier Guide Version 2.0 (1996): Pharmaceutical Industry SupplierGuide for Validation of Automated Systems in Pharmaceutical Manufacture


Appendix 1: VALIDATION PLAN

PURPOSE

SCOPE System, application area

SYSTEM DESCRIPTION Production environment

RESPONSIBILITIES Test facility management,System owner, IT responsible,Validation director, Validationteam, QA

TEST ENVIRONMENT Hardware (model), Software (ver-sion), Network, Test location

VALIDATION METHOD Process or data validation, testsagainst user requirements oruser manual

TESTS Test cases/scriptTest data (real, stress)Acceptance criteria

SCHEDULE Start and end date of test phase

PROCEDURE Conduct of testsEvaluationReport

DOCUMENTATION

ARCHIVING


Appendix 2: VALIDATION REPORT

SUMMARY

PURPOSE *

SCOPE *

SYSTEM DESCRIPTION *

DOCUMENTS, SOPS *

FACILITIES, PERSONNEL, RESPONSIBILITIES *

DATES Effective start and end datesof test phase

PROCEDURE

RESULTS OF TESTS • Expected results• Acceptance criteria• Results obtained• Deviations from expected re-

sults• Comments

EVALUATION / DISCUSSION / RECOMMENDATION

QA AND GLP STATEMENT

ARCHIVING

* Information already indicated in the validation plan


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


Appendix 4: General Principles of Validation

System Development Life CycleThe V-model shown in figure 1 below gives an overview on the differentphases during a system development life cycle.

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 ofdoing some specific tasks; e.g. measuring the plasma concentration of drugswithin a given sensitivity range. The user compiles formally all his/her require-ments in a document called User Requirements; it is part of the design quali-fication. These user requirements contain scientific and business, regulatory,safety, performance and quality requirements. It is of paramount importance torealise that the user requirements serve as the basis for the user acceptancetest, sometimes also referred to as performance qualification. The aim ofthe user acceptance test is to demonstrate that a computerised system is suit-able for its intended purpose in the user’s own environment.

The next level concerns the functional specifications of the computerised sys-tem. In case of a new development, the developer translates the user re-quirements into functional specifications. However, if the user prefers to pur-chase an off-the-shelf product, the functional specifications can be obtained

User Requirements

Module Design

System Design

FunctionalSpecification

Code

Module Test

Integration Test(Installation Qualification)

System Test(Operational Qualification)

Acceptance Test(Performance Qualification)

AcceptanceTest Plan

System Test Plan

IntegrationTest Plan

UnitTest Plan

Use

r

Sof

twar

e D

evel

oper

Use

r

Sof

twar

e D

evel

oper


from the User’s Manual; i.e. the user has to compare the offered functions ofthe product with his/her user requirements and determine whether the productcould in principal fulfil his needs with the given functionality. The functionalspecifications and the functional risk assessment serve as the basis for thesystem test, also referred to as operational qualification. The aim of thesystem test is to demonstrate that all functions needed for the intended pur-pose 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 arespecified. The system integration test (or installation qualification) buildsupon the system design specification. It shows that the system was properlyinstalled in the user’s environment and that all components are operative.

Module design, module testing and coding of the individual modules is in theresponsibility of the developer. Thus, the user is not directly involved, but (s)hehas to ensure e.g. by a vendor audit that the software is developed accordingto commonly accepted development standards (e.g. ISO 9000-3, IEEE).

The System Life-Cycle at the User’s siteAt the user’s site, the system passes also through a life-cycle which is detailedin figure 2.

Again, the life-cycle starts with the definition of user requirement for a particu-lar system. The system would then either be developed according to figure 1or purchased.

UserRequirements

Sof

twar

eV

ersi

on 1

.0

ValidationVers. 1.0 Vers. 1.0 in Production

Full SystemDocumentationValidation Plan - ReportManualsSOPsetc.

ChangeRequests

Sof

twar

eV

ersi

on 2

.0

ValidationVers. 2.0 Vers. 2.0 in Production

AdditionalSystem Docu-mentationValidation Plan - ReportNew Manualsupdated SOPs

TechnicalEnhancement

Proposals

RetirementRequest

GLP Archive

Retirement- Plan- Report

Sof

twar

eV

ersi

on 2

.0

Documents & Raw Data

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 andall documentation about the system, its operation and maintenance would becompiled in a validation package. If the validation passes all acceptance crite-ria, management would release the system Version 1.0 to production. Whileworking productively with a system, it commonly happens that the users haveadditional requirements for the improvement of the system which they forwardto the system developer in the form of change requests. In addition, develop-ers usually want to keep their system technically up-to-date; i.e. there are alsochange requests from their site. By implementing these system change (againaccording to figure 1), a new version 2.0 of the system emerges that will be


shipped to the user. Depending on the extent of changes of the system eithera 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. Thiscycle of change requests, implementation of changes, validation, release toproduction 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 ob-solete – system and to purchase a new one. The end of the system life-cycleis the retirement of the system according to a formal retirement plan. The en-tire system documentation has to be archived, also the electronic raw data andthe software code.

According to the GLP principles it is imperative that the system - as long as itis in productive use - has to be maintained in a validated state throughout thewhole system life-cycle.


Working Group Information Technology (AGIT)

Working Group Information Technology (AGIT) was founded 27 March 1998 with theobjective to discuss relevant problems of Good Laboratory Practice (GLP) in the fieldof information technology and exchange experience between industry and monitoringauthorities. Furthermore it is intended to support test facilities in solving problemswhile applying information technology in practice. As basis for the discussions OECDConsensus Document number 10 on the application of the principles of GLP to com-puterised systems is used.

Members of AGIT are representatives from the Swiss GLP monitoring authorities(Olivier Depallens, Federal Office of Public Health; Hansruedi Hartmann, Intercanto-nal Office for the Control of Medicines; Hans Peter Saxer, Swiss Agency for the Envi-ronment, Forests, and Landscape) as well as representatives from industry (BrunoEschbach, Novartis Pharma; Peter Grass, Novartis Pharma; Stephan Hassler, No-vartis Crop Protection; Heinrich Urwyler, F.Hoffmann-La Roche).

The cooperation started with a stock-taking followed by priority setting. Performingvalidations in practice and use of electronic records and signatures according to theguideline of US FDA were selected as main topics. Both turned out to be tricky andtherefore involve extensive discussions.

The present paper intends to give support to perform validations of computerisedsystems in practice. Based on experience gained during practical application it mightbe necessary to amend the current version.

Attempts to interpret rule 11 of US FDA (21 CFR Part 11) concentrate on the impacton future documentation of raw data, the difference between electronic signaturesand electronic visa as well as the management of electronic signatures. Currentlyavailable software for the use of electronic signatures helps to simulate the applica-tion in practice.

Establishing and managing electronic Standard Operating Procedures (SOPs) andarchiving electronic raw data are further topics of main interest.

Internet Home Page „www.glp.admin.ch“ guarantees speedy access to recent infor-mation for users. Finalised documents of AGIT will be made available as well as linksand references to guidelines, laws and regulations, definitions, relevant literature,training courses, workshops etc.