Computerized System Audits In A GCP Pharmaceutical Laboratory Environment

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 36 Computerized System Audits In A GCP Pharmaceutical Laboratory Environment By Maintaining data integrity for both clinical laboratory processes and patient data is pivotal to Good Clinical Practice. Successful system audits are crucial to continuing GCP. Computers and computerized systems are an integral part of daily life in the laboratory. Examples include: laboratory equipment, Laboratory Management Information System (LIMS), the network, servers, databases, and individual workstations, all providing remote access to important data. Government rules, regulations and guidance documents contain specific requirements for computerized systems. One of those regulations is Good Clinical Practice (GCP). As quoted from the International Conference on Harmonization (ICH) Guideline for Good Clinical Practice: GCP is an international ethical and scientific quality standard for designing, conducting, recording and reporting trials that involve the participation of human subjects. Compliance with this standard provides public assurance that the rights, safety, and well-being of trial subjects are protected consistent with the principles that have their origin in the Declaration of Helsinki, and that the clinical trial data are credible. 1 The key point to remember is that clinical laboratories process and manage patient data, and this data is used to make critical medical decisions. If the data a laboratory produces is incorrect, decisions taken may be incorrect, and this could mean: Patients may be harmed Submissions may be delayed or turned down Inaccurate information may be included on the product label Therefore, we must maintain a high confidence level in the integrity of the data to protect patient safety - both during the clinical trials and post-marketing. Scope This article provides a practical and non-technical overview of the most important topics that are typically covered during a computer system laboratory audit. Although the comments and self- 36 Journal of GXP Compliance

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 37 audit questions are based on experience in the clinical arena and the regulations (Good Clinical Practice) that govern them, they are equally applicable to other laboratories. Before discussing the audit approach, it is important to define the audit scope. The Food and Drug Administration (FDA) defines a computerized system to Include hardware, software, peripheral devices (equipment that is directly connected (to) a computer), personnel, and documentation; e.g., manuals and Standard Operating Procedures. 2 So, it is not only about hardware and software, the scope is much broader. Defining Audit The International Organization for Standardization (ISO) in document 19011 3 defines an audit as a systematic, independent, and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which audit criteria are fulfilled. In most instances, the audit evidence will be documentation (electronic or paper) that proves that requirements have been met. The laboratory staff, Information Technology (IT), and the Quality Control/Quality Assurance Departments must work together to understand how IT impacts their business and how to set appropriate controls that comply with regulatory and client requirements. Client auditors or regulatory body representatives perform audits on the facilities and processes. As part of these audits, it is highly likely that the laboratory will be inspected. Audit Standard All audits are conducted against a standard. In the case of computerized systems, there are multiple documents that create the standards that are used during the audit. A critical standard is the U.S. FDA s Code of Federal Regulations (CFR) 21 Part 11. 4 In August 1997, the FDA effected 21 CFR Part 11 on Electronic Records; Electronic Signatures. The FDA issued this regulation to provide criteria for acceptance of electronic records and electronic signatures. The original intention was to permit the widest use of electronic technology compatible with FDA's responsibility to promote and protect public health. However, there are still discussions going on around the interpretation and scope of Part 11. A number of guidance documents were issued and withdrawn again as described in the current guidance for industry on Part 11, Electronic Records; Electronic Signatures - Scope and Application. 5 An FDA guidance contains nonbinding recommendations and represents FDA s current thinking on a subject. Since the scope of Part 11 was interpreted very broadly by Industry, the FDA tried to narrow the scope and elucidate more about the scope in the 2004 Draft Guidance for Industry on Computerized Systems Used in Clinical Trials 6 (hereinafter referred to as 2004 Draft Guidance ): This document provides guidance about computerized systems that are used to create, modify, maintain, archive, retrieve, or transmit clinical data required to be maintained and/or submitted to the FDA. These data form the basis for the Agency s decisions regarding the safety and efficacy of new human and animal drugs, biologic products, medical devices, and certain food and color additives. Because the data have broad public health significance, they are expected to be of the highest quality and integrity. This guidance document addresses long-standing FDA regulations concerning clinical trial records. It also addresses requirements of the Electronic Records/Electronic Signature rule (21 CFR Part 11). There are additional predicate rules and regulations in place that impact compliance in a laboratory setting. Predicate rules are requirements set forth in the Act, the PHS Act, 7 or any FDA regulation, with the exception of Part 11. July 2006 Volume 10, Number 4 37

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 38 Timing and Agenda Typically an audit starts with analyzing the nature and amount of work done by the auditee. This information can be given by the laboratory or preferably by the person who is managing the laboratory (contract). Often they can provide you valuable information of the laboratory (quality of work provided, data requirements, (problem) area s for investigation, etc.). Furthermore, previous audit reports should be reviewed and other sources could be consulted (e.g.: the website of the auditee often contains valuable information). Applicable rules, regulations, and good business practices should be taken into account as well when setting the scope and objectives of the audit. This might result in an audit lasting one day or up to more than one week. Resulting from this analysis, the scope and objectives of the audit are determined and typically an agenda will be sent to the auditee listing what will be reviewed during the audit. This gives the auditee the opportunity to prepare and have the appropriate staff, documentation, and facilities available. The agenda for a computerized system audit can look like this: General topics and activities: Opening meeting, audit agenda, scope, and objectives Company organization, departmental overview, and reporting structures Tour of facilities and security (including server room) Review of: Company s quality system Documentation practices Personnel records (CV, job descriptions, qualifications, and training) IT standard operating procedures (SOPs), including: - SOP management and training - Software Development Life Cycle (SDLC) and/or software validation - Change control and configuration management - Data back-up, recovery, and archiving - Logical and physical security Copies of the company s business continuity and disaster recovery plans Evidence of the company s compliance with 21 CFR Part 11 (Electronic Record; Electronic Signatures) Closing meeting and discussion of findings Let us now review these agenda items in more detail. Opening Meeting The opening meeting should allow the auditee and the auditors to introduce themselves and to express expectations from and to each other. It is recommended to discuss the agenda and make sure the appropriate staff is available at a convenient time for the auditor. Although it is fairly obvious that the audit will consume a significant amount of the auditee s time, they should, nonetheless, be allowed to run their business, so the auditor must be flexible. After the opening meeting, there should be a mutually clear understanding of the agenda and the expectations. It is recommended to have a daily wrap-up meeting allowing the auditee and the auditor to discuss the progress of the audit and any outstanding questions and issues. Quality System When the actual audit begins, a good starting point is the review of the quality system. A good quality system contains a clear description of expectations. However, quality must also be lived through the company s quality culture. A good way to assess the quality culture is by watching employees do their jobs, and asking questions about how they do them (how do they access SOPs, are they trained on the use of equipment, etc.). A tour around the laboratory facilities is usually included in an audit. Documentation should be organized and contain up-to-date information. Document-naming convention (Quality Manual or Guidance, Procedures, Policies or work instructions) can assist in determining the ease of use of the quality system, so a consistent use of the naming convention throughout the company is important. SOPs should clearly define who is responsible for what. A clear definition of process flow, tasks, responsibilities, and deliverables (e.g., documentation) should be included. This saying is still true: 38 Journal of GXP Compliance

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 39 Figure 1 Typical Audit Cycle Plan next Audit (If appropriate) Follow-up on Findings Preparation Send Agenda Review of: Rules and Regulations Guidelines and Good Business Practices Contract and Agreements Previous Audits Involved Risk Communication Audit Report Opening Meeting Audit Close-Out Meeting Review of: Quality System Training Software Validation Business Continuity Plan and Disaster Recovery Plan Data Back-up, Recover and Archiving Logical and Physical Security Compliance with 21 CFR Part 11 If you do it, document it If it is not documented, it is not done Basically, the message is simple: PROPOSED PART 11 APPROACH training if needed? Document your good business practices and take credit for what you do! Does the period between the document (SOP) approval date and the effective date allow sufficient time for reading and employee Do SOPs and other controlled documentation have sufficient version control and document identifiers? In the 2004 Draft Guidance it is recommended Does the company allow simple but secure Determine Predicate Rule Requirements that pertinent SOPs to the use of the computerized system be available on site including: accessibility (paper or electronic)? Is it clearly identified who is supposed to read which documents (e.g.: in a curriculum)? System setup and installation Data collection Narrow and Scope handling - Identify Electronic Records that Require Part 11 Training Compliance Data backup, recovery, and contingency plans Security Training on SOPs (a read and acknowledge form Change control is the minimum) should be documented. In the 2004 System maintenance Draft Guidance, it is furthermore stated: Alternative recording Part 11 methods Records Not Part 11 Records (in case of system unavailability). (This item was added in the 2004 Draft Guidance.) The agency recommends that training be provided to individuals in the specific operations with regard to computerized Assess Risk - Evaluate Level of The challenge is to keep the SOP instructions systems that they are to perform. We Controls Appropriate to Risk always as clear, precise, and flexible as possible. recommend that training be conducted Apart from the content of SOPs, there should also be sufficient guidance regarding management, accessibility, Implement and training Appropriate in the SOPs. Part 11 Some questions to ask Controls regarding document control include the following: by qualified individuals on a continuing basis, as needed, to ensure familiarity with the computerized system and with any changes to the system during the course of the study. July 2006 Volume 10, Number 4 39

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 40 In addition, a job-description and Curriculum Vitae (CV) for employees should be available and evidence related to the requirements as specified in the job-description to show that an employee is qualified to do the job as specified. This would satisfy curent regulatory agency expectations.the number of training-related regulatory agency observations has increased significantly during recent years. Software Validation One of the typical tasks IT employees and laboratory personnel are involved in is validation or qualification of computerized systems. A definition of software validation is given by the FDA: Software validation means confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled. 6 The level of software validation varies significantly and depends on a number of variables, such as: Type of computerized system - Commercial Off The Shelf (COTS) or in-house or customdeveloped Regulatory and business requirements associated with the intended use of the computerized system Complexity of the computerized system Results of vendor evaluation, if applicable If a company uses only COTS user-configurable (directly out of the box) software, then most likely they only need to verify that the software is installed according to a pre-defined process and that the configuration of any parameters make the software fit for its intended purpose. This is typically documented in an Installation Qualification (IQ) or an Equipment Qualification (EQ). This is intended to: Furthermore, documented verification should occur to demonstrate that, when installed in its production environment, software performs as anticipated and specified in the requirements. The thoroughness of qualification and verification depends on a number of variables, such as the criticality of the system and the risks (i.e., regulatory risks or patient safety) involved. If a company develops software in-house, the SDLC (Software Development Lifecycle) should be described. In-house built data analysis tools, databases, and even spreadsheets should be covered by the SDLC as well. The development of software is a shared effort between IT and the intended user. All anticipated functionalities and user and regulatory requirements must be documented in a clear, consistent, and testable way. A traceability matrix can be used to track these requirements through the design and the testing and should assure that all requirements have been met. When using computerized systems, a company must maintain procedures around change control and configuration management. The change control procedure should cover and describe items such as: Reviewing (software and hardware) changes to assess the impact on software, data, and safety Reviewing and approving proposed changes by appropriate staff Acting upon emergency changes (such as patches or bug fixes) Documenting the change control process Configuration management is linked to change management and is used to record versions of hardware and software at points in time. Version control and release control are important aspects of configuration management to allow traceability of which (software and hardware) versions are installed and when and how software and hardware were and are to be released. Provide control over the installation process Verify proper installation Maintain a record of the installation Establish a starting point for change control 40 Journal of GXP Compliance

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 41 Business Continuity Plan and Disaster Recovery Plan Although Business Continuity Planning (BCP) and Disaster Recovery Planning (DRP) are not extensively covered by pharmaceutical regulations, it is a good business practice to have a BCP and DRP. Some questions to ask regarding business continuity and disaster recovery planning: If a disaster were to happen: Can the company still receive, register, and analyze samples when the facilities are no longer available? How would analysis of samples with limited stability continue (blood samples are a good example)? How would capturing data for ongoing analysis continue? Is it necessary to consider alternative sites within hours or days of prosaective or actual downtime? Would extended downtime threaten patient safety? The occurrence of a disaster (e.g., fire) may take a significant number of companies out of business due to the lack of BCP and DRP. In most instances, the compilation of a BCP and DRP is the collective effort between the IT Department and their internal business partners, but should extend beyond computerized systems. The BCP should protect essential business operations in the event that required (computer) systems are not available, by documenting the process that the business will follow until the (computer) systems are restored. A recommendation specifically mentioned in the 2004 Draft Guidance is that a company should have an SOP covering the Alternative Recording Methods (in case of system unavailability). That means that a company should think about how to proceed when one or more computerized systems (e.g., LIMS) are not available. The BCP can encompass a couple of pages for a small company to hundreds of pages for a larger company, or several separated BCPs. Items to think about while developing a BCP include: If the power supply fails, is there a power supply backup (batteries and generator)? Do fire protection and detection systems exist? If so, has the power supply backup and fire protection systems been tested and documented? Has an impact analysis study been performed to identify and quantify the impact of the potential loss of critical business assets? What is the impact if the laboratory is not available for some time? What would it mean to lose one of your key staff members? Is there a crisis plan that specifies the continuation of critical business functions from the time the computerized systems (or building) are unavailable to the time they are returned (or re-built) to production? What would be the impact of the LIMS not being available for some time? Does the plan include processes affected, resources required, and automated operating procedures (e.g., fax, e-mail, and telephone) to be used during an outage? Can fax, telephone services, and e-mail be easily rerouted to alternate locations? Is there a process in place to capture data outside your LIMS and a validated way to enter it into the system once back to production? Is there a process to integrate the data created or changed outside of the computerized system into the system once it has returned to production? Is there a schedule to test the plan? For example, will the management team meet together annually for one day and simulate the occurrence of a disaster? The DRP has a different objective. The DRP documents the steps to be taken in the event of a disaster to restore the availability of a computerized system. Items to think about while developing a DRP include: Where will the DRP be stored (off-site, fire-proof safe, etc.)? Do key staff have access to the plan(s)? Is a reference needed to other DRPs? Is there a list containing the key internal and external (sponsor) contacts? Is the list up-todate and accurate? July 2006 Volume 10, Number 4 41

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 42 Is there an inventory of all systems, equipment, and other resources needed to maintain services (computers, fax, connections, software, etc.)? Can you rebuild the current systems using this information? Is a recovery process and related activities described? What is the verification process to ensure all system components are back in place? Is there a schedule to test the plan? Data Back-up, Recovery, and Archiving Although the backup and recovery procedures are sometimes included in the DRP, it is common practice and recommended to have a dedicated back-up SOP. The following is stated in the 2004 Draft Guidance: Backup records should be stored at a secure location specified in the SOPs. Storage is typically off-site or in a building separate from the original records. Items to think about while developing SOPs on backup and recovery: Has the entire backup and restoration process been described? This should include backup success verification, backup media, and problem resolution. Is the transport and storage of backup tapes secure? What is the scope of data backup (e.g.: all data, production data, source, test data, software)? What is the backup frequency and scheduling? Once a week, full back-up and daily incremental, differential, or back-up changes to data instantly to another server at another location? That depends on the criticality of the data. What is the backup retention schedule and how is the quality of the data maintained? If there is a need to send the final results to the sponsor, has the data been archived according to the archiving strategy? Is there still a need to keep the back-up tapes? How is the restoration of data managed? This includes: frequency of restoration testing, what can be restored, how long to retain data (for customers) to request restoration? Have you ever tested that restoration works (from old data)? As highlighted in the 2004 Draft Guidance, the FDA is moving to a more documented risk-based approach, stating: Firms that rely on electronic and paper systems should determine the extent to which backup and recovery procedures are needed based on the need to meet predicate rule requirements, a justified and documented risk assessment, and a determination of the potential effect on data quality and record integrity. Needless to say, backup should also include company critical documents that are not covered by the regulatory authorities. Logical and Physical Security Directly related to record integrity is logical and physical security. An SOP should describe the security measures taken. Items that should be considered in an access and security SOP should include: Which secure network shares or applications are identified? Who should have access to which areas (buildings, secure rooms, such as archive, server room, sample storage, laboratory area) and is this controlled? Who are system administrators? Who is allowed to authorize accounts? Details about fire protection. Do your employees know what to do in case of fire? Is correct use made of electrical backup or Uninterrupted Power Supplies (UPS)? That is, if the power goes down, are batteries strong enough to keep the equipment running or do you need to bring the equipment back on-line again? Is it appropriate to have a (diesel) generator to keep your equipment going? 42 Journal of GXP Compliance

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 43 Compliance with 21 CFR Part 11 Figure 2 Proposed Part 11 Approach PROPOSED PART 11 APPROACH Determine Predicate Rule Requirements Narrow Scope - Identify Electronic Records that Require Part 11 Compliance Part 11 Records Not Part 11 Records Assess Risk - Evaluate Level of Controls Appropriate to Risk Implement Appropriate Part 11 Controls Furthermore the logical security measures taken should be described as well. Items that should be considered include the following: The process to approve, activate, and deactivate accounts, every user should have a unique ID; is this process documented? A description of the access levels, e.g., defined by role. Can you show for each employee to which network areas and applications they have access and what the level of access is? Unauthorized attempts to access systems should be monitored in a timely manner. How frequently is this done? Systems should be set-up to facilitate log-off after an idle period and enforce change of password after a specified period. Do the applications in use in the laboratory and the workstations facilitate this? Compliance with 21 CFR Part 11 Because the scope of 21 CFR Part 11 has been narrowed by the FDA as stated in the current guidance for industry, 5 the first question to answer should be something like: must my system still comply with Part 11, and if so, which Part 11 controls should be implemented? One way to analyze the need for compliance has been given by FDA officials 8 as visualized in Figure 2. The result of this analysis should be documented. Under a narrow interpretation, FDA considers Part 11 to be applicable to the following records: Records that are required to be maintained under predicate rule requirements and that are maintained in electronic format in place of paper format. Records that are required to be maintained under predicate rules, that are maintained in electronic format in addition to paper format, and that are relied on to perform regulated July 2006 Volume 10, Number 4 43

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 44 activities. Records submitted to FDA, under predicate rules (even if such records are not specifically identified in Agency regulations) in electronic format. Many laboratory records are included in submissions and are, therefore, covered by Part 11. It is important to remember that Part 11 is not a regulation about computers. It is about electronic records and signatures. Depending on the applicability of Part 11, appropriate controls should be implemented. The system risk analysis and the implemented Part 11 controls should cover items such as: Are the electronic records identified? Have all the electronic records produced in the laboratory been reviewed? Is a documented process for record management (including storage or archiving, back-up, etc.) in place? Does this process cover the laboratory records as well? Do any applicable records that may be altered have an audit trail? Are the records secure? Is there appropriate password management? Is data transferred, and if so, is it controlled? For example, the way data is transferred to the sponsor. Are Electronic Signatures in use? If so, do they comply with Part 11? Does the signature, for example, link irreversibly to the record it belongs to and does a statement explain what the signature means? Close-out Meeting The audit should typically be closed with a meeting wherein all the key staff of the auditee and the auditors meet and the auditors present the outcome of the audit and motivate findings, if any. Typically, the following will be covered: The audit findings, both positive and negative. It is important that when the auditor leaves the premises of the auditee, the meaning of the finding(s) have been made completely clear. Reporting requirements and documentation logistics are completely understood. Typically, the auditor will send a report or a summary with the outcome of the audit, including the finding(s), so that the auditee can work to resolve them. It is important that the auditee sets realistic deadlines for the completion of the finding(s) and to follow-up on the resolution of those findings. CONCLUSION In this article, a typical audit process and key areas of review are described. However, each specific audit may vary depending on the services the auditee provides and the focus of the auditor. Depending on the size of the auditee s company and scope of the audit, other agenda items may be added such as: The vendor management process (if auditee has outsourced tasks) The IT infrastructure Once the audit has been performed, the findings must be evaluated against the potential risks of problems occurring due to outstanding issue(s). The relevance of the issues should be documented and a report should be sent to the auditee. It is important to follow-up on the report by the group or individual managing the auditee to assure that issues are resolved. If serious issues were discovered, remediation and rectification timeframes should be established and a follow-up audit scheduled to assess progress in these areas. Although a comprehensive story cannot be told here, the issues discussed endeavor to indicate a good starting point and provide guidance to point you in the right directions. ABOUT THE AUTHOR studied Biochemistry at the Nijmegen University in The Netherlands. Since 1994 has been employed by Eli Lilly and Company and has held a variety of positions of increased responsibility since 44 Journal of GXP Compliance

IVTGXP_july06.qxd 6/28/06 1:09 PM Page 45 then. As a Lilly Computer System Quality Assurance Auditor he has audited a variety of companies and internal departments regarding computer systems. Currently he is doing a two year Executive Master Course on IT-auditing at the Erasmus University of Rotterdam. REFERENCES 1. Guideline for Good Clinical Practice (GCP) ICH Harmonised Tripartite Guideline (ICH Topic E) 2. U.S. FDA Glossary of Computerized Systems and Software Development Terminology 3. ISO 19011:2002 Guidelines for Quality and/or Environmental Management Systems Auditing 4. U.S. FDA 21 CFR Part 11: Electronic Records; Electronic Signatures (August 1997) 5. U.S. FDA, Guidance for Industry, Part 11, Electronic Records; Electronic Signatures - Scope and Application (August 2003) 6. U.S. FDA, Guidance for Industry, Computerized Systems Used in Clinical Trials (April 1999 and draft released: September 2004) 7. U.S. FDA Public Health Services Act - Title 42 - The Public Health and Welfare, Chapter 6A - Public Health Service 8. Presentation of Joe Famulare, Scott McIntire, J. Murray, U.S. FDA: 21 CFR Part 11 - Scope and Application - Inspection and Enforcement Discretion SUGGESTED READING and REGULATORY REFERENCES U.S. FDA 21 CFR Part 58, Good Laboratory Practice for non-clinical Laboratory Studies (April 2003) U.S. CFR Part 211, sub-part I, Laboratory Controls, April 1996 EU GMP Guide, Annex 11, Computerized Systems, October 2003 U.S. FDA 42 CFR Part 493, Laboratory Requirements (October 2003) Clinical Laboratory Improvement Amendments of 1988 (CLIA) U.S. FDA, Guidance for Industry, Computerized Systems Used in Clinical Trials, April 1999 (draft released: September 2004) U.S. FDA, Guidance for Industry, Part 11, Electronic Records; Electronic Signatures - Scope and Application (August 2003) General Principles of Software Validation; Final Guidance for Industry and FDA Staff (FDA, Center for Devices and Radiological Health, Center for Biologics Evaluation and Research, January 2002) PIC/S Good Practices for Computerized Systems in Regulated GXP Environments (August 2003) (Pharmaceutical Inspection Convention) OECD Principles of Good Laboratory Practice, 1997/98 (Organisation for Economic Co-operation and Development) OECD The Application of the Principles of GLP to Computerised Systems, 1995 GAMP Validation of Laboratory Computerized Systems, April 2005 (Good Automated Manufacturing Practices) BCP CFR CLIA COTS CV DRP EQ EU FDA GAMP GCP GXP ICH IQ ISO IT LIMS OECD SDLC SOP U.S. UPS Article Acronym Listing Business Continuity Plan Code of Federal Regulations Clinical Laboratory Improvement Amendment Commercial-Off-The-Shelf (Software) Curriculum Vitae Disaster Recovery Plan Equipment Qualification European Union Food and Drug Administration Good Automated Manufacturing Practice Good Clinical Practice Good Manufacturing, Clinical, Laboratory, etc., Practice International Conference on Harmonization Installation Qualification International Organization for Standardization Information Technology Laboratory Information Management System Organization for Economic Cooperation and Development Software Development Lifecycle Standard Operating Procedure United States Uninterrupted Power Supply July 2006 Volume 10, Number 4 45