Best practices for computerised systems in regulated GxP environments.

Transcription

1 PIC/S Logo PHARMACEUTICAL INSPECTION PH/W 01/2000 (DRAFT) CONVENTION January 2000 PHARMACEUTICAL INSPECTION CO-OPERATION SCHEME PIC/S Guidance Best practices for computerised systems in regulated GxP environments. Draft Version 3.01 (January 2000) Editor: PIC/S Secretariat 9 11 rue de Varembe CH-1211 Geneva 20 Tel Fax

2 2 Table of Contents Page 1. Document History 2 2. Purpose 3 3. Scope 3 4. Introduction 4 5. Implementation of Computerised Systems 6 6. The Structure and Functions of Computer Systems 7 7. Planning and Life-cycle Management 8 8. Information Technology Management and Administration 9 9. User Requirement Specifications Functional Specifications Change Management Change Control and Error Report Systems Software and Hardware Selection Important QMS and Software Standards Attributes Testing Validation Validation Strategies and Priorities GAMP Validation Approach Retrospective Validation System Security, Including Back-up Data Changes Audit Trail/Critical Data Entry Electronic Records and Electronic Signatures Personnel Inspection considerations References for Relevant Standards and GMP Guides/Codes Suggested Further Reading Glossary Acknowledgments Table of Amendments Document History Working Party Coordinators/Authors: 3 rd Draft: Mr Anthony J Trill, MCA, UK 2 nd Draft: Ms Sharyn McGregor, TGA, Australia 1 st Draft: Mr Paul Humphreys, TGA, Australia 1 st draft submitted to PIC/S Committee 4 June 1998 PIC/S Committee requested new title and re-formatting 9 June nd draft submitted to PIC/S Committee 21 September rd draft submitted to PIC/S Committee February 2000 PH/W 01/2000 AJT 3 rd Draft January 2000 Page 2 of 2

3 PH/W 01/2000 AJT 3 rd Draft January 2000 Page 3 of 3 3

4 4 2. Purpose 2.1 International regulatory agencies have collaborated to produce this harmonized guidance for the validation, control and use of computerized systems in GxP regulated applications in the pharmaceutical industry. It is intended for both external reference by the pharmaceutical industry and its suppliers and also for internal use by regulatory inspectors and investigators. 2.2 This guidance document is intended to provide a logical explanation of the basic requirements for the implementation, validation and operation of computerised systems. Additionally, the document may be adapted to identify the criteria that would be expected to be considered if a manufacturer, or a regulatory agency, were to conduct an inspection of the implemented computerized system(s), against GxP compliance requirements and/or perceived risks 2.3 At the time of issue, this document reflects the current state of the art. However, it is not intended to be a barrier to technical innovation or the pursuit of excellence It should be noted that whilst this document has been prepared with care, it is important for national legislation to be referred to when determining the extent to which the provisions laid down in this document may be applicable. 3. Scope 3.1 It is acknowledged that the field of computer technology continues to develop at a considerable speed and the pharmaceutical manufacturer has to ensure that the software has been developed to best software engineering practices in a quality assured manner. This document sheds some light on the techniques and controls required for this. 3.2 For hardware, peripherals, integrated process links and system functionality in general then the controls and testing arrangements are by comparison to software, fairly mature, logically more visible and the failure modes more predictable. 3.3 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.4 The scope of the document is broad, covering necessary steps and the documentation needed for the implementation and validation of a computerised system. Management of such projects requires the linking of important aspects of management policies, documentation and record systems embracing the respective professional disciplines involved in the development and use of the computerised system. 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 user [purchaser and user of the computerised system]. 3.5 Of necessity this guidance contains some how to achieve GxP compliance advice for suppliers and developers of software and automated systems, in addition to guidance for the users in the pharmaceutical industry. This is because of the iterative nature of software PH/W 01/2000 AJT 3 rd Draft January 2000 Page 4 of 4

5 5 development and the requirement for quality and functionality to be built into the software in a disciplined manner, to ensure structural integrity, consistency, robustness and reliability. This will generally be outside of the direct control of the pharmaceutical business (purchaser/customer). There will normally be a need to manage and control the split responsibilities of contracted suppliers (whether in-house or external party) and pharmaceutical businesses (customers), for project management, product specifications, quality assurance standards and performance. 3.6 This document also identifies the important aspects of validation of computerized systems. Descriptions of strategies that may be used for different categories of computer systems are described as well as identifying the approach that might be taken for the retrospective validation of legacy (old) systems. 3.7 The important elements to be considered for review during an inspection of the system are also considered and this guidance document should be used as a reference during PIC/S related inspections. (Source: PIC/S SOP PI 001-1, 22 October 1999). 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 computerized systems to establish quality assurance systems and records capable of demonstrating compliance with current GxP requirements and related guidance. 3.9 The structure of the document is designed to identify discrete subsections and their interrelationship within the principal topics of Implementatio n, Validation and Operation of computerised systems. To assist users of this document, a list of reference information is provided where more specific details of a number of principles, systems and procedures relevant to these topics may be found. A reference list and a glossary of terms commonly used in this industry sector will be found at the end of this document. 4. Introduction 4.1 In recent years there has been an increasing trend to integrate electronic record systems with manufacturing operations. In future years it is expected that the industry s reliance on computer systems will continue to grow, rather than diminish. The use of computerised systems should provide enhancements in product quality assurance, if the systems are properly established, are validated and are operating effectively and in accord with GxP requirements. The extent of additional validation effort and control arrangements should not be underestimated and a harmonized approach by industry and regulators is beneficial. 4.2 Commercial off the shelf, standard, or proprietary systems can be particularly difficult to assess from a quality and performance point of view. For critical GxP applications it is essential for the pharmaceutical company to define a requirement specification prior to selection and to carry out a properly documented risk analysis for the various system options. Information for such exercises may come from supplier audits and research into the supplier s product versions in the user community and literature. This risk-based approach is one way for a firm to demonstrate that they have applied a controlled methodology, to determine the degree of assurance that a computerized system is fit for purpose. It will certainly be useful evidence for PH/W 01/2000 AJT 3 rd Draft January 2000 Page 5 of 5

6 6 consideration by an inspector. 4.3 Whilst much of the detailed industry guidance relates to bespoke and configured applications there are a number of tools and assessment techniques recommended for the commercial packages and standard automated equipment mentioned above. For complex automated state of the art processing equipment (such as high output tabletting machinery with in-process monitoring and feedback control functionality) then it is helpful for suppliers to anticipate the user s requirement specifications (AURS = Anticipated User Requirements Specification) and thus give added value for their products. The QA and validation aspects for the automation aspects will inevitably be complex and subsumed in the major engineering project activated by the potential pharmaceutical customer. Inspectors will be interested in the evidence relating to the firm s assessment of the supplier s critical automated features aswell as the traditional engineering, qualification and process performance aspects. Much of the guidance given in the GAMP Guide for example is scaleable to complex projects and equipment with sub-contracted features. (Note: The risk assessment described above will identify critical features and functions for both the project team and the inspector). 4.4 When a GxP inspector has to assess an installed computerized system in a pharmaceutical company, he/she may consider some, or all, of the elements shown in Figure 1, (page 7): Computerized system, (viz: the controlling system and the controlled process in an operating environment). The inspector will consider the potential risks, direct or indirect, from the automated pharmaceutical process to the product quality or data integrity, in order to assess the fitness for purpose of the particular system(s). The company s risk assessment records may also be referred to as part of this process. The inspector s assessment may also involve a consideration of system life cycle, quality assurance measures, validation and operational control evidence for the controlling system, as well as validation and operational experience with the controlled process. (Note the term Computerized System is analogous to Computer Controlled System or Programmable Electronic System.) 4.5 The company s validation documentation should include assessments and reports of quality and performance measures for all the life-cycle stages of software and system development, its implementation, qualification and formal acceptance. 4.6 The Pharmaceutical Industry Systems Validation Forum in the UK developed the Good Automated Manufacturing Practice (GAMP) Supplier Guide to assist software suppliers in implementing an appropriate quality management system. The GAMP Guide and appendices has evolved largely to define best practices in specifying, designing, building, testing, qualifying and documenting these systems to a rigorous validation management scheme, largely for the controlling system. The GAMP 1998 Guide is divided into two volumes: Vol 1 (Part One) 'The User Guide' outlines the requirements for validation of automated systems and describes the role of the pharmaceutical user organisation in this process. Vol 1 (Part Two) 'The Supplier Guide' describes the quality requirements for a supplier of automated systems to the pharmaceutical industry and describes a proposed management system for such suppliers. A companion, Volume 2 'Good Practice Examples' contains guidance and examples of the application of 'good practice' to particular systems, and includes various Good Practice definitions, together with sections on the validation of: PH/W 01/2000 AJT 3 rd Draft January 2000 Page 6 of 6

