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).
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.
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
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
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
1. 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.
2. 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:
• Providing adequate resources.
• Final authorisation of the validated system for use.
2.2. System Owner/User Role
Responsible for:
• 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.
2.3. 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.
2.4. Developer/Technical Role
Responsible for:
• 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.
2.5. Support/Maintenance Role
Responsible for:
• 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.
2.6. 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.
3. 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 and electronic signatures (ERES) status (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.
The basic attribute list is not exhaustive and may be extended as appropriate to meet specific site needs. The system register should cover all
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.
A separate entry is required for each physical system of the same type. pH Meter Ultrasonic Bath Mass Balance HPLC FTIR
Chromatography Data System Robotic Systems
Process Control One entry per system.
A separate entry is required for each physical system of the same type.
Intelligent/Smart Instruments PLCs
SCADA System
Distributed Control Systems
Expert Control Systems Desktop (User)
Applications
One entry per GxP spreadsheet/database
applications.
Spreadsheet applications. Database applications including Lotus Notes.
IT System One entry per production system instance.
Care must be taken to ensure sites understand which multi-site systems they use.
SAP R/3 BPCS LIMS
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.
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
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.
• 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 requirements tracking (Requirements Traceability Matrix [RTM]).
• Unambiguous, clear and concise. • Testable/measurable.
• Be approved by the end-user.
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
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.
• 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.
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.
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 and consistency (i.e. modular 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.
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 elements of the application fulfil design specifications.
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.
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
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.
• 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.
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.
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.
− 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).
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. It may be possible to train operators to help conduct testing.
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:
• Progressing data changes. • System availability.
• System stability.
• Problem resolution to incident logging. • Progressing system changes.
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:
• 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).
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).
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.
Documentation Management
The validation process should create and maintain a package of documentation. Document management procedures, where they do not already exist, should be established to manage and control such documentation. The contents of the validation package should be securely stored.
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.
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:
• 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.
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
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.
• 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
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.
6.2.3. 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,