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