7 7 Information Systems; Programmable Logic Controller (PLC) and Supervisory Control Automated Data Acquisition (SCADA) systems; Process Control Systems. 4.7 GAMP 1998 brings together 'user' and 'supplier' requirements, controls, activities, quality systems and deliverables. (See Appendix 10 'User Quality and Project planning' and the 'X' lifecycle model in GAMP 1998, in particular). 4.8 The performance qualification of the system, in its operating environment, will be against a User Requirements Specification (URS) and this 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. Cross-references to any related, relevant process validation documentation should be clearly stated in respect of the latter. The GAMP Supplier Guide and PDA technical report No 18 provide good practice guidance to drafting and using a URS, whereas pharmaceutical process validation guidance is given elsewhere (see PIC/S PH 1/96 and related EU/USFDA documents). 4.9 Computerized systems may simplistically be considered as existing as four main application types, i.e.: Process control systems, record systems, data-processing systems and data storage systems. There may be links between these four types of system, described as interfaces. For critical systems, (i.e. those that impact product quality and /or data integrity), the inspector should study the user s specifications, reports, data, acceptance criteria and other documentation for various phases of the project. The pharmaceutical company should be able to demonstrate through the validation evidence that they have a high level of confidence in the integrity of both the processes executed within the controlling computer system and in those processes controlled by the computer system within the prescribed operating environment The regulated pharmaceutical system users have the ultimate responsibility for ensuring documented validation evidence is available to GMP inspectors for review In addition to the validation considerations, the inspector will also be concerned with assessing the basic operational controls, quality system and security features for these systems, as indicated in the EU GMP Annex 11 and amplified in the APV Guidance (4), q.v. 5. Implementation of Computerized Systems 5.1 The assurance of the reliability of a Supplier s software products is attributable to the quality of the software engineering processes followed during development. This will include design, coding, verification testing, integration, version, and modification control features of the development life cycle, (including after sales support). In order for the customer to have a high degree of confidence in the reliability of the products, they should, ideally, evaluate the quality methodology of the supplier for the design, construction, supply and maintenance of the software. A formal, extensive review of the history of the Supply Company and the software package should provide an additional degree of assurance of the reliability of the software. Prospective purchasers should consider any known limitations and problems for particular software packages or versions and the adequacy of any PH/W 01/2000 AJT 3 rd Draft January 2000 Page 7 of 7

