Preview only show first 10 pages with watermark. For full document please download

Glaxosmithkline-computer System Validation Guideline

GSK Computer System Validation

Rating
Date

June 2018
Size

484.7KB
Views

1,737
Categories

Verification And Validation Specification (Technical Standard) Embedded System Life Cycle Assessment Quality Assurance

Transcript

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

Glaxosmithkline-computer System Validation Guideline

Rating

Date

Size

Views

Categories

Share

Transcript

Forgot your password?.