GlaxoSmithKline-Computer System Validation Guideline

GlaxoSmithKlineGLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 RATIONALE Computerised systems are increasingly being implemented to realise operational benefits within manufacturing working environments. It is essential that there are controls in place to ensure such systems are validated as fit for purpose. PURPOSE To provide guidance when implementing GQP 1205 Computerised System Validation. To provide specific additional guidance on the approach to validating different types of computerised systems. SCOPE This guideline applies to all sites and companies manufacturing, distributing or marketing materials, products or devices for use or sale by, or for, GSK. This guideline applies to computerised systems that are used in support of those agency regulated manufacturing of pharmaceutical, biologic/biopharmaceutical, and healthcare products requiring computer validation. Agency regulations include but are not limited to: • Adverse Event Reporting. • Electronic Records and Electronic Signatures (ERES). • Good Distribution Practices (GDP). • Good Laboratory Practices (GLP). • Good Manufacturing Practices (GMP). Throughout this guideline GDP, GLP and GMP and are collectively referred to as GxP. Page 1 of 104 GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 SUMMARY OF REVISIONS This replaces GQG 1205 dated October 2001, with the following revisions: • The Scope has been extended to introduce the use of GxP throughout the rest of the guideline. • The section on System Registers has been updated to include reference to GQG 3202. • The section on Prospective Validation has been updated. The subsection on Compliance Assessments has been extended to include guidance on Commercial off-the-Shelf (COTS) products. The subsection on Validation Planning has been extended to include GxP Risk Management. The subsection on Supplier Assessments has been revised to improve grammar. A subsection on the Requirements Traceability Matrix has been added. The subsection on Operational and Support Plans has been updated to include reference to GQG 3203 and GQG 3301. The subsection on Use has been extended to include a subsection on Service Level Agreements. The subsection on Archive and Decommissioning has been renamed Decommissioning. • The section on Retrospective Validation has been revised to improve grammar. • The section on Approach to Laboratory Systems has been revised to improve guidance on System Registers and Special Considerations for Simple COTS Firmware Instrumentation. • The section on Approach to Control Systems has been revised to improve guidance on System Registers, and use of off-line simulation to support Operational Qualification. • The section on Approach to Desktop Applications has been revised to improve guidance on Compliance Assessments and System Registers. • The section on Approach to IT Systems has been revised to include Distribution Systems within Scope of Systems Covered and Examples of System Categorisation. Requirements for Compliance Assessments have been clarified. • A section has been added on Approach to Centrally Developed/Supported Systems. • A section has been added on Approach to Medical Devices. • The section on Inspection Readiness has been revised to improve guidance on Documentation. • The Bibliography has been updated to reflect the latest edition of the good automated manufacturing practice (GAMP) and PIC/S guidance on regulated GxP applications. Page 2 of 104 GlaxoSmithKline Management: Management Systems COMPUTERISED SYSTEM VALIDATION GLOBAL QUALITY GUIDELINE 1205 JUNE 2002 CONTENTS 1. Introduction ................................................................................................................. 6 2. Responsibilities .......................................................................................................... 7 2.1. Senior Management................................................................................................ 7 2.2. System Owner/User Role........................................................................................ 7 2.3. Project Manager...................................................................................................... 7 2.4. Developer/Technical Role ....................................................................................... 8 2.5. Support/Maintenance Role...................................................................................... 8 2.6. QA/Validation Role.................................................................................................. 8 3. Site/Function Activities .............................................................................................. 9 3.1. Validation Master Plans .......................................................................................... 9 3.2. System Register...................................................................................................... 9 4. Prospective Validation.............................................................................................. 11 4.1. Planning Phase ..................................................................................................... 12 4.2. Supplier Assessment Phase ................................................................................. 13 4.3. Requirements Phase............................................................................................. 14 4.4. Design and Code Phase ....................................................................................... 14 4.5. Development Testing Phase ................................................................................. 20 4.6. Deployment Phase................................................................................................ 23 4.7. Use Phase ............................................................................................................ 28 4.8. Decommissioning Phase....................................................................................... 30 4.9. Cross Phase Activities .......................................................................................... 31 5. Retrospective Validation .......................................................................................... 32 5.1. Gap Analysis ......................................................................................................... 33 5.2. Priorities ................................................................................................................ 33 5.3. Interim Measures .................................................................................................. 34 6. Managing Hardware and Software........................................................................... 36 6.1. Hardware Categories ............................................................................................ 36 6.2. Software Categories.............................................................................................. 37 Page 3 of 104 ....................... 51 8.......................................................2........ Approach to Laboratory Systems..............3....................... Scope of Systems Covered... 49 8............................................................. Examples of System Categorisation ....... Approach to Control Systems.6...................................................... 43 7........ 90 11.....................................6.......... 51 8............................... Responsibilities .......................................................................4..... 63 9.................................. Scope of Applications Covered ................................ Responsibilities .. 89 11...........2........ 42 7............... Definition of Desktop Applications....................................................... 90 11................ System Register......................................... 50 8............................. 44 7......... Systems Register .................6................................................................................................................................. 61 9..........1......... 76 10.......................................................................... Approach to Desktop Applications ........... 75 10.....................5....................................................... 76 10.................... Scope of Systems Covered.......4................................................... 76 10.... Validation Life-Cycle ....................................................4... Controls for IT Infrastructure .................2........................................................................................................ Examples of System Categorisation ............. Laboratory Systems Definition .........2.............................................................. 75 10...1..........2......................... Scope of Systems Covered.............. 64 9.............. Definition of IT Infrastructure ..................... 51 8........................................................... Responsibilities ............ 74 10.............................................................1...................... 43 7...........................................1........5................................................................................ Definition of a Control System................................................... Validation Life-Cycle ......................3......................................... Definition of IT Systems ..............4... Examples of System Categorisation .................................................................................... Approach to IT Systems .......................................GlaxoSmithKline Management: Management Systems COMPUTERISED SYSTEM VALIDATION GLOBAL QUALITY GUIDELINE 1205 JUNE 2002 7.......... 62 9...................... Validation Life-Cycle ...............................6....................... 64 9..................................... Approach to IT Infrastructure ....................................................................................................................5............................................................... 42 7................ 62 9...................3............... 49 8...............1........................................ Validation Life-Cycle ..... 90 Page 4 of 104 ..........................3..........5.................... 44 7................................................................................ 62 9........... Systems Register .............. Responsibilities ........ System Register................ Examples of System Categorisation ............................................................................................................... 49 8.......................... 75 10. .................................................................................... Responsibilities ......... 100 14.... Inspection Readiness ................ 101 15........................ Responsibilities ............................................2..........4..........1........ Validation Plans/Reports and Reviews ...... System Registers .....................................4...........6..11.... 103 15.................................................... 95 13....... Validation Requirements ................. Definition ...................................................1................................................................................................... Systems Register ........ 97 13.......................................... 97 13....... 101 15............ 97 13........................... High Level Site Mapping of Key Computerised Systems .. Definition of a Software Tool .................. Scope of Tools Covered..................4......................................................................................................................................GlaxoSmithKline Management: Management Systems COMPUTERISED SYSTEM VALIDATION GLOBAL QUALITY GUIDELINE 1205 JUNE 2002 12................5.2..................................................................................................................................................................................................... 101 15........ Definition of Inspection Readiness .............. 94 12................ Organisation Charts .............................. Documentation ............................................ 104 Page 5 of 104 ......................... 100 15.............. 102 15......................12........................................................................................ 102 15.................................... Mock Inspections ........................... 103 15............................................................................ System Register.................................8.............3.................... Inspection Management............................. 103 16....... 101 15...9.......... 102 15. 103 15............10..................................................................... 101 15.........................7.......................................................... Internal Audit Program ........................................ Scope..................................................................................................................2................. 99 13....... Approach to Software Tools ................................................................................................... 95 12. Approach to Centrally Developed/Supported Systems .......... 99 13.......................... Use of Trained Personnel ................................................ 94 12.............................. Presentation .....5..................... System/Project Overviews ............ 94 12............................................................................................................................. 94 12.......3...................3... Validation Life Cycle............5. Approach to Medical Devices ........................ Bibliography ....................................................... 101 15..........1.................. Reports and sub-systems should not be considered computerised systems in their own right. Examples of computerised systems include: laboratory systems. and IT infrastructure. IT systems. This guideline applies predominately to the introduction of new systems where it is possible to build in validation requirements at each stage in the life of a computerised system. This guideline is not intended to cover safety or environmental protection requirements. process control systems. desktop applications. • Expectations regarding the application of the general life-cycle methodology to different types of computerised systems (laboratory systems. • A general life-cycle methodology for computerised systems validation. and employ quality practices known to minimise errors. and hardware platform collectively providing functionality to a user or other computer system. Validation does not end with implementation of computerised systems. A section is also included on retrospective validation describing where this is appropriate and the basic approach to be adopted. data. • Guidance on appropriate use of terminology. desktop applications (end-user computing). and software tools). control systems. Page 6 of 104 .GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1. Guidance includes: • How to establish whether or not a computerised system requires validation. IT systems. IT infrastructure. • Advice on inspection readiness for computerised systems. from requirements definition to decommissioning. Validation activities encompass the entire life of the computerised system. An effective strategy may be to include such requirements within the scope of validation rather than as a separate exercise. • Guidance on roles and responsibilities. but includes maintaining computerised systems in a validated state and using computerised systems in a compliant manner. however these should be considered concurrently with the validation process. 1205 JUNE 2002 Introduction Computerised systems for the purpose of this guideline are considered as consisting of application software. GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 2. acceptance and use of a computerised system. laboratory technicians.2. provision. controls engineers. The senior management role is usually conducted in conjunction with QA. 1205 JUNE 2002 Responsibilities It is the responsibility of the personnel associated with computerised systems to ensure that they understand the requirements of GQP 1205 and comply with it. • Providing adequate resources. Project Manager Responsible for: • Ensuring that validation activities associated with any aspect of the development. implementation and handover to the user of a computerised system are conducted in accordance with agreed plans. Page 7 of 104 . IT.1. • The integration of the computerised system with existing processes. Senior Management Responsible for: 2. This guideline should be used by individual sites/departments as appropriate to prepare their own local procedures. • Final authorisation of the validated system for use. • Ensuring that appropriate user procedures are in place. • Ensuring that the system is validated and used in a compliant manner. Emphasis between roles will vary depending on the nature of the work being conducted. Local user. System Owner/User Role Responsible for: 2. • Validation activities associated with any aspect of the requirements definition.3. • Ensuring that system end users/operators are trained. 2. infrastructure and ways of working. and QA are expected to take an active role. • Defining the system requirements. Validation and regulatory compliance is the responsibility of each site/department and should be incorporated into their quality planning. 4. • Conducting compliance audits on the implementation of GQP 1205 in support of 'regulated' computerised systems. • The technical implementation and delivery of the computerised system including preparing test documentation. QA/Validation Role Responsible for: • Preparing and approval of validation plans and of associated validation reports.6. • Ensuring that appropriate support and maintenance procedures are in place.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 2. Page 8 of 104 . • All technical aspects of the system development and validation including preparing specification and design documentation. qualification plans/reports. • Provide GxP and regulatory input into validation projects with particular focus on product quality impact. change control records. • Providing key validation activities and approvals as defined in validation plans such as supplier audits. Support/Maintenance Role Responsible for: 2.5. • Authorising validated computerised systems as fit for purpose. 1205 JUNE 2002 Developer/Technical Role Responsible for: 2. and configuration management. conduct testing. etc. • All technical aspects of the system support and maintenance whilst the system is in use including documentation not covered by QA/Validation. validation not required). • System type (indicate. identifying validation requirements for both new and legacy computerised systems. Note: Sub-systems and systems components should not be listed in the system register. providing an inventory of computerised systems should be created and maintained for each site or company. and electronic signatures (ERES) status The basic attribute list is not exhaustive and may be extended as appropriate to meet specific site needs.1. or a corporate system). • Electronic records (see GQG 3202). Each register should contain. e. validation in progress.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 3. • Regulatory submissions use (whether used for regulatory purposes other than GxP) (Yes/No). Advice for centrally developed/supported systems can be found in Section 12. whether this is a local system. • Validation status (whether it meets current computer validation requirements) (validated. 3. • Reference to validation support and documentation index/archive location. the following information for each system listed: • Name (by which the system is known and commonly referred to).2. 1205 JUNE 2002 Site/Function Activities 3. Plans should be produced in association with system registers. • Unique reference/acronym (for traceability). • GxP/regulated determination (whether it is GxP/regulated system) (Yes/No). as a minimum. not validated.g. Validation Master Plans Computerised systems requiring validation should be identified as such in site/function validation master plans (VMP) (see Section 14 and GQP 1204). • System description (phrase/sentence describing what the system does). a system that is supported by another site. System Register System registers. The system register should cover all Page 9 of 104 . Page 10 of 104 . Instruments SCADA System A separate entry is required for each physical system of the same type. Database applications including Lotus Notes. Sites may wish to consider including a document archive reference to facilitate faster document retrieval.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 manufacturing. Some sites may wish to include names of contacts (e. Mass Balance HPLC FTIR Chromatography Data System Robotic Systems Process Control Intelligent/Smart PLCs One entry per system. developer. system support. user and validation) that could present information concerning the computerised system during an inspection. Distributed Control Systems Expert Control Systems Desktop Applications IT System (User) One entry per spreadsheet/database applications. pH Meter Ultrasonic Bath A separate entry is required for each physical system of the same type. SAP R/3 BPCS LIMS Care must be taken to ensure sites understand which multi-site systems they use. packaging and distribution computerised systems. Table 1 Approach To System Register Contents Type of System System Register Guidance Examples Laboratory System One entry per system.g. GxP One entry per production system instance. Spreadsheet applications. For example.GlaxoSmithKline Management: Management Systems COMPUTERISED SYSTEM VALIDATION GLOBAL QUALITY GUIDELINE 1205 JUNE 2002 Guidance on which systems require registration on the system register is given in Table 1.g. Standard COTS packages should not be registered separately from their application (e. Written dispensation may be given to individual functions/departments excluding them from the scope of the system register where they have no computerised systems within the scope of GQP 1205. and hand-over issues such as advance knowledge of operation and support requirements. MS Word. A description of each phase of the life-cycle validation activities is presented below as a sequential process. however certain activities may overlap or be combined. In practice in can be impossible to validate existing systems where initial design requirements are no longer available or appropriate activities were not performed or documented as the system was designed and implemented. Excel. Guidance on which systems require registration and how to record them on the system register is provided in the section of this guideline dealing with desktop applications. The validation plan should define such overlaps and amalgamations. and Oracle should not be registered. The validation life-cycle activities and their order should be documented in a validation plan. In some situations there may be large numbers of computer applications that do not require validation and the practicalities and value of listing them on the system register might be questioned. The following sections describe the validation activities appropriate to a new system. Examples include procurement (supplier capability). these life-cycle requirements should be considered when attempting retrospective validation of existing systems. All validation activities should be carried out in a safe and secure manner. NT. observing local safety procedures and requirements. Prospective Validation Validation of computerised systems requires careful planning to identify the set of validation activities required from initial design through to implementation use and final decommissioning. The system register may consist of a number of lists so long as collectively they cover all computerised systems. regulatory expectations for electronic records/signatures. However. Page 11 of 104 . Operating systems such as Unix. A number of key issues should be addressed as soon as reasonably practical. MS Project. user security. 4. data integrity. spreadsheet applications are used widely but typically only a small fraction is used in a GxP context. MS Access) as their use will be captured as part of the application using them. The emphasis is on the required functions and not the method of implementation and should therefore not be product specific. desktop (end-user) applications. Validation plans should take account of the different software categories comprising a computerised system and the mix of GxP Page 12 of 104 . The application of the life-cycle will vary as appropriate to the type of computerised system being validated. therefore. Compliance Assessment All computerised systems should be assessed during the early planning phase to determine if there is a GxP impact and. control systems. Validation Planning The validation plan is a document (or group of documents) stating the standards and the methods employed to maintain quality through the system life-cycle and to establish the adequacy of performance of the computerised system. The approved business requirements should provide sufficient information for the compliance assessment and system selection activities to be completed. whether the system should be validated or not. The compliance assessment should be approved by QA/Validation.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 For the purpose of this guideline the following generic validation life-cycle is presented. Later sections in this guideline address how to approach the validation of laboratory systems. the operating environment and constraints. The validation plan should be initiated at the earliest practicable stage and may be reviewed and updated through subsequent stages of the project. The Compliance Assessment should include a review of COTS product license requirements and release notes in order to determine any impact/restrictions on use within specific operating environments. regulatory or otherwise. Planning Phase Business Requirements This high level document describes the functions to be carried out. deliverables and authorities should be defined in the validation plans. IT infrastructure and software tools. 4. Electronic Records and Electronic Signatures Assessment Where the compliance assessment indicates a GxP impact an ERES assessment should be planned based on the guidance offered by GQG 3202. IT systems. The business requirements will often document the business case and approval for work and capital investment. A rationale supporting any validation decisions made should be included within the validation plan. Key roles and responsibilities.1. 2. Where a need is identified. GxP Risk Assessments may be conducted at several key phases of the system lifecycle. • Use of programming standards and good practices.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 and non GxP components (see GQG 1401A). 4. • Availability and use of competent people. The need for follow-up supplier assessments should be commensurate with the number and severity of the identified deficiencies. For larger. • Availability and application of an effective quality management system (procedures and practices). The validation plan should document applicability and timing of supplier audits. the timing of/and approach to assessments should be documented in the Validation Plan. then these should cross-reference each other. • Availability of a support service (as required). Supplier Assessment Phase Supplier assessments determine the level of assurance in the supplier that activities/deliverables equivalent to those outlined in this guideline have been followed/produced for development of computerised systems. then the validation plan for the computerised system may be embodied within the overall validation plan for the equipment. The information is used to determine any corrective/additional activities to be undertaken by the supplier and/or GSK in order to address identified deficiencies. The system category (see Section 6) will assist in deciding when an audit is necessary. The need to conduct GxP Risk Assessments should be considered. Guidance for the scope of validation required for different types of computerised system is defined in Section 6. If the computerised system is relatively small and contained in its entirety within a stand-alone piece of equipment. Key areas of assessment are: • Existence and authority of quality assurance organisation. The IT Risk Management Framework can be used to help facilitate GxP Risk Assessments for larger projects. more complex projects. Supplier audits are most beneficial if they are conducted as part of the supplier selection and procurement process so that any actions arising can be planned and managed as part of the project implementation. • Effectiveness of testing. Page 13 of 104 . Where there are validation plans for both the process/equipment/area and computerised system. All URS requirements should be successfully validated before system use unless otherwise justified and approved.e. A repository of supplier audit reports is also available at Global Computer Validation web-site.4. 4. OQ. • Testable/measurable. 4. and the system coding/configuration performed against pre-determined standards. must. i. PQ). the design is documented. Each URS requirement should be: • Referenced to facilitate Traceability Matrix [RTM]). and could.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION • 1205 JUNE 2002 Ongoing viability of supplier’s business (e. For small and simple systems the business requirements and URS may be combined. e. Requirements Phase Business requirements are further developed to produce what is commonly called a user requirements specification (URS). Assistance on conducting Supplier Audits is available through Global Computer Validation. programming (including source code review).3. a number of URSs may be required. The URS should focus on what the system should do and not to detail how to achieve this. Page 14 of 104 . IQ. should. requirements tracking (Requirements The URS provides the basis for system acceptance testing and should be approved before a design review is conducted. • Be approved by the end-user. • Unambiguous. design statements should not be incorporated.g. and testing (pre-qualification. verified by a design review. clear and concise. Each requirement should be categorised in order to define the level of importance. Design and Code Phase During this phase of the life-cycle. financial stability). For large and complex systems. The URS provides a statement of process/functional requirements of the proposed system.g. Requirements Traceability An RTM or other equivalent mechanism should be established in order to provide a means of demonstrating how a particular function of a system/application has been validated through design (including any DQ). reliability. any automated and manual interfaces to other systems. Business requirements may contain business case and business strategy information that is not appropriate to GxP regulatory inspection. hardware and key functions. Functional and Design Specification Functional specification documents are commonly used as the highest-level design document from which more detailed design documents are developed. concise. • All outputs that the computerised system will produce. The system overview should be reviewed and approved prior to use of the system.g. System overviews have a similar content compared to business requirements. providing a summary of the system scope. The system overview is aimed however for use during inspections. • All functions that the computerised system will perform. data throughput. The functional specification provides a response to the URS. Functional specifications will typically address: • All inputs that the computerised system will receive. inputs. • What constitutes an error and how errors should be managed. Where this approach is adopted. effective change control must be implemented to ensure that the effect of changing one component on others is fully assessed. • The definition of internal. Where large systems are being developed it is permissible to split the design specifications into a number of separate documents. The system overview should be written in non-technical language so that personnel not trained in computing can understand it. • All performance requirements that the computerised system will meet (e. It should include diagrams indicating the physical layout of the system hardware. Contents of the design specification should be cross-referenced to the system and functional requirements to demonstrate traceability. System Overview There should be a single document (clear. outputs and main data flows. Diagrams should be used where appropriate to assist readability.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Design specifications may take a variety of forms. external and user interfaces. Page 15 of 104 . timing). accurate and complete) describing the purpose and function of the system. The design of a system should consider the partitioning of GxP and non-GxP elements such that they can be validated and supported separately. • All ranges. The use of formal design techniques is encouraged. Page 16 of 104 . • Disaster/failure recovery. hardware design specification and software design specifications. Further subdivision is common for larger systems where for example unit/module design specifications may be produced. error/handling and alarm messages. Detailed design specifications document the equipment hardware and/or software in sufficient detail and clarity to enable the hardware and software to be built and tested. • Cabling/wiring schedules. Detailed design specifications should include but are not limited to: • System architecture (software and hardware. defaults and calculations should be defined ready for programming and testing). • Back-up. limits. • Safety considerations where inclusion of this information is deemed appropriate. defaults and specific values that the computerised system will accept.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 • The intended operating environment for the computerised system (e. • Software program specifications (All inputs. hardware platform.g. archiving and restoration. • Data processing and integrity. • System functionality (including reporting). if this is a design constraint). • System interfaces (including human/operator interface). outputs. Other documentation includes: • System architecture (including relevant design drawings). modularity). Detailed design specifications may be split into discrete elements for example. ranges limits. • Security. etc. operating system. files and databases should be specified by reference to its source. • Testable: Criteria within the specification to be used for user acceptance should be specific. measurable. • Access controls to ensure data can only be entered or amended by persons authorised to do so. • Complete: To establish that the specifications unambiguously and adequately define the system and that the requirements traceability matrix (RTM) (or equivalent mechanism) has been maintained. and minimise hazards. • Include ERES requirements (where applicable): The design review should confirm whether or not electronic record and electronic signature functionality has been addressed. • Built in checks for valid data entry and data processing. • Fit for purpose: To generate confidence that the system will satisfy the user’s requirements. The data definition may standalone as a separate document or be incorporated within functional/design specification. achievable. Page 17 of 104 . maintainability. • Current: Verify the documentation is current and necessary change control has been applied. realistic and traceable to the functional requirements and design specification.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Data Definition Data dictionaries. have the necessary attributes of reliability. Design Review A design review is undertaken to ensure that all documentation from the requirements and design phases have been produced and are: • Clear and concise: The specification should conform to documentation standards and should be readily understandable. Data Definitions may be incorporated into the Functional or Design Specification documents. Methods such as a FMEA (failure mode effects analysis) or CHAZOP (computer hazard and operability study) should be used to verify the design. architectures and flow should be defined. Actual data to be loaded into tables. usability. or prepared as a separate document as appropriate. Data dictionaries should be used to describe different data types. Specific functional aspects to be covered by the data definition include: • ERES requirements (GQP 3202). e. The report should clearly state if the quality of the design is acceptable. change details etc).e. object oriented. Configuration and System Build Prior to commencement of coding. Activities and documents should be reviewed and approved as defined in the validation plan and management procedures.g. procedures. modular Page 18 of 104 . • In-code documentation. e. • Data definition and scope (e. Design reviews may be known as design qualifications (DQ). structured. ladder logic. author. • Avoiding creation of non-executable code (i. • Branching. Their scope of application may include use of the computerised system in its wider context including equipment. • Expandability considerations.g. list any deficiencies together with details of planned remedial action.e. • Software/configuration structure). programming standards will address: • Content of header information in software listings (i. configuration or system build the design review should have been successfully completed.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 After the review a report should be prepared and approved summarising the design review. • Error/exception handling. dead code). Typically. Coding. Software/configuration developed internally should adopt programming standards. and operator interaction. global versus local). All software (including configuration) should be developed with good programming practices to appropriate standards. etc. • Naming and definition of variables. • Use of sub routines. version. It should be understood that the requirement for this design review does not mean that other routine reviews are no longer appropriate. Such standards should reflect the type of programming language used. structure and consistency (i. • Determine a level of assurance that the code has been constructed against the approved requirements and design specifications. Equally reports do not need to identify each individual typographical error where a general statement of observation can do just as well. All actions should be completed before progressing to testing of the software unit/module. • Identify evidence of dead code. • The configurable specifications. • Provide assurance that the code is maintainable by a competent programmer. Page 19 of 104 . A two-tier approach is advocated: a high level overview of all software identifying areas of code and a low-level walk through of critical areas. Care must be taken only to place actions on what is required from a regulatory or tangible business benefit perspective. The source code review aims to provide confidence in the operability of the system and should: • Verify expected use of good programming practices and adherence to programming standards referenced in development documentation. • Detect possible coding errors. Code/Configuration Review A source code or configuration review should be performed on all bespoke/custom application software and configurations prior to formal testing. Configuration details should be reviewed to provide confidence in the operability of the system and should verify that: • 'Unused' options are deselected and cannot function. Note: The correction of typographical errors is not needed if there is no impact on GxP functionality. elements of the application fulfil design The outcome of the source code or configuration review will typically be a report providing an overview of the review conducted together with a list of all observations that have been noted.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Hardware should be assembled and constructed in accordance with good practice taking into account aspects such as regulatory requirements and manufacturer’s recommendations. • Interface testing. Initial and subsequent product releases should only be used once they have been proven over a period of time by a user community to be fit for purpose. 4. Simulation and test equipment should be calibrated/tested. Where suppliers withhold software source codes then access agreements should be established. Other review evidence should also be retained and similarly managed. • System testing. It is important to recognise that computerised systems and software not specifically written by GSK should also be tested prior to its use. Testing is carried out according to pre-approved test plans and test cases. Products that are released by a supplier pending final evaluation (beta testing) should not be used. Progression from one test phase to another should not occur without satisfactory resolution of any adverse test results. Development testing in these circumstances in the responsibility of the supplier (system developer). Development Testing Phase The system developer should conduct formal development testing prior to the deployment phase.5. New releases should Page 20 of 104 . Confirmation that the test environment is indeed controlled is usually achieve by conducting an installation qualification (IQ) similar to that conducted as part of the deployment phase. For small computerised systems it may be appropriate to consolidate or omit some of the above test activities. Test data-sets should be reviewed and approved prior to use. Testing should be conducted against approved specifications. or referenced by. The justification for consolidation or omission of any test activities should be documented in the validation plan. • Integration testing. Testing should be conducted in controlled test environments that should be documented and verified in order to confirm that the hardware and software used in the testing are appropriate representations of the finally operating environment. Due account should be taken of any test requirements identified by the validation plan. Development testing includes: • Unit/Module testing. the report.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Complete hand-written annotated listings of software subject to detailed low-level walkthrough should be retained and attached to. supplier audit and design review. documented and verified prior to use. Test plans should be reviewed and approved before the defined testing begins. • Include power failure tests. It is important that testing is objective. • A reproducible test procedure. combined with test cases. The test approach should: • Verify the normal operation. Test Case Test cases provide the methods by which tests are conducted and the acceptance criteria against which the test results are assessed. • Challenge failure modes. • Any prerequisites such as calibration or test data or other tests that should be completed beforehand. or exist as separate documents. Test cases should not introduce new requirements or specifications. Each test case should include: • Objective of test. and impartial. Test Plan Test plans are used to define and justify the extent and approach to testing. Test plans may be embedded in validation plans. challenging. The requirements traceability matrix (RTM) or equivalent mechanism should be used to map tests to design specifications.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 be evaluated based on pilot and/or additional system testing based on the premise that it is not fully market tested. • Challenge the normal operation across the design range. Note: The person who develops the system should not be the person who develops the test and should not be the same person who executes the test. • Challenge boundary limits. Page 21 of 104 . Group or individual test cases are identified with any interdependence. • Cross-reference to the part of the system specification that is being tested. • Acceptance criteria. Test Results All raw data and derived results obtained should be indelibly documented. 'ok' or other abbreviations to indicate acceptance are not generally accepted by regulatory authorities and should be avoided.g.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 • Details of data to be recorded during test or test evidence to be appended (e. Test Failures The person approving the test cases should consider the consequences of a failure on the validity of completed testing. • Dated signature for the person approving test results. screen prints). and subsequently approved. • References to the incident log for test failures or observations. Test cases should provide 100% requirements coverage to the URS/Functional Specification. on the test case. All test failures should be recorded in incident logs. • Dated signature for each person performing the test. The testing results should include: • Actual test results and observations. The use of ticks. Testing nevertheless should aim to challenge the system and demonstrate it as fit for purpose. signed and dated. Full branch/decision/condition coverage testing within the functionality supporting these requirements is not usually practical. crosses. Inconsequential issues raised with test cases are not logged as test failures but the nature of the annotation should be registered in the incident log so that the resolution can be tracked. typographical errors not affecting the integrity of testing) can be annotated as cosmetic changes.g. This can be achieved by showing within the RTM that all URS/Functional specification sections have an associated test case. • A statement (pass or fail) as to whether or not the acceptance criteria have been met. Page 22 of 104 . reviewed for integrity and against acceptance criteria. Further testing should be performed/repeated where necessary. The detail of necessary testing will require some judgement. It would be expected that all product quality related data input/output and product quality related decision points would be tested. Inconsequential issues raised with the test cases (e. e. The test report should not exclude any test data. may be accepted with the approval of the User and QA/Validation. The test report may be combined with the test results. • Authorise any subsequent phase of testing.6. • The actions taken to resolve incident log issues. GxP requirements are not considered low risk. • Identification of test cases and supporting raw data. • Whether the results meet the acceptance criteria. Deployment Phase On completion of successful testing the system is ready for installation into the final operational environment. • Conclude each phase of testing. raw data). with justification. During this phase it is necessary to ensure that arrangements for the use and ongoing systems support and maintenance are either established or that documented plans have been prepared to ensure that these arrangements are in place when the system becomes operational.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 If the analysis of a test failure results in amendment to the test case or associated specification. Such concessions should be recorded in the incident log and justified in the test report. 4. Test Report Test reports should be prepared in order to: • Collate evidence of testing (i. then the remedial action should be performed under change control. Minor deviations from the acceptance criteria. where there is no risk to GxP. may be deferred. if indicated by the requirement categorisation in the URS. Resolution of test failures associated with low risk functions. version configuration). The results of testing are analysed and summarised in a test report that should state: • System identification (program. During this phase the hardware and software installation is qualified and operational checks are performed. Page 23 of 104 . Other checks should be put in place as required to verify original GxP data is correct. service contracts. and approved before the systems is approved for use. Where data representative of the live environment is required for testing or where data load/migration routines need to be tested prior to final load. Statistical sampling can be used to check other data commensurate with the business need to verify data integrity. • Maintenance The following areas should be addressed (where appropriate): − Recommended spares holding. super users. Page 24 of 104 . password management and physical security measures) should be specified. business continuity plans. reviewed. SOPs should be approved before the computerised system is approved for use and available. approved and where appropriate tested before the computerised system becomes operational. even if only in approved draft form for operational qualification (OQ). tested. Operational and Support Plans Operational and support plans should be established in order to ensure that SOP. All GxP data should be at least double-checked to verify that it has been correctly loaded. Rationales justifying sampling regimes should be defined. maintainers and normal users. • Security Management SOPs for managing security access (including adding and removing authorised users. training. Support organisations (both internal and external) should be periodically audited to verify continued service in support of GQP 1205 and associated GxP regulatory expectations. virus management.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Data Load Plans. • User Procedures SOPs should be established to define the use of the computerised system. procedures and protocols should define the data load process. Security management procedures should apply to all users including administrators. etc are established. Automated data load tools should be validated. the data load/migration activity may be phased. − Frequency of routine testing/calibration. Page 25 of 104 . − Procedures covering maintenance activities should be specified. Alternative means of operation should be available in case of failure where critical data maybe required at short notice (e. compilers.g. tested.g. Topics for consideration should include catastrophic hardware and software failures. source code. protected within fire safes. e. in case of drug product recalls).g. • Data Archiving and Retrieval Archiving and retrieval procedures for data should be specified. including their associated audit trail information (see GQG 3203 and 3301). and approved before the system is approved for use. and security breaches. • Business Continuity Plans Procedures and plans supporting business continuity (disaster recovery plans and contingency plans) should be specified. ESCROW accounts. protection and confidentiality of electronic records. tested. formal agreements should be established to ensure software can be accessed when needed. Backup and restoration procedures should be verified. − Performance monitoring. and where practical tested. Careful consideration should be taken of special requirements affecting the retention preservation. and approved before the system is handed over for use. maintained and retained within safe and secure areas. • Training Training plans should be established for use and support of the computerised system. Copies of the software should be retained within safe and secure areas. fire/flood/lightning strikes. protected within fire safes. Where access to software is restricted. • Availability of Software and Reference Documentation All software (e. operating system) and reference (supplier) documentation should be available for inspection and copies should be available for business continuity. • Backup and Restoration Backup copies of all software and relevant data (see GQG 3202) should be taken.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 − Backup and restoration of software and data files. and approved before the system is approved for use. • Checking timer accuracy. • Verifying SOPs established to control the use and maintenance of the computerised system. System tests from the developer may be used to reduce the amount of OQ testing conducted. under realistic stress conditions. • Conducting system loading tests.g. OQ should cover: • Checking required functionality. • Checking calculations and algorithms. data. Testing should be designed to demonstrate that operations will function as specified under normal operating conditions and. • Operating environment checks (e. power. It may be Page 26 of 104 . Operational Qualification OQ should only commence on successful completion of IQ and involves user acceptance testing of the base functionality of the computerised system. where appropriate.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Installation Qualification Checks should establish that the installation has been completed in accordance with system specification. software name and version. • Diagnostic checks (installation diagnostics and software launch). temp). Checks should be based on: • Inventory checks (hardware models. An IQ summary report should be prepared and approved prior to OQ commencing. • Checking alarm and alert messages. • Checking de-selected functionality cannot be accessed. The boundary of the system and hence the scope of the IQ should be defined in the validation plan. possible to train operators to help conduct testing. • Checking execution flows/sequences. user manuals and SOPs). RFI/EMI. The suitability of such testing and available documentation must be reviewed and approved by QA for this purpose. RH. Tests should reference appropriate functional specifications. Multiple reports may be required in order to phase roll out of discrete aspects of the system or where there is a phase roll out to multiple sites. System Release Computerised systems are often released into the live environment following completion of OQ. for testing purposes.g. system release note should be prepared. OQ may be conducted in a controlled off-line test environment. reproducible and reliable. This should be complemented by a collective OQ demonstrating that the fully integrated system functions as intended. Product PQ establishes the confidence that the data-dependent output from the system consistently meets specification across the defined range of output variants. to do this the system must be brought into use in the live environment. Test environments should be subjected to IQ demonstrating they are. • Pharmaceutical product packaging variants. More complex computerised systems may be divided into sub-systems and each of those systems subjected to separate OQ. Process PQ ensures that operational and support processes are effective. i. Examples of product PQ outputs include: • Batch reports. An interim validation report or alternative e. in advance of performance qualification (PQ).GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 An OQ summary report should be issued on completion of OQ activities. Alternatively OQ may be conducted with the final system installed in-situ prior to its release for use in the live environment. Final evidence needs to be collected from the live environment to conclude that the system is fit for routine use. The interim report should cover all aspects of the validation plan up to and including OQ. However. Performance Qualification PQ should only commence on successful completion of OQ and comprises product PQ and/or process PQ. Process PQ typically include: • Monitoring of user enquiries. For simple computerised systems IQ and OQ may be combined into a single activity and documented accordingly. equivalent to the intended live environment.e. Page 27 of 104 . • Label variants. reviewed and approved in order to authorise system release. 1205 JUNE 2002 Manual processes. The validation report for a system should not be approved until all the relevant documents defined within its validation plan have been approved. SLAs should address: • Scope of service. • Progressing system changes. Page 28 of 104 . a SLA or other similar contractual document should be established to define the support service provision.7. • System availability. Validation Reporting A validation report should be prepared to conclude on the completion of the activities prescribed in the validation plan. • System stability. The validation report should address each of the activities defined within the validation plan and confirm that these have been successfully completed with a clear statement that the system is validated and fit for purpose. Where critical unresolved issues exist. Service Level Agreements (SLA) Certain requirements of the Use Phase may be provided by internal or external support organisations. Use Phase This phase of the system life-cycle describes the period of time when the system is in operational use. 4. • Problem resolution to incident logging. such as additional data checks and report verification. then the system cannot be considered validated and should not be put into use for GxP applications. The validation report and supporting documentation should be lodged with the relevant site validation manager.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION • Progressing data changes. should be operated in parallel with the computerised system until the completion of PQ. In such cases. Where there are deviations from the validation plan or unresolved incidents then these should be documented and justified to allow the computerised system to be used on an ongoing basis. fault reporting and resolution. • Scope and nature of access the supplier has to the system (e. Page 29 of 104 . plans. The use of such services is not prohibited. system performance monitoring. • What software/diagnostic tools the supplier will use. operating system. • Controls applied in support provision. upgrades. contracts. raw data. • Confidentiality agreements established with the supplier. etc established in accordance with operational and support plans should be implemented. Dial-In Support Services Suppliers of sophisticated computerised systems may offer dial-in fault diagnosis and correction.g. back-up and restoration. • Keystroke/Log reports which detail all actions performed remotely on the system by the supplier. Consider the following: • ERES requirements – particularly with regard to the open/closed status of the system. • Audit of the supplier specifically relating to the support service offered. Implementation of Operational and Support Plans During this phase. but extreme care should be taken prior to allowing such remote access. all SOPs.g.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 • Service access and response time. configuration. • Formal support contracts agreed (this should include statements relating to the above points). • Escalation procedures • Service definition (e. Make full use of local GSK knowledge prior to requesting dial-in support from the supplier. archive management). electronic records). • Access to the system by the supplier should be controlled by GSK. • Service performance monitoring. Minor changes. such as patches. • Number of changes made. preservation. protection and confidentiality of electronic records including their associated audit trail information (see GQG 3202 and 3301). • Changes in regulatory or company requirements. Page 30 of 104 .GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Upgrades Upgrades to software (including new releases and bug-fixes) and hardware (including model upgrades and replacement with ‘like-for-like’ equivalents) should be managed through change control. The document set for the computerised system should be updated. should analyse any impact to the existing functional specification and re-test affected functionality with new supplementary tests as required. 4. especially those. to reflect the change. Necessary validation for the upgrade will be influenced by: • Bespoke/custom versus standard characteristics. Any requirements for refresher training should be reviewed (see also section on deployment phase). Periodic Review and Revalidation Validation reviews should be conducted on systems to verify the compliance and validation status. • Complexity. Decommissioning Phase At the end of the operational life of a system a process of decommissioning takes place. Reviews may recommend revalidation exercises for particular computerised systems. as appropriate. which includes archiving data and system software. Large-scale functionality enhancements. Refer also to section on retrospective validation for guidance. • Criticality of the operations performed. Careful consideration should be taken of special requirements affecting the retention. which involve a change to the character of the system may require a full validation reassessment. the following factors need to be taken into account when determining the frequency of review: • Criticality.8. g.9. OQ. including all supporting infrastructure. including regression testing. A plan should be generated describing the archive approach. data. and electronic records archived. The incident log records details of the incident. PQ). raw data. The mechanism should provide a method of tracing a requirement from the initial URS document to the functional specification. or upon completed installation of a major release or upgrade. for example. Incident logs should be closed down at appropriate stages. document and resolve incidents that occur during the life of a computerised system. The incident log should record remedial action. design specification and through development testing and qualification activities (IQ. An incident log should be set up and used. Page 31 of 104 . and consider any testing. GxP related changes should be reviewed and approved by QA. Incident Management Processes should be established to capture. Incidents can be prioritised for resolution. An index for incident logs should be maintained. Procedures should be established to ensure that the following are maintained for the entire system life: Requirements Traceability RTMs or equivalent mechanism should be established to provide an assurance that all requirements have been included in the system design and tested to verify correct operation. Change Control Change control must be established for the project and ongoing use of the system. testing and use of the system. and hardware. Configuration management applies to software and hardware including operating system versions. manage. documentation. Cross Phase Activities Several activities need to be managed and linked across a number of life-cycle phases. Configuration Management A system should be established to document. data sets and bespoke/custom code. the circumstances under which the incident was noted (e. 4. at the end of a project. and control the versions of configuration items making up the computerised system through the design and development. Change control should be established within the planning phase and apply to software. and a corresponding report issued on completion listing documents. reference to test case) and the name of the person making the observation.GlaxoSmithKline Management: Management Systems COMPUTERISED SYSTEM VALIDATION GLOBAL QUALITY GUIDELINE 1205 JUNE 2002 Archiving activities should be planned and results collated. application software. Training All personnel developing. Retrospective validation. Documentation and raw data should be reviewed prior to approval and maintained under change control. documentation. using or maintaining a computerised system should be trained in the technical and procedural aspects of the computerised system in order to attain a level of competence commensurate with their job description. supplier audit exhibits and test evidence). process should create and maintain a package of Document management procedures. Otherwise it is expected that validated computerised systems will have been maintained in a state of compliance. All such amendments should be signed and dated. Raw data forming attachments to documents should be marked as such (e. Sets of raw data should have each page marked as belonging to the set and the front page signed and dated. For non-GSK personnel (including contractors or temporary staff who do not have a GSK personnel number) a Curriculum Vitae including all relevant details should be retained by the responsible manager. It is also acceptable to conduct retrospective validation when addressing a change in regulatory requirements/expectations. Training should be conducted against approved user procedures. stored. Sets of raw data should be physically coupled together (e. It is not acceptable to implement a new computerised system and knowingly defer validation until after its implementation. signed and dated. User training records should be updated to reflect training given on the system.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Documentation Management The validation documentation. Retrospective Validation Computerised systems should be validated prospectively. Page 32 of 104 . is acceptable when a change in use brings a validation requirement to an existing system that did not previously require validation. 5. however.g. or included in the personnel training records.g. where they do not should be established to manage and control such The contents of the validation package should be securely Raw data attached to documents. Hand written amendments to documentation and raw data should not obscure the original entry. bound or stapled). or existing in their own right. already exist. Pencils and white-over must not be used. and the reason for the change noted. should be clearly itemised. A training plan should be developed to manage this activity. A checklist can be developed for the validation documentation and an analysis made as to whether there is any existing documentation. Such rationales must be documented and approved by QA. plus any other relevant policies and guidelines such as GQP 3202 and GQG 3202 on ERES. 5. (see GQP 1204). system modification. Retrospective validation may involve modifications. Page 33 of 104 . The degree to which interim corrective actions is required will depend on a number of factors including the size of the existing compliance gap and the proposed duration of continued use for the system. Existing documents and specifications should be reviewed for accuracy and completeness and used where possible. Prioritisation should take into account relevant factors such as: • Product quality impact. Where system functionality does not meet current functional requirements or regulation.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Retrospective validation should be conducted as a prospective exercise. e.1. Priorities Priorities should be established from the gap analysis and any retrospective validation requirements identified. upgrade or replacement may be necessary. Critical applications that cannot be validated or are unsupportable must be removed from use unless corrective actions can be used to justify their continued use. that regulatory authorities will expect where such rationales are put in place that the legacy computer system will be phased out of use within a reasonable time frame. Gap Analysis A systematic survey and gap analysis should be conducted on legacy computerised systems. whether it fulfils the intent of validation documentation outlined in this guidance. however. upgrades. The change history of a computerised system should be reviewed alongside any statements made about reliable operation.g. It must be understood. The basis for assessing any gap should be GQP 1205 and this GQG. Information regarding the operational history of a computerised system may be used to supplement its validation. and where there is documentation. cannot rely solely on the operational history of a computerised system to justify its ongoing use. 5. through the development of replacement programmes. system specification and testing which must be performed against these requirements. or replacement. the business owner and a technical authority.2. It should include preparation of current functional requirements. Interim corrective actions may be required if retrospective validation cannot be achieved in a timely fashion. Retrospective validation. Anecdotal evidence of reliable operation should not be used. however. 1205 JUNE 2002 A high level strategy for the site or for specified departments should be developed to document the prioritisation and any key milestones. In some cases full compliance will not be possible until the software supplier makes a new release of software/hardware available. • Bespoke/custom or COTS system. This is normally achieved by requiring human rather than computer decision making and often requires additional hard copy documentation. Where non compliant legacy computerised systems apply to a number of steps in the manufacturing and despatch process. • ERES compliance status. • Complexity of system corrections needed. a step by step flow chart of the process highlighting the role of the computerised system at each stage should be prepared. Immediate priorities are those computerised systems directly involved with the manufacturing and despatch process and the critical quality related activities that these systems support. • Ability of supplier to support changes.3. These interim measures must be sufficient to ensure product integrity and effective disposition and release but should be no more extensive than is necessary to achieve this.business and quality. • Stage in system life-cycle. • Severity of non-compliance. • Validation status.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION • System criticality . 5. Interim measures should be recognised as temporary and not be viewed as a long-term alternative. Interim Measures An interim measure is an additional control applied in the process that reduces the reliance on the computerised system performing a critical function. Interdependencies between different streams of work should be clearly identified. Interim corrective actions should be considered until a fully compliant solution can be applied. Supplementary interim measures should be used where the critical activity cannot be assured due to the reliance on the computerised system. Critical activities that relate to product quality should be identified and the reliance on the legacy system should be assessed. The inherent non-compliance of the legacy computerised system must be addressed through further longer-term Page 34 of 104 . • Interim measures are implemented to bring additional controls to critical quality decisions or information where non-compliant computerised systems are used. • Sentencing/disposition of product. and used to supplement or replace certain computer transactions. vision system checking a labeller).g. In practice it may be easier to achieve control by introducing or strengthening another control downstream of the process that verifies the output (e. • Label information and printing. Current hard copy systems that are already in place may provide the basis for the interim measures and minimise the need for additional documents. • Critical processing activities that are reliant on computerised systems such as dispensing. • They are typically paper based. Those critical activities that should be given particular consideration for interim measures should include: • Stages in the process where status change occurs such as approval of a raw material or intermediate product. • Product quality related specifications held by or used by computerised systems. documented by procedures. documented and approved. Both short-term interim measures and the longer-term plan for final measures should be available to show to inspectors. Such documents may require only minimal change to content or to the review and approval mechanisms. Verification of output such as inspection through sampling may also be a means to reduce reliance on the computerised system. • Interim measures must be fully defined. The key aspects of these documents are: • They are a formal record and must be maintained with the batch documentation.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 corrective action plans. Page 35 of 104 . The following are important principles that need to be understood in applying interim measures: • Interim measures do not eliminate the need for full corrective actions and do not overcome system non-compliance. particularly approval to release to the market. 1. • The documents should be reviewed and approved using the sites normal mechanisms. and customer complaints. Examples of other activities include facility maintenance scheduling. • The key product critical information on each document must have been obtained from a compliant computerised system or secure approved hard copy source. Bespoke/Custom Built Hardware Components These requirements are in addition to those of standard hardware components. Justifications should be documented in rationales approved by QA. Hardware acceptance or IQ must verify installation and connection of components.2. Each site will need to identify how it can justify the continued use of computerised systems supporting such activities without the use of interim measures. The model. Standard Hardware Components The performance capability of standard hardware components should be documented along with manufacturers/supplier details and version numbers. Extra personnel may be required to install and operate interim. 6. it is also important to understand how computerised systems support the complete manufacturing and despatch process as this can be more extensive than is expected. Pre-assembled hardware that is sealed does not have to be disassembled.1.1. version number and. The main impact will probably be on quality organisation personnel. To minimise the disruptive effects of introducing additional procedures it is crucial that each site focuses only on the critical quality related activities. of pre-assembled hardware should be recorded. In such cases the hardware details can be taken from the hardware’s data sheet or other specification material. where available.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 • The minimum number of documents should be created and each kept as simple as possible. However. as these will usually require additional activities. This may break warranty. serial number.1. 6. Managing Hardware and Software 6. Bespoke/custom items of hardware should have a Page 36 of 104 . The number of personnel will depend upon the extent to which existing documentation can be used and the extent to which interim measures are required. Hardware Categories 6. Examples include weigh scales. Software Categories It is important to understand that computerised systems often consist of multiple software elements and that within a single system these elements may represent a variety of software categories. Category 1 Operating Systems These are established commercially available operating systems.1. Bespoke/custom firmware should be considered as Category 5. Application revalidation shall reflect degree of impact. 6.2. Configuration may be required in order to set up runtime environment and/or process parameters. Supplier audits may be needed for highly critical or complex applications. Assembled systems using bespoke/custom hardware from different sources require verification confirming compatibility of interconnected hardware components.2. Functionality should be tested during OQ.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 design specification and be subjected to acceptance testing. Change control should be applied to manage upgrades to the Operating system in order to determine the impact of new. The name. Operational procedures should be established and training plans implemented.2. Features of the operating system are functionally tested and challenged indirectly during testing of the application. version number and any configuration/calibration for the firmware should be documented and verified (installation qualification). 6. Change control should be applied to manage any change to firmware or configuration parameters. Applications are developed to run under the control of these operating systems. 6. Page 37 of 104 . A supplier audit should be performed for bespoke/custom hardware development. modified or removed features on the application. bar code scanners. Any hardware configuration should be defined in the design documentation and verified in the IQ. The name and version number of the operating system is documented in application design documentation and verified (installation qualification). Windows NT® and VMS®. Category 2 Firmware Typically these are embedded in commercially available pieces of electronic equipment designed to perform discreet operations.2. three-term controllers. Examples include Unix®. Examples of standard software packages include statistical analysis packages. In the absence of a documented quality system. 6. alarm and event handling. standard software packages providing an off-the-shelf solution to a business or manufacturing process. Runtime process parameters may be input to the application. Configuration should be limited to establishing the run time environment of the package. A supplier audit is typically required in order to confirm that the software package has been developed in accordance with appropriate quality systems and that application development and support organisations are robust and competent. Category 4 Configurable COTS Software Packages These packages provide standard interfaces and functions that enable configuration of user specific business or manufacturing processes from pre-defined or customised modules. Software packages and the platform should be well known and mature before being considered Category 4 software.g. Operational procedures should be established and training plans implemented. reviewed and tested. The name of the package and the version number should be recorded.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 6. New and bespoke/custom modules should be handled as Category 5 software. laboratory instruments such as Fourier transform infrared (FTIR) and standard diagnostic tools. Supplier audits may be needed for highly critical or complex applications or where utilisation of the application within the pharmaceutical industry is limited. Supplier documentation should be leveraged wherever possible (e. 1205 JUNE 2002 Category 3 Standard COTS Software Packages These are commercially available. PLC-based manufacturing control systems such as non-customised software for a coating pan controller.4. The full life-cycle should be addressed. Complex systems often have layers of software. configurable. Page 38 of 104 . The validation plan should document a structured approach to the validation of the application. suppliers should use this guide to provide the foundation for establishing a suitable quality system to control package development and support. Validation should focus on the configured business or manufacturing process. with one system including several software categories. calculations and algorithms) need to be documented. security.g. The system is not configured to define the business or manufacturing process itself. user and technical manuals).3.2.2. To satisfy validation requirements critical user requirements (e. 5. ladder logic) and user applications (e. Category 5 Bespoke/Custom Software These systems are developed to meet the specific needs of the pharmaceutical organisation. Bespoke/custom developments may be a complete system or extension to an existing system.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 although much of it is the developer’s responsibility and thus may be verified during the supplier audit. Complex systems often have layers of software. with one system including several software categories. The validation plan should reflect supplier audit observations. application criticality.g. spreadsheet configuration and database customisation). application criticality. 6. supervisory control and data acquisition packages (SCADA).2. A supplier audit will typically be required in order to confirm that appropriate quality systems are in place to control development and ongoing support of the application.g. In the absence of a documented quality system. The validation plan should document a full life-cycle approach to the validation of the bespoke/custom application based upon the life-cycles contained in this guide. suppliers should use this guide to provide the foundation for establishing a suitable quality system to control application development and support. Examples include distributed control systems (DCS). Page 39 of 104 . The validation plan should reflect supplier audit observations. Examples of bespoke/custom software includes bespoke PLC programming (e. manufacturing execution systems and some LIMS and MRP packages. size and complexity and should include strategies for the mitigation of any shortfall identified in the supplier’s system development process. size and complexity and include strategies for the mitigation of any shortfall identified in the supplier’s system development process. Page 40 of 104 . Consider auditing the supplier for critical and complex applications. Manage any bespoke/custom programming as Category 5 software. 3 Standard COTS Software Packages Record version and verify operation against user requirements.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 6. COTS Record version and configuration of configurable COTS firmware. The operating system will be challenged indirectly by the functional testing of the application.2. 5 Bespoke/ Custom Software Audit supplier and validate complete system. Manage bespoke/custom firmware as Category 5 software. 2 Firmware Record version of non-configurable firmware and calibrate as necessary. Calibrate as required and verify against user requirements. Consider auditing the supplier for critical and complex applications. and verify operation against user requirements. 4 Configurable COTS Software Packages Record version and configuration.6. 1205 JUNE 2002 Summary of Software Categories Category Software Type Validation Approach 1 Operating Systems Record version. business continuity plans.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 6. Page 41 of 104 . 1205 JUNE 2002 Summary of Software System Documentation Documents typically prepared by GSK Software Category 2 Business Requirements Comments 3 4 5 X X X May be combined with URS. Compliance Assessment X X X X System Register X X X X Per system. interface and system. Design Review X X Sometimes known as DQ. Archiving and Decommissioning X X X X Special attention is required for electronic records/signatures. Qualification documents may be combined as long as test plans and test cases are collectively approved before testing. Validation Plan X X X X Per system. Installation Qualification X X X X Operational Qualification X X X X Performance Qualification X X X X Validation Report X X X X May be in the form of a certificate for very simple systems. not per software category. maintenance. Development Testing X X X X Includes unit. backup and restoration. not per software category. System Overview X X X Consider as separate document. integration. maybe included in URS/functional specification. For standard COTS category 2 qualification may be based on calibration activities. Operational and Support Plans X X X X Activities include user procedures. Functional Specification X X X For standard COTS packages reference to product specification is sufficient. X X For bespoke and critical COTS applications. Detailed Design Specifications X X X Maybe split into hardware and software design documentation. Source Code Review X X Configuration only for category 4 software. Data Definition For projects that populate the new system with existing data. Supplier Audit User Requirements Specification (URS) X X X X ERES Assessment X X X X When the compliance assessment states that the system must be validated. security management. Note: No specific validation activities for standard COTS compilers and operating systems beyond documenting version details. Data Load X X X X For projects that populate the new system with existing data.2.7. ) collects the analytical data (e.1. • Bespoke/custom laboratory application.g. Standard COTS supervisory control and data acquisition systems with user configuration. for example. Instruments with associated personal computer are excluded from this class.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 7. or provide information that is used in product quality control. manipulate data. Includes Page 42 of 104 . Some of these systems can be considered as 'SCADAs' because the PC supervises in the instrument activity (test parameters etc. store and manipulate data for analysis (see GQG 3202). Non-configurable instrumentation with data acquisition. spectra) and then performs data analysis (e. Laboratory systems cover a wide range of computer applications. Laboratory systems include equipment that measure physical variables. manipulation and/or reduction software. 1205 JUNE 2002 Approach to Laboratory Systems 7. Four classes of laboratory systems are identified here: • Simple firmware COTS Instrument. and control laboratory equipment. Electronic records may be retained. laboratory system. Analytical data is typically displayed. product release or submissions to regulatory bodies. a pH meter with microprocessor control through to sophisticated chromatography systems and software providing complex statistical data analysis. Non-configurable instrumentation with dedicated functionality. record. spectral library matches). • Configurable laboratory automation. Customised and bespoke/custom bespoke/custom instrumentation. Most laboratory systems comprise COTS products. Laboratory Systems Definition Laboratory systems measure. • Complex COTS Instrument.g. User performs calibration/set-up. Laboratory systems may also be linked to higher levels of computer integrated manufacturing systems such as laboratory information management systems (LIMS). Analytical data is displayed but no electronic records are retained. • Database applications (see guidance on desktop applications). 1205 JUNE 2002 Scope of Systems Covered Laboratory systems typically include the following: • Data acquisition and on-line analysis systems linked to production systems. user and QA/Validation Page 43 of 104 .g. or a member of the local QA/Validation personnel. (see also guidance on control systems). Combining process and computer validation offers an opportunity to consolidate roles and amalgamate documentation. • Gas chromatography (GC) systems.3. • Chromatography data systems (CDS). • Data historian/trending/statistical analysis systems. • Laboratory information management systems (see guidance on IT systems).GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 7. • High performance liquid chromatography (HPLC) systems. • Supervisory control and data acquisition (SCADA) systems (see also guidance on control systems). QA/QC laboratory personnel). • Spread-sheet applications (see guidance on desktop applications). • Networks and interfaces within the laboratory system and to any other connected system (see guidance on IT Infrastructure). Combining roles may be the only practical way to tackle simpler laboratory systems. For example. Where roles are combined it is essential that the person conducting the work is suitably qualified for the combined role and that they do not review or approve their own work. Examples of computerised systems found in the laboratory for which guidance is given elsewhere in this GQG: 7.2. • Systems controlled by standalone personal computers (PC). Responsibilities Many laboratory systems require both process and computer validation. Independent developer. • FTIR spectrophotometry. the QA/Validation role may be taken by someone in a department that is responsible for quality (e. The basic validation life-cycle for laboratory systems should be in line with this guideline and support where necessary process validation requirements. the overall validation approach to a SCADA system that controls several balances might be to validate the balance based on the use of standard firmware.4. it is important that the laboratory system (high level) requirements are considered and identified at the project planning Page 44 of 104 . 7. 7. The specific assignment of personnel to roles should be documented in the validation plan. 4 and 5 software respectively but taking into account any other software categories present in the laboratory system. configurable laboratory automation. complex COTS instrument. Responsibilities must be clearly defined throughout the lifetime of the system. Planning Requirements should be specified by the users in consultation with developers and laboratory personnel. The definition of what comprises a system needs careful consideration. Simple COTS instrument. The use of common proformas and templates is encouraged. For example. and to validate the SCADA software based on the use of userconfigurable standard software. For systems where separate process and computer validation plans exist. special consideration should be given to the interfaces and responsibilities of the computer and process validation specialists. 3.5. Where new laboratory systems are being introduced.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 roles should always be assigned. and as such there is an opportunity to standardise on the approach to validation and to provide efficient and consistent validation. either as a project in its own right or as part of a larger project. The following points provide some additional specific guidance for each of the life-cycle phases as described in Section 4. many laboratory systems comprise of a number of interchangeable items that should be managed under change management not the system register. Many laboratory systems are of similar type/design.1. Systems Register All laboratory systems should be maintained on a single register at a site or laboratory level as appropriate. For example. 7. and Bespoke/custom laboratory application should be validated focused on Category 2.5. Validation Life-Cycle The validation approach for a laboratory system may incorporate a number of separate validation strategies as appropriate to its components. 3.5. 7. Requirements Requirements should describe the intended use and equipment type. • Maintenance and calibration requirements. Supplier Assessments Supplier audits should be conducted for configurable software packages and bespoke/custom software (see Section 6). including: 7.4. 7. • User operation. • Communication interfaces to other equipment/systems. This information may be available for standard systems in the form of a datasheet published by the supplier. For simpler laboratory systems. Laboratory systems must be assessed for applicability with the ERES regulations and functional and design specifications should be developed to address necessary requirements. This design documentation is expected to comprehensively describe the functionality of the laboratory system. Detailed Design The documentation to support the design and code phase of the life-cycle should be provided by the supplier of the laboratory system. • Operational ranges and tolerances.2. Supplier audits are not required for standard COTS software. • IQ/OQ protocol packages.5. the validation activities may be encompassed within the overall project validation plan.5. It is important to appreciate. • Environmental constraints. Rationales justifying why supplier audits are not necessary should include information on how many products for the version of interest have been distributed for use and are currently supported. GQG 3202 provides additional guidance on ERES requirements. however.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 stage. that many COTS laboratory systems are sold in very small numbers and the argument that they represent standard software may not be appropriate. Configuration aspects of the laboratory system should Page 45 of 104 . • Training and support. an increased level of user acceptance testing.5.5. which is supported by a testing rationale/plan. These qualification protocols should be based on the requirements that are documented in the system and functional requirement documents. Code Review Source code reviews should be conducted for bespoke/custom software (see Section 6). Development Testing It is expected that evidence of supplier development testing and calibration should be available as part of the laboratory system documentation. Detailed design and code activities are not normally required for small/simple laboratory instruments.5.7. When this evidence is not available a review should be performed to identify what action needs to be taken. Evidence that the supplier has performed source code review of the laboratory system should be available from the supplier. provide specific documented evidence of testing in the form of hard copy printouts. the general principles described in Section 4 and 6 should be applied. The detailed design includes the production of hardware. Where code reviews have been conducted by the supplier.8. PQ should be based on verifying system suitability tests. separate IQ and OQ is recommended for complex laboratory systems. 7. software and associated instrumentation specifications. For other laboratory systems. Qualification IQ and OQ are typically combined.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 be included in the design documentation. 7. including any calibration.6. Where the supplier does not provide specific evidence of functional testing. auditing should be considered to ensure that the reviews have been completed by competent individuals.5.5. For embedded systems these documents may include the preparation of mechanical and electrical specifications/documentation. independent from those developing the code/configuration. will be required. Other testing requirements may also be included from the business and user Page 46 of 104 . 7. Wherever possible. 7. Pre-Installation Testing Pre-installation testing should focus on ensuring the correct configuration/set-up has been conducted. Documentation of unused and de-selected functionality should be included. However. e. Business and user requirements specifications are typically combined as a single document that is designed to support the purchasing process. It should be normal practice to use the suppliers’ standard literature (datasheets) to document the functional specification. No further design and code documentation is required. Special Considerations for Simple COTS Firmware Instrumentation COTS firmware instrumentation is non-configurable but the user can perform calibration/parameter set-up. and should be clearly identified within the validation and support documentation.5. For instrumentation the term qualification is sometimes used rather than validation. covering a range of models). 7.11. that pre-installation testing is not Page 47 of 104 .9. change control and routine recalibration. the requirements. PQ will verify the operation of the laboratory system in the live environment.5.5. Pre-installation testing should focus on ensuring the correct configuration/set-up has been conducted. including any calibration. Nevertheless simple validation plan and validation reports should still be produced. It should be recognised. however. 7. Decommissioning Special activities for archiving and decommissioning are required if there are electronic records. Since the instrumentation is generally purchased on the basis of equipment catalogues or supplier datasheets. Record retention policies may require the supporting user and supplier documentation to be archived when the equipment is decommissioned. The validation requirements for any associated personal computer workstations should be considered separately. specifically associated with the laboratory system are subject to this validation exercise. 7. A requirements traceability matrix (RTM) is expected where the traceability of user requirements through design to test cases cannot be easily demonstrated. Use Ongoing use of the laboratory system should be supported by system suitability testing. This is because validation is largely based on calibration and system suitability testing. it is expected that the functionality will be pre-set and designed for a specific task.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 requirements specification.10. Where these documents are generic (i. GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 applicable to simple. The validation planning requirement may be proceduralised rather than generate separate validation plans and validation reporting may be through certification rather than separate validation reports (e. instrument certification). This protocol will typically be a verification of components.g. the networks/interfaces should be qualified as part of the validation of the overall system. chromatography data systems).12. Page 48 of 104 . Ongoing use of the laboratory system should be supported by change control and routine re-calibration. PQ is satisfied by ‘system suitability testing’ that may be repeated within analytical methods. and calibration. firmware versions. See also guidance on IT Infrastructure. ERES assessments will be required but should be simple to conduct since most systems only deal with electronic raw data rather than electronic records. Qualification should be based on the requirements documented in the datasheets and manuals. 7.5. smart instruments. IQ and OQ are typically combined. An RTM is not normally required because the laboratory systems have limited functionality that can be easily traced manually through to qualification. Application Networks Where networks/interfaces are used by the laboratory system to transfer data to.g. Record retention policies may require the supporting user and supplier documentation to be archived when the equipment is decommissioned. For these instruments configuration/set-up will take place at IQ/OQ and be documented in the IQ/OQ records. or to access analytical methods or raw data from other systems (e. 3. Laboratory Systems Categories pH Meter 2 Ultrasonic Bath 2 Mass Balance 2 High Performance Liquid Chromatography (HPLC) 1. 4 Chromatography Data Systems (CDS) 1. The need to assess each system individually is still strongly recommended. 4 SCADA system (with user defined macros) 1. 4. logic blocks etc. a single loop temperature controller through to a large distributed process control system with thousands of inputs and outputs.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 7. 4. Page 49 of 104 . for example. 4. Definition of a Control System Control systems monitor and control production processes or environments. 8. 2. 3. Control systems may also be linked to higher levels of computer integrated manufacturing systems.1. effect real time control on physical parameters. 4 SCADA system (no user defined macros) 1.. 3. 3. 1205 JUNE 2002 Examples of System Categorisation The following list gives guidance on the expected categories (see Section 6) of some typical laboratory systems. A wide range of equipment is covered from. 5 FTIR Spectrophotometry 1. 5 Standard interfaces to other connected systems 3 or 4 Bespoke/customised interfaces to other connected systems 5 Approach to Control Systems 8. Control systems include equipment that measure physical variables. 5 Laboratory Robotic Systems 1. 3. present and store data and through pre-programmed/configured control algorithms.6. 3. • Intelligent Instrumentation and associated networks. These systems are generally developed and tested (factory acceptance testing) in isolation before delivery to site. filling machine. • Data acquisition systems linked to production systems. • Expert control systems. 8.g.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Control systems may be sub divided into two main classes: • Embedded systems. • Distributed control systems (DCSs). Page 50 of 104 . Standalone systems typically could include multi-loop controllers/PLCs used to control part of a process. packaging machine). • Standalone systems. and the multi-disciplined engineering effort to produce this associated life-cycle documentation will be the contracted responsibility of the supplier. and SCADA/DCS systems used to control the process plant as a whole. These systems may be integrated vertically with other management systems. A standalone system refers to control systems that are typically supplied to control or monitor and collect data from a process. and with embedded systems covering individual items of process equipment.2. Scope of Systems Covered Control system equipment typically includes the following: • Programmable logic controllers (PLCs). centrifuge. • Data historian/trending systems. An embedded system refers to control systems that are delivered as an integrated part of a piece of manufacturing equipment (e. • Loop controllers. and are generally supplied separate to the process equipment. • Supervisory control and data acquisition systems (SCADA). Typically for these systems the control system documentation and qualification will be combined with that for the overall equipment. Following delivery and installation. • Systems controlled by standalone personal computers (PC). acceptance testing and qualification with the process equipment is completed. Responsibilities should be clearly defined throughout the lifetime of the system. For systems where separate process and computer validation plans exist. the interfaces and responsibilities of the computer and process validation specialists should also be considered. Validation Life-Cycle The validation of control systems is one element of the equipment/process validation. • Site entry systems. Control systems validation should be in line with this guideline and support the process validation requirements. The following points provide some additional process control specific guidance for each of the life-cycle phases as described in Section 4. • Building management systems. the PLCs may be considered separate systems as they provided discrete standalone functionality. Examples of less obvious applications utilising control systems might be: 8. Systems Register The definition of what comprises a system needs careful consideration. 8.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION • 1205 JUNE 2002 Networks and interfaces within the process control system and to any other connected system. possibly systems integrators (configuring the systems). a managing contractor and project team. Page 51 of 104 . • Warehouse management systems. 8. user and QA/Validation roles should always be assigned.3.4. Where a large DCS is interfaced to embedded PLCs controlling process equipment. however independent developer. Responsibilities Particularly for large DCS systems there are likely to be multiple equipment/system suppliers.5. For less complex systems roles and responsibilities may be combined. 5. 8.3. e.g. it is important that the control system (high level) requirements are considered at this stage. For small process control systems. particularly during the IQ and OQ stages.5. may involve the development of a separate URS for just the control system. Control systems should be assessed for applicability with the electronic records. the validation activities may be encompassed within the overall project validation plan. 1205 JUNE 2002 Planning For projects where control systems are only a part of a larger project. For embedded systems the control system functions may be included within the overall specification for the machine or equipment. The user should specify requirements in consultation with developer/engineers.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 8. Supplier Assessments For embedded control systems it may be more efficient to have a combined audit to establish the supplier’s capabilities with respect to mechanical and electrical activities in addition to control system development.5. The physical parameters to be monitored/controlled and the data to be generated by a control system should be clearly documented during the specification phase. GQG 3202 provides additional guidance on ERES requirements. Requirements Phase The user requirements specification (URS) for large applications. The need to assess both the development and maintenance organisation should be assessed and documented in the validation plan. DCS or SCADA. These parameters and data should be Page 52 of 104 .1. The advantage of this approach is that it helps to focus the software developer on the control functionality aspects. Development and maintenance organisations may operate from different locations and to different quality management systems.2. 8. For systems where the regulations apply consideration as to how the system will comply should be included within the requirements and functional specifications. electronic signatures regulations. A separate requirement specification should provide appropriate production process and product information. electrical and mechanical details and performance requirements. Co-ordination of activities with those defined in any associated process/equipment validation plans is essential. This information provides the basis for the traceability of critical parameters and data through the design process to the final testing stage. The functional specification typically only covers the control system (i.g. sequence logic. device/interface logic. For embedded systems these documents may include the preparation of mechanical and electrical specifications/documentation. software and associated instrumentation specifications. trips and alarms etc. electrical or mechanical etc) and is often termed a functional design specification where it combines sufficient detailed design information for the system to be configured and built. This traceability can be documented as a requirements traceability matrix (RTM). 8. The functional specification often consists of multiple documents. some examples are provided below for guidance: • Embedded system. Page 53 of 104 . Typically a single document combining computerised system and overall functional specification (process.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 reviewed with regard to their overall function (GxP. • Small SCADA system. process control) and level of criticality.) for the equipment is appropriate.e. mechanical. not process. • Complex DCS. A categorisation of parameters and data should be carried out to ensure the design and testing of both hardware and software associated with each is appropriate for the function and level of criticality. safety/environmental. electrical etc. e.4. typically one for each process unit covered by the system and/or a functional specification for each area of functionality. Design and Code Phase Functional Specifications The structure of Functional Specifications should be tailored to suit the category and complexity of the system. Detailed Design The detailed design includes the production of hardware.5. there are likely to be multiple design reviews. Where the supplier has conducted code reviews. Design Review The fundamental purpose of a design review is to ensure that the user and functional requirements have been addressed satisfactorily within the design of the system. Mechanisms such as requirement traceability matrices (RTM) can therefore assist in the design review process. • Engineering line drawings/process and instrument drawings. The use of 'holds' within documents is recommended to allow work to continue. Code Review During the design phase the configuration languages and complexity should be considered in order to establish the approach to code review. For larger systems with multiple design documents. with each hold logged and subject to review once resolved. For embedded systems where there are no safety/operability issues. • Interconnection drawings. CHAZOP) should also be performed on the system.g. Page 54 of 104 . alarm settings. auditing should be considered to ensure that competent individuals have completed the reviews and that they are independent from those developing the code/configuration.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Control systems differ to IT and laboratory systems in terms of the direct interface to the manufacturing process and field instrumentation/plant equipment. Some form of hazard and operational study (e. • Loop/Instrument schedules and alarm/trip schedules. For larger and/or more complex control systems some detailed design information may not be available until later stages of the project. Within the detailed design therefore consider the following key documents: • Plant/equipment layout drawings. e. • Process description/sequences.g. design review may consist of a simplified process to ensure that GSK requirements have been covered within the supplier’s standard document set. Simulation tools are often used to simulate both the input/output (I/O) devices (instrumentation and control devices) and the operation of devices and process for example when the DCS sends an output to open a block valve. Where pre-installation test activities are well documented. Particular attention should be focussed on stress and boundary testing at this stage as performing such tests in a 'live' environment on process plant may not be possible.5. with supporting evidence and have been executed to the principles of cGMP. the corresponding confirmation inputs are transmitted back to the DCS by the simulation package. 1205 JUNE 2002 Development Testing Phase Testing of the system should be a combination of off-line simulation. • The nature and scope of changes required to the control system configuration for the simulation tool to operate (e. realistic and challenging tests to the control system software. itself alter the configuration of the control system.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 8. and integration testing utilising plant/equipment. • The simulation tool cannot. Page 55 of 104 .5. in order to demonstrate the operation of equipment under computer control. Thorough system integration testing and usually factory acceptance testing should be completed prior to delivery of the system to site. disabling of I/O scan blocks) are understood and documented. particularly in terms of stress testing where these could potentially cause damage to process equipment. It is not considered necessary to formally validate simulation packages where the following points have been addressed (see also guidance on software tools): • The system vendor has approved use of the simulation tool. • The use. scope and limitations of the simulation tool are documented.g. The use of such tools is generally to be encouraged as these provide the opportunity to perform more thorough. then these may be used to support OQ. This is particularly important for more complex systems such as DCS. Hardware and equipment IQ establishes that adequate documentation for the installation of the system is available. The configuration parameters of standard instruments should be recorded in the equipment IQ. the following: • Documentation describing all hardware components and any peripherals associated with the system including CPU. • List of instruments and field devices associated with the system. 8. hardware and equipment) has been installed according to the manufacturer’s specifications. but is not limited to. Simulation is not used instead of formal OQ and PQ in the 'live' process environment. A typical list of documentation that should be available for hardware and equipment IQ includes. etc. Page 56 of 104 .5.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Any configuration of the simulation tool itself is documented and verified. a list of manuals or procedures specifying how the equipment and process instrumentation will be maintained and serviced. printers. including security methods for computer hardware. and that the system is properly installed (as per the appropriate specifications). • Documents describing all electrical connections. Installation Qualification The purpose of IQ is to demonstrate that the system (including software. including grounding and shielding. • Documents describing all network and communication hardware (including for larger systems a network/topology diagram) associated with the system.6. • Documents describing all wiring and connections associated with the system. Deployment Phase Operational and Support Planning Control systems should have hardware maintenance and diagnostic procedures. interfaces and instruments. Data capture. • Documents describing the system’s total core and storage capacity as installed. Some examples are: Page 57 of 104 .GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 • Documents describing the actual accuracy of I/O devices and instrument associated with the system. power fluctuation (power supply stability). humidity. and verifying that devices can be operated (manually) from the system – note that this activity may be conducted as a separate activity. System tests should include testing the system under stress conditions where these cannot be effectively tested during factory acceptance testing. field equipment panel. dust. archiving and retrieval systems can also be tested within this phase. internal and external. electromagnetic interference and radio frequency interference (power line noise and required filtration). • Documents describing calibration requirements for associated instruments and equipment. This should be designed such that the testing covers the entire range of the system’s specified operating parameters and also demonstrates system repeatability over a number of test runs. to configure the system as specified. field sensor. • Documents describing switch settings. control device and alarm. including temperature. static. This aspect may also cover verifying display information. • Functional acceptance testing. Operational Qualification The purpose of OQ is to ensure that the system functions in the user environment as intended. This area will ensure that physical devices attached to the control system operate correctly and over the required ranges (may be termed hot loop testing). interlocks and any other safety/guarding devices. • Documents describing environment condition requirements for the system and associated equipment. • List of the loop drawings that indicate the writing terminal address on each process control panel. • Hardware and equipment testing. This area also includes testing of trips. For secondary manufacture.g. Pre-installation tests (e. − Verifying system operation with multiple operator requests. − Radio Frequency Interference (RFI). Page 58 of 104 . OQ will typically involve the use of placebo. Post Implementation Monitoring In addition to general areas described in Section 4. Electro-Magnetic Interference (EMI) susceptibility of the system. Frequently for control systems.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 − Verifying the full-scale measurement capability during hot loop testing. bottles. Where this is the case the associated validation documentation should have clear cross-referencing to indicate this. OQ1 and OQ2 and performed in conjunction with the process validation activities. OQ is frequently split into two phases. certain tests may only be possible within a simulated/environment off-line. boxes. Typically OQ1 includes all activities up to and including system testing using water runs in plant. consider the following: • Trips and alarms – frequency of nuisance alarms.. number of 'standing alarms' on the system. For many active pharmaceutical ingredient (API) manufacturing control systems (SCADA and DCS). OQ2 generally covers systems testing utilising solvent and commissioning batches. Factory Acceptance Testing) may be used to support (but not replace) OQ activities where these have been conducted to GxP principles. Performance Qualification This should always be performed at the user site and include testing specific to the user environment and defined ways of working. − Verifying the capability of the system to deal with multiple critical alarms. but not necessarily product. ampoules etc. PQ will be conducted as part of an overall process validation activity. • Operability – is the plant being operated in line with the original philosophy for example where a high degree of automation is available is this being used or is the plant effectively being run in 'remote-manual'. Further. Document Management Control systems are often dependant on documentation that is not 'owned' solely by the control system.5. 8. Cross Phase Activities Change Control.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 8. For control systems with non-standard data formats and hardware consideration should be given to migrating data to portable data formats (using a validated process) or retention of hardware to allow retrieval of data/records. process and instrumentation diagrams (P&IDs) and process descriptions. instrument/electrical schedules. • Configuration changes – inevitably with control systems minor configuration changes are required through the life of the system. 1205 JUNE 2002 • Are system maintenance and calibration (support) procedures being completed (including support agreements with system suppliers).9.5. Use Phase Operational and support plans are implemented as stated in the management principles. • Verify that the change control system is being adhered to and that the number of minor changes is not excessive. Consequently.7. 8. Engineering line diagrams (ELDs). raw data and system software (including configuration). Periodic review and revalidation will be conducted in accordance with criticality of the system to the production process. It is therefore important that a clear cross-referencing Page 59 of 104 .5.8. process or equipment change proposals should trigger an assessment of whether the associated control system requires modification. Management Configuration Management and Incident Changes to associated manufacturing processes or equipment are likely to have an effect on the associated control systems. Decommissioning For control systems with ERES functionality particular care should be given to archiving of the electronic records. For example. accuracy of process diagrams displayed on operator screens. these should be reviewed for any potential impact on the control system e. Where 'as built' changes have been included on documentation such as ELDs/P&IDs. Page 60 of 104 .GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 system is established to these 'external' documents (see also change control section above).g. 2. 4 SCADA system (no user defined macros) 1. 3 or 4 LIMS. Fieldbus devices) control multiple process parameters and implement control functions. 3. 3. 4 DCSs (customised e. Intelligent instruments (e. 3. Process control systems type Categories Loop Controllers 2 Smart Instruments (analogue transmission of variable) process 2 Smart Instruments (digital transmission of process variable) 2. 5 DCSs (standard configuration) 1. Page 61 of 104 . 5 Standard interfaces to other connected systems (e. The need to assess each system individually is still strongly recommended. Visual Basic routines) 1. 4 SCADA system (with user defined macros) 1. 4. 5 Data acquisition systems macros/programming) (configured. 4.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 8. but no user 1. 3 Intelligent Instruments (without control/logic functions) 1. 1205 JUNE 2002 Examples of System Categorisation The following list gives guidance on the expected categories (refer to Section 6) of some typical process control systems. 3 Intelligent Instruments (with control/logic functions utilised) 1.6. 5 PLCs (embedded system with no customisation 1. MRPII.g. 4 PLCs (customised system) 1.g. 4. MES) Bespoke/customised interfaces to other connected systems 5 Smart Instruments report one process parameter (on an exception basis the instrument can be interrogated for configuration such as range and engineering unit). 2. 4 Expert Control systems 1. 3.g. simple. Lotus Notes. process.1. for execution they rely upon the environment provided by the package from which they were created. • Created and supported by a user or user group to provide supplemental information processing or reporting capability not available in existing electronic or paper systems. and low impact applications. number of users. This section of the guideline addresses validation of the application created by using such packages and not the package itself. Page 62 of 104 . Exclusions from the scope of this guideline include: • Software developed in a traditional programming language such as C++ or the 'stand alone' Visual Basic development environment. Another common example is user scripting of report queries for systems that may be under the control of another group. In comparison to purchased software systems or those developed by internal groups such as IT. such as IT. • Are typically not 'stand-alone' programs. This guidance is intended for relatively small. desktop applications are usually smaller in terms of code volume.2. MS Access. and report writer packages for databases. such as MS Excel. • Configured and/or created using the development capabilities provided within COTS packages on standard GSK PC builds and IT approved software. complexity. or store electronic signatures. and robustness of features or functionality provided. configuration) or extension through software development (i. Definition of Desktop Applications The name desktop application identifies software that is the result of a user’s adaptation (i.e. MS Word. entry of calculations or macro coding) of readily available software packages. • Applications that employ. MS Access. 1205 JUNE 2002 Approach to Desktop Applications 9. such as Oracle. Common characteristics of desktop applications are: 9. The most common examples of packages from which desktop applications are created include MS Excel.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 9.e. or Lotus Notes. Scope of Applications Covered Several packages such as MS Excel are available to the GSK user community via the standard Desktop configuration. g. Word processor and spreadsheet packages (e.g. Page 63 of 104 . The files created by these packages to provide typewriter functionality are not considered desktop applications and do not require validation. interfacing LIMS with a network chromatography system). The QA/Validation role can be assumed by someone in a department that is responsible for quality (e. QA/QC laboratory personnel) or a member of the local QA/Validation staff.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION • 1205 JUNE 2002 Applications that interface systems that are not desktop applications (e.e. validation of all components should be addressed as part of the larger system.g. The inclusion of calculations. 9. since there is no additional coding or configuration to specify. such as creation of documents with MS Word for management within an electronic document management system (EDMS). and Support/Maintenance. Responsibilities For smaller desktop applications. MS Word and Excel) are often used as electronic typewriters to create simple output such as reports and forms. information that is not processed by the software package. These roles may also be assigned to one. The specific assignment of personnel to roles should be defined during validation planning. appears too complex or large for validation as a desktop application. project manager. A person should never sign as reviewer or approver of their own work.3. review and test. which are expected to be the majority of cases. it would be unreasonable to replace the sophisticated features and controls of a commercial LIMS system with a series of MS Excel macros or a MS Access database. automated graphs. Where files created by packages are used in the context of a larger system. Authors should be competent in the development and/or configuration capabilities of the packages from which they develop desktop applications. consult local procedures or QA/Validation staff for further guidance. independent review is required. which is to be created with a package such as MS Excel or MS Access. Further review is advised whenever an application. two or three different people depending on the complexity and size of the effort. automated data extraction/reduction or any other programming logic such as macros indicates creation of a desktop application and the typewriter exclusion is no longer applicable. roles may be combined such that the author performs the roles of User. For example. When in doubt on the applicability of this guidance for a specific application. i. However. Such a determination suggests a poor fit between the technology and the intended functionality. printing and retaining verified spreadsheet formulas) rather than adherence to a life-cycle.1. the GxP significance of any systems the desktop application interfaces to should be considered in the assessment. Where this approach it taken it should be documented in a rationale approved by QA. The decision that the desktop application is one-off or non-GxP should be agreed between the user and local QA/Validation personnel. 9. The one-off approach may also be appropriate for easily verified applications that will be used indefinitely. 9. Since desktop applications often interact with or report data from other systems. The approach for one-off desktop applications is based on a complete review of the results and retention of evidence to support that review (e. Validation Life-Cycle Two approaches to desktop application validation are provided. Page 64 of 104 . Compliance Assessment and System Registers The determination of GxP significance for desktop applications should follow the same rules and logic as other types of applications. ERES should be considered as per GQP/G 3202. 1205 JUNE 2002 System Register A list of desktop applications requiring validation should be maintained on a system register (see Section 3).GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 9. It is expected that QA will be consulted for determination of GxP significance of systems/software. A key difference for desktop applications is that individual written assessments of GxP significance and systems register entries are not required for one-off and non-GxP desktop applications.4. The approach for desktop applications not considered one-off will broadly follow the validation life-cycle described in Section 4 but guidance is provided for streamlining activities in accordance with the scale of the application.5. Instead a single entry in the system register (with associated compliance assessment) can be made to capture certain types of non-GxP desktop applications such as non-GxP spreadsheets applications (see Section 3). Desktop applications such as spreadsheet and databases however are extensively used applications and the vast majority do not require validation.5. for example. As a consequence it may only be practical to list those requiring validation on the system register. one for very simple 'one-off' applications that are typically used once or a very limited number of times and another for more complex applications that are difficult to verify or will be used for an extended period of time. a spreadsheet that simply reformats a small amount of information from another system.g. The type and detail of specifications and testing should be planned in accordance with the expectations of the applicable software categories. simpler) processes may be established for a specific application or group of applications as long as they satisfy the content expectations of Section 4 and are defined during validation planning or local procedures.2. Alternatively.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 GxP desktop applications that are not one-off should have a written assessment of GxP significance and be maintained on a systems register in the same manner as other systems. Planning The decision to validate using the desktop application approach should be documented in a compliance assessment. Desktop Applications (Not One Off) The validation life-cycle is broadly in line with the model specified in Section 4 of this guideline. Validation plans should be prepared as described in Section 4. This guidance provides a means of scaling the general life-cycle expectations to desktop applications. A key difference from other systems. more focused and streamlined (i.e. More complex desktop applications. the activities up to test execution may be combined within one document. is that the desktop applications are usually so small and simple as to warrant overlap in the phases and combination of most activities. Desktop applications may be controlled using change control. 9. For example. such as databases or spreadsheets with macros. configuration management. such as LIMS or networked chromatography data systems. Local procedures may be used as 'generic' plans or controls for desktop applications in cases where little or no variability would be expected if separate plans were created for each application. such as a spreadsheet that only calculates linearity. Considerations for Documentation Efficiency Activities for the phases up to but not including the execution of test plans/cases may be combined commensurate with the size and complexity of the application. separate specification and design documents) due to the higher level of complexity and inherent risk of expending a significant volume of effort without review/approval of preceding life-cycle activities. For the simplest of applications. will require more granularity (e. a generic validation plan could be embodied in a local procedure to address the needs of most MS Excel spreadsheets. and incident management methods already established for other types of applications. Implementation of such Page 65 of 104 .g.5. Documentation may be stored locally to the user or maintainer but should be kept in a secure location. system requirements.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 controls may be as simple as a version log sheet for configuration management of a spreadsheet application. e. testing of the resultant application implicitly verifies the integrity of the underlying package further minimising the value of auditing the package supplier. Specifications and Design Review The desktop application may be so minimal that creation of separate User/Business requirements. desktop applications are internal systems developed by company staff using well-known. These sections may be combined into as little as one section of one document as long as this approach is addressed during validation planning and all applicable Page 66 of 104 . A generic ERES assessment report may be used for all desktop application used by the site provided they are managed/controlled using the same desktop application validation procedure and stored in the same qualified server.g. system overview and data definition sections would needlessly replicate the same information. Electronic Records and Electronic Signatures Desktop applications should be assessed in accordance with GQP 3202. such as adding one or more worksheets to a MS Excel workbook. Printing out and signing the applicable components constitutes approval of such embedded documentation. packages with development and/or configuration capabilities. Additionally. Specifications for desktop applications that include electronic records should include the requirements identified in GQP 3202. functional requirements. Supplier Assessments Supplier audits will generally not be required for desktop applications. By definition. locked cabinet. Inclusion of the life-cycle documentation within the created application. The extent to which intended functionality of the desktop application can be fully qualified through testing should be considered in the audit decision for these exception situations. Any system that employs electronic signatures should not be validated as a desktop application. The purchase of externally developed applications and the application of new packages with limited quality history are exceptions in which audits should be considered. is allowed when supported by the package. widely available. a review of that code should be performed to determine the following: • The code conforms to the specifications. Any configuration should be reviewed to verify the intended function of the application. • Appropriate header information in software listings such as author. unused options should be disabled through configuration. Design review should be conducted in accordance with the guidance provided in Section 4 but the summary of the review.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 information is included. When disabling is not allowed by the desktop application package. may be included in the Specifications documentation. Code Review and/or Configuration Review When the desktop application includes development of bespoke/custom source code. A separate design review report is suggested only for the more complex desktop applications. Page 67 of 104 . Whenever possible. Configuration and System Build Coding or configuration prior to design review is acceptable for simple applications in which there is minimal time lost and minimal risk if the application does not provide the intended functionality. clear user instruction should be provided to ensure only the appropriate options are utilised. Unused options are not considered dead code. A suggested title for the composite description of this information is 'specifications. and change information are provided. When configuration results in the creation of code. and any planned remedial activities to address deficiencies. that code should be reviewed in accordance with guidance immediately above. Coding. Additional programming guidance or standards should be considered for more involved desktop applications such as databases and complex spreadsheet macro programming.' Literature references to support calculations or other specific requirements should be used rather than replication of the information in the specifications when the source documents are controlled and maintained to appropriate retention schedules. This exception is strongly discouraged for relatively complex applications such as those requiring more than one or two hours of development and testing effort. version. • The code is free of non-executable (dead) code. The OQ and PQ information may be combined within one section of documentation. • Verification that installation was in accordance with those instructions and the environmental requirements. or loaded on other computers prior to their production use). version of MS Excel for which the application has passed testing and any applicable hardware standards). and Performance Qualification Separate documents titled IQ.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Review results may be documented by as little as one or two sentences that reiterate the objectives of the review and that the conditions have been satisfied. IQ documentation should. and PQ are not required for simple desktop applications if similarly named sections are included within other testing and deployment phase documentation.g. The approach to testing and any combination of activities and deliverables should be addressed during the validation or test planning activities. moved to designated folders. For example.g. provide the following: • Identification of environment requirements for the application (e. Page 68 of 104 . it is anticipated that the general guidance for the development testing phase (see Section 4) will be applicable but additional types of testing are not required if they would simply repeat prior testing or are inappropriate for the application. • Identification of all computers on which the application is installed. With rare exception. Operational. Installation. at minimum. Installation instructions and operating environment information are not required for applications that are tested in the environment they will be used (e. GxP desktop applications should be used on validated servers or PCs. OQ. Development Testing and Deployment Phases Test plans and cases for these phases may be consolidated into as little as one test script for very simple applications and may be combined with prior activities as long as the test documentation is approved prior to execution. simple spreadsheets that are not copied. • Instructions for installation of the application. integration or interface testing is unnecessary for a small spreadsheet. GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 OQ testing is not required if development testing fully addressed all specifications and was conducted under normal operating and stress conditions. OQ testing is encouraged under the following conditions: • The target environment is different from that in which prior testing was conducted (e.g. different version of operating system or MS Excel). • Single user testing was conducted however, the application will be used by multiple users (e.g. multi-user database). • The application will have interactions with other systems that were not simulated in prior testing. PQ is not required if prior testing is performed in the environment in which the application will be used. This exception should be justified during validation planning. Complexity, function, the extent to which prior testing covers the User/Business requirements, and the added value of parallel running with any displaced manual ways of working are also key considerations when assessing the need for PQ. For example, there is likely little value in PQ for a two-calculation spreadsheet but a multi-user database that replaces several paper processes is a strong candidate for PQ. User Procedures and Training User procedures and training can be as minimal as instructions embedded within a very simple spreadsheet. A slightly higher level of application complexity might combine the embedded instructions with a brief walk-through of the application. The most complex desktop applications should adhere to the guidance for formal procedures and training provided in Section 4. For example, procedures and formal training may be established for a multi-user database system and become part of a department’s training curriculum whereas a much simpler spreadsheet application may only include a few instructions viewed at the top of a spreadsheet when opened. The appropriate method of training and control should be considered during validation planning and the users should know of any required training or applicable procedures prior to using the application. It is recommended that contact information be provided either within desktop applications or local procedures for user questions, suggestions, or problem reporting. Page 69 of 104 GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Backup and Data Archival/Retrieval The primary considerations for maintenance are backup/restoration of the application and data. If the application does not store data then periodic backup and data archival are not required since applications can be restored from the backup performed at the conclusion of validation (the master copy). When required, the method by which both the application and any data are backed-up and restored should be addressed by procedure. Procedures for these activities should address the needs of the application but, for flexibility, are not required to be specific to a particular application. For example, a department or site may establish a backup/archival/restoration procedure applicable to all spreadsheets. However, the person responsible for each application should be readily identifiable (documented using a logbook or other means). Such procedures should ensure retrieve-ability of any electronic records throughout the applicable retention period. The regulatory expectations for retention of electronic records created by desktop applications are no different than other types of systems. Security Management Desktop applications should be protected from both alteration of the application itself (source code and/or configuration) and any stored data. To the extent possible, applications that store data should use the security mechanisms available in the underlying package to preserve application and data integrity. For example, MS Excel password protection can be employed to lock all but input cells, protect the workbook structure, or save the file as read-only. Databases should be configured with differing levels of access security tailored to the actions that will be performed by various users. The security of many desktop applications can be tremendously improved by placing the application on servers with managed access control. Security for the servers should be configured such that users can access the application in read-only mode or make a one-use copy which they delete after results are reported. For example, a validated spreadsheet with a macro for extracting and trending sample results from a LIMS database placed on a secure server, executed from that server to create a report, and then closed without saving of results due to the read-only status of the server directory. Administrative or master passwords which allow users to modify the application or make data changes outside the intended control of the Page 70 of 104 GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 application logic, should be restricted to defined roles responsibilities for maintenance of the applications. Such passwords should be kept secret and known only to the define individual. It is recommended that such passwords be changed upon completion of validation and strictly controlled thereafter. An example control scheme would be to store the password in a confidential envelope in a locked cabinet accessible only to the application maintainer. A history of password access and changes could be kept on a log in the same envelope. In exceptional conditions, such as the maintainer forgetting the password or leaving the company, the password could be retrieved from the sealed envelope. Password sharing is not recommended but may be necessary for some packages that do not allow multiple accounts for administration activities. While technical controls such as password locking are by far the preference, procedural controls may also be used to enhance the security of a desktop application. The more limited the available technical controls the less appropriate it is to introduce or continue use of the application in the regulated environment. All security mechanisms should be identified in the planning phase and subsequently tested or verified. The testing and verification should address both the security features that are designed as part of the desktop application itself and any configured environmental controls such as access rights for an application placed within a read-only server share. Consult local QA/Validation and IT staff for guidance on locally available environmental security options (e.g. administration of secure area on local server) and additional guidance on securing your specific desktop application. Periodic Review, Revalidation, and Business Continuity Plans Periodic review is required but may be as simple as a statement reflecting that the operating history of the application has been reviewed and the application continues to satisfactorily provide the intended functionality. Revalidation is not required but should be considered where the results of periodic review are not satisfactory. The revalidation effort may be as simple as documenting the re-execution of a set of test data. However, multi-user database systems and similarly complex systems will require more comprehensive revalidation actions that should be commensurate with the complexity and function of the system. Business continuity planning is not required but should be considered for systems where reverting to manual processes is not feasible. Page 71 of 104 documented hand-over to personnel that can ensure availability throughout the required retention period. Decommissioning Special consideration should be given to ensuring retrievability of desktop applications after their decommissioning. The systems register should be updated to reflect the decommissioned status of the application. Archival of the software package required for execution of the desktop application. the decommissioning process should ensure that all documentation can be identified. Post Implementation Monitoring Post implementation monitoring should be considered only for the more complex desktop applications such as multi-user databases. For example.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Validation Report It is recommended that the validation report follows the same structure and format as the validation plan. For simple applications. It is critical that the document containing the validation report information be signed-off prior to use in the end-user environment. Page 72 of 104 . for example a specific version of MS Excel. located and retrieved by persons other than those that created and maintained the application. For example. if the complexity of the application requires a separate validation plan then a separate validation report is anticipated for consistency. should also be considered to ensure operability of the retrieved application. it is common for only one or two people in a department to be aware of a desktop application that performs critical calculations for product release decisions. It is recommended that the archive and decommissioning process include formal. Cross Phase Activities All cross phase activities described in Section 4 apply (including requirements traceability matrix) but may be scaled to size and complexity of the application. In addition to archival of the application and any associated data. the application can effectively disappear once the limited number of knowledgeable personnel have left the company or taken other positions. If decommissioning is not properly managed. the validation report information may be combined with other deliverables in the development testing (execution/results) and deployment phase. GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 9.5.3. 1205 JUNE 2002 Considerations for One-off Desktop Applications The following items are recommendations for qualification of one-off applications to alleviate full life-cycle documentation requirements: • The intended functionality of the application should be clear and unambiguous to ensure appropriate manual verification. The presentation of this information may range in formality from the clear labelling of columns within very simple spreadsheets (e.g. 'average') to separate requirements/specifications documentation, as appropriate for the complexity of application functionality. • 100% manual checking (verification) of input data and processing actions (e.g. spreadsheet calculations or database functions such as record count) should be performed at each use of the application. Someone other than the user should perform the check. The processing provided by calculations and/or functions that are used multiple times should be verified only once with subsequent uses verified to ensure accuracy of the copy and applicable data references. • The output should indicate how the verification was performed and include the dated signature of the person that performed the verification. An explanation of the meaning of the signature should be provided (e.g. a statement indicating all input data and calculation results have been manually re-calculated to verify their accuracy). • Printouts produced as part of the qualification, such as spreadsheet formula with manually calculated results or report query listings should be retained with the report printout. • The qualification process, including considerations for the accuracy of transcribed information and calculations, and any other required documentation should be addressed in local procedures. This approach is only suitable for applications that lend themselves to manual checking such as those that are very simple and/or infrequently used, e.g. spreadsheets containing a few calculations for a low volume product. For example, ad-hoc queries for databases with thousands of records are not good candidates due to the difficulty in verifying that all intended records, and only the intended records, are included in the reports. The practical limits of a user’s ability to verify large and/or complex volumes of information such as frequent Page 73 of 104 GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 manual recalculation of Fourier transform results may also affect whether this approach is appropriate. 9.6. Examples of System Categorisation Desktop applications typically involve three types of software: an operating system, a commercially available 'standard' configurable software package such as MS Excel or Lotus Notes, and the desktop application which results from configuration and/or bespoke/custom coding of such a package. The table below provides guidance for application of the software categories (see Section 6) to desktop applications. Desktop Application Categories Spreadsheet Applications (no user configuration) 3 Spreadsheet Applications (user configuration of standard functions) 4 Spreadsheet Applications (user defined macros/programming, e.g. VBA macros or calculations, report queries developed with SQL, any other bespoke/custom programming) 5 Database Applications functions) standard 4 Database Applications (user defined macros/programming, e.g. VBA macros or calculations, report queries developed with SQL, any other bespoke/custom programming) 5 Statistical Analysis Package (user configuration of standard functions) 4 (user configuration of Many desktop applications will be the result of both configuration and bespoke/custom programming for example, a spreadsheet containing a macro written to retrieve and parse data from an external source (custom component) and then average the data by use of standard functions (configuration component). Each component can be considered separately and validated in accordance with the appropriate validation strategy for the component (see Section 6). Many packages provide 'wizards' to configure an application or extend functionality through assisted code creation. In general, the use of Wizards should be considered as a configuration activity. Wizard generated code which is modified by a user should be considered bespoke/custom as should a complete 'stand alone' application which does not require the presence of the 'parent' software package (e.g. MS Access) to execute. Page 74 of 104 GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 10. Approach to IT Systems 10.1. Definition of IT Systems IT systems can be characterised as networked applications used within a multi-user environment that encompass a range of business and GxP critical activities. They are commonly referred to as business or information systems. A key characteristic of IT systems is that they are usually networked applications that operate in a multi-user environment. As such these systems are dependant upon a supporting network and IT infrastructure for their operation. Typical business processes managed by an IT system include but are not limited to inventory management, capacity planning, master production scheduling, sales order processing, materials requirement planning, purchase order processing and shop floor control relating to the manufacture and distribution of bulk drug substances, intermediates and finished packed stock. 10.2. Scope of Systems Covered The following are examples of IT systems covered by this guideline. This list is not exhaustive: • Enterprise resource planning (ERP). • Manufacturing resource planning (MRPII). • Laboratory information management (LIMS). • Electronic document management systems (EDMS). • Financial planning and management. • Engineering maintenance management system (EMMS). • Distribution Systems. • Schedulers. • Financial systems. • Purchasing systems. • Human Resource systems. Page 75 of 104 4. 10.3. Activities to ensure ERES are met (e. This guideline outlines validation expectations that should be considered alongside the procedures embodied in the selected IT quality system. Compliance Assessment Compliance Assessments should be used to document whether any aspects of a computerised system have GxP impact and hence require validation. iQMS) should be used for the development and implementation of IT systems. compliance assessments. Particular consideration should be given to duplication of electronic records across systems and also distribution of component sub-records across systems and how they are synchronised.5. System Register Central IT support organisations as well as operating sites should maintain system registers. 10.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 The inter-relationships between IT systems can make it difficult to scope the boundaries for validation. The System Register should indicate whether any aspect of a computerised system has GxP functionality. Guidance on dividing interconnected IT systems into GxP and non-GxP is provided in GQG 1401A. Responsibilities An approved quality system (e. Planning Phase Business Requirements Business requirements must clearly scope what are often networked systems with numerous interfaces. Where ever possible records should be linked rather than duplicated to clarify status of master data.5. 10.1. Electronic Records and Electronic Signatures Assessment IT systems used in GxP applications that contain a number of electronic records or electronic signatures must comply with GQP 3202.g. Advice on desktop applications.g. IT infrastructure and software tools that might be associated with an IT project can be found elsewhere in this guideline. Early consideration of archiving requirements Page 76 of 104 . design reviews and testing) should be built into the validation plan. Validation Life-Cycle 10. requirements specification. It may be necessary to consider the development of a hierarchy of validation plans that define the generic project validation activities and documentation and the specific site activities and documentation. The requirements for IQ. OQ. Validation Planning Site validation plans may leverage information from related quality documents such as project quality plans and deployment plans developed by central projects. GQG 1401A can be used to assist the identification of GxP and non-GxP functionality. acceptance testing and post deployment review for IQ. and PQ however should be reviewed to check whether supplementary activities are required. Particular attention should be made to interfaces between IT systems when defining the validation scope. Systems integrators often employ their own development methodologies. validation plans.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 is recommended as this may affect the architecture and design of the final system. Site validation plans should use terminology familiar to their respective regulatory authorities. Further leverage can be made of technical installation. where necessary. specify any enhancement to meet pharmaceutical industry standards. The potential impact of non-GxP critical functionality on GxP critical functionality should be clear before a validation strategy can be developed.g. OQ and PQ respectively. Page 77 of 104 . Many IT systems have a multiple site implementation. IQ. Any reporting requirements necessary to authorise a phased release of the IT system should be defined. Validation plans should take account of the different categories of software comprising the IT system and the mix of GxP critical functionality and non-GxP critical functionality. The validation plan should clearly define the scope of the IT systems to be addressed. Careful consideration should be given to the deployment strategy. PQ and validation reports. Validation plans should document this relationship and. e. The relationship between core project team members and site project team members should be clearly defined. Consideration should be given to the organisation of the validation team and how the needs of each business and/or site are met and how consistency is to be maintained considering different cultures and working practices at each site. OQ. Such methodologies should be reviewed in order to determine their relationship to GSK methodologies and validation life-cycles. a number of user (system) requirements may be needed in order to convey the system and functional requirements to a system integrator or supplier. Supplier Assessments should focus on products (including specific versions) in addition to quality management systems. prototyping may be used to support the development of requirements specifications. Requirements should be uniquely referenced in order to facilitate the development and maintenance of a requirement traceability matrix. • Support organisations. Consideration should be given to the impact of such observations and additional validation activities and operational controls required to minimize their impact until such times that a future release of the product is deployed.5.2.3. however. Development of user requirements may be phased in accordance with the implementation plan. Page 78 of 104 . The validation plan should define the strategy and scope for conducting supplier audits in addition to the rationale for not auditing particular suppliers.5. The need to assess the following should be considered: • Business consultants. Requirements Phase For IT systems. For standard software products. Supplier Assessments The scope of supplier audits is often greater for IT systems than other systems. • System Integrators. such tools should not be used to implement the IT system.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 10. Development and support organizations may be located in different countries/sites and may be working to different quality standards potentially increasing the scope of audits required. e. • Hardware suppliers.g. observations against the quality management system or product may not be addressed until future releases of the product. Methods and tools e.g. planning. materials management. 10. maintenance management. • Application suppliers. Requirements specifications may be based on application modules. For large IT systems. These may be organized at the module level (e. design documents are consistent and complete. with field format and data lengths provided for each field name. Reference should be made to GQG 3202.5. database table name. record life-cycles. tables. System Overview A system Overview should be developed for the IT system. Development of the system overview should be started as early as possible. and selection criteria for view. Design and Code Phase Design methodologies may differ from application to application or supplier to supplier. Where modular overviews are developed.g. database schema. to ensure that it reflects the final system. Record life-cycles should include indications of steps involving record authorisation and approval.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 10. Data dictionaries. networks) should be included.4. Page 79 of 104 . data distribution across systems and data security should be defined. Relevant design for IT infrastructure (e. separate system overviews may be developed at a modular level. A listing of all database views. Typical design documentation should be reviewed in order to ensure that irrespective of methodology used. they should be clearly cross-referenced. The methods and information required for the audit trail should be stated as required by GQG 3202. Data Definition Data definition for an IT system is usually a major component of the design. Package configuration and programming standards should be documented. the following should be included: view name.g. Indexes. indexed tables and indexed fields should also be included. An assessment should be made of the GxP nature of data (or information) in order to determine the degree of data migration validation required. Design Specifications Multiple design specifications are often appropriate for large IT systems. This document should be further reviewed and amended when the system is approved for use. and indexes comprising the system should be prepared. For database views. field name. Unit Specification). For database tables the following should be included: table names and field names. Configuration and System Build and Code Reviews Bespoke/custom developments and GSK specific configuration and customisations should be developed in accordance with defined programming and configuration standards as indicated in Section 4. Customisations e. Documentation should cover unit testing and system testing for in-house developments.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Where data is to be migrated from a legacy or manual system the mapping of legacy system data structures to new data structures should be defined along with any automated or manual data translations. extensions to tables and development of SQL scripts however. Installation of hardware and software should be recorded to assure that the environment upon which pre-installation testing takes place is a match of the operating environment.g. may not be controlled by tools that impose such configuration standards. Design Review Design reviews may be known as design qualification.5. Such tools often impose configuration standards on the developer. All GxP critical configuration and customisation should be subjected to configuration and/or code review (i. This is normally involves an IQ for the development environment. quality and business representatives should be involved in the review. The impact of migrating electronic records should be assessed and the rationale for continued integrity of the electronic records documented. Coding. Configuration is often implemented under the control of configuration tools that form part of the standard IT system product. Testing should include screen navigation and screen flow testing and error message testing. The adequacy of the system integrator’s/supplier’s configuration/coding standards should be assessed prior to commencing code/configuration development. Appropriate technical. Development Testing Phase Pre-Installation Testing Pre-installation testing should ensure that new code and configuration functions in accordance with the design and that test business scenarios are successfully processed.5. Page 80 of 104 . source code review). 10.e. It may be necessary to have a period of parallel operation until the performance of the replacement system can be determined (see performance qualification).5. IT systems are generally associated with management of the business and therefore cut-over from legacy systems to new systems should be carefully managed. Testing of interfaces to other systems is critical before go live. business continuity and contingency plans are still needed including procedures for reverting back to the legacy system in the event of a disaster.6. however.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Custom code and configuration should be subjected to unit and integration testing. Often systems will not be run in parallel for practical reasons. Interface testing should be carefully planned in order to ensure that parallel projects are synchronised so that testing can proceed when required. Deployment Phase The deployment phase essentially takes what is delivered from the Pre-installation phase and ensures successful operation and maintenance of the system. a plan of deployment phase activities is needed in addition to the validation plan. A minimum period of outage between the shutdown of the legacy system and start-up of the replacement system is required. Interface testing should verify: • Transport file security. Test specification standards employed by system integrators and suppliers may not meet the requirements of the pharmaceutical industry. 10. • Data mapping. early understanding of how expectations will be met is necessary. Unit and integration tests should ensure that the developed/configured functionality meets design specifications. As such. The plan should address both IT and user deployment activities. • Transfer synchronisation. IT system interfaces generally involve the transfer of files from one system (server) to another. This can be achieved either by system integrators/suppliers raising their standards or additional test specifications being developed to replace or enhance those from the system integrator/supplier. Page 81 of 104 . Often. Such interfaces may be to existing systems or new systems being developed concurrently. • Data translation. Where migration routines are fully automated and validated. Data manipulations conducted during the load/migration process should be fully understood and documented. greater volumes of data may be migrated to enable comprehensive testing of business scenarios. • Data archiving. purging of test data prior to migration of business data). reviewed and validated as appropriate. A final data load/migration will be required prior to system cut-over in order to synchronise data between the new system and legacy systems. migration of a limited sample of data may take place to enable early testing. Historical data may not require migration to the new system and may be archived. consideration should be given to the currency of data. The design phase should have previously considered data migration in terms of: • Data sources (including source verification). As testing progresses. Consideration must also be given to archived data. Archived data will be in the format of the legacy system. yet Page 82 of 104 . • Manual entry and manipulation of data. Initially. All data migration routines should be documented. Validation of automated data load/migration tools should be considered and the requirements and timing of the validation should be addressed by validation and project plans. When migrating data from a legacy system.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Data Load Data load/migration often takes place in stages. Statistical rationales should be used to justify different approaches data load verification. Where data is migrated from a non validated system consideration should be given to how the data will be verified. • Data cleansing requirements (e. Where data load involves manual transfer or entry of data. all GxP data should be at least double-checked to verify it is correct.g. • Automated migration routines. • Mapping of data between systems. it may be appropriate to consider statistical sampling of migrated data especially for large volumes of data. terminology. − Resource to deliver training. Training issues include: − Generic and business/site-specific training needs. templates. internet and firewalls. − Users accessing information across a wide area network. • Security Management Security Access is a key issue. They should match training and be appropriate to job roles of users. roles and responsibilities and as such User (and other) procedures should take account of differences. such considerations should be built into project plans. − Critical data being transferred across a wide area network. − Tracking of training plans. As IT systems are often deployed across multiple business and sites. Training considerations must be considered early in project plans. − Training of Support organisation. • User Procedures It should be recognised that different businesses and sites of GSK have different standards. Page 83 of 104 . • Operational and Support Plans Operational and support plans (sometimes referred to as post deployment review) should state how the validated status of the IT system is to be maintained. Additional considerations for an IT system are: − The use of intranet.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 should still be retrievable for the retention period dictated by regulation. User profiles should be defined and maintained. • Training Training may be a major undertaking for a global IT project. − GxP systems require documented job roles and training records. Page 84 of 104 . consideration should be given to how knowledgeable resource may be made available to support site inspections. Also. • Availability of Software and Reference Documentation Regulatory inspections are largely conducted with a site focus. Consideration should be give to the availability of global documentation for a site inspection. − Migration of archived records following system upgrade. service level agreements and operational level agreements. Business continuity plans (also known as system continuity plans) should address the immediate and higher risks following cut-over. In the event of a catastrophic failure. − Ready retrieval of archived records for the defined retention period. • Service/Support Transition Plans Service requirements. and transitions plans should be developed where IT systems are handed over to service/support organisations. reverting to a legacy system is one option for consideration.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Central and site based procedures should be established to ensure that functionality and data is only accessible to authorised personnel. Service implementation plans. Consideration should be given to: − Which records are GxP (and business) critical? − Appropriate archived media (volume and integrity)? − Archive frequency (business risk). • Business Continuity Plans The risk of system failure during operation must be managed. service models. • Data Archiving and Retrieval Archiving of GxP records and data is a major consideration for an IT system as large volumes of information are involved. however an inspection may investigate the validation of a global IT system in use on the site. service readiness testing. • Phasing of installation with concurrent related projects. • Site specific records/templates. IQ for core components should include software installation procedure and expected outputs. The plan should also state the tools to be used to make changes. installation job logs. etc. IQ of hardware should include the recording of all appropriate and accessible part numbers and serial numbers. e. • Maintenance As with other activities.g. configuration and hardware have been correctly installed into the operating environment. Installation Qualification IQ should ensure that the IT system software. • Installation and interfacing of clients and servers. Consideration should be given to those IQ and OQ Page 85 of 104 . are there multiple network connections to enable new clients to be connected before legacy clients are removed). central and site responsibilities should be defined.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION • 1205 JUNE 2002 Configuration Management Plan This plan should state how changes are to be made and by which groups. • Phasing of installation with respect to ongoing legacy system operations (e. Particular considerations for IT systems include: • Organisation of IQ for core components of the system and site-specific components. IQ activities can leverage installation plans and reports if available.g. Central and site-specific backup needs should be established and the adequacy documented in the validation plan. • Backup and Restoration IT systems largely reside on central servers that are backed up in accordance with central systems. exception reports. Site specific components should take into account the operational environment of the system. IT systems often require the deployment of 10’s if not 100’s of PC based clients. OQ at this point is synonymous with acceptance testing. all GxP scenarios should be tested. As the validation at this point is not necessarily complete a system release note or Interim validation report should be prepared in order to authorise system cut-over. This should normally involve 'end to end' testing of business scenarios using a replica of the current legacy system database (or a fully populated new database for non-legacy systems) and SOPs designed for the new system. OQ tests should be designed to challenge as many permutations of the business scenarios as possible however it may not be practicable to test all permutations prior to cut-over. Involvement of users in the OQ also provides additional system familiarisation and training. SOPs. Installation of client front end should be covered by defined. A system release note may be issued to authorise progression to PQ. Operational and support plans should be in place before authorisation of cut-over. Page 86 of 104 . As a minimum. including operation and maintenance. Actual users of the system should be involved in this testing as they have knowledge and experience of current systems and processes and are able to identify issues not previously identified. System Release System release to the live environment normally occurs following OQ of an IT system. When all scenarios cannot be tested. the worst-case situations should be used. should be verified during OQ.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 qualifications that need to be conducted at the point of installation and what qualifications can be conducted within a controlled desktop environment prior to deployment of the client (see Section 11). approved procedures. Operational Qualification OQ for an IT system should include demonstration that business scenarios are successfully processed within a normal operating environment. using test data-sets. OQ testing should be conducted within the final operating environment but should be conducted before the system is made live. Validation reports can leverage quality reports where available. • Performance of system interfaces. The validation report should respond to the site validation plan and the generic project validation plan. • Close out of issues/resolution of faults. • Measure of the issues/faults raised when the system is in use. This should include: • Audit of the system.g. PQ should consider: • Tracking all permutations of business scenarios (e. e. It may be appropriate in some cases to perform product performance PQ in conjunction with OQ.g. for a corporate labelling system this would be when all combinations of label formats and product information have been generated). That part of PQ relating to process performance is sometimes referred to as post implementation review or post deployment review.e. • Monitoring the performance of systems when there are many concurrent users (i. difficult to monitor performance of system for 50 concurrent users under OQ conditions). This generally involves running the system under the control of normal SOPs and tracking certain events and performance conditions. Where parallel operation is required (see introduction to deployment earlier in this section) the following considerations should be made and documented: • Which system holds the master data for the purpose of decision making? • What are the infrastructure implications? Page 87 of 104 . Consideration must be given to the phasing. Validation Reporting Multi-site IT systems may be deployed in a phased manner. a validation report should be considered for each site or business.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Performance Qualification PQ for the IT system should be conducted under live operating conditions. location.7. 10. Decommissioning Due to the volumes of data and records involved. Consideration should be given to: • GxP records and their required retention period. • Update of the system register. Cross Phase Activities Cross phase activities should include document management. incident management. storage. archiving and decommissioning is a major consideration for IT systems. • Archive management procedures (media.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION • How will the parallel systems be synchronised? • What are the system interface implications? • What are the resource implications? • What are the procedural implications? 1205 JUNE 2002 10.8. change control. Use Phase The following points should be considered during the use phase: • An audit trail of any changes made.5.9.5. long term integrity). • Need to migrate to neutral file formats. • Need to migrate records to new system and re-archive. configuration management. • Retention of legacy hardware and software (not recommended). • Periodic review and revalidation.5. and training are required in order that: • The benefits of a standard deployment across businesses and sites is maintained. Special consideration to who should be involved in the periodic reviews of multi-site systems to ensure appropriate representation. • Maintenance of an error/deviation log. Page 88 of 104 . 10. labelling. Given the large scale of IT systems and their constantly evolving nature. 5 (EMMS) Distribution System 1. The need to assess each system individually is still strongly recommended. The following list gives guidance on the expected categories (see Section 6) of some typical IT systems. 3. 5 Electronic (EDMS) Document Management system 1. 3. 5 Page 89 of 104 . • How will core product changes be made and site impact assessed and communicated? • How will central and site specific responsibilities be defined? • How will documentation impacted by the change be managed? 10. Examples of System Categorisation Typically IT systems can be regarded as a combination of category 3. • Cross function/business/site responsibilities are defined. Change Control Particular considerations need to be made for change control in a global IT system: • The impact of change at one installation is considered for other installations. 4. 3. attention must be given to maintaining design and test traceability. 3. 4. 4. 4. IT System Categories Enterprise Resource Planning (ERP) 1.6. 5 Engineering Maintenance Management system 1. 4. 4. 4 and 5 software. 3. 5 Laboratory Information Management (LIMS) 1. 5 Manufacturing Resource Planning (MRPII) 1.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 • Documentation is accessible across all installations. 3. The use of validation terminology will. Approach to IT Infrastructure 11. • Ability to manually lock PCs. Desktop Environment Procedural controls should be established in order to manage the distribution of desktop software and associated configuration.1. hardware and procedural environment that supports the secure operation of applications. Suitable records should be available to demonstrate configuration management.2. • Servers. IT Infrastructure includes: • Standard desktop. Such controls include but are not limited to: • Access limited to authorised users. The validated status of computerised systems/applications is dependent on the controlled management of the IT Infrastructure. • Service management.2. Management controls should take account of this characteristic.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 11.1. 11. Security controls should conform to the requirements of GQP 3202 ERES. Page 90 of 104 . Conflict testing should be conducted in order to ensure that applications are able to co-exist on the desktop PC. Logical controls should be applied to all desktop PCs containing GxP applications and electronic records. • Networks. Definition of IT Infrastructure IT Infrastructure comprises the software. be dictated by the regulated applications and IT infrastructure they support. • Control of security code issue and re-issue. IT Infrastructure typically exhibits an evolutionary development rather than the distinct application development associated with the computerised systems it supports. to a large degree. Controls for IT Infrastructure 11. Servers should be managed under change control in accordance with defined procedures. Such plans should be periodically tested. Servers should be backed up in accordance with appropriate SOPs. Servers should be located in secure locations subject to appropriate environmental controls and protected against risks of flooding. The standard desktop configuration should be documented and critical aspects of the desktop subjected to change control and configuration management. Configuration records should be in place for server hardware and software. The ability to restore multiple and single files should be tested and documented. Server Servers containing GxP applications or data should be subject to controls that ensure that the integrity of such applications and data is maintained. 11. Processes should be established for the distribution of virus protection software and the maintenance of virus detection databases in order to maximise GSK’s ability to detect and eradicate viruses.2.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 • Automated locking of PCs after a defined period of inactivity. etc. The integrity of backup and archive media should be verified at appropriate intervals throughout the retention period.2. • Disabling of user accounts following a defined number of failed login attempts. Backup and archive media should be adequately labelled to enable clear identification when required. Business continuity plans and disaster recovery plans should be in place to manage catastrophic events. Procedures should be in place to archive GxP data at defined intervals and to ensure that such data can be readily retrieved for the duration of the retention period. Page 91 of 104 . fire. Backup and archive media should be stored in secure locations subject to appropriate environmental controls. Networks Specifications and diagrams should be in place that describe the Local area network and identify critical physical and logical components of the network. Network specifications and diagrams should be in place for wide area networks. Communication protocols should be documented. servers. Appropriate naming conventions should be used for networks and devices. and tested as part of the computerised system it supports. This procedural framework is critical in keeping the IT infrastructure in a Page 92 of 104 . firewalls and cryptographic techniques where employed. testing. change control and configuration management. such as access controls.2.4. The boundaries between open and closed networks should be documented along with methods for protecting data. 11.g. 11. routers and bridges and should show connections between local and wide area networks. Specifications and diagrams should identify key entry points to the network and how security is managed. Network diagrams should identify all critical equipment e. SNA.2.3. Service Management Procedural controls should be established in order to manage the ongoing support and maintenance of the IT infrastructure.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Configuration records should be in place for server hardware and software. Configuration parameters should be documented and verified. transmission control protocol/internet protocol. Distinct import and export features built into computerised systems are not middleware and should be validated as part of the application.g. Tools should be used to monitor network operation and performance and security breaches. Critical network configuration should be subject to installation controls. e. ongoing monitoring. Middleware (communication software used to link different applications) should be installed according to defined procedures. Such specifications should be reviewed and approved. DecNet. long term data archiving. logical security. etc. service start up and shut down. changes. management of third party networks. decommissioning. etc. desktop. Desktop Management Establishment of standard hardware/software installation. system monitoring. installation of anti virus software. and Installation. record management. job scheduling. Areas that should be addressed are as follows: Element Detail General Management Training. problem logging/tracking/reporting. Data Management Back-up and restoration of data. etc. password ageing. decommissioning. hardware/software maintenance. management of outsourced services. changes. the objective being the maintenance of a continuous state of compliance as the IT infrastructure evolves to meet business requirements. corrective and preventative action. maintenance protection. hardware/software maintenance. Servers Mainframes level agreements. Security Management Physical security. etc. user account management. Network Management Installation. etc. problem logging/tracking/reporting. access rights. GxP training. changes and decommissioning. handling of virus alerts and infections. etc.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 state of control. distribution of upgrades. etc. service monitoring. Quality Management Internal audit process. process improvement. document management. Service contracts. media management. of virus software Page 93 of 104 . 12. All IT systems should be subject to change control documented in appropriate SOPs. in particular. Scope This guidance applies to computer systems developed and supported centrally regardless of whether or not there are local modifications. It applies to: Single instance of an application serving multiple locations (e.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION Change Configuration Management Continuity Management 1205 JUNE 2002 and All systems should be subject to configuration management.1. This guidance is intended to complement other guidance in this GQG. Site Validation Plans should define where central application/product documents are used in support of Page 94 of 104 .3. Approach to Centrally Developed/Supported Systems 12. and guidance will be available from Global Computer Validation and the central Support Group for the computer system concerned. MERPS) One instance of an application serving one location (e. 12. As such. HP Chem LMS BPCS.2. and common Near Infrared (NIR) instruments) Sites may require assistance in making this distinction.g. recovery and contingency 12. support and validation costs. Responsibilities Central development and support teams may adopt methodologies and terminology determined by their quality systems as long as they comply with the principles embodied with GQP/G 1205.g. site modification of applications/products should be minimised. Definition This section provides guidance on the validation implications for centrally developed and/or supported applications/products deployed across multiple sites. and JD Edwards. The objective of centrally developed and supported applications/products is primarily to establish consistent. common Distributed Control System (DCS). common Chromatography Data System (CDS). Disaster planning. effective and efficient business processes and to minimise development. Approach to IT Systems. Centrally organised Supplier Audits should be conducted in conjunction with Global Computer Validation. 12. those elements of the site implementation need not be validated.4. Central Activities Supporting Validation The central implementation team should conduct activities to the agreed standard in order to avoid or minimise additional work required to achieve validation. Suppliers supporting local modifications should also be subject to supplier assessment. Central and site teams should agree relationships between central and site activities and documents. Both Site Validation Plan and central Validation Master Plan (Quality Plan) should clearly differentiate central team accountabilities and deliverables from site validation accountabilities and deliverables. Supplier Assessment Interfaces between suppliers supporting central and site activities should be clearly defined. System Register Sites should keep an entry in their System Register for those applications/products they use that are centrally developed/supported. Central development and support teams should assure the quality of suppliers supporting central activities. Central development and support groups and Site Validation should work with Global Computer Validation (GCV) in order to facilitate consistent validation (e. Further. Central support groups should maintain a System Register of sites using the GxP systems they support. Page 95 of 104 . Validation Life Cycle Validation Plans Each implementing site should develop a Validation Plan. The Validation Plan should reference the central Validation Master Plan (or Quality Plan as appropriate) in addition to defining site-specific validation activities. Consideration should be given to GxP and non-GxP components of the application/product (GQG 1401A provides further guidance). certain sites may not be using the application/product within a GxP environment and as such. Centrally supported infrastructure should be incorporated within central activities. 12.5. Key documents supporting validation should be reviewed by central and/or site validation teams as appropriate. use of templates) and maximise use of central documents without duplicated site effort.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 validation.g. The use of computer systems should be consistent with relevant GQP/Gs. test records. PQ) should verify core functionality including any local modifications. SOPs should be established to provide the required operational and maintenance controls described in section 4. and change control records should meet regulatory requirements. Page 96 of 104 . Issues raised during PQ should be reviewed with central support teams and sites. A central Validation Summary Report (Quality Report) report should be developed reviewing the adequacy and release of each application/product version. specifications. SOP templates can be provided by the central implementation team for modification by sites as appropriate. Validation Report Site Validation Reports should be developed in response to site Validation Plans.g. It may be beneficial for the central implementation team to develop template documents. including any local modification. Central documents supporting validation e.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Site Validation Activities User Requirement Specifications (URS) stating site needs should be established and documented in central URS and site-specific URS as appropriate. Where applicable. and specification/design/testing of any locally developed specific site modifications. Specific local regulatory requirements should be clearly stated. Where ever possible a common set of user requirements should be developed between sites using the same system.6 of this guidance. Site supported infrastructure should be incorporated within site activities. OQ. Validation Reports should confirm the adequacy of all relevant central activities. adapted by site teams as appropriate. Deployment & Use • Procedures. Sites do not need to repeat centrally supported IQ/OQ where central testing fulfils local requirements. Site validation activities will include configuration management. PQ is a site-specific activity but may be co-ordinated across multiple sites if appropriate. Central testing should be used in support of qualification. design documents. data load. should be validated. in order to provide a consistent approach across sites. • Service Level Agreements. Site implementation of centrally developed and supported systems. In addition to confirming site validation activities. Service Level Agreements (SLA) should be established in order to define the support service requirements and central and local support accountabilities. Site testing (IQ. Sites should not make unauthorised changes to shared aspects of applications/products. which should ensure that the validated status of the application/product is maintained. Scope of Tools Covered 13. Approach to Software Tools 13. Central Support Groups should ensure new or updated documentation is provided in support of changes to the central elements of the application/product. Central Support Groups should notify all sites of modifications to the central elements of the application/product in order that site support teams may assess the impact of such changes on local developments.1. • Change Management. Tools Related to GxP records and functions These tools are used to control business data within the application. or for handling system data such as configuration records or validation related records. Example of the use of such tools include: • Manage validation documents. Support service arrangements should take account of different time zones. SLAs should address requirements for access to centrally held documents to support maintenance and inspection readiness. SLAs should ensure that sites are given notification of upgrades to central elements of the application/product in order to allow appropriate impact assessment and revalidation planning. Changes to central and site-supported infrastructure should be subject to appropriate change control procedures.2. Both sites and Central Support Groups should periodically assess the cumulative effect of change and whether any revalidation is required.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 Interfaces between central support teams and sites should be defined and appropriate SOPs established to manage the interfaces. 13. Page 97 of 104 .2. Sites should conduct appropriate revalidation following modification to both central and site-specific elements of the application/product.1. All changes should be subject to change control procedures. Definition of a Software Tool Software tools are used to support the development and use of computerised systems and do not form part of the end application. The are primarily used for improved performance. 13. 3. or monitor inventory of validated systems or components including source code. Business Tools These are tools that are used in day to day work but that are not used to create records used in GxP decision processes and are not used in the management of GxP records. 13. For example. In this case the tools function essentially like manual typewriters or pens and any signatures. automated testing. use of word processing software to generate a paper submission or other compliance related document. • Govern change management process (including change control records). More importantly.2. • Manage other validation-related data. would be traditional hand-written signatures.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 • Generate. Other examples include simulation and emulation tools used to support testing. Such tools include spreadsheet packages and database packages. Application Development and Diagnostic Tools These tools provide a development and runtime environment for an application. Page 98 of 104 . if required. Such tools include: • Diaries. 13. 13.2. test records). Record storage and retrieval would be of the traditional 'file cabinet' variety. • Manage release and distribution of validated software.2. • E-mail.4. Tools Incidental to the Creation of GxP Records These are tools used to create paper records that are subsequently maintained in traditional paper based systems. • Control application level security.g. • Govern validation activities (e. • Monitor security breaches. overall reliability. manage. and ability to access the records would derive primarily from well-established and generally accepted procedures and controls for paper records. • Manage network time protocols. trustworthiness.2. Such tools would include programming tools such as PLC Programmers.3. These tools are not routinely used to control or monitor production processes but may affect the operation and performance of a computerized system. Typically business tools and tools incidental to the creation of GxP records need not be listed on the system register. Datalogger Programmers and MS Visual Basic programming environments. Responsibilities Responsibilities should be discharged as outlined in Section 2. Compilers and Operating Systems Compilers include for the purpose of this policy those tools that are used purely in the development and translation of software into an executable form. Tools should be listed on the system register unless some other arrangement has been agreed.5. 13.2. internal registers and buffers. Such tools provide status information and often provide the capability to change runtime parameters. These tools may have in-built diagnostic facilities used such as debugging aids.4. • Diagnostic tools used to monitor the operation or performance of a computerised system or application. 13. System Registers The approach to listing tools on the system register should be documented and approved by QA. 13. Page 99 of 104 . network or application if their use is not controlled.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 • Address books. applications. Where ever possible COTS tools should be used. DOS. 14.5. The costs associated with validating bespoke/custom may be prohibitive to their use. and Operating systems UNIX. modified or removed features on developed applications. database packages. Validation not required (except for e-mail Diaries. Application Development and Diagnostic Tools These tools may come in standard or bespoke/custom form and should therefore be addressed under the appropriate software Category. configuration records. distribution or marketing of medical devices should be validated in accordance with this guideline. Test record management for validated systems. Business Tools Examples Word processing. Address used to transmit GxP records or approved Books. Email (not GxP decisions .see GQG 3202) used to transmit GxP records or approve GxP decisions). Where a medical device itself is automated. Incidental to Validation not required the Creation of GxP records. Spreadsheets packages. system operation and Change control must be applied to manage diagnostic tools used upgrades to development and diagnostic to support validated tools. Security management on validated systems. advice should be sought from GCV prior to defining the validation strategy. Change control must be applied to manage Management of upgrades to development and diagnostic change control & tools in order to determine the impact of new. Tools should be validated as computerised system. Compilers Validate as per Section 6. PLC programming tools. Approach to Medical Devices Computerised systems used in the manufacture. Page 100 of 104 . Tool Usage Validation Requirements Directly supporting GxP functions and associated records Validation required.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 13. Validation Requirements Validation requirements for software tools are dependent on usage of the tool as summarised in the following table. High Level Site Mapping of Key Computerised Systems Each site should maintain a high level map of the sites business processes indicating where systems support the activities. None of the other additional fields described in Section 3. Page 101 of 104 . one for process control systems. Inspection Readiness 15. manual and electronic.g.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 15. Some key aspects to computerised systems inspection readiness that should be proactively managed are outlined in this section of the guideline. Where a site’s inventory is managed in a number of registers (perhaps one per laboratory. old systems are decommissioned.2 should be offered during an inspection. 15. 15. It should be borne in mind that where spreadsheets and databases are used to manage an inventory then they should be assessed for validation requirements just like any other computerised system. 15. and as the use and interfaces of some systems are modified to meet evolving user demands. Organisation Charts Organisation charts should be maintained to explain the fit of QA with the wider organisation. Care must be taken to keep system maps up to date as new systems are introduced.4.1.5. Definition of Inspection Readiness A state of inspection readiness implies that a site is prepared for an unannounced inspection and that minimal work is required to prepare for an announced inspection. This should concentrate on GxP activities and identify the extent of support provided by the systems e. Regulators are often interested in system interfaces. highlight out of specification values. allocate batch numbers.2. and the validation status of connected systems. 15.3. one for IT systems) care must be taken that duplicate entries are avoided and equally some systems are not missed. Use of Trained Personnel Training records including role specifications should be kept current and demonstrate that individuals are appropriately trained to conduct their duties. Key interfaces should be identified and whether they are manual or automatic. Systems Register An inventory of systems and which ones are GxP requiring validation should be maintained and available for inspections. Many of the computerised systems used today have been in use over many years. Where requested. Service Level Agreements between Central Support Groups and sites should define the service levels for access to documentation. normally 24 hours. System/Project Overviews High-level descriptions should be available for systems and projects giving a succinct summary of the scope of the system. This line of investigation may stop with a yes/no response.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 15. the line of investigation may lead to a follow-up request to see the validation plan and report for a system described as validated. Validation plans/reports and reviews should be available in English for FDA inspection. Access to electronic copies of centrally held protocols and reports can be facilitated during regulatory inspections to avoid unnecessary delays waiting for paper master copies to arrive. access to master (or copies of) documents (including raw data such as test evidence) should be provided within reasonable time scales. and the regulator may also ask for any evidence of any validation reviews. Documentation Key documentation to support validation should be available at site during inspection. A procedure should be developed describing how to handle requests by regulators for documentation. Validation plans. Validation Plans/Reports and Reviews It is likely that during a GxP inspection a regulator will ask whether or not a particular system has been validated. reports. however. 15. Such access can be facilitated through email or a shared system directory.8. Top-level functional diagrams and physical layout diagrams are highly recommended. Controlled copies of centrally held Validation Plans and associated Validation Reports should be issued to sites in advance of any regulatory inspection. They should be developed with the aim of helping regulators concentrate on key aspects of the system during an inspection without getting deeply involved in aspects of the system that are not of a prime concern. In such circumstances it should be clearly stated to the regulator that these electronic copies may not adhere to Page 102 of 104 . Owners of GxP data should be identified.6. and meet current regulatory expectations. are approved. A document index should be maintained to facilitate retrieval of on site and off site information. 15. The role of GxP functionality and the use of GxP data should be understood in the context of the overall system.7. System boundaries need to be clearly defined. Raw data and other supporting information should be retrievable within a reasonable timeframe (see below). identifying functionality and use of the system/application concerned. and reviews should be checked to make sure they exist. Sometimes doing yet more training will not be enough. A schedule of audits should be planned placing priority on key topics subject to inspection such as laboratories. If necessary be prepared to withdraw individuals from the front line of a potential inspection if they are not readily capable of fulfilling this role. 15. Presenters need to be knowledgeable about systems/projects they are asked to front. It is essential that audit observations are closed out in a timely manner and that the status of corrective actions arising from audits is known. Mock inspections should be as realistic as possible.9. There is a risk that too high a level of information may be viewed as misleading following close examination of the system/application. The slides should be suitable to provide the inspector with a copy if requested. 15. Mock Inspections A mock inspection programme should be developed if one does not already exist. access should be provided to support personnel with knowledge of the central application and documentation during regulatory inspections. and supply chain systems. 15. It is important to accept that not everybody is suitable for putting in front of an inspector. clearly identifying areas for improvement. The availability and use of trained personnel during inspections is key. 15. manufacturing lines.12. Inspection Management Personnel associated with computerised systems should be trained as appropriate on how to handle inspections. The opportunity should be taken to coach personnel receiving the mock inspection. They need to Page 103 of 104 . Mock inspections on computerised systems validation may be conducted as part of a more wide ranging mock inspection or as a topic of a mock inspection in its own right. Internal Audit Program An internal audit program should be established if it does not already exist to cover the use of computerised systems. Presentation It can be useful to prepare a small presentation of each system that may be subject to an inspection.11.GlaxoSmithKline Management: Management Systems COMPUTERISED SYSTEM VALIDATION GLOBAL QUALITY GUIDELINE 1205 JUNE 2002 regulatory electronic record/signature requirements but are being provided to assist the inspector in advance of hard copies being delivered to site.10. consequently it is worthwhile asking the legal department to review the slides. The presentation slides should not be too detailed but should provide a broad picture to describe a system/application and facilitate discussion. In addition to documentation. Those who present to an inspector should be permanent employees otherwise there may be an impression of dependence on quality from temporary staff. Reference Materials and Training Aids for Investigators. A SOP should be prepared to describe how inspections are to be managed from the notification of an inspection. Food and Drug Administration (FDA). Parenteral Drug Association (PDA). published by International Society of Pharmaceutical Engineers (ABPI and IQA Approved Supplier Guidance in association with ISPE). Technical Report. Bibliography Food and Drug Administration (FDA). and appreciate why certain project and validation decisions were taken. Good Automated Manufacturing Practice (GAMP) . Pharmaceutical Inspection Co-operation Scheme (PIC/S). Technical Report 18. Glossary of Computerised system and Software Development Terminology.Guide for Validation of Automated Systems Version 4. Pharmaceutical Inspection Convention. 1995. 16. Retention and Retrieval Page 104 of 104 . Document PI 011-1 (Draft). REFERENCES GQG 1401A GMP Compliance: Identification of GMP Business Processes GQP 1204 The Validation Life-Cycle GQP 3202 Electronic Records and Electronic Signatures GQP 3301 Document Archiving. January 2002. Good Practices for Computerised Systems in Regulated ‘GxP’ Environments. Advice on how to handle inspection scenarios should be handled through training rather than the SOP. through its completion. Validation of Computer Related systems. 2001.GlaxoSmithKline GLOBAL QUALITY GUIDELINE Management: Management Systems COMPUTERISED SYSTEM VALIDATION 1205 JUNE 2002 understand the validation approach taken. 1983. PDA Journal of Pharmaceutical Science and Technology. Guide to Inspection of Computerised systems in Drug Processing. 1995. The inspection of computerised systems is usually included within the scope of such SOPs.