8 8 corrective actions by the Supplier. Appropriate, comprehensive customer acceptance testing should support the final selection of the software package. Errors often come to light after implementation and it is important for the Supplier to advise/assist the Customer of with any problems and modifications to resolve errors. For so called standard software packages it is important that purchasers are vigilant in maintaining reliable systems. This will include reviewing their own experiences, (e.g. error reporting and resolution), reading relevant literature and by participating in User Groups to identify and resolve any serious problems. 5.2 For complex software products, if the reliability is not able to be directly assessed, nor completely evaluated, then it is even more important to assure a good construction process is used and is properly documented. (Note: It is recognised that complex commercial proprietary applications can be extremely difficult to assess due to commercial secrecy and rivalry between suppliers, competing for market share. Such software has been referred to as SOUP (Software Of Unknown Pedigree) by the Real Time Engineering group in the UK and the Interdepartmental government Committee for critical Software Engineering (ICSE). Market research plus focused quality system and product specific audits of the suppliers by the firm (or by an accredited third party auditor) may be essential 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. The need for control and documentation of the development, implementation and operations of a computer system is extremely important for the validation of the system. There needs to be a strong emphasis on quality in the development stages. 6. The Structure and Functions of the Computer System(s). 6.1 The current USFDA document Software Development Activities 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. Quality cannot be inspected or tested into the finished software. Each phase of the development process must be controlled to maximise the probability the finished software meets all quality and design specifications A computerized system is composed of the computer system and the controlled function or process. The computer system is composed of all computer hardware, firmware, installed devices, and software controlling the operation of the computer. The controlled function may be composed of equipment to be controlled and operating procedures that define the function of such equipment, or it may be an operation, which does not require equipment other than the hardware in the computer system. Interfaces and networked functions through LAN and WAN are aspects of the computerised system and operating environment potentially linking a multitude of computers and PH/W 01/2000 AJT 3 rd Draft January 2000 Page 8 of 8

9 9 applications. A firm s GxP system environment, functionality and interactions with other system(s) needs to be clearly defined and controlled in respect of EU GMP Annex 11 (4). It may be necessary to ring fence personal PC applications and Internet/ / 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 Schematic (below) identifies the relationship of the various components of a Computerrelated system. SOFTWARE OPERATING PROCEDURE HARDWARE COMPUTER SYSTEM (Controlling System) EQUIPMENT (OPTIONAL) CONTROLLED FUNCTION COMPUTERISED SYSTEM OPERATING ENVIRONMENT Figure 1. Schematic Illustrating the Components of a Computer Controlled System (A computerised system in its operating environment) 6.3 There are a large variety of computer systems used in pharmaceutical manufacturing organisations, which vary in their size and complexity. For example, a significant proportion of programmable electronic systems and proprietary automated equipment for manufacturing or laboratory use, contains 'firmware' with embedded software in place (for further details on firmware PH/W 01/2000 AJT 3 rd Draft January 2000 Page 9 of 9

10 10 and embedded software refer to the glossary). These embedded systems also need to be quality assured and validated. 7. Planning and Life-cycle Management 7.1 A high level of assurance of quality and reliability cannot be attributed to a computerised system based on a series of tests confirming the correct function of the software and its interaction with hardware alone. There needs to be a formal planned approach to assure quality is built into the product. ISO 9001 provides a quality system model for quality assurance in design, development, production, installation and servicing. ISO : 1997 Part 3 provides guidelines for the application of ISO 9001: 1994 to the planning, development, supply, installation and maintenance of computer software. ISO 9001 identifies the need to plan and ISO has a comprehensive list of sub-plans and planning issues that should be addressed. 7.2 ISO/IEC 12207:1995 provides guidance on acceptable practices for Information Technology - Software life cycle processes and ISO 9004, ISO and ISO provide guidance on Quality Management and system elements, including quality plans and configuration management. IEEE 1298 is specific and prescriptive on what should be addressed in planning. 7.3 It is imperative to plan how to satisfy requirements before undertaking the details of doing the work. Plans should identify what the objectives are, and how they are going to be met. Having planned, it is important to constantly review and revise the plan to keep as close to original commitments as possible. 8. Information Technology (IT) Management and Administration 8.1 It is important for a manufacturer to have in place a comprehensive manufacturer policy and related procedure for the purchase of computer systems. Ideally these procedures would cover all computerised systems; this PIC/S document will only concern itself with those systems that have an impact on GMP requirements for pharmaceutical product manufacture. 8.2 The organisation should regard disciplines related to the introduction of a computerised system as in accord with the basic principles of project management. Achieving the quality; performance and reliability objectives for any project requires competence in engineering and design. Where manufacturers do not have the resources for engineering and design within their own organisation, there is a heavy reliance on the supply company s resources. 8.3 To satisfy the quality, performance and reliability objectives, the manufacturer needs to assure that the supplier s management policies; systems and related procedures will achieve the desired objectives It is important to acknowledge that the scope and level of documentation and records needed to formalise and satisfy basic project management requirements for critical systems will be dependent upon: the complexity of the system and variables relating to quality and performance; PH/W 01/2000 AJT 3 rd Draft January 2000 Page 10 of 10

11 11 the need to ensure data integrity; the level of risk associated with its operation; the GMP impact areas involved; the need to safeguard product quality, process control and critical records integrity. 8.5 There should be within the manufacturing organisation clearly defined responsibilities for the management of all information technology products, systems and projects. Management should cover the full spectrum, from simple input/output devices and programmable logic controllers (PLCs) through to integrated supervisory or information systems and business management levels. These responsibilities should involve development and administration of policies on purchase of IT products, as well as the introduction, commissioning and maintenance of IT products. The responsib ilities should extend to development and implementation of formal monitoring, auditing and servicing of each system and designate the related documentation and records for such activities. 8.6 BS 7799: 1999, (12), 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 security. It supercedes BS 7799: 1995, which is withdrawn. The 1999 revision takes into account recent developments in the application of information processing technology, particularly in the area of networks and communications. It also gives greater emphasis to business involvement in, and responsibility for, information security. The 1999 revision was carried out by an international group of experts and a range of additional guidance documents from BSI-DISC supports the standard. 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. 9. User Requirement Specifications (URS) 9.1 When utilising a computerised system within manufacture there is a need for development and maintenance of a written detailed description of the system to include all software and hardware elements, such as a system control document. This document should provide a record of the User Requirement Specifications (URS). This document should also be the definitive statement of what the system must or must not do. This document is also important for legacy as well as underdevelopment systems. 9.2 If properly documented, the URS should be complete, realistic, unrestrictive, definitive and testable. Establishment and agreement to the requirements for the software is of paramount importance. 9.3 User Requirement Specifications, requirements should satisfy the following criteria: Each requirement should be reviewed, authorised and uniquely catalogued. There should be no conflict between requirements. Each requirement, particularly mandatory/regulatory requirements, should be testable. The URS should be understood and agreed by both user and supplier. Note: This is PH/W 01/2000 AJT 3 rd Draft January 2000 Page 11 of 11

12 12 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. There should be clear distinction between mandatory/regulatory requirements and optional features. Figure 2 on page 11 shows the relationship between URS and performance qualification (PQ). 10. Functional Specifications (FS) 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, ie. the customer's needs The functional specifications should provide a precise and detailed description of each of the essential requirements for the computer system and external interfaces. This means descriptions of functions, performances and where applicable, design constraints and attributes For particular types and levels of systems it may be appropriate to have a combined URS and FS. Section 18 of this document gives further details of validation strategies for the five different categories for computer software as identified in the GAMP Guide Evaluation of the URS and the functional specifications should allow identification of the GxP requirements covered by the system. Additionally the URS will provide information as to where there are important interfaces between the system and manual operations. The URS should also form the basis for a risk analysis of the system for GxP compliance requirements, in addition to other risks such as safety. The risk analysis and the results including the reasons for the ranking as either: critical or not critical should be documented. The nature of any GxP risks should be clearly stated The manufacturer should be able to provide documentation describ ing the computer system(s) to include logic flow or block diagrams where practical, also indication of hardware layout and interaction. These basic schematics should align with the functional specification and be traceable to the URS All computerized systems should have been subjected to prospective validation. However, as user s systems evolve through modification, enhancement or integration and in response to additional regulatory requirements, it may be necessary to conduct additional re-qualification and revalidation work on the legacy systems. The URS should be correspondingly updated as per the validation life cycle and for Annex 11(4). [Note: GAMP Forum has recently produced a draft guidance document on this topic (q.v.)]. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 12 of 12

13 13 Figure 2 on page 11 shows the relationship between FS and operational qualification (OQ). 11. Change Management 11.1 It is important for proper control that a comprehensive change management system be instituted. This may take two forms in that during the Design phase it may only be necessary to keep records pertaining to the project up-to-date without formal sign-off approvals for all changes. However, once the project reaches a point where specifications are under development and conceptual aspects have been finalised, then a formal change control procedure should be established which will require clear, prescriptive and accurate documentation and records. It is important the responsibilities of participants in the change control procedure be carefully defined A system control document or some other record system should be used to achieve a documented baseline record for the computerised system. The system control documentation should be the definitive statement of what the system must do. The control document should provide a record of the User Requirement Specifications. The change control procedure for the computerised system project should be integrated with the Master change control procedure for the manufacturing organisation. The change control procedure will need to take account of the corresponding procedures and records used by suppliers, integrators and other parties contracted to support the particular system and applications. Common IT infrastructure features may need to be controlled centrally by IT systems and security management. Key roles, responsibilities and procedures need to be clearly documented in relevant internal and external Service Level Agreements, (SLAs). 12. Change Control & Error Report System The formal change control procedure should outline the necessary information and records for the following areas: - Records of details of proposed change(s) with reasoning. System status and controls impact prior to implementing change(s). Review and change authorisation methods (also see 12.5) Records of change reviews and sentencing (approval or rejection). Method of indicating change status of documentation. Method(s) of assessing the full impact of change(s). Interface of change control procedure with configuration management system The procedure should accommodate any changes that may come from enhancement of the system, ie. 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 actions taken should be fully documented and signed off. The records should be either paper based or electronically filed on a separate, secure, computer system Computer systems seldom remain static in their development and use. For documentation PH/W 01/2000 AJT 3 rd Draft January 2000 Page 13 of 13

14 14 and computer system control it should be recognised that there are three areas that would initiate change or a review for change. These are: a deviation report; an error report; or a request for enhancement of the computer system. 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 actioning. The change control procedure should complement and interlink with the deviation and errors report system. Section 6 of the APV Guidelines Computerized Systems, (GAMP Guide), provides further guidance on error handling and system failure 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 Changes to the system should be not undertaken without review and authorisation of all stakeholders responsible for the establishment of the original user requirements. Test scripts should be used to verify the acceptability of the software element developed in response to a change request. Integration testing may also be necessary before release of the new software version. 13. Software and Hardware Selection 13.1 The quality controls and quality assurance procedures, documentation and records related to the development and production of the software and hardware for computer systems are of critical importance. There are a number of accepted models for software development eg. The spiral model of development, the waterfall model and the life cycle model. All models have their own special attributes. GAMP identifies the importance of the application of a V framework (see figure 2 below) for specifications, design and testing to the life cycle model requirements. GAMP 1998, User Guide Vol 1, Part 1 Appendix 10 addresses 'User Quality and Project Planning' - see also sections 3.4 and 7.1 of this PIC/S document. USER REQUIREMENTS SPECIFICATIONS RELATED TO PERFORMANCE QUALIFICATION FUNCTIONAL SPECIFICATIONS RELATED TO OPERATIONAL QUALIFICATION DESIGN SPECIFICATIONS RELATED TO INSTALLATION QUALIFICATION PH/W 01/2000 AJT 3 rd Draft January 2000 Page 14 of 14

15 15 SYSTEM BUILD Figure 2. Basic framework for specification, design and testing 13.2 Supplier reputation and trading history provide some guidance to the level of reliability that maybe assigned to the product supplied. The pharmaceutical manufacturer therefore should have in place procedures and records that indicated how and on what basis suppliers were selected Compliance with a recognised quality management system (QMS) may provide the manufacturer and regulatory agencies with the desired confidence in the structural integrity, operational reliability and on-going support for software and hardware products utilised in the system. The accreditation assessment schedule and scope of certification needs to be relevant to the nature of the proposed application. Structural integrity and the application of good software and hardware engineering practices are important for critical systems Confidence in the structural integrity may be based to some extent on the recognition of accreditation of a company s QMS to ISO 9001 standard, TickIT accreditation and utilisation of the ISO guide. The assessment schedules applied by the standards auditors should cover the engineering quality standards, actual practices, controls and records in place including nonconforming product (error feedback from the market), corrective actions, change management and so forth for particular products and versions. These can be very useful benchmarks for the design engineering, replication and maintenance standards in place at suppliers of large proprietary or COTS packages and can assist pharmaceutical clients with short listing and selection criteria However, an assessment of the supplier s QMS and recognized certification, alone is unlikely to be the final arbiter for critical systems. The certification may very well be inadequate, or inappropriate. In such cases, the manufacturer should seek to conduct its own supplier audit based on pre-determined requirements, specifications and anticipated risks. This may also include the specific conformity assessment of existing, aswell as bespoke software and hardware products. GAMP and PDA guideline documents identify a need to audit suppliers for systems carrying a high risk and have detailed guidance on supplier auditing procedures/ options Appendix 4 of the GAMP User Guide, which incorporates the APV commentary on EU GMPs Annex 11 provides specific advice on quality and operational matters to help ensure compliance with the EU GMPs. Users and suppliers are advised to note this guidance and adopt a similar approach, to ensure that software, hardware and systems are: quality assured; fit for their intended purpose; and supported by appropriate documentation for quality and validation traceability. 14. Important QMS and Software Standards Attributes 14.1 The Standards ISO 9001 (ISO ) & IEEE 1298 have a number of important features PH/W 01/2000 AJT 3 rd Draft January 2000 Page 15 of 15

16 16 that can be summarised in the following points: They are structured around a QMS approach to the development, testing and documentation for software design, production and installation. Compliance with the standard requires formal systems for control, traceability and accountability of product(s) and personnel. The standard outlines the features and requirements of a life cycle approach to software production ( manufacture ), with emphasis on the importance of a change control procedure. 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: Unit code testing; Integrated module testing; and Customer acceptance testing There are a number of advantages in organisations utilising a QMS approach for development and changes to software product. It would be expected that this approach if utilised by developers and producers of software should ensure (within the limitations of the quality management system approach) the following: Management commitment to quality and design control by instituting systems for quality control, documentation and quality assurance. Development, production and installation based on quality plans, verified by quality records. The QMS requires development, testing and programming standards. Adherence to quality assurance disciplines such as internal audits of the processes, corrective & preventative action procedures and control of non-conforming product. QMS methodology to establish requirements for purchased (subcontracted) software product. 15. Testing 15.1 Assurance of reliability is achieved by execution of quality plans and testing during the software development process. This involves unit code testing and integration testing in accord with the principles of ISO and IEEE This testing is defined as verification of the software element. Verification is defined as the process of determining whether or not the products of a given phase of the software development cycle fulfil the requirements established during the previous phase. The development and testing of hardware and software should be done under a quality assurance system agreed and defined in a contract between the pharmaceutical manufacturer and the supplier/ developer IT, QA and engineering departments One of the most critical aspects of development of software is the integration testing phase where individual elements of software code (and hardware, where applicable), are combined and tested until the entire system has been integrated. Testing during this stage should involve where appropriate code walk -throughs including evaluation of critical algorithms and/or routines For some relatively simple GxP systems, for example PLCs and systems based on basic PH/W 01/2000 AJT 3 rd Draft January 2000 Page 16 of 16

17 17 algorithms or logic sets, the testing conducted as part of the qualification phases at the installation, operational and performance stages of the system may provide adequate assurance of reliability of the computerised system. For more details on installation qualification (IQ), operational qualification (OQ) and performance qualification (PQ) refer to the glossary. For many systems it is important to recognise that the validation exercise should not be limited to the installation, operational and performance qualification stages. For 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 Test scripts should be developed, formally documented and used to demonstrate that the system has been installed, and is operating and performing satisfactorily. These test scripts should be directly related to the User Requirements Specifications and the Functional specifications for the system. In software engineering terms the satisfactory results obtained from the testing confirm design validation. This schedule of testing is specifically aimed at the validation of the computer system. (Note: The supplier/ developer should draft test scripts according to the project quality plan to verify performance to the functional specifications The scripts should test the structural integrity, critical algorithms and borderline aspects of the integrated software. The test scripts related to the user requirements specification should be developed by the user) Any processing equipment and activities related to or controlled by the computer system would require additional OQ and PQ testing regimes Each requirement should be specified in a manner such that compliance with the requirements is capable of being verified objectively by an authorised method, eg. inspection, analysis or test There is also a need for the developer to describe the crucial components of the software design including databases and internal interfaces. In complex systems, the description of crucial components should be expanded to include descriptions of subcomponents of the major component. These descriptions are the Software Design Descriptions. 16. Validation 16.1 It would be expected that the manufacturer s Validation Master Plan (VMP) should identify the company s approach to validation and its overall philosophy with respect to computerised systems. The VMP should: Identify which computerised systems are subject to validation. Provide brief descriptions of the validation strategies for different categories of computerised systems as well as other validation activities. Outline protocols and related test procedures for all validation activities including computer systems. Define reporting requirements to document validation exercises and related results. Identify key personnel and their responsibilities as part of the Validation Program. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 17 of 17

18 Validation Strategies and Priorities 17.1 The firm s range of computerised systems needs to be formally evaluated and priorities assigned for validation, based on GMP compliance criteria, ranked for product quality and data integrity. This process represents one of the most important pre-requisites of Validation Master Planning (see PIC/S doc. PH 1/96), in that it is essential to assign priorities and attention to those systems (and features within systems), that represent the highest potential for disaster, should they malfunction or become inoperative. The risk analyses and the results, together with reasoning for critical or non-critical classifications, should be documented. Risks potentially impacting on GMP compliance should be clearly identified. There are a number of techniques to help identify and analyse risks. For example, the use of hazard and operability studies, failure-mode effects analysis, cause and effect diagrams, together with other qualitative and quantitative measures, help to formalise the assessment of risks. (See the GAMP Guide for further information) Examples of systems where strong emphasis for GMP compliance is essential are: batch documentation systems; aseptic area and clean room ventilation automated control systems; dry heat tunnel controllers; lyophiliser controllers; material status control systems; autoclave controls; process control/monitoring systems. Traditionally, these systems have relied on manual systems and/or electro-mechanical controls. This requirement and emphasis for compliance is not diminished by the use of computers Other examples of critical systems would be: laboratory information management systems; process applications, eg. process monitors/controls, autoclave controllers, clean-in-place (PLC s); data handling and decision based systems, eg label verifiers, analytical instrument out-puts; other documentation systems, eg. Standard Operating Procedure manufacturing documentation and databases, inventory and status control calibration, maintenance and training records. Note: the systems listed are not exhaustive but are given as examples of typical critical or important applications The current Good Automated Manufacturing Practice (GAMP) Supplier Guide provides essential guidance to suppliers of software to the Industry. The guide also provides a concise explanation of the interrelationship between various stages of software development and the requirements for Installation, Operational & Performance Qualification. The GAMP identifies five different categories of software GAMP categories for computer systems: PH/W 01/2000 AJT 3 rd Draft January 2000 Page 18 of 18

19 Operating systems Category one computer systems would be typified as simple operating systems such as Windows or DOS, UNIX etc The software systems related to operating systems that are considered well established with a reliable history of use do not at this time, require specific validation other than as part of particular applications which they support. It is important that during the qualification stage of the validation the name and version number of the operation and system should be recorded in the Installation records Where it is necessary to upgrade an operating system then the new version(s) should be critically reviewed prior to use. Results of this review should be recorded. The review should consider the impact of all new, amended or deleted features of the new version on dependent application programs. The need for limited, or extensive, revalidation work on any applications should be carefully considered, justified and documented. Where a major upgrade of the operating system is being implemented then a re-test of critical features of the applications should be undertaken in a test environment before controlled release to the live environment Standard & smart instruments, micro controllers Category two type computer systems are generally characterised as non-user programmable firmware. Control system software generally has a particular structure. It is characterised by the fact that as little as possible is freely programmed in the adaptation of the control system to the respective application. Standard functions are used which can be adapted to the respective application by means of parameter sets. Such functions are described as tailored software modules or tailored functions and they are not specific to the application The tailored functions are in turn likewise based on control system operating systems that are not specific to the applications, and these may be based on commercially available dedicated operating systems The tailored software modules and the operating system of the control system are considered to be firmware. The proper functioning of this firmware should be sufficiently assured by the proven track record and quality assurance measures of the manufacturer Since a detailed inspection of the firmware is only anticipated in exceptional cases, it is sufficient for its documentation to be kept available by the supplier, and not at the manufacturer s production plant. The supplier must keep the corresponding documentation available. Examples of instruments containing firmware would be bar code scanners and weigh scales Dedicated operating systems are generally not inspected since their capability for the intended work has already been sufficiently demonstrated by their widespread operational use, unless a new, as yet little tried version is being used. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 19 of 19

20 These instruments are driven by non-programmable firmware. They are configurable and the configuration should be recorded in the equipment IQ. Introduction of new versions of firmware may occur during maintenance activities or equipment upgrades; such changes should be covered by a definitive application of the change control procedure. The impact of the changes on the status of the IQ should be reviewed before the controller is released for use Standard software packages Category three type computer software is generally referred to as COTS, Commercial-off-the-shelf CONFIGURABLE packages. Examples would be Lotus 1-2-3, Microsoft Excel There is currently no requirement to qualify the software of a standard software package. It is important to utilise new versions with caution. Validation effort should concentrate on the application, which includes: - System requirements and functionality. The high level language or macros used to build the application. Critical algorithms and parameters. Data integrity, accuracy and reliability. Operational procedures. However, where such standard packages are intended for use as part of a regulated application, (e.g. electronic records and signatures), then they should be considered to be in GAMP category 4 which has requirements for vendor audits and validation work Change control should be applied stringently. Where practical and important for security reasons access control should be implemented as a feature of the program Configurable software packages Category four type computer would be typified as systems that permit users to develop their own applications by configuring/amending predefined software modules and also developing new application software modules. Each application (of the standard product) is therefore specific to the user s process. For these systems maintenance and on-going evaluation becomes a key issue, particularly when new versions of the standard product are produced These are called custom configurable packages in the USA. Examples include Distributed Control Systems (DCS), Supervisory Control and Data Acquisition packages (SCADA), manufacturing execution systems and some LIMS and MRP packages. In these examples the system and platform should be well known and mature before being considered in category 4, otherwise category 5 should apply It is important that emphasis of the validation plan should be on any additional or amended code and to the configuration of the standard modules. A software review of the modified code (including any algorithms in the configuration) should be undertaken. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 20 of 20

21 In addition, an audit of the supplier should be considered to determine the level of quality, reliability and structural testing built into the standard product. It is important that the development process is controlled and documented. If an audit is conducted of the supplier it should have sufficient scope to provide adequate assurance of the acceptability of the quality methodology used Validation Plans should document what activities are necessary to validate an application, based on the quality methodology used by the supplier and on the complexity of the applications Custom built systems Category five type computer software is generally described as custom built or bespoke system constructed to specific user specific requirements The life-cycle model approach should be utilised for the development of custom built or bespoke systems. For these systems the full life-cycle should be followed for all parts of the system. Complex computer systems often have layers of software, and one computer system could exhibit several or all of the features above categories The quality planning and control of the project throughout the development, implementation, operation, modification and retirement of the system is fundamental to ensure compliance and valid ation throughout the life of a computer system. Quality records may include the following: A project outline A quality plan A URS System design specifications Reports from risk analyses Supplier and product assessments Records of the development of system components The detailed description of the system and its functionality User and system manuals and training records Records of the installation and operational qualification Acceptance test planning and execution System acceptance/ release Operational controls and records -change controls -system monitoring and maintenance -error handling -all EU Annex 11 specific activities Upgrade/ phase out/ retirement/ replacement Planning and execution of tests Configuration control Information security procedures PH/W 01/2000 AJT 3 rd Draft January 2000 Page 21 of 21

22 22 Planning and conducting audits and reviews Standard operating procedures Contracts with suppliers and with contracted out IT services Utilising the different categories of software identified in the GAMP guideline the following basic requirements should be available for validation of the computer system. 18. GAMP Validation Approach Based on Different Categories of Software Products The GAMP User and Supplier 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: Category 1 record software version and record testing for IQ activities Category 2 Category 3 record configuration and record testing for IQ activities qualification (IQ, OQ & PQ) of application, on-going evaluation Category 4 establish assurance of QMS approach to software development, qualification (IQ, OQ & PQ) of application and any bespoke code, on-going evaluation. Category 5 establish assurance of QMS approach to software development, qualification (IQ, OQ & PQ) of complete system, on-going evaluation However, this pre-defined category approach may be difficult to apply to complex integrated computerised systems where different GAMP category levels are effectively combined. The category types are not considered to be exhaustive and many systems span the category levels. For all critical systems a holistic risk-based approach is necessary. This should consider the risks from the entire pharmaceutical application. Quality assurance controls, qualification work and risk reduction measures can cascade from this to consider each of the elements comprising the computerised system. GAMP guidance is considered to be scaleable for large, medium and small, complex and simple systems. Where software and systems do not appear to fit readily into this category system then it is for users to apply judgement in determining particular quality measures, validation strategies and acceptance criteria. For instance, under particular circumstances the operating system configuration may contribute to the overall risk of the system and the level of validation should reflect this. Inspectors will be interested in the company s approach to identifying GxP risks and the criteria for assessing the fitness for purpose of the system application There are a number of additional important aspects that would be required in the documentation and records necessary to support a validation exercise. These aspects relate to ongoing evaluation and system maintenance. As a result the documentation and records for validation of a computer system would also require information and records for the following aspects of system control: PH/W 01/2000 AJT 3 rd Draft January 2000 Page 22 of 22

23 23 Evaluation records to demonstrate system does as described in the URS (verification stage and on-going monitoring). Records of operator training (introduction and on-going training). Procedure for on-going monitoring, this procedure would interlink the error report system and the deviation reports system with the change control procedure. Maintenance of user manuals for all systems. 19. Retrospective Validation 19.1 Legacy computerised systems are regarded as systems that have been established and in use for some considerable time. For a variety of reasons, they may be generally characterised by lack of adequate GMP compliance related documentation and records pertaining to the development and commissioning stage of the system. Additionally, because of their age there may be no records of a formal approach to validation of the system. A significant number of legacy systems may operate satisfactorily and reliably, however this does not preclude them from a requirement of validation. The approach to be taken is to provide data and information to support a retrospective validation and requalification of the system. GMPs have required the validation of computerised systems for many years. It should therefore be noted that a lack of prospective validation evidence for computerised systems will increasingly be seen as a serious deviation from GMPs by a number of regulatory authorities. [Author s Note: Compared with 10 to 20 years ago, when GMP related applications were often rudimentary and standalone, there are now many more integrated, infrastructure computer systems to consider. This is particularly the case when firms are striving to achieve so-called paperless systems where there is a recently introduced requirement for such systems to comply with country specific GMP compliance regulations, e.g. for the USA 21 CFR Part 11: Electronic Records and Electronic Signatures. For legacy systems, firms often have to consider retrospective validation, upgrading or replacement. GAMP Forum has recently produced guidance on the validation of legacy systems, (q.v.)] 19.2 The principles identified above for computer systems validation should be addressed where a retrospective validation approach has been undertaken for a legacy system. For legacy systems, because of their age and unique characteristics, the system development documentation and records appropriate for validation may not be available. As a result the approach taken to establish and document system reliability and on-going assurance based on the build-in-quality concept for software development would be, of necessity, different to a current system Nevertheless, the validation strategy would be consistent with the principles established for classic retrospective validation where the assurances are established, based on compilation and formal review of the history of use, maintenance, error report and change control system records and risk assessment of the system and its functions. These activities should be based on documented URS s. If historical data do not encompass the current range of operating parameters, or if there have been significant changes between past and current practices, then retrospective data would not of itself support validation of the current system 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 PH/W 01/2000 AJT 3 rd Draft January 2000 Page 23 of 23

24 24 system. For example, change control, audit trail(s), data & system security, additional development or modification of software under a QMS system, maintenance of data integrity, system back up requirements, operator (user) training and on-going evaluation of the system operations. 20. System Security, Including Back-up 20.1 It is very important for the manufacturer to maintain the procedures and records related to the access to the system(s). Of necessity, there may be different levels of access authorisation required for particular operators to limit their access to specific system functions. It is of vital importance to control access to the computerised system, especially if it is in any way connected to a network system. The system security manager will have ultimate responsibility for these privileges and they are typically incorporated in logon identity inputs and passwords linked to hierarchical application menus 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 electronic access. Basic rules exist and are documented to ensure security related to personal passwords or pass cards and related system/data security requirements are not reduced or negated. Correct authority and responsibilities are assigned. Authorisation for access is assigned to the correct organisational level. There are documented procedures for regular changes of passwords. Procedures identify prohibited passwords. Procedures to invalidate lost, stolen or potentially compromised passwords or devices, which generate or store them. Appropriate security back-up requirements are established for encrypted data. [Note: Inspectorates of the national competent authorities will need to be able to access a firm s encrypted GxP data. Keys for decryption will need to be available to the Inspectors working for the competent authorities] 20.3 There should also be available written procedure for recovery of the system following a breakdown; these procedures should include documentation and record requirements to assure retrieval and maintenance of GMP information. The manufacturer should have in place procedures to assure routine back-up of data to a safe storage location, ideally off-site 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 GMP- relevant documentation (including audit trail records). The back-up procedure including storage facilities and media should be demonstrated to assure data integrity 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. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 24 of 24

25 Data changes - Audit Trail/Critical Data Entry 21.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 pharmaceutical company 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. 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 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 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. The audit trail for the data integrity may need to consider functions such as creations, links, embedded comments, deletions, modifications/corrections, authorities/ privileges, time and date, inter-alia. Relevant recent guidance is also provided in BS7799 (1999) on Information Security Management and in the pre-amble to FDA s 21CFR Part The records pertaining to the audit trail events should be documented, ideally as a feature of the operating system. Audit trail records should be available, if required, as a paper (hard copy) printout record. It should be noted that for the USA market it is currently a requirement in 21CFR Part 11, for audit trails to be available in electronic form, not just paper Where electronic signatures are used it is expected that appropriate controls will exist such as the maintenance of a register of personnel passwords, identification codes and other forms of electronic signatures There should be records of checks that the data/control/monitoring interface(s) between the system and equipment ensure correct in-put and out-put transmission. 22. Electronic Records and Electronic Signatures 22.1 EC Directive 91/356 sets out the legal requirements for EU GMPs. The GMP obligations include a requirement to maintain a system of documentation, (Article 9). 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 electronic, photographic or in the form of another data processing system rather than written. The main requirements here being that the manufacturer 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. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 25 of 25

26 The guidelines relating to documentation in the EU GMP Guide are in Chapter 4 and there is no requirement here that documents be in writing. Indeed in paragraph 4.9 the section amplifies Article 9.2 (see above). It references electronic data processing systems and sets out a number of measures that should be in place to protect the data: access by authorised personnel only use of passwords creation of backup copies independent checking of critical data safe storage of data for the required time The central consideration here as in Directive 91/356, is that records are accurately made and protected against loss or damage or unauthorised alteration so that there is a clear and accurate audit trail throughout the manufacturing process available to the licensing authority for the appropriate time. 22.2The situation for an authorised wholesale distributor is similar for records covering purchases/sales invoices, (on paper or on computer, or any other form). 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. The requirements for records are amplified: Records should be made. in such a way that all significant activities or events are traceable.and are clear and readily available In summary, generally there is no requirement for records and documents created and maintained, as part of GMP and GDP, to be in writing and electronic versions are permitted. In the absence of provisions to the contrary this will arguably extend to electronic signatures. Certainly from the forgoing requirements described for accurate, authorised, secure electronic record systems these will lo gically require an attached immutable audit trail identifying person, time and date and linking to particular transactions Whilst Article 22 of EC Directive 75/319 requires a Qualified Person to certify in a register that batches for release meet the required condition we are not aware of any provisions that would restrict this activity to paper based media and a handwritten certifying signature. Validated and secure electronic data processing systems may therefore be used in this context The situation for GCP and GLP practices is rather more complex and will not be included in this current guidance at this time Electronic Identification and Electronic Signature are synonymous in the context of a closed, in-company system. The minimum key components to be controlled are: the authorised user name log-on a menu driven password related to the specific application permitted task functionality and duration for that user the system to have common time and date standard referencing and transaction linking PH/W 01/2000 AJT 3 rd Draft January 2000 Page 26 of 26

27 27 the audit trail system information security 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 legible and reasons for all transactions to be documented in the audit trail. Firms will need clearly documented policies, standard operating procedures, validation reports and training records covering such system controls. Information Security Management standards such as BS 7799 (1999) may be of assistance with the design, implementation and control of such systems Additional security arrangements and controls will be needed for external access, inputs and outputs linking with the firm s GxP computerised systems. These requirements are being determined largely by international initiatives to establish electronic commerce. For the EU reference may be made to: EC Directive 1999/93/EC on a Community framework for electronic signature, (Official Journal of the European Communities, ). It is not the remit of GxP guides to reproduce such business and commerce requirements. 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. 23. Personnel Note: 23.1 to 23.7 is based on the APV Guideline (Reference 4), q.v There should be sufficient, qualified staff with the relevant experience to carry out tasks for which the Pharmaceutical Manufacturer is responsible in connection with the planning, introduction, application (operation), application consultancy on, and regular monitoring of, computerized systems Staff qualifications should be assessed on the basis of professional training, education and experience in handling and developing computerized systems. The field of work in which the staff will be operating should determine qualification requirements. Staff should only be deployed in areas suited to their skills and training The individual areas of responsibility should be laid down in writing and be clearly understandable to every member of staff. The fact that computerized systems may take over decision-making functions does not affect the legally prescribed responsibilities of the persons in key positions 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 The Pharmaceutical Manufacturer is responsible for ensuring all staff who have to perform tasks in connection with computerized systems are given the requisite training and for familiarizing them with the relevant guidelines on computerized systems. That should also apply to system developers, maintenance and repair staff and staff whose work could affect the documented PH/W 01/2000 AJT 3 rd Draft January 2000 Page 27 of 27

28 28 operability of the systems Apart from a basic training in computerized systems, newly recruited staff should also be trained in the tasks assigned to them personally. Furthermore, continuous training should also be ensured according to standard training programs and implementation in practice should be assessed from time to time In connection with training, the GMP 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 It is not the remit of this document to identify and list characteristics and skills required for software and systems engineers, or semiconductor specialists! Guidance on these requirements may be obtained from the respective professional institutions and standards bodies. Pharmaceutical firms will need to satisfy themselves in this regard for development, integration and support roles. 24. Inspection considerations 24.1 The attention paid by inspectors to the assessment of the GxP implications of computerized systems on a site (and between sites), will be determined to some extent by the overall site history and risk assessment carried out by the inspector in preparing for the inspection Clearly where a site has a lot of automation and integrated computerized systems - and manufactures a range of sterile products - (for example), then the potential risks from a GxP failure, (whether computer related or otherwise) for the patient are high. But for a well designed, validated and controlled automated facility it can be argued that the risks of 'human error' compared with a non-automated, labour intensive operation can in reality be lower. Inspectors have to come to a judgement on this by studying the firm's evidence not just in relation to the technology aspects (through the application of GAMP etc.) but also the GxP risks identified (through PQ reports and such-like) 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. Hence the need for detailed guidance from GAMP Forum to suppliers, purchasers (and inspectors) in rela tion to these systems, concerning procedures, quality records and responsibilities 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 Where little is known about computerization on a site, then it may be necessary to use a preinspection questionnaire to amplify the Site Master File details Inspectors should select the GMP Critical computer systems from the information provided PH/W 01/2000 AJT 3 rd Draft January 2000 Page 28 of 28

29 29 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 GMP Critical computer systems are those that can affect the quality and safety of the pharmaceutical product, either directly ( e.g. control systems) or indirectly (e.g. data/information systems) It is essential that firms have a list of all their computerized systems classified as to their validation status. For long standing systems, validation may have been carried out retrospectively and for systems purchased or implemented in the last few years, the validation should have been carried out (and recorded) prospectively. Firms should have plans to complete any outstanding retrospective validation of GxP related computer systems within a reasonable time period (say 6 to 12 months, depending on the risks and complexity of the systems). Critical Systems that are unsupportable and cannot be validated must be discarded and replaced The firm's validation approach should follow a life-cycle methodology, with management controls and documentation as outlined in this guidance, which contains consensus best practice guidelines Review the firm's Summary Validation Report, (SVR) for the selected system and refer as necessary to the System Acceptance Test Specification and lower level documents. 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 Supplier audit reports Validation and *quality plans. (e.g. Master Validation Plan or MVP). (* There should always be a project quality plan and a QMS for the documentation). 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 Inspectors should consider all parts of EU GMP Annex 11 for relevance to particular validation projects and in particular, the 'Principle' and items 1, 2, 3, 4, 5 and 7. The lack of a written detailed description of each system, (kept up-to-date with PH/W 01/2000 AJT 3 rd Draft January 2000 Page 29 of 29

30 30 controls over changes), it's 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 inspector s 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) If satisfied with the validation evidence, inspectors should then study the system in operation, 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 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 Consider also EU 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 (4). Deficiency ratings applied by Inspectors will be based on the relative risk of the application and his/her judgement of risk criticality. 25. References for Relevant Standards, and GMP Guides/Codes (1) EU Annex 11 to the EU guidelines of Good Manufacturing Practice for Medicinal Products. (2) Good Automated Manufacturing Practice [GAMP] Guide Version 3.0, 1998 Vol 1 Part 1 User Guide and appendices Vol 1 Part 2 Supplier Guide Vol 2 Best Practices (3) PDA Technical Report No 18. (4) APV Guidelines to the Annex 11 of the EU GMP Guidelines. (5) GMA/NAMUR for process control systems. (6) USFDA Technical Report - Software Development Activities. (7) Australian Code of GMP for Medicinal Products, August (8) WHO Guideline for GMP for Manufacture of Pharmaceutical Products. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 30 of 30

31 31 (9) Relevant CRF sections of the USFDA Register: Hardware 21 CFR , 67, CFR Part 11 Electronic Records: Electronic Signatures Software 21 CFR , 180, 188, CFR Part11 Electronic Records: Electronic Signatures (10) ISO standards: Quality management and quality assurance ISO Part 1: Guidelines for selection and use. ISO 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 Part 1: Guidelines. ISO Part 2: Guidelines for Services. ISO Part 4: Guidelines for quality improvement. ISO 10005:1995 Quality management - Guidelines for quality plans. ISO 10007:1995 Quality management - Guidelines for Configuration Management Life cycle management ISO/IEC 12207:1995 Information Technology - Software Life Cycle processes (11) IEEE Publications IEEE 729 Glossary of Software Engineering Terminology IEEE 730 Quality Assurance Plan IEEE 828 Software Configuration Management Plans IEEE 829 Software Test Documentation IEEE 830 Guide to Software Requirements Specification IEEE 983 Guide to Software Quality Assurance Planning IEEE 1012 Software Verification Plans IEEE 1298 Software Quality Management System Part 1: Requirements (12) British Standards BS 7799: 1999 Information Security Management, BSI DISC 389 Chiswick High Road, London W4 4AL.(Tel: Fax: Suggested Further Reading Good Computer Validation Practices Common Sense Implementation [Stokes, Branning, Chapman, Hambloch & Trill. Interpharm Press, USA: ISBN: ] Validation of Computerized Analytical Systems [Huber. ISBN: ]. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 31 of 31

32 32 Computer Systems Validation for the Pharmaceutical and Medical Device Industries [Chamberlain. ISBN ]. Validating Automated Manufacturing and Laboratory Applications, [Wingate et al., Interpharm Press, USA: ISBN X] USFDA General Principles of Software Validation- Guidance for Industry PDA Technical Report No. 31: Validation and Qualification of Computerized Laboratory Data Acquisition Systems, PDA Journal of Pharmaceutical Science and Technology, 1999 Supplement, Vol. 53, No Glossary of Terms This glossary has been extracted predominantly from the (1) PIC/S PH1/96 Validation recommendation document, (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. The sources of each of the definitions have been identified in the following manner: PIC/S validation recommendation document definitions are recorded as (1); GAMP definitions are recorded as (2); PDA technical report no. 18 definitions are recorded as (3); EC Directive 1999/93/EC on a Community framework for electronic signature, (Official Journal of the European Communities, ), (4); Definitions not found in any of the above documents are given within the text. Acceptance Criteria The criteria a system or process must meet to satisfy a test or other requirements.(3) Action Levels Levels or ranges distinct from product specifications which, when deviated from, signal a drift from normal operating conditions and which require actions.(2) Advanced Electronic Signature (EU) means an electronic signature, which meets the following requirements: (a) it is uniquely linked to the signatory; (b) it is capable of identifying the signatory; (c) it is created using means that the signatory can maintain under his control; and (d) it is linked to the data to which it relates in such a manner that any change of the data is detectable. (4) Alert or Warning Levels or ranges which, when deviated from, signal a potential Levels drift from normal operating conditions but which do not necessarily require action. (2) PH/W 01/2000 AJT 3 rd Draft January 2000 Page 32 of 32

33 33 Application-Specific A software program developed or adapted to the specific Software requirements of the application. (3) Audit An activity to determine through investigation the adequacy of, and adherence to, established procedures, instructions, specifications, codes, and standards or other applicable contractual and licensing requirements, and the effectiveness of implementation.(2) Auditee The organisation to be audited. (2) 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) Bespoke A system produced for a customer, specifically to order, to meet a defined set of user requirements.(2) Boundary Value A minimum or maximum input, output, or internal data value, applicable to a system or process.(3) Branch Testing Execution of tests to assure that every branch alternative has been exercised at least once.(3) Bug A manifestation of an error in software (a fault).(2) Calibration Demonstration that a particular measuring device produces results within specified limits by comparison with those produced by a reference standard device over an appropriate range of measurements. This process results in corrections that may be applied to optimise accuracy. (2) Certification Documented testimony by qualified authorities that a system qualification, calibration, validation or revalidation has been performed appropriately and that the results are acceptable. The procedure and action by a duly authorised body of determining, verifying, and attesting in writing to the qualifications of personnel, processes, procedures, or items in accordance with applicable requirements. (2) PH/W 01/2000 AJT 3 rd Draft January 2000 Page 33 of 33

34 34 CGMP (Code of Abbreviation for Current Good Manufacturing Practice. (2) Federal Regulations) Change Control A formal monitoring system by which qualified representatives of appropriate disciplines review proposed actual changes that might affect a validated status to determine the need for corrective action that would assure that the system retains its 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.] Change Note Change Plan Commercial off-the-shelf A document specifying the details of an authorised change request.(2) A plan defining the details of the authorised change request, defining actions, responsibilities and procedures.(2) Configurable Programs- Stock programs that can be configured to specific user applications by filling in the blanks, without (COTS) altering the basic program.(3) Commissioning Activities to put a computerized system into proper operation.(3) Compiler A program used to translate a higher order language into its relocatable or absolute machine code equivalent.(2) 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) 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) Computerised System A computer system plus the controlled function that it operates. (3) [Authors note: To-day 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. EU GMPs Annex 11(4) is relevant here PH/W 01/2000 AJT 3 rd Draft January 2000 Page 34 of 34

35 35 regarding documenting the scope and interaction of systems] Computerised System A document or set of documents that describe how a Specification computerised system will satisfy the system requirements of the computer-related system.(3) Configuration The documented physical and functional characteristics of a particular item or system. A change converts one configuration into a new one. (2) Configuration The process of identifying and defining the configuration items in Management 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) Construction Qualification Controlled Function Documented evidence to show that those constructional aspects of a facility which can affect product quality have been constructed in accordance with the approved specification.(2) A process and any related equipment controlled by a computer system.(3) Control Parameters Those operating variables that can be assigned values that are used as control levels.(2) Control Parameter Range of values for a given control parameter that lies between its two Range outer limits or control levels. (2) Critical Process A process variable which, when out-of-control, can potentially cause an adverse effect on fitness-for-use of an end product or on process state-of-control.(3) Customer Database (ANSI) DCS The company or group responsible for specifying and procuring a system. (3) Collection of data fundamental to a system.(2) Distributed Control System.(2) Dead Source Code 1. Superseded code from earlier versions. Avoided by using (KG Chapman) quality software development standards. 2. Residue from system modification. Avoided by effective configuration change controls. 3. Rarely used code that appears dead such as:. Modules in some large configurable programs; PH/W 01/2000 AJT 3 rd Draft January 2000 Page 35 of 35

