Documente Academic
Documente Profesional
Documente Cultură
RATIONALE
PURPOSE
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:
Throughout this guideline GDP, GLP and GMP and are collectively referred to as GxP.
Page 1 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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 Approach to Control Systems has been revised to improve guidance
on System Registers, and use of off-line simulation to support Operational
Qualification.
Page 2 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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
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
Page 3 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 4 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 5 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
Page 6 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
2. Responsibilities
Responsible for:
Responsible for:
Responsible for:
Page 7 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Responsible for:
Responsible for:
Responsible for:
Page 8 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
3. Site/Function Activities
• Name (by which the system is known and commonly referred to).
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 1205
Table 1
Ultrasonic Bath
FTIR
Robotic Systems
SCADA System
A separate entry is required for
each physical system of the Distributed Control Systems
same type.
LIMS
Care must be taken to ensure
sites understand which multi-site
systems they use.
Page 10 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
4. Prospective Validation
Page 11 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
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.
Validation Planning
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 1205
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.
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.
• Effectiveness of testing.
Page 13 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• Testable/measurable.
The URS provides the basis for system acceptance testing and should be
approved before a design review is conducted.
Requirements Traceability
Page 14 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
System Overview
The system overview should be reviewed and approved prior to use of the
system.
Page 15 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• All ranges, limits, defaults and specific values that the computerised
system will accept.
Detailed design specifications should include but are not limited to:
• Security.
• 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:
• 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 1205
Data Definition
Design Review
• 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.
Page 17 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
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.
• In-code documentation.
• Branching.
• Error/exception handling.
• Expandability considerations.
Page 18 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Code/Configuration Review
The source code review aims to provide confidence in the operability of the
system and should:
Page 19 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
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.
Page 20 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
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.
Page 21 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• 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:
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 1205
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
The results of testing are analysed and summarised in a test report that
should state:
The test report should not exclude any test data. The test report may be
combined with the test results.
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 1205
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.
• Security Management
• User Procedures
• Maintenance
Page 24 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
− Performance monitoring.
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.
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).
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.
Page 25 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Installation Qualification
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
Page 26 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
Performance Qualification
• Batch reports.
• Label variants.
Page 27 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• System availability.
• System stability.
Validation Reporting
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.
This phase of the system life-cycle describes the period of time when the
system is in operational use.
• Scope of service.
Page 28 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• Escalation procedures
During this phase, all SOPs, plans, contracts, etc established in accordance
with operational and support plans should be implemented.
Page 29 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Upgrades
• Complexity.
• Criticality.
Any requirements for refresher training should be reviewed (see also section
on deployment phase).
Page 30 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Requirements Traceability
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
Incident Management
Page 31 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Documentation Management
Training
5. Retrospective Validation
Page 32 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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:
Page 33 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• Severity of non-compliance.
• Validation 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.
Page 34 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
corrective action plans. Both short-term interim measures and the longer-term
plan for final measures should be available to show to inspectors.
• Interim measures do not eliminate the need for full corrective actions
and do not overcome system non-compliance.
Those critical activities that should be given particular consideration for interim
measures should include:
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 1205
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.
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.
Page 36 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 37 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 38 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 39 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 40 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Note: No specific validation activities for standard COTS compilers and operating systems
beyond documenting version details.
Page 41 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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).
Page 42 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• FTIR spectrophotometry.
• Networks and interfaces within the laboratory system and to any other
connected system (see guidance on IT Infrastructure).
7.3. Responsibilities
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 1205
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 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
Page 44 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
7.5.3. Requirements
• User operation.
• Environmental constraints.
Page 45 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
7.5.8. Qualification
Page 46 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
7.5.9. Use
7.5.10. Decommissioning
Page 47 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 48 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
pH Meter 2
Ultrasonic Bath 2
Mass Balance 2
FTIR Spectrophotometry 1, 3, 4
Page 49 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• Embedded systems.
• Standalone systems.
• Loop controllers.
Page 50 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• Networks and interfaces within the process control system and to any
other connected system.
8.3. Responsibilities
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.
Page 51 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
8.5.1. 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.
Page 52 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Functional Specifications
• Embedded system.
• Complex DCS.
Detailed Design
Page 53 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• Process description/sequences.
• Interconnection drawings.
Design Review
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.
Code Review
Page 54 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
Page 55 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Installation Qualification
Page 56 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Operational Qualification
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.
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.
Page 57 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Performance Qualification
This should always be performed at the user site and include testing
specific to the user environment and defined ways of working.
Page 58 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
8.5.8. Decommissioning
Document Management
Page 59 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 60 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Loop Controllers 2
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 1205
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.
• Are typically not 'stand-alone' programs, for execution they rely upon
the environment provided by the package from which they were
created.
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.
Page 62 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
9.3. Responsibilities
Page 63 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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 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.
Page 64 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
GxP desktop applications that are not one-off should have a written
assessment of GxP significance and be maintained on a systems
register in the same manner as other systems.
Planning
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.
Page 65 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Supplier Assessments
Page 66 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 67 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
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.
Page 68 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 69 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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
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.
Page 70 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 71 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Validation Report
Decommissioning
Page 72 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 73 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
The table below provides guidance for application of the software categories
(see Section 6) to desktop applications.
Page 74 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
The following are examples of IT systems covered by this guideline. This list
is not exhaustive:
• Distribution Systems.
• Schedulers.
• Financial systems.
• Purchasing systems.
Page 75 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
Business Requirements
Compliance Assessment
Page 76 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Validation Planning
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 1205
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.
The validation plan should define the strategy and scope for
conducting supplier audits in addition to the rationale for not auditing
particular suppliers.
Page 78 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
System Overview
Design Specifications
Data Definition
Page 79 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Design Review
Pre-Installation Testing
Page 80 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• Transfer synchronisation.
• Data translation.
• Data mapping.
Page 81 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Data Load
• Data archiving.
Where data load involves manual transfer or entry of data, all GxP
data should be at least double-checked to verify it is correct.
Page 82 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• User Procedures
• Training
• Security Management
Page 83 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Page 84 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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
Installation Qualification
Page 85 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Operational Qualification
System Release
Page 86 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Performance Qualification
Validation Reporting
• Which system holds the master data for the purpose of decision
making?
Page 87 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
10.5.8. Decommissioning
Page 88 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Change Control
IT System Categories
Distribution System 1, 3, 4, 5
Page 89 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
• Standard desktop.
• Servers.
• Networks.
• Service management.
Page 90 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
11.2.2. Server
Page 91 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
11.2.3. Networks
Page 92 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Element Detail
Page 93 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
12.1. Definition
12.2. Scope
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
Page 94 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
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.
Supplier Assessment
Page 95 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
Validation Report
• Procedures.
Page 96 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
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.
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.
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:
Page 97 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
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.
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 1205
• Address books.
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
Page 99 of 104
GlaxoSmithKline GLOBAL QUALITY GUIDELINE 1205
Validation requirements for software tools are dependent on usage of the tool
as summarised in the following table.
Where a medical device itself is automated, advice should be sought from GCV prior
to defining the validation strategy.
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.
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.
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
15.9. Presentation
understand the validation approach taken, and appreciate why certain project
and validation decisions were taken.
16. Bibliography
REFERENCES