COTS Validation Post FDA & Other Regulations

COTS Validation Post FDA & Other Regulations

TABLE OF CONTENTS 1. Abstract 3 2. What is COTS 3 3. Why should COTS require Validation? 3 4. Risk Based Approach 4 5. Validation Approach 6 6. Applicable Regulations 6 7. FDA Guidance on Validation of Software 7 8. Summary 8 9. About the Speaker 9 10. Reference 9

1. Abstract Ever since FDA s Quality System regulation (21 CFR 820) & Design Control were finalized in 1997 & 1998 respectively, medical device and pharmaceutical industries have been in a tizzy about the requirements for validation of commercially off the shelf software (COTS). This paper discusses why validation is required even for off the shelf software, who is responsible for the validation and what some of the top 40 Medical Device & Pharmaceutical Research Organization are doing to meet the regulatory requirements. 2. What is COTS? The Food and Drug Administration (FDA) Glossary of Computerized Systems Software Development Terminology, published in 1995, defines COTS as configurable, off-the-shelf software, but within regulated industries the c also is understood to mean commercial. FDA now simply identifies software as offthe-shelf (OTS) only (FDA, Jan. 11, 2002). Product vendors validate these systems to make sure they meet the industry standards. However FDA is getting increasingly concerned with these validation practices for COTS products such as spreadsheet programs and has taken regulatory action based on that concern. 3. Why should COTS require Validation? As per FDA s view on software validation, Medical Device & Pharmaceutical companies have the ultimately responsibility for the software they use. This includes software like Excel, MathCad, Matlab, Codewright, GNU Emacs etc. Whether the software is developed in-house, by a contractor, or purchased from a vendor; Manufacturers cannot assume current Good Manufacturing Practices (cgmp) were followed for the development or validation of the software. 3

Some of the computer systems that require validation are: Computer systems used as part of Production or the quality system Computer systems used for production and service provision that affect the ability of the product to conform to specified requirements Computer systems that pharmaceutical companies introduce into systems of manufacturing, including storage, distribution and quality control. Ultimately documented evidence of cgmp is required along with the Quality System Regulation; especially 21 CFR Part 820.30 & Design Control must be followed. As per General Principles from FDA: quality, safety, and effectiveness must be designed and built into the product; quality cannot be inspected or tested into the finished product; and each step of the manufacturing process must be controlled to maximize the probability that the finished product meets all quality and design specifications. 4. Risk Based Approach In accord with FDA s focus on high-risk systems, this paper talks about risk- based approach to Title 21 of the Code of Federal Regulations (CFR) Part 11, Electronic Records; Electronic Signatures. Part 11 has been in effect for almost ten years, yet many companies find it tedious to comply with 21 CFR Part 11. FDA Warning Letters 8 June 2000... Failure to validate computer software used as part of the quality system for its intended use according to an established protocol1 For example: software such as Excel, Access, and Word used to create and maintain databases (rejects, complaints, and concessions) and electronic documents, is not validated. 4

10 July 2001... Failure to have an adequate validation procedure for computerized spreadsheets used for in-process and finished product analytical calculations. The current validation procedure uses only the values that result in within specification findings, aberrant high findings, and aberrant low findings. For example,... Spreadsheet Validation is deficient in that only a small range of values are being used to challenge computerized spreadsheet mathematical calculations. Failure to use fully validated computer spreadsheets to calculate analytical results for in-process and finished product testing.. For example, the computer spreadsheets used to calculate analytical results for... have not been validated. The two primary areas of focus for compliance are the Standard Operating Procedure (SOP) infrastructure and validation. FDA expects all companies to have SOPs to address computer security, data transfer, audit trails, electronic signatures, validation, and training. The second area is much larger because it deals with validation of new computer systems and existing legacy systems. FDA understands that companies have limited resources, so the riskbased approach is just a common sense way to approach the problem. What are the other approaches available? The risk-based approach starts by identifying the computer systems to validate first. New systems, lacking performance history data, present unknown risks and therefore must be validated first. As these systems are used in regulated industry thus they are considered more critical. If the final product quality gets affected it may lead to product recalls, even heavy fines from regulatory authorities. Furthermore, Part 11 requires users to validate prospectively all systems that manage good industry practice (GxP) data, meaning that validation must be undertaken before going live into production use. The selection of new systems must be based on user requirements that address Part 11 features, such as security and audit trails. Next to be validated are the upgrades to existing systems. The last systems to undergo validation are the legacy systems. All electronic 5

