PICS - Guidance On GP For SC in GXP Environments
PICS - Guidance On GP For SC in GXP Environments
PICS - Guidance On GP For SC in GXP Environments
PI 011-3
25 September 2007
PIC/S GUIDANCE
Editor:
PIC/S Secretariat
e-mail:
web site:
[email protected]
http://www.picscheme.org
PI 011-3
25 September 2007
TABLE OF CONTENTS
Page
1.
Purpose........................................................................................................... 1
3.
Scope.............................................................................................................. 2
4.
Introduction ..................................................................................................... 3
6.
7.
8.
9.
10.
11.
12.
13.
Testing .......................................................................................................... 15
14.
15.
16.
Change management.................................................................................... 21
18.
19.
20.
21.
22.
Personnel...................................................................................................... 30
23.
24.
25.
26.
27.
28.
29.
Revision history............................................................................................. 50
____________________
PI 011-3
-i-
25 September 2007
1.
DOCUMENT HISTORY
1 September 2003
PURPOSE
2.1
The PIC/S Guide to Good Manufacturing Practices is the basis for GMP
inspections. In particular its Annex 11, Computerised Systems is used when
inspecting such systems.
2.2
2.3
2.4
2.5
2.6
Throughout this document the users (owners of the good practice computerised
systems being inspected) are collectively referred to as regulated users for clarity.
PI 011-3
Page 1 of 50
25 September 2007
2.7
2.8
2.9
2.10
Some repetition is inevitable in a document that has evolved over many years
and through various working party multinational iterations. It is not intended that
this document is read from cover to cover, but should be dipped into as a
reference source when needed and for that reason some sections have to
stand-alone.
3.
SCOPE
3.1
3.2
At the time of issue this document reflected the current state of the art. It is not
intended to be a barrier to technical innovation or the pursuit of excellence. The
advice in this Guidance is not mandatory for industry. However, industry should
consider these recommendations as appropriate.
3.3
3.4
As a result, we have tried to keep the contents of this document practical and
principle-oriented, to ensure that it retains relevance for as long as possible.
However, value judgements and consensus between parties can be difficult to
achieve at times in this complicated field.
3.5
The scope of the document is broad, covering necessary steps and the
documentation needed for the implementation and validation of a computerised
2
system. Management of such projects requires the linking of important aspects
of management policies, documentation and record systems embracing the
For successful project management these links should be established between the
supplier(s) [developer(s) and producer(s) of individual components or complete
computerised system] and the regulated user [purchaser and user of the computerised
system].
PI 011-3
Page 2 of 50
25 September 2007
3.7
3.8
PIC/S considers that adoption of the principles, guidance, reporting and life
cycle documentation best practices, outlined in this document, will enable users
of computerised systems to establish quality assurance systems and records
capable of demonstrating compliance with current GxP requirements and
related guidance.
4.
INTRODUCTION
4.1
4.2
In recent years there has been an increasing trend to integrate electronic record
and business management systems across all operational areas. In the future it
is expected that our reliance on computer systems will continue to grow, rather
than diminish. The use of validated, effective, GxP controlled computerised
systems should provide enhancements in the quality assurance of regulated
materials/products and associated data/information management. The extent of
the validation effort and control arrangements should not be underestimated
and a harmonised approach by industry and regulators is beneficial.
4.3
PI 011-3
Page 3 of 50
25 September 2007
4.5
4.6
The validation documentation should cover all the steps of the life-cycle with
appropriate methods for measurement and reporting, (e.g. assessment reports
and details of quality and test measures), as required. Regulated users should
be able to justify and defend their standards, protocols, acceptance criteria,
procedures and records in the light of their own documented risk and
complexity assessments, aimed at ensuring fitness for purpose and regulatory
compliance.
PI 011-3
Page 4 of 50
25 September 2007
4.7
4.8
Apart from user acceptance testing (OQ) versus the functional specification,
which may include Factory Acceptance Testing (FAT), for example, at the
supplier, the regulated user also has responsibility for the (PQ) performance
qualification of the system. In this context the PQ user acceptance test of the
3
system is in its operating environment , and will again be against a User
Requirements Specification (URS) that will include protocols and criteria for the
performance and quality acceptance, not only for the controlling system but
also for the controlled (pharmaceutical related) process application. Crossreferences to any related, relevant process validation documentation should be
clearly stated in respect of the latter. The GAMP Guide and PDA technical
report No 18 (Further Reading Ref: 6) provide good practice guidance to
drafting and using a URS, whereas pharmaceutical process validation guidance
is given elsewhere (see PIC/S PI 006 and related EU/USFDA documents).
4.9
4.10
4.11
The regulated users of the system have the ultimate responsibility for ensuring
that documented validation evidence is available to GxP inspectors for review.
Large enterprise or MRP-II systems may be tested in a pilot mode environment initially,
followed by controlled roll-out to the user environment.
PI 011-3
Page 5 of 50
25 September 2007
4.12
5.1
5.2
A minority of suppliers are not responsive to requests for an audit. The need to perform
a supplier audit should be linked to the regulated users risk assessment and quality
assurance standards.
PI 011-3
Page 6 of 50
25 September 2007
research plus focused quality system and product specific audits of the
suppliers by the regulated user (or by an accredited third party auditor) may be
beneficial here. The business/GxP criticality and risks relating to the application
will determine the nature and extent of any assessment of suppliers and
software products. GAMP Forum and PDA have provided advice and guidance
in the GxP field on these matters.
5.3
At all times there is a need for complete and accurate documentation and
records to cover all aspects of the design phase, implementation & validation of
the computerised system(s). Operating and reporting requirements for the
important phases of the Software development Life Cycle related qualifications
and testing exercises and commissioning should be covered by comprehensive
Standard Operating Procedures or quality plans. The need for control and
documentation of the development, implementation and operation of computer
systems is extremely important for the validation of the system. There needs to
be a strong emphasis on quality assurance in the development stages. It is
fundamental for system life cycle documents to be controlled and maintained
(version, audit trails as appropriate), within a quality assured document
management system and available for inspection, if necessary. Regulated
users may choose to implement these requirements using either robust paper,
electronic or hybrid systems.
6.
6.1
A recent USFDA document identifies three premises that constitute the basic
principles of quality assurance, which apply to software engineering:
Quality, safety and effectiveness must be designed and built into the
software.
6.2
Audits are not mandatory but are considered good practice, and it is for the regulated
user to determine any auditing needs, scope and standards.
Final Guidance for Industry and FDA Staff: General Principles of Software Validation,
CDRH, January 2002 (Further Reading Ref. 5).
PI 011-3
Page 7 of 50
25 September 2007
11 (4). It may be necessary to equip personal PC applications and Internet/ email/ personal data filing/ etc., with appropriate security and design measures to
protect GxP systems whilst permitting authorised users to control the personal
applications on their desktop PCs.
Figure 1
OPERATING
PROCEDURES
AND PEOPLE
SOFTWARE
HARDWARE
EQUIPMENT
Firmware
COMPUTER SYSTEM
(Controlling System)
CONTROLLED FUNCTION
OR PROCESS
COMPUTERISED SYSTEM
OPERATING ENVIRONMENT
(including other networked, or standalone computerised systems, other
systems, media, people, equipment and procedures)
6.3
PI 011-3
Page 8 of 50
25 September 2007
7.
7.1
7.2
7.3
Outline protocols and related test procedures for all validation activities
including computer systems.
8.
8.1
10
Refer to GMP Annex 15 for more details concerning the VMP requirements.
11
PI 011-3
Page 9 of 50
25 September 2007
8.2
8.3
To satisfy the quality, performance and reliability objectives, the regulated user
needs to assure that the suppliers management policies; systems and related
procedures will achieve the desired objectives. Enlightened suppliers should
provide such evidence and added value to all customers, whether large or
small, through the recognition of industry standards from GAMP Forum,
Supplier Forum, PDA, ISPE, etc., and also through shared audits, user groups,
and product certification arrangements.
8.4
8.5
8.6
BS 7799: 1999, (13), is issued in two parts (Part 1: Code of practice for
information security management, and Part 2: Specification for information
security management systems) and provides recommended guidance on a
comprehensive set of controls comprising best practices in information
13
security . These controls and measures (or the equivalent) are recommended
for adoption within this PIC/S guidance. They will assist in drafting the internal
control standards and procedures to be implemented by IT management and
administration departments.
12
13
PI 011-3
Page 10 of 50
25 September 2007
9.
9.1
9.2
9.3
14
Linked, approved system life-cycle records may very well meet the requirements for the
system control documentation/system description.
15
16
17
Note: This is straightforward for a bespoke system. However, for marketed proprietary
systems or configurable packages then it is for prospective users, integrators and
suppliers to discuss and review proposed user requirements, versus package
functionality. It is essential to determine the degree of fit and then control any
necessary configuration work, modification, coding, testing and validation requirements
in line with this guidance.
18
PI 011-3
Page 11 of 50
25 September 2007
9.4
9.5
10.
10.1
From the URS, the supplier (this would include in-house developer) of the
software would be able to develop the functional specifications (in the case of
bespoke programs) or clearly identify the functional specifications for selection
and purchase of off-the-shelf systems. The functional specifications should
define a system to meet the URS, i.e. the customer's needs.
10.2
10.3
10.4
19
Risk assessments and analyses can be useful at various stages during the entire
system life-cycle and not just for the FS or URS, (see also GAMP 4 M3).
PI 011-3
Page 12 of 50
25 September 2007
11.
Figure 2 below maps the relationships between the key specification and qualification
elements as the system is specified, designed, built and tested.
USER REQUIREMENTS
SPECIFICATION
PQ
Verifies
FUNCTIONAL
SPECIFICATION
OQ
Verifies
DESIGN
SPECIFICATIONS
Verifies
IQ
SYSTEM BUILD
Figure 2.
11.1
11.2
Supplier and developer reputations and trading histories for the software
product provide some guidance to the level of reliability that may be assigned to
the product supplied. The pharmaceutical regulated user therefore should have
in place procedures and records that indicated how and on what basis suppliers
were selected.
11.3
20
This is an example only. Regulated users would be expected to comment on their own
particular model. They should also interpret and define the relationships between
various life-cycle elements as appropriate.
PI 011-3
Page 13 of 50
25 September 2007
11.4
11.5
11.6
quality assured;
12.
12.1
The Standards ISO 9001, ISO 9126 & IEEE 1298 have a number of important
features that can be summarised in the following points:
The need for, and importance of, testing of software product/s is identified
by the standard as it requires a tiered approach to testing and identifies
three levels of testing for software:
PI 011-3
Page 14 of 50
25 September 2007
12.2
requirements
for
purchased
13.
TESTING
13.1
13.2
21
PI 011-3
Page 15 of 50
25 September 2007
13.3
For some simpler GxP systems, for example certain PLCs and systems based
on basic algorithms or logic sets, the functional testing may provide adequate
assurance of reliability of the computerised system. For critical and/or more
complex systems the verification testing that is conducted at the IQ, OQ & PQ
stages provides only a limited level of assurance that the system does what it
purports to do, reliably. This level of testing provides only limited assurance of
the operation and reliability of hidden functions and code. For complex systems
there should also be a high level of assurance that the development of the
software has ensured delivery and operation of a quality product that is
structurally sound, clearly defined and controlled.
13.4
13.5
13.6
14.
14.1
14.2
22
The supplier/developer should draft test scripts according to the project quality plan to
verify performance to the functional specifications. The scripts should stress test the
structural integrity, critical algorithms and boundary value aspects of the integrated
software. The test scripts related to the user requirements specification are the
responsibility of the regulated users.
23
Tools and controls within the QMS, such as audits, change controls, configuration
management and continuous improvement programmes may feature here.
PI 011-3
Page 16 of 50
25 September 2007
24
(See also
14.3
14.4
GxP compliance evidence is essential for the following aspects and activities
related to computerised systems:
26
14.5
Historically, these systems have relied on manual systems, some electromechanical controls and paper based documentation. The introduction of
computerised systems does not diminish the need for compliance with GxP
requirements and guidelines.
24
25
The scope or extent of validation for each system can be detailed in individual validation
plans. A hierarchy of linked validation plans may be appropriate as outlined in GAMP 4
guidance Appendix M1: Guideline for validation planning.
26
PI 011-3
Page 17 of 50
25 September 2007
14.6
15.
15.1
The GAMP Guide may be referred to as appropriate for detailed guidance both
in the core project management section, the quality narrative and the specific
appendices. The following are category summaries from GAMP 4:
Category
Software Type
Validation Approach
Operating System
Firmware
Standard Software
Packages
Configurable
Software Packages
PI 011-3
Custom (Bespoke)
Software
Page 18 of 50
25 September 2007
15.2
15.3
Procedure for on-going monitoring, this procedure would interlink the error
report system and the deviation reports system with the change control
procedure.
16.
RETROSPECTIVE VALIDATION
16.1
PI 011-3
Page 19 of 50
25 September 2007
16.2
16.3
16.4
16.5
The validation exercise for on-going evaluation of legacy systems should entail
inclusion of the systems under all the documentation, records and procedural
requirements associated with a current system. For example, change control,
audit trail(s), (where appropriate), data & system security, additional
29
development or modification of software under a QMS, maintenance of data
integrity, system back up requirements, operator (user) training and on-going
evaluation of the system operations.
27
Compared with 10 to 20 years ago, when GxP related applications were often
rudimentary and standalone, there are now many more integrated, infrastructure
computer systems to consider, especially when regulated users are striving to achieve
so-called paperless systems. Some specific national GxP compliance regulations,
such as the US FDAs 21 CFR Part 11: Electronic Records and Electronic Signatures
have set specific requirements in this field. For legacy systems, firms often have to
consider retrospective validation, upgrading or replacement.
28
29
PI 011-3
Page 20 of 50
25 September 2007
16.6
16.7
Defined requirements
Verification evidence that the system has been qualified and accepted and
that GxP requirements are met
17.
CHANGE MANAGEMENT
17.1
17.2
17.3
30
It is important for regulated users to ensure that change control management is in place
during all system life cycle phases, i.e. from design and development through operation,
maintenance, modification and retirement. The arrangements should be described in
the validation plans for the project. Records should be kept with the project files.
PI 011-3
Page 21 of 50
25 September 2007
18.
18.1
The formal change control procedure should outline the necessary information
and records for the following areas:
18.2
The procedure should accommodate any changes that may come from
enhancement of the system, i.e. a change to the user requirements
specifications not identified at the start of the project. Or alternatively a change
may be made in response to an error, deviation or problem identified during use
of the system. The procedure should define the circumstances and the
documentation requirements for emergency changes (hot-fixes). Each error
and the authorised actions taken should be fully documented. The records
should be either paper based or electronically filed.
18.3
Computer systems seldom remain static in their development and use. For
documentation and computer system control it should be recognised that there
are several areas that would initiate change or a review for change. These are:
a deviation report;
an error report; or
18.4
The results of periodic reviews may be helpful, e.g. in indicating process drifts
and the need for change. Quality systems procedures should ensure that the
changes are clearly documented and closed out after actions have been
completed. The change control procedure should complement and link with the
deviation and errors report system. Various GAMP 4 Operation appendices
include guidance in these areas.
18.5
The supplier of the software should have its own change control system in
place and there should be clear and agreed procedures covering the
interrelationship of the suppliers and users change control system. Where
changes are made then the modifications of software should be undertaken
following formal QMS documentation, records and procedural requirements.
PI 011-3
Page 22 of 50
25 September 2007
18.6
19.
19.1
The security of the system and security of the data is very important and the
procedures and records pertaining to these aspects should be based on the IT
policies of the regulated user and in conformance with the relevant regulatory
requirements. The use of a computerised system does not reduce the
requirements that would be expected for a manual system of data control and
security. System owners responsibilities will include the management of
access to their systems and for important systems the controls will be
implemented through an Information Security Management System (ISMS).
19.2
It is very important for the regulated user to maintain the procedures and
records related to the access to the system(s). There should be clearly defined
responsibilities for system security management, suitable for both small and
complex systems, including:
19.3
31
The examination of the procedures and records should assure that the following
basic requirements are satisfied:
Access rights for all operators are clearly defined and controlled, including
physical and logical access.
PI 011-3
Page 23 of 50
25 September 2007
19.4
19.5
The validated back-up procedure including storage facilities and media should
assure data integrity. The frequency of back up is dependent on the computer
system functions and the risk assessment of a loss of data. In order to
guarantee the availability of stored data, back-up copies should be made of
such data that are required to re-construct all GxP-relevant documentation
(including audit trail records).
19.6
The back-up procedure including storage facilities and media used should
assure data integrity. There should be a log of backed up data with
references to the media used for storage. Media used should be
documented and justified for reliability.
All GxP related data, including audit trails should be backed-up.
19.7
Procedure for regular testing, including a test plan, for back up and
disaster recovery procedures should be in place.
A log of back up testing including date of testing and results should be
kept. A record of rectification of any errors should be kept.
The physical security of the system should also be adequate to minimise the
possibility of unauthorised access, wilful or accidental damage by personnel or
loss of data.
PI 011-3
Page 24 of 50
25 September 2007
20.
20.1
Where applicable, the audit trail for the data integrity may need to include
functions such as authorised user, creations, links, embedded comments,
deletions, modifications/corrections, authorities, privileges, time and date, inter32
alia. All linked components are to be immutably linked in an IT system security
controlled audit trail. All original data records and masters and any subsequent
alterations, additions, deletions or modifications are to be retained accurately
and comprehensively within the retrievable audit trail. The nature and context of
transactions logged in the audit trail to be deducible from and in agreement
with, the firms approved Standard Operating Procedures for information
security management for the particular computerised applications and users
33
authorities . Firms will need clearly documented policies, standard operating
procedures, validation reports and training records covering such system
controls. Information Security Management standards such as ISO/IEC
34
17799:2000 may be of assistance with the design, implementation and control
of such systems.
20.2
Where applicable, there should be special procedures for critical data entry
requiring a second check, for example the data entry and check for a
manufacturing formula or the keying in of laboratory data and results from paper
35
records . A second authorised person with logged name and identification, with
time and date, may verify data entry via the keyboard. For other automated
systems featuring direct data capture linked to other databases and intelligent
peripherals then the second check may be part of validated system functionality
(e.g. in a dispensary). Special access, system control features and/or special
devices such as identification code bars, and the inclusion and use of an audit
trail to capture the diversity of changes possibly impacting the data may
facilitate this check.
20.3
The records pertaining to the audit trail events should be documented, ideally
as features of the operating system, database management system (DBMS),
document management system (DMS) and other major applications. Timelinked audit trail records should be available, if required, in a human readable
36
form as required by the inspector . GxP Inspectors may see evidence for
different forms of audit trail depending on the regulations prevailing in the
intended regulated markets for the products or data.
32
33
The systematic contextual labelling of transactions in the electronic audit trail log is
recommended as it can have automated functional feedback control links with security
validation features.
34
35
36
It should be noted that for the USA market it may be a requirement in for audit trails to
be available in electronic form, not just paper, but the implementation and enforcement
of compliance with 21 CFR Part 11 is under review by FDA in 2003, (see Ref. 11).
PI 011-3
Page 25 of 50
25 September 2007
20.4
20.5
21.
21.1
EC Directive 91/356 sets out the legal requirements for EU GMP. The GMP
obligations include a requirement to maintain a system of documentation,
37
(Article 9) . The main requirements here being that the regulated user has
validated the system by proving that the system is able to store the data for the
required time, that the data is made readily available in legible form and that the
data is protected against loss or damage.
21.2
use of passwords
21.3
37
The main requirements in Article 9.1 are that documents are clear, legible and up to
date, that the system of documentation makes it possible to trace the history of
manufacture (and testing) of each batch and that the records are retained for the
required time. Article 9.2 envisages that this documentation may be electronic,
photographic or in the form of another data processing system, rather than written.
PI 011-3
Page 26 of 50
25 September 2007
21.4
21.5
21.6
38
The relevant EC directive being 92/25, Article 6(e), as amplified in the GDP guidelines
(94/C 63/03). Article 8 of 92/25 requires that the documentation system makes it
possible to trace the distribution path for every product.
39
It has been proposed via industry comments that a signature should be unique to the
owner of that signature but not necessarily unique to the system. It has also been
argued that it may be desirable to issue and maintain only one signature across a
multitude of systems. Regulated users may need to explain and justify such
arrangements, controls and logic.
40
The regulated user is expected to justify the choice of methods to be used to ensure
compliance with regulations and GxP, (see glossary Advanced Electronic Signature,
Electronic Signature (3) etc.
41
In this context writing meaning written by hand and/or signed by hand on paper
media.
PI 011-3
Page 27 of 50
25 September 2007
21.7
21.8
21.9
the system to have defined time zone(s) and date standard referencing
with relative transaction linking, (complex systems may span several time
zones)
44
Where risk assessment concludes that the use of a digital signature may
be necessary (e.g. Certification to a third party or in GCP field data
collection and transmission) that adequate security measures exist to
protect the key to a digital signature. The level of security that is
appropriate depends on the sensitivity of the transaction and the possible
impact of the unauthorised use of the key. Public Key Infrastructure (PKI)
may be appropriate where risk assessment indicates that a high level of
security is required.
There are procedures that ensure that entities authorised to use electronic
signatures are aware of their responsibilities for actions initiated under
their electronic signatures.
42
43
44
PI 011-3
Page 28 of 50
have
appropriate
security
25 September 2007
21.10 Issues to consider where electronic records are used to retain GxP data:
21.12 Issues to consider when the GxP system has a provision for external access :
The system has a method of ensuring that external access and inputs
come only from authorised clients and that they come in the correct
format, for example as encrypted, digitally signed mail or data packets. A
mechanism must exist to quarantine external inputs where security
conditions are not met. The information security management
arrangements need to cover the quarantine, notification and the final
sentencing of such inputs.
The capacity should exist to keep copies of data and to re-send them from
one stage to another if they get lost or corrupted at a later stage of
processing.
45
A database management system (DBMS) will have this included as an optional feature,
but for other systems it may be necessary to ensure that it is an added function.
Regulated users will then need to ensure that it is left switched on.
46
PI 011-3
Page 29 of 50
25 September 2007
21.13 Additional security arrangements and controls will be needed for GxP
computerised systems which electronically generate regulatory records, allow
external access, or enable key decisions and actions to be undertaken through
electronic interfaces. These requirements are being determined largely by
47
international initiatives to establish electronic commerce . However, where
firms are interfacing such open system (external access) functionality, in whole
or in part, with their GxP systems, then the security, control and validation
information will need to be documented and available to GxP inspectors.
22.
PERSONNEL
48
Note: 22.1 to 22.7 is based largely on the APV Guideline , q.v., with judicious
editing where necessary to fit the context of this document.
22.1
There should be sufficient, qualified staff with the relevant experience to carry
out tasks for which the regulated user is responsible in connection with the
planning, introduction, application (operation), application consultancy on, and
regular monitoring of, computerised systems.
22.2
22.3
22.4
47
Including 21 CFR Part 11. Title 21 Code of Federal Regulations Part 11 (21 CFR
Part 11), which was issued by the US FDA in 1997 and provides criteria under which
that agency considers electronic records and electronic signatures to be equivalent to
paper records and hand-written signatures. In Europe EC Directive 1999/93/EC
(December 1999) on a community framework for electronic signatures and EC Directive
2000/31/EC (May 2000) on electronic commerce in the internal market are important.
These directives were implemented during 2001. It is not the purpose of GxP guides to
reproduce such business and commerce requirements.
48
Section 22.4 has been substantially re-worded compared with the original (English
language version) APV guidance, for clarity.
49
Account should be taken of the risk of certain aspects of the previous procedures such
as quality or safety being lost as a result of reduced operator involvement following the
introduction of a computerised system.(to quote the APV document)
PI 011-3
Page 30 of 50
25 September 2007
22.5
The regulated user is responsible for ensuring all staff who have to perform
tasks in connection with computerised systems are given the requisite training
and relevant guidelines on computerised systems. That should also apply to
system developers, maintenance and repair staff and staff whose work could
affect the documented operability of the systems.
22.6
22.7
In connection with training, the GxP and life-cycle concept and all measures to
improve understanding and application of the concept should be explained.
Training measures and qualifications should be documented and stored as
part of the life cycle documentation. (Training records may be stored in
accordance with regulated user procedures)
23.
INSPECTION CONSIDERATIONS
23.1
23.2
23.3
Humans design, build, test, implement and change these complex systems
and there is opportunity for critical error with automated systems at any stage in
the life-cycle unless properly managed. The GAMP Guide provides relevant
guidance on these aspects.
50
PQ = Performance Qualification
PI 011-3
Page 31 of 50
25 September 2007
23.4
It is not intended that this guidance should be used as a 'blunt instrument' for all
on-site inspections but inspectors should use it selectively to build up a clear
picture of a company's scale and complexity of on-site computerization (or
automation) and investigate selectively the critical systems and risks. As stated
in 2.7 of this PIC/S guidance, inspectors may wish to consider evidence for
compliance with GxP as indicated by italicised text throughout the document.
Table 1 (page 34) immediately following this section provides a suggested
51
checklist for information to be considered prior to inspection .
23.5
23.6
Inspectors should select the GxP critical computerised systems from the
information provided and consider firstly the validation evidence for the selected
system(s) and then the routine operational controls for maintaining a valid
system that is accurate and reliable. Inspectors may find that different
departments in pharmaceutical companies will have responsibility for GxP
aspects of commercial, or business (IT systems) and lower level process
control systems. Look for evidence of inconsistency, or muddled standards.
23.7
GxP critical computerised systems are those that can affect product quality and
patient safety, either directly (e.g. control systems) or the integrity of product
related information (e.g. data/information systems relating to coding,
randomisation, distribution, product recalls, clinical measures, patient records,
donation sources, laboratory data, etc.). This is not intended as an exhaustive
list.
23.8
23.9
51
PI 011-3
Page 32 of 50
25 September 2007
52
23.10 Inspectors should review the firm's Validation Summary Report , (VSR) for the
selected system and refer as necessary to the System Acceptance Test
Specification and lower level documents. They should look for evidence that the
qualification testing has been linked with the relevant specification's acceptance
criteria, viz:
PQ versus URS .
OQ versus FS
IQ versus DS or DR
53
54
(*For big projects there should be a project quality plan and a QMS for the
documentation. For smaller projects established SOPs may suffice)
23.11 Inspectors should look for the traceability of actions, tests and the resolution of
errors and deviations in selected documents. If the firm has not got proper
change and version controls over its system life-cycle and validation
documents, then the validation status is suspect.
23.12 Inspectors should consider all parts of PIC/S GMP Annex 11 for relevance to
particular validation projects and in particular, the 'Principle' and items 1, 2, 3,
4, 5 and 7.
23.13 The lack of a written detailed description of each system, (kept up-to-date
with controls over changes), its functions, security and interactions
(A11.4); a lack of evidence for the quality assurance of the software
development process (A11.5), coupled with a lack of adequate validation
evidence to support the use of GMP related automated systems may very
well be either a critical or a major deficiency. The ranking will depend on
the inspectors risk assessment judgement for particular cases. (NB.
Since 1983, the GMPs have called for validated electronic data-processing
systems and since 1992 for the validation of all GMP related computer
systems).
23.14 If satisfied with the validation evidence, inspectors should then study the system
when it is being used and calling for printouts of reports from the system and
archives as relevant. All points in Annex 11 (6, 8-19) may be relevant to this
part of the assessment. Look for correlation with validation work, evidence of
change control, configuration management, accuracy and reliability. Security,
access controls and data integrity will be relevant to many of the systems
particularly EDP (i.e.: Electronic Data Processing) systems.
52
VSR=A best practice high level report, summarising the validation exercise, results and
conclusions, linking via cross referencing to lower level project records, detailed reports
and protocols. This is useful for briefing both senior managers, in regulated user
organisations and for reference by auditors/ inspectors.
53
54
PI 011-3
Page 33 of 50
25 September 2007
23.15 Consider also PIC/S GMP 4.9 and EC Directive 91/356/EEC Article 9(2) for
EDP systems. Guidance on the common industry interpretation of Annex 11 is
given in the GAMP Guide, from the German APV.
23.16 Deficiency ratings applied by Inspectors will be based on the relative risk
of the application and their judgement of risk criticality.
24.
Table 1
Table 13.5 in the publication Good Computer Validation Practices, (Suggested Further
Reading Ref.1), provided a summary of typical information to be made available to an
inspector as part of preparation work. As it is still largely relevant, it is reproduced in
updated form below, with the authors permission, for information:
INSPECTORS - PREPARING FOR AN INSPECTION
1.
Details of the organisation and management of IT/Computer Services and Project Engineering on
Site.
2.
The regulated users policies on procurement of hardware, software and systems for use in GxP
areas.
3.
4.
5.
The project management standards and procedures that have been applied to the development of
the various applications.
6.
Identify work contracted out routinely for systems support and maintenance.
7.
A list, or inventory, of all Computerised Systems on site by name and application for business,
management, information and automation levels. The list should also indicate validation status and
risk ranking. (Include basic schematics of installed hardware and networks).
8.
Identify and list those systems, sub-systems, modules and/or programs that are relevant to GxP
and product quality. Cross-refer to the lists provided for 6 above.
9.
For the GxP significant elements and systems identified in 7 please provide additional information
as below:
10. Details of disaster-recovery, back up, change-controls, information security, and configuration
management.
11. A summary of documentation that generally exists to provide up-to-date descriptions of the
systems and to show physical arrangements, data flows, interactions with other systems and life
cycle and validation records. The summary should indicate whether all of these systems have
been fully documented and validated and confirm the existence of controlled system description
documents as required by EU GMP A11 (4).
12. A statement on the qualifications and training background of personnel engaged in design, coding,
testing, validation, installation and operation of computerised systems, including consultants and
sub-contractors, (specifications, job descriptions, training logs).
13. State the firms approach to assessing potential suppliers of hardware, software and systems.
14. Specify how the firm determines whether purchased or in-house software has been produced in
accordance with a system of QA and how validation work is undertaken.
15. Document the approach that is taken to the validation and documentation of older systems where
original records are inadequate.
16. Summarise the significant computer system changes made since the last inspection and plans for
future developments.
17. Ensure that records relating to the various systems are readily available, well organised, and key
staff are prepared to present, discuss and review the detail, as necessary.
PI 011-3
Page 34 of 50
25 September 2007
Table 2
55
Software Related - Inspectors Aide Memoir
Life Cycle Stage
1. Development
1. Development
1. Development
2.
Implementing
2.
Implementing
3.
Testing (Modules)
Testing (Integrated
Modules).
4.
Maintenance
5.
Documentation
6.
Re-validation.
7.
Other matters
55
Some of the details below are not relevant for COTS but it is necessary to have clearly
defined the requirements for intended use and to have assessed the applications
fitness for purpose.
56
PI 011-3
Page 35 of 50
25 September 2007
Table 3
Computer System Validation Related Inspectors Aide Memoir
Number
Element
1.
Define
2.
Testing
3.
Documented results
4.
Verify correctness
5.
6.
Conclusions
7.
Approval
8.
On-going evaluation
PI 011-3
Page 36 of 50
25 September 2007
Table 4
Annex 11 Inspectors Checklist
Point
Requirement
Inspectors
Check/Comment
Personnel (1)
Personnel (1)
Validation (2)
System (3)
policy
and
Influence of environment
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(14)
(15)
Alternative
routine
arrangements
established in the event of system failure.
(16)
(17)
(18)
(19)
PI 011-3
nd
Page 37 of 50
25 September 2007
Table 5
General Points for Inspectors To Consider On Inspection
Number
Area
Remember
1.
Personnel
2.
Organisation
Is management involved?
3.
Organisation
4.
Data system
5.
Data system
6.
Validation
7.
Security
8.
Maintenance
9.
Control of System
10.
Self-inspections
PI 011-3
Page 38 of 50
25 September 2007
Table 6
57
Overview of User Responsibilities (from GAMP 4 Table 7.1)
Step
Task
Description
1.
Identify system
2.
Produce URS
3.
Risk Assessment
Assessment of system
components
Supplier assessment
4.
5.
6.
Monitor development of
system
7.
8.
9.
Perform testing
10.
11.
12.
Maintain System
13.
System Retirement
57
Refer also to Section 15 for context (validation strategy for different systems).
PI 011-3
Page 39 of 50
25 September 2007
25.
(1)
(2)
(3)
(4)
(5)
(6)
Software
21 CFR 211.68,
180, 188, 192
21 CFR Part11
Quality System
21 CFR 820
GLP
21 CFR 58
(7)
ISO standards:
Quality management and quality assurance
ISO 9000-1 Part 1: Guidelines for selection and use.
ISO 9000-3 Part 3: Guidelines for the application of ISO9001:1994 to the
development, supply, installation and maintenance of
computer software. See also current Tick-IT Guide for
construction, software engineering, assessment and
certification (see ref. 12 re:BSI DISC London)
Quality Management and quality system elements
ISO 9004-1 Part 1: Guidelines.
ISO 9004-2 Part 2: Guidelines for Services .
ISO 9004-4 Part 4: Guidelines for quality improvement.
ISO 10005: 1995
Quality management - Guidelines for quality plans.
ISO 10007: 1995
Quality management - Guidelines for Configuration
Management
PI 011-3
Page 40 of 50
25 September 2007
IEEE Publications:
IEEE 729
IEEE 730
IEEE 828
IEEE 829
IEEE 830
IEEE 983
IEEE 1012
IEEE 1298
(9)
British Standards:
BS 7799:
BS 7799: 2000
(10)
(11)
PI 011-3
Page 41 of 50
25 September 2007
26.
1.
2.
3.
4.
5.
General Principles of Software Validation - Final Guidance for Industry and FDA
Staff (FDA, CDRH, January 2002)
6.
7.
PDA Technical Report No. 32, Report on the Auditing of Suppliers providing
Computer Products and Services for Regulated Pharmaceutical Operations
(PDA, 1999)
8.
9.
10.
11.
12.
13.
14.
15.
PI 011-3
for
Good
Page 42 of 50
Clinical
Practice.
(ICH-
European
25 September 2007
27.
GLOSSARY OF TERMS
This glossary has been extracted predominantly from the (1) EU GMP Annex 15,
Qualification and Validation document, [see Further Reading Ref:14]; (2) the GAMP
Guide; and (3) the PDA Technical Report No 18. The list of definitions has been
compiled to reflect the current terminology generally accepted internationally.
Inspectors may have to correlate or adapt the terms in the light of internal policies,
standards and guidelines used by regulated users companies and relevant SDLC
methodologies. The sources of each of the definitions have been identified in the
following manner:
(b)
(c)
it is created using means that the signatory can maintain under his
control; and
(d)
Application-Specific Software
A software program developed or adapted to the specific requirements of the
application. (3)
Automated System
Term used to cover a broad range of systems, including automated manufacturing
equipment, control systems, automated laboratory systems manufacturing execution
systems and computers running laboratory or manufacturing database systems. The
automated system consists of the hardware, software and network components,
together with the controlled functions and associated documentation. Automated
systems are sometimes referred to as computerised systems; in this Guide the two
terms are synonymous. (2) (GAMP 4 (3) Scope page 14)
Bespoke
A system produced for a customer, specifically to order, to meet a defined set of user
requirements. (2)
Bug
A manifestation of an error in software (a fault). (2)
PI 011-3
Page 43 of 50
25 September 2007
Change Control
A formal system by which qualified representatives of appropriate disciplines review
proposed or actual changes that might affect a validated status of facilities, systems,
equipment or processes. The intent is to determine the need for action that would
ensure that the system is maintained in a validated state. (1)
[Authors note: FDA may specifically require evidence of pre and post implementation
reviews of changes. The latter to detect any unauthorised changes that may have been
made despite established procedures. These are quality assurance activities.]
Commercial off-the-shelf (COTS)
Configurable Programs- Stock programs that can be configured to specific user
applications by filling in the blanks, without (COTS) altering the basic program. (3)
Computer Hardware
Various pieces of equipment in the computer system, including the central processing
unit, the printer, the modem, the cathode ray tube (CRT), and other related
apparatus. (3) (See also Figure 1, page 8, of this document).
Computer System
Computer hardware components assembled to perform in conjunction with a set of
software programs, which are collectively designed to perform a specific function or
group of functions. (3) (See also Figure 1, page 8, of this document).
Computerised System
A computer system plus the controlled function that it operates. (3)
[Authors note: Today this may be considered to be rather a narrow definition, especially
in the context of integrated computers. The definition should therefore include all
outside influences that interface with the computer system in its operating environment.
These may typically include monitoring and network links, (to/from other systems or
instruments), manual (keypad inputs), links to different media, manual procedures and
automation. The term also covers automated instruments and systems. See also the
definition for automated systems in this section and Section 26, Reference 11, the
GLP OECD consensus document. PIC/S GMP Annex 11(4) is relevant here regarding
documenting the scope and interaction of systems.]
Configuration
The documented physical and functional characteristics of a particular item, or system,
e.g. software, computerised system, hardware, firmware and operating system. A
change converts one configuration into a new one.
Configuration Management
The process of identifying and defining the configuration items in a system, controlling
the release and change of these items throughout the system life cycle, recording and
reporting the status of configuration items and change requests, and verifying the
completeness and correctness of configuration items. (2)
Debugging (IEEE)
The process of locating, analysing, and correcting suspected faults. (2)
PI 011-3
Page 44 of 50
25 September 2007
Electronic Signature
An electronic measure that can be substituted for a handwritten signature or initials for
the purpose of signifying approval, authorisation or verification of specific data entries.
See also definition for Advanced Electronic Signature, above.
Electronic Signature (FDA)
21 CFR Part11 defines this as: The computer data compilation of any symbol or series
of symbols executed, adopted, or authorised by an individual to be the legally binding
equivalent of the individuals hand-written signature.
Electronic Signature (EU)
1999/93/EC states: electronic signature means data in electronic form which are
attached to or logically associated with other electronic data and which serve as a
method of authentication. (See also Advanced Electronic Signature) (4)
Embedded System
A system, usually microprocessor or PLC based, whose sole purpose is to control a
particular piece of automated equipment. This is contrasted with a standalone
computer system. (2)
Executive Program (ANSI/IEEE/ASO)
A computer program, usually part of the operating system, that controls the execution
of other computer programs and regulates the flow of work in a data processing
system. (2)
Firmware
A software program permanently recorded in a hardware device, such as an
EPROM. (3) (Note: EPROM stands for Erasable Programmable Read Only Memory)
Functional Requirements (ANSI/IEEE)
Statements that describe functions a computer-related system must be capable of
performing. (3)
Functional Specifications
Statements of how the computerised system will satisfy functional requirements of the
computer-related system. (3)
Functional Testing
A process for verifying that software, a system, or a system component performs its
intended functions. (3)
Hardware Acceptance Test Specification
Statements for the testing of all key aspects of hardware installation to assure
adherence to appropriate codes and approved design intentions and that the
recommendations of the regulated user have been suitably considered. (2)
Hardware Design Specification (APV)
Description of the hardware on which the software resides and how it is to be
connected to any system or equipment. (2)
Hybrid Systems
Refer to Section 21.6 of this document
PI 011-3
Page 45 of 50
25 September 2007
PI 011-3
Page 46 of 50
25 September 2007
58
Raw Data
Any work-sheets, records, memoranda, notes, or exact copies thereof, that are the
result of original observations and activities and which are necessary for the
reconstruction and evaluation of a work project, process or study report, etc. Raw data
may be hard/paper copy or electronic but must be known and defined in system
procedures. (2)
Regulated User
The regulated Good Practice entity, that is responsible for the operation of a
computerised system and the applications, files and data held thereon. (See also
User)
Revalidation
Repetition of the validation process or a specific portion of it. (2)
Security (IEEE)
The protection of computer hardware and software from accidental or malicious
access, use, modification, destruction or disclosure. Security also pertains to
personnel, data, communications and the physical protection of computer
installations. (2)
Source Code (PMA CSVC)
An original computer program expressed in human-readable form (programming
language), which must be translated into machine-readable form before it can be
executed by the computer. (2)
Standalone System
A self-contained computer system, which provides data processing, monitoring or
control functions but which is not embedded within automated equipment. This is
contrasted with an embedded system, the sole purpose of which is to control a
particular piece of automated equipment. (2)
Structural Integrity (Software)
Software attributes reflecting the degree to which source code satisfies specified
software requirements and conforms to contemporary software development practices
and standards. (3)
Structural Testing
Examining the internal structure of the source code. Includes low-level and high-level
code review, path analysis, auditing of programming procedures and standards actually
used, inspection for extraneous dead code, boundary analysis and other techniques.
Requires specific computer science and programming expertise. (2)
Structural Verification
An activity intended to produce documented assurance that software has appropriate
structural integrity. (3)
58
PIC/S Authors Note on Raw Data- For information: FDAs 21 CFR Part 11 requires the
retention of electronic records in electronic form (thus including raw data electronically
captured or recorded). Also, for all good practice disciplines regulated by competent
authorities it must be possible to reconstruct studies and reports from raw data and the
electronic records may be needed to support any paper printouts.
PI 011-3
Page 47 of 50
25 September 2007
59
This can be very risky. Fix testing/ implementation work should ideally not be carried
out initially in the live environment. All changes to the live validated system(s) must be
subjected to the firms change control, configuration management and validation
procedural controls, to ensure compliance with GMP and the maintenance of a
validated state.
PI 011-3
Page 48 of 50
25 September 2007
28.
ANSI:
APV:
BSI:
DCS:
DR:
Design Review
DS:
Design Specification
DQ:
Design Qualification
EDP:
EU:
European Union
FDA:
FS:
Functional Specification
GAMP:
GCP:
GDP
GLP:
GMP:
GxP:
IEC:
IEEE;
IQ:
Installation Qualification
ISMS
ISO:
ISPE
LIMS:
LAN:
PI 011-3
Page 49 of 50
25 September 2007
MRP:
MRP-II:
OQ:
Operational Qualification
PDA:
PIC/S:
PKI
PLC:
PQ:
Performance Qualification
QMS:
R&D:
SCADA:
SLA:
SOPs:
URS:
VSR:
WAN:
29.
REVISION HISTORY
Date
1 July 2004
25 September 2007
Version Number
PI 011-2
PI 011-3
_______________
PI 011-3
Page 50 of 50
25 September 2007