36 36. Certain diagnostic programs that are intended to be inactive until needed. Removal of code in category 3 leads to serious potential future problems. Idle code can be parked in libraries until needed. [PIC/S Authors note: (3) Rarely used code is not considered to be the same as never used or non-executable remnants of prior program code and is not strictly dead source code.] Debugging (IEEE) faults.(2) The process of locating, analysing, and correcting suspected Design Qualification Formal and systematic verification that the requirements defined (DQ) during specification are completely covered by the succeeding specification or implementation.(2) Design Specification A specification that defines the design of a system or system component (3) Documentation Any written or pictorial information describing, defining, (ANSI N ) reporting or certifying activities, requirements, procedures, or results. (2) Edge-of-Failure Electronic Approval A control parameter value that, if exceeded, causes adverse effect on state of control and/or fitness for use of the product. (2) An input command requiring restricted entry made under a level of higher authorisation, which signifies an act of approval. (2) 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. (1) 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 individual s 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. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 36 of 36

37 37 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) External Quality Audit A systematic and independent examination to determine whether quality activities and related results comply to a documented Quality System and whether this documented Quality System is implemented effectively and is suitable to achieve the contractual requirements placed by the customer. (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 ) Flow Chart A graphical representation of the definition, analysis or solution (ANSI/IEEE) of a problem in which symbols are used to represent operations, data, flow, and equipment. (2) Functional Statements that describe functions a computer-related system must Requirements be capable of performing. (3) (ANSI/IEEE) Functional Specifications Functional Testing GxP GMP GCP GLP GDP Statements of how the computerised system will satisfy functional requirements of the computer-related system.(3) A process for verifying that software, a system, or a system component performs its intended functions.(3) A global abbreviation, intended to cover GMP, GCP, GLP, GDP and other regulated applications in context. Good Manufacturing Practice Good Clinical Practice Good Laboratory Practice Good Distribution Practice Hardware Acceptance Statements for the testing of all key aspects of hardware Test Specification installation to assure adherence to appropriate codes and approved design intentions and that the recommendations of the manufacturer have been suitably considered.(2) Hardware Design Description of the hardware on which the software resides and PH/W 01/2000 AJT 3 rd Draft January 2000 Page 37 of 37

38 38 Specification (APV) how it is to be connected to any system or equip ment. (2) High Level Review Purposes: determine if programs meet design specs as described of Software by such documents as modular flow diagrams, HIPO charts, pseudo code and operating manuals. Characteristics: involves comparing design specs and acceptance criteria with cognitive mechanisms which depict the program in terms more easily understood by automation practitioners and non-computer scientists. Uses: quality acceptance review by QA software auditing, for example, to complement walk -through, for inspections, and for troubleshooting problems.(2) Installation Qualification (IQ) Documented verification that all key aspects of hardware and software installation adhere to appropriate codes and the computerised system specification. (3) Integration Testing An orderly progression of testing in which software elements, (IEEE) hardware elements, or both are combined and tested until the entire system has been integrated. (2) Interface A shared boundary. To interact or communicate with another (ANSI/IEEE) system component. (2) Life Cycle Concept An approach to computer system development that begins with (PMA CSVC) identification of the user s requirements, continues through design, integration, qualification, user validation, control and maintenance, and ends only when commercial use of the system is discontinued.(2) LIMS Loop Testing Laboratory Information Management System. Checking the installed combination of elements characterising each type of input/output loop. (2) Low Level Review Purposes: of Software. Detect possible coding errors. Determine adherence to design specs. Determine adherence to standards. Implement path analyses Characteristics:. Requires highly trained experts who are familiar with software/hardware systems on which program is based; Use; chiefly during software development (2) Machine Code A representation of instructions and data that is directly (ANSI/IEEE) PH/W 01/2000 AJT 3 rd Draft January 2000 Page 38 of 38

39 39 executable by a computer (machine language). (2) Major Change A change to a validated system that affects system performance (PMA CSVC) and drug product quality, or that goes beyond established operational limits that necessitates a revalidation of the system. (2) Minor Change A change to a validated system that does not affect system (PMA CSVC) performance or drug product quality, nor goes beyond established operational limits and does not necessitate a revalidation of the system. (2) Modularity (Software) (ANSI/IEEE) The extent to which software is composed of discrete components such that a change to one component has minimal impact on other components. (2) MRP Manufacturing Resource Planning. (2) Network a. An interconnected or interrelated group of nodes. (ANSI/IEEE & GAMP) b. An interconnected communications facility. A Local Area Network (LAN) is a high bandwidth (allowing a high data transfer rate) computer network operating over a small area such as an office or group of offices. (2) Ongoing Evaluation The dynamic process employed after a system s initial validation to maintain its validated state. (3) Operating Environment Those conditions and activities interfacing directly or indirectly with the system of concern, control of which can affect the system s validated state. (3) Operating System A set of software programs provided with a computer that function as the interface between the hardware and the applications program.(3) Operational Documented verification that the system or subsystem operates as Qualification (OQ) specified in the computerised system specifications throughout representative or anticipated operating ranges.(3), (2, Appendix P) Packaged System Path Testing A computerised system where the computer system and the controlled function equipment are designed and constructed as an integrated assembly.(3) Execution of important control flow paths throughout the program.(3) Performance Qualification (PQ) Documented verification that the integrated computerised PH/W 01/2000 AJT 3 rd Draft January 2000 Page 39 of 39

40 40 system performs as intended in its normal operating environment; i.e., the computer related system performs as intended. (3) ), (2, Appendix P) [Author s note: cross references may be appropriate in reports to link with related pharmaceutical product (process/ analysis/ data) validation dossiers as indicated in the URS and the master validation plans.] Planned Change An intentional change to a validated system for which the (PMA CSVC) implementation and evaluation program is predetermined. (2) PLC Programmable Logic Controller. (2) Policy A directive usually specifying what is to be accomplished. (2) (PMA CSVC) Procedure A directive usually specifying how certain activities are to be (PMA CSVC) accomplished. (2) Process Structured activities intended to achieve a desired outcome. (3) Process System The combination of process equipment, support systems (such as (PMA CSVC) utilities), and procedures used to execute a process.(2) Process Validation Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes. (3) Product Any computer system supplied by the supplier to the customer as (computer) the result of an agreed contract between the two parties. (2) Prospective Validation Establishing documented evidence that a process, procedure, system, equipment or mechanism used in manufacture does what it purports to do based on a pre-planned validation protocol. (1) Proven Acceptable All values of a given control parameter that falls between proven Range (PAR) high and low worst-case conditions. (2) Pseudo Code (ANSI/IEEE) A combination of programming language and a natural language used for computer program design.(2) Qualification Protocol A prospective experimental plan that when executed is intended to produce documented evidence that a system or subsystem has been qualified properly. (3) PH/W 01/2000 AJT 3 rd Draft January 2000 Page 40 of 40

41 41 Quality Assurance a. A planned and systematic pattern of all actions necessary (QA) to provide adequate confidence that the item or product (ANSI/IEEE & conforms to established technical requirements. Dr J M Juran) b. The activity of providing, to all concerned, the evidence needed to establish confidence that the quality function is being performed adequately. (2) Quality Control (QC)(Dr J M Juran) The regulatory process through which industry measures actual quality performance, compares it with standards, and acts on the difference. (2) Quality Function The entire collection of activities from which fitness for use is achieved, no matter where these activities are performed.(2) Quality Plan A plan created by the supplier to define actions, deliverables, responsibilities and procedures to satisfy the customer quality and validation requirements. (2) Quality System (2) The organisational structure, responsibilities, procedures, processes and resources for implementing quality management. Range Testing Checking each input output loop across its intended operating range.(2) 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) [PIC/S Author s Note on Raw Data - For information: FDA s 21 CFR Part 11 requires the retention of electronic records in electronic form (thus including raw data electronically captured or recorded). Also for FDA s GLP regulations there is a requirement to be able to reconstruct a study from raw data and the electronic records may be needed to support any paper printouts.]. Re-qualification (PMA CSVC) Repetition of the qualification or a portion thereof.(2) Requirement. A condition or capability needed by a user to solve a (ANSI/IEEE) problem or achieve an objective. A condition or capability that must be met or possessed by a system or PH/W 01/2000 AJT 3 rd Draft January 2000 Page 41 of 41

42 42 Retrospective (PMA CSVC) system component to satisfy a contract, standard, specification, or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component. (2) Establishing documented evidence that a system does what it Validation purports to do based on an analysis of historical information.(2) [PIC/S Author s note on Retrospective Validation - To-day this definition is seen as too narrow and it is not an option for new systems. Firms will be required to justify the continued use of existing computerised systems that have been inadequately documented for validation purposes. Some of this may be based on historical evidence but much will be concerned with re-defining, documenting, re-qualifying, prospectively validating applications and introducing GMP related life-cycle controls. Reference should also be made to GAMP Forum s paper on Legacy Systems for further guidance.]. Revalidation SCADA Repetition of the validation process or a specific portion of it.(2) Supervisory Control And Data Acquisition.(2) Security (IEEE) Simulation Simulator 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) (i) A model that behaves or operates like a given system when provided a set of controlled inputs. See also emulation in IEEE terminology. (ii) The process of developing or using a model as in (i). (IEEE Std ) A device, computer program, or system that behaves or operates like a given system when provided a set of controlled inputs. See also emulator in IEEE terminology. (IEEEStd ) Software (PMA CSVC) A collection of programs, routines, and subroutines that controls the operation of a computer or a computerised system. (2) Software Life Cycle The period of time that starts when a software product is (ANSI/IEEE) conceived and ends when the product is no longer available for use. The software life cycle typically includes a requirements phase, test phase, installation and checkout phase and operation and maintenance phase. (2) PH/W 01/2000 AJT 3 rd Draft January 2000 Page 42 of 42

43 43 Source Code (PMA CSVC) An original computer program expressed in human-readable form (programming language), which must be translated into machinereadable form before it can be executed by the computer.(2) Specification A documented evaluation of the detailed specification, carried out Qualification for the purpose of confirming compliance with the User Requirement and Functional Specifications and providing the detailed design documentation required for subsequent stages (eg installation and operational Qualification) and ongoing operation of the facility or system in compliance with regulatory requirements related to product quality. (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) Standard Operating Instructions that specify how something is to be accomplished. Procedures (SOPs) (3) State-of-Control A condition in which all operating variables, that can affect performance, remain within such ranges that the system or process performs consistently and as intended. (3) Structural Integrity 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 (Bluhm.Meyers and low-level and high-level code review, path analysis, auditing of programming Hetzel) 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) Sub-contractor Any organisation or individual used by a supplier to provide material or services which are embodied in the product to be supplied. (2) Sub-program A self contained program unit which forms part of a program. Sub-programs are sometimes referred to as procedures, subroutines or functions. (2) PH/W 01/2000 AJT 3 rd Draft January 2000 Page 43 of 43

44 44 Supplier System Any organisation or individual contracted directly by the customer to supply a product. (2) A collection of components organised to accomplish a specific function or set of functions. (IEEE Std ) System Acceptance Test Specification (2) The system acceptance test specification is a description of those tests to be carried out to permit acceptance of the system by the user. Typically it should address the following: System functionality System performance Critical parameters Operating procedures The tests should ensure that the product operates as indicated in the functional specification and meets the user requirements as defined in the URS. The tests typically include limit, alarms and boundary testing. The System Acceptance Test Specification is a contractual document and, as such, should be approved by both the supplier/ developer/ integrator and the end user. An example procedure for producing a System Acceptance Test Specification is given in GAMP Guide Appendix P. System Software Software designed to facilitate the operation and maintenance of a computer system and its associated programs, such as operating systems, assemblers, utilities, network software and executive programs. System software is generally independent of the specific application.(3) System Specifications (PMA CSVC) Testing Describes how the system will meet the functional requirements.(2) The process of exercising or evaluating a system or system (IEEE) component by manual or automated means to verify that it satisfies specified requirements or to identify differences between expected and actual results. (2) Testing: Structural Both forms of testing are essential. Neither form of testing can and Functional be exhaustive. Structural testing should occur chiefly during software development. (2) Test Procedure A procedure which when executed successfully provides PH/W 01/2000 AJT 3 rd Draft January 2000 Page 44 of 44

45 45 documentary evidence that part of the automated system works as specified.(2) Unplanned (Emergency) An unanticipated necessary change to a validated system requiring Change (PMA CSVC) rapid implementation, also known as a hot-fix. (2) [PIC/S author s note: 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 firm s change control, configuration management and validation procedural controls, to ensure compliance with GMP and the maintenance of a validated state.] URS User Requirements Specification (2) User The company or group responsible for the operation of a system.(3) The pharmaceutical customer or user organisation contracting a supplier to provide a product. In the context of this document it is, therefore, not intended to apply only to individuals who use the system, and is synonymous with Customer. (2) Utility Software Computer programs or routines designed to perform some general (ANSI/IEEE) support function required by other application software, by the operating system, or by system users.(2) Validation of Computerised Systems (MCA) The formal assessment and reporting of quality and performance measures for all the life-cycle stages of software and system development, its implementation, qualification and acceptance, operation, modification, re-qualification, maintenance and retirement. Such that the user has a high level of confidence in the integrity of both the processes executed within the controlling computer system(s) and in those processes controlled by and/or linked to the computer system(s), within the prescribed operating environment(s). [PIC/S Author s note: The italicised-bold part of this definition should be interpreted as requiring controlled documented methodology and records based on best compliance practices. This is to ensure that firms have generated documented evidence (electronic and/ or paper based), that gives a high level of assurance that both the computer system and the computerised system, will consistently perform as specified, designed, implemented and validated. Related validation dossiers for complex integrated projects should be clearly cross-linked for audit purposes.] Validation Master A document providing information on the company's validation Plan work program. It should define details of and timelines for the PH/W 01/2000 AJT 3 rd Draft January 2000 Page 45 of 45

46 46 validation work to be performed. Responsibilities relating to the plan should be stated. (1) Validation Project A document that identifies all systems and subsystems involved in Plan a specific validation effort and the approach by which they will be qualified and the total system validated; includes identification of responsibilities and expectations.(3) Validation Protocol A written plan stating how validation will be conducted, including test parameters, product characteristics, production equipment and decision points on what constitutes acceptable test results. (1) Vendor The company or group responsible for developing, constructing and delivering a system or part of a system. (3) Worst Case A set of conditions encompassing upper and lower processing limits and circumstances, including those within standard operating procedures, which pose the greatest chance of process or product failure when compared to ideal conditions. Such conditions do not necessarily induce product or process failure.(3) PH/W 01/2000 AJT 3 rd Draft January 2000 Page 46 of 46

47 Acknowledgments Members of the Working Group who contributed to the preparation of this document are: Coordinator: Mr Anthony Trill MCA, UK (from 4/1999) Past Coordinators Ms Sharyn McGregor TGA, Australia (11/1997 to 3/1999) Mr Paul Humphreys TGA, Australia ( ) Members: Mr Daniel Albrecht IKS, Switzerland (drafts 1 and 2 only) Ms Stephanie Gray FDA, USA Ms Lilian Hamilton MPA, Sweden Mr Karl-Heinz Menges RP Darmstadt, Germany Mr Paul Motise FDA, USA Mr Tony Trill MCA, UK Mr Bernhard Schertz IKS, Switzerland Mr Robert Tribe TGA, Australia Comments on Version 2 considered and embraced by Version 3, are acknowledged from: Lilian Hamilton MPA Paul Motise FDA Karl-Heinz Menges RP Darmstadt Tony Trill MCA PIC/S Ad-Hoc meeting, Oxford, England (9/9/1999) New material for Version 3 is acknowledged from: Tony Trill MCA Karl-Heinz Menges Bernard Schertz IKS Robert Tribe TGA PIC/S Ad-Hoc meeting, Oxford, England (9/9/1999) Also PIC/S member states are continuing to forward the group details of their national positions regarding electronic records and signatures as requested via PIC/S COO 9/1999. The exercise is incomplete at this time. PH/W 01/2000 AJT 3 rd Draft January 2000 Page 47 of 47

48 Table of Amendments Version Number Date: By: Reason for Amendment: 2 1 Sept 98 R Tribe & S McGregor As requested by the PIC/S Committee on : reformatting of document; new title; minor editing. 3 January A J Trill Revised at the request of PIC/S Committee to take account of comments on Version 2 from Mr. Motise, Mr. Menges and Mr Trill; to update the content; simplify-where possible; also to include electronic records and electronic signatures, personnel and inspection aspects PH/W 01/2000 AJT 3 rd Draft January 2000 Page 48 of 48