systems that already are in operation or that a company introduces are subject to rigorous validation in compliance with either Part 11 or the predicate rules. 5. Validation Approach The Pharmaceutical Industry Systems Validation Forum in the United Kingdom developed the Good Automated manufacturing Practice (GAMP) Supplier Guide to help software developers implement quality management systems. The GAMP Guide has evolved to define best practices for these systems, providing category summaries that capture the breadth of activities involved in software validation. The ten-step validation process satisfies categories three and four of the Good Automated Manufacturing Practices (GAMP) guidelines. Category 3: This includes standard software packages such as databases and spreadsheets. Validation of the software itself is not a requirement, but validation of applications made with the software is. Category 4: This category includes COTS software packages intended for specific use, such as Laboratory Information Management Systems (LIMS) or document management. 6. Applicable Regulations In general, according to 21 CFR Part 11, Electronic Records; Electronic Signatures, companies can use electronic records and signatures in place of paper, provided such records are trustworthy and reliable. The regulation applies to all data reported to FDA and includes unreported supporting data as well. Electronic record and signature regulations, as delineated in 21 CFR 11, are not the single driving force behind COTS validation. 21 CFR 11 also states that companies must adhere to the predicate rules the binding regulations that drive the industry such as FDA s 21 CFR 58 Good Laboratory Practices (GLPs), 21 CFR 211 Good Manufacturing Practices (GMPs), and 21 CFR 820 FDA Quality System Regulation, 1996, to name a few. Implicit in the predicate rules that govern any facet of the manufacture of a drug, biologic, medical device, or cosmetic is that any system of control be confirmed as appropriate for the task at hand. Inherent in the 6

term control is validation, if the process utilized is computerized. In an ISO environment, all processes related to product quality that use COTS software must undergo validation. Although many countries embrace the standards set forth by ISO, most countries (for example, Australia, Canada, the United Kingdom, and Japan) also have additional governing regulations that cite the need for COTS validation. Regulatory expectations for electronic systems When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented. 1 7. FDA Guidance on Validation of Software: For validating OTS software used in automated processes, the guidance recommends that a beginning point might be an assessment of the vendor s development and validation information where available, and an audit of the vendor where appropriate, especially for high-risk software. For OTS tools (e.g., compilers, linkers, editors, operating systems, and databases), the guidance states that exhaustive black-box testing may be impractical. Proper operation or validation of the tools may be inferred or covered through validating the overall application usage requirements that are traceable and indirectly implemented by the OTS tool functions. Software tools are frequently used to design, build, and test the software that goes into an automated medical device. Many other commercial software applications, such as word processors,spreadsheets, databases, and flowcharting software are used to implement the quality system. All of these applications are subject to the requirement for software validation, but the validation approach used for each application can vary widely. Numerous commercial software applications may be used as part 7

of the quality system (e.g., a spreadsheet or statistical package used for quality system calculations, a graphics package used for trend analysis, or a commercial database used for recording device history records or for complaint management). The extent of validation evidence needed for such software depends on the device manufacturer's documented intended use of that software. For example, a device manufacturer who chooses not to use all the vendor-supplied capabilities of the software; only needs to validate those functions that will be used. However, high risk applications should not be running in the same operating environment with non-validated software functions, even if those software functions are not used. Risk mitigation techniques such as memory partitioning or other approaches to resource protection may need to be considered when high risk applications and lower risk applications are to be used in the same operating environment. When software is upgraded or any changes are made to the software, the device manufacturer should consider how those changes may impact the "used portions" of the software and must reconfirm the validation of those portions of the software that are used 8. Summary: As per the guidance from FDA, COTS may be used in any application, critical or otherwise, but not without being validated. COTS software validation often is a time-consuming process in which a great deal of effort is spent determining the necessary validation tasks and the content and format of the validation documents. Hence risk based approach is time and cost effective. COTS software may contain bugs that can create problems when run in conjunction with other software, just as any other software. However, COTS software is recognized to have unique aspects to it. By virtue of its potentially wide use, bugs or other limitations or problems may be known and can be discovered at an early stage. This helps organizations take corrective and preventive actions before being used in the regulated environment. Hence Medical device & pharmaceutical companies can benefit by show casing the validated applications to the agencies in the Quality management system. The companies also can thus develop understanding of the gaps between COTS and regulated software 8

product in a time frame sometimes as less as 2 months. 9. About the Speaker Vijay Kumar Mallavarapu Consultant in HCL s Life sciences practice helps clients in regulatory compliance. Vijay KM, an expert in Quality management systems brings with him rich experience of Pharmaceutical quality Management and lead teams to implement QMS. 10. Reference General Principles of Software Validation 21 CFR part 11, 21 CFR Part 820 www.pda.org/stores 9