The use of computer systems

Technology Update Computer Systems Validation, Part 1 Software Purchase and GCP Compliance Teri Stokes Teri Stokes, PhD, is senior consultant and director of GXP International, 131 Sudbury Road, Concord, MA 01742, (978) 287-4393, fax (978) 369-8907, gxpintl@ma.ultranet.com. The data produced by software for GCPregulated applications must be validated to satisfy regulatory requirements. This series opens with guidelines and standards to help you make an informed software selection. The use of computer systems and automated devices in clinical research and in clinical practice has increased dramatically in this decade. Through various international good clinical practice (GCP) regulations, authorities express their desire for auditable quality that shows that management is in control of electronic information. Regulators now seek documented evidence of data integrity and system reliability for electronic handling of critical clinical information. Application software provides the electronic handling functions for clinical data. It collects, stores, retrieves, analyzes, transforms, and reports data in graphical form. Thus the application software becomes a major focus of validation efforts and its purchase a logical starting point for a series on computer validation in GCP-regulated areas. Subsequent articles in the series will focus on validation activities for software application use and for the supporting platform of configured hardware and operating system. GCP status When considering a software purchase for any activity in clinical research, it is important to first determine the regulatory status of such software. This depends on the regulatory status of the data you expect it to handle that is, to collect, store, control, manipulate, transform, analyze, and/or report in graphical form. If you expect to use the data to prove to authorities the safety, efficacy, or quality of a regulated product, then both the data and the software handling the data are subject to GCP directives and open to audit and inspection under GCP principles. The physical location of the software is irrelevant to its GCP jurisdiction. The software can be on a system at a sponsor, investigator, laboratory, or CRO site or in a subject s home. It is the intended use of the data being handled by the software that determines its GCP status. When software requires GCP compliance, it is important to discuss that requirement with suppliers and include it in any requests for proposal (RFP). Suppliers who are unfamiliar with GCP concepts should be provided with a summary of your GCP requirements to serve as a checklist both for suppliers themselves and for quality assurance (QA) auditors who visit suppliers on your behalf. Requirements might include audit trail capability, specific built-in checking routines, special security measures, user training materials, and/or data flow diagrams in the system description. Documented quality assurance of the software engineering process and testing records before product release are also important. Purchasing practices Commercial off-the-shelf (COTS) software packages (such as word processors, spreadsheets, operating systems, and database engines) have a straightforward buy as-is purchasing procedure. In such cases, the supplier s reputation for quality in the industry becomes a factor, and the internals of the software itself are September 1996 APPLIED CLINICAL TRIALS 71

usually not a subject for major validation efforts. The use of such software by many thousands of installations provides broad testing and verification of its performance. As a result, critical failures are rare. Less critical problems become widely known, and work-around procedures are quickly established. Modified off-the-shelf (MOTS) and custom-built software packages, on the other hand, are significantly changed to accommodate the purchaser s needs. Therefore, they require a more thoughtful and thorough purchasing process. When a purchaser installs a one-of-a-kind (or few-of-a-kind) system, the possibility of undiscovered serious problems is much higher, and thus the validation risk much greater. The Institute of Electrical and Electronic Engineers, Inc. (IEEE) has developed a standard for purchasing software IEEE Std. 1062-1993: IEEE Recommended Practice for Software s GCP status depends on the intended use of the data it handles. Software Acquisition. Although it is useful for the purchase of any software, it is more likely to be used for MOTS and custom-built applications such as case report form (CRF) data management systems, adverse events (AE) data management systems, laboratory information management systems (LIMS), and remote data entry/remote data capture (RDE/RDC) systems. The IEEE standard describes a fivestage software acquisition life cycle (see chart). It defines this cycle as the period of time that begins with the decision to acquire a software product and ends when the product is no longer available for use. 1 The standard then goes on to explore in considerable detail nine steps toward acquiring quality software, which should result in the delivery of highquality, well-documented products. 1 The third column of the chart lists GCP activities relevant to each stage and step. International guidelines The European Union has the most computer-specific GCP guidelines. The relevant text is in Volume III, Part 2, of the Rules Governing Medicinal The IEEE Software Acquisition Life Cycle Model The 5 Stages The 9 Steps Related GCP Activities Planning 1. Planning organizational strategy 2. Implementing organization s process 3. Determining the software requirements 1. 2. 3. Analyze user needs and determine GCP status of data to be handled by software Apply computer validation SOPs and GCP quality regulations to company s purchasing process Develop RFP to include a written description of software functions, GCP quality needs, acceptance criteria, and validation process Contracting 4. Identifying potential suppliers 5. 6. Preparing contract requirements Evaluating proposals and selecting the supplier 4. 5. 6. Select candidates who will: demonstrate their software, provide documentation for their software, and provide formal proposals Develop service level agreement (SLA) contract to include QA audits, documented software testing, payments tied to performance milestones, and software documentation sets Select a qualified supplier with a documented software QA process and negotiate SLA contract; review contract with legal counsel Product implementation 7. Managing supplier performance 7. Monitor supplier s performance to all milestones and approve work segments; provide all of purchaser s deliverables to the supplier when needed Product acceptance 8. Accept the product 8. Review and test product to written validation plan and test plan procedures to certify that all discrepancies are corrected and all acceptance criteria satisfied Follow-on 9. Using the software 9. Establish change control and maintenance logs, ongoing user training, and periodic retesting per validation plan 72 APPLIED CLINICAL TRIALS September 1996

Products in the European Union. Chapter 3, on data handling, addresses quality concerns for computerized systems at both sponsor and investigator sites (see Data Handling box). 2 The EEC guide to GMP mentioned in section 3.2 of these guidelines is a reference to the GMP Guide Annex 11 (on computerized systems) in Volume IV of the Rules Governing Medicinal Products in the European Union. This four-page annex has 19 paragraphs of guidance for computer validation practice (see Purchasing and Validation box). It is a useful primer on the key points for validating computer systems in operation. The major principle of the annex is stated as follows: Where a computerized system replaces a manual operation, there should be no resultant decrease in product quality or quality assurance. 3 Any business manager who invests money in new computer software would heartily agree with this principle. It is highly recommended that the full text of Annex 11 be made available to all parties involved in purchasing or supplying GCP software. In essence, the international regulations expect software purchasers in the clinical research area to have a clearly defined and documented process for planning, buying, S Contracts he European Union s GCP guidelines specifically address the quality issues involved with the sponsor s and investigative site s use of computerized systems. The following are from the Rules Governing Medicinal Products in the European Union: 2 Investigator 3.2 Entry to a computerized system is acceptable when controlled as recommended in the EEC guide to GMP. 3.3... Computerized systems should be validated and a detailed description for their use be produced and kept up-to-date. 3.4... For electronic data processing, only authorized persons should be able to enter or modify data in the computer and there should be a record of changes and deletions. 3.5 If data are altered during processing, the alteration must be documented and the system validated. Sponsor/monitor 3.10 The sponsor must use validated, error-free data processing programs with adequate user documentation. 3.11... If a computer assigns missing values automatically, this should be made clear. 3.12 When electronic data handling systems or remote electronic data entry are employed, SOPs for such systems must be available. Such systems should be designed to allow for correction after loading, and the correction must appear in an audit file (cf. 3.4 and 3.16). 3.15 If data are transformed during processing, the transformation must be documented and the method validated. 3.16 The sponsor must maintain a list of persons authorized to make corrections and protect access to the data by appropriate security systems. installing, maintaining, and operating their GCP software systems. When external suppliers are involved, the guidelines expect a written agreement that defines the roles and ection 5.2.2 of the ISO 9000-3 standard recommends that software supply contracts include the following: 5 a) acceptance criteria b) handling of the changes in purchaser s requirements during development c) handling of problems detected after acceptance, including quality-related claims and purchaser complaints d) activities carried out by the purchaser, especially the purchaser role in requirements specification, installation, and acceptance e) facilities, tools, and software items to be provided by the purchaser f) standards and procedures to be used g) replication requirements the number of copies of each software item to be delivered the type of media for each software item, including format and version, in human-readable form the stipulation of required documentation such as manuals, user guides copyright and licensing concerns addressed and agreed to custody of master and backup copies, where applicable, including disaster recovery plans the period of obligation of the supplier to supply copies T Data Handling responsibilities of all parties. Operating this way is also, in fact, good business practice. It is both costeffective and helpful to the understanding of end users to thoroughly define at the start what functions are needed and how a system failure could affect safety and efficacy data. Defining the need for built-in checks, audit trails, and other functional logic and security needs in a written system requirements specification reduces costly confusion and reworking on the part of the software supplier. Understanding the regulatory requirements for a written detailed description of the system (section 11.4) can help suppliers plan ahead to document the system as it is being built to be sure that all critical elements are described. Supplier QA audits Paragraph 5 of Annex 11 states that software suppliers should have a documented QA system for their development process. This applies to internal as well as external software September 1996 APPLIED CLINICAL TRIALS 73

suppliers. The clinical research purchaser may call upon the clinical QA unit or corporate QA to audit a current or prospective software supplier and assess the adequacy of the supplier s QA process. Many ISO 9001 certified suppliers consider that certificate to be sufficient evidence of their ability to meet GCP needs for software. But it is not sufficient. The ISO certificate does mean that they have some form of documented QA process, but the degree of discipline and quality level may or may not conform to the GCP standard. Purchasers of GCP software must check to be sure, either by conducting an audit on site or getting cooperative audit information from other users of the supplier s software perhaps through a users group review. Actually, the International Organization for Standardization (ISO) recognized the need for special quality standards in software production and issued the ISO 9000-3 standard, Quality Management and Quality Assurance Standards Part 3: Guidelines for the Application of ISO 9001 to the Development, Supply and Maintenance of Software. This document provides an excellent benchmark for QA audit review of software supplier practices. ISO 9000-3 states that as part of the development planning, the supplier should prepare a quality plan (see Quality Plan box). Contracts and quality ISO 9000-3 also provides good T 5.5.2 Quality Plan Content The quality plan should specify or reference the following items: a) quality objectives, expressed in measurable terms whenever possible b) defined input and output criteria for each development phase c) identification of types of test, verification and validation activities to be carried out d) detailed planning of test, Quality Plans nnex 11 to the GMP Guide in the Rules Governing Medicinal Products in the European Union provides guidance on software purchasing and system validation. 3 Here are some of the relevant passages: 11.2... Validation should be considered as part of the complete life cycle of a computer system. This cycle includes the stages of planning, specification, programming, testing, commissioning, documentation, operation, monitoring and modifying. 11.4 A written detailed description of the system should be produced (including diagrams as appropriate) and kept up-to-date. It should describe the principles, objectives, security measures and scope of the system and the main features of the way in which the computer is used and how it interacts with other systems and procedures. 11.5 The software is a critical component of a computerized system. The user of such software should take all reasonable steps to ensure that it has been produced in accordance with a system of quality assurance. 11.6 The system should include, where appropriate, built-in checks of the correct entry and processing of data. 11.7 Before a system using a computer is brought into use, it should be thoroughly tested and confirmed as being capable of achieving the desired results. 11.18 When outside agencies are used to supply a computer service, there should be a formal agreement including a clear statement of the responsibilities of that agency.... reading for purchasers and suppliers during contract development. An important concept throughout the standard is the principle of mutual responsibility and mutual cooperation for the success of the software project. This includes joint reviews of contract milestones and the appointment of a purchaser s representative with the authority to deal with contractual matters. An agreed single point of contact between purchaser and supplier, combined with regular joint review activities, keeps the lines of communication open and mutual he ISO 9000-3 standard recommends the following for software development quality plans: 4 A verification and validation activities to be carried out, including schedules, resources and approval authorities e) specific responsibilities for quality activities such as reviews and tests configuration management and change control defect control and corrective action Purchasing and Validation milestone progress clear for all to understand. The ISO 9000-3 standard provides a detailed discussion of contract items from both the supplier and purchaser perspectives (see Contract Items box). 5 It recommends establishing regular review meetings for the contract and a well-defined channel of ongoing communication. A single representative from each side purchaser and supplier should be assigned to work together to resolve any issues that arise and to ensure the mutual success of the MOTS or custom-built software project. An informed decision Purchasing software for clinical research is serious business. Before buying, you must consider how a software failure to function as intended might affect the integrity of safety, efficacy, or quality data to be used for submissions the safety, efficacy, or quality of clinical test products used in trials the safety of the system operator or trial subjects. Software that affects any of these three categories is subject to inspection for compliance with GCP principles. 74 APPLIED CLINICAL TRIALS September 1996

References 1. IEEE Recommended Practice for Software Acquisition, Std. 1062-1993 (The Institute for Electrical and Electronic Engineers, Inc., Piscataway, NJ, 1993), p 6. 2. European Commission, The Rules Governing Medicinal Products in the European Union, Volume III, Part 2, in Good Clinical Practice for Clinical Trials on Medicinal Products in the European Community (Office for Official Publications of the European Communities, 2 rue Mercier, L-2985 Luxembourg), p. 387. 3. European Commission, Guide to Good Manufacturing Practice for Medicinal Products, The Rules Governing Medicinal Products in the European Union, Volume IV, Annex 11 (Office for Official Publications of the European Communities, 2 rue Mercier, L-2985 Luxembourg), pp. 139 142. 4. International Organization for Standardization, Quality Management and Quality Assurance Standards Part 3: Guidelines for the Application of ISO 9001 to the Development, Supply and Maintenance of Software, ISO 9000-3:1991(E) (International Organization for Standardization, Case Postale 56, CH-1211 Geneva 20, Switzerland, 1991), p. 6. 5. ISO 9000-3, p. 4. Where to Get the Guidelines C opies of the guidelines and standards discussed in this article are available from their respective organizations: IEEE Customer Service Institute of Electrical and Electronic Engineers 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331 (800) 678-4333 or (908) 981-0060 fax (908) 981-9667 EU Office for Official Publications of the European Communities 2 rue Mercier L-2985 Luxembourg ISO International Organization for Standardization Case Postale 56 CH-1211 Geneva 20 Switzerland September 1996 APPLIED CLINICAL TRIALS 75