GAMP 5 Quality Risk Management Approach

1 MAY/JUNE 2008 PHARMACEUTICAL ENGINEERING1 Quality Risk Management Copyright ISPE 2008 CategoryGAMP 4 gamp 51 Operating systemInfrastructure software (OS,middleware, DB managers, etc.)2 FirmwareNo longer used Firmware is nolonger functionally distinguishable3 Standard softwareNon-configured software Includes default configurable SW4 Configurable softwareConfigured software configuredpackagesto satisfy business process5 Custom softwareCustom SoftwareTable A. gamp 5software articledescribes howthe gamp 5quality riskmanagementstrategy offers apragmaticapproach 5 Quality Risk ManagementApproachby Kevin C. Martin and Dr. Arthur (Randy) PerezIntroductionBackgroundIn today s competitive and highly regulatedenvironment in the life sciences industry,companies need to focus skilled resourceswhere the risks are highest, thus minimiz-ing risk to patients while maximizing resourceutilization and efficiencies.

2 To achieve thisresult, it is imperative to understand severalcritical issues. Companies must have a thor-ough understanding of their business processesand the Critical Quality Attributes (CQAs) ofthose processes. This knowledge along withappropriate risk Management methods makeit possible to identify potential areas that mayfail, and to identify areas with acceptable riskor low risk that can be assigned a lower priorityor effort for mitigation. It should be possible toreduce or eliminate unwarranted work at allrisk levels, but especially on low risk areas,freeing critical resources to mitigate 5 provides guidance in the applica-tion of risk Management principles to the de-velopment of computer systems in GxP envi-ronments.

3 It has become far less common thanit was 10 years ago for life sciences firms todevelop their own software. This leads to thegenerally positive consequence that most soft-ware is developed by companies whose contin-ued viability is predicated on their delivery ofgood software. gamp 5 recognizes this fact, apoint emphasized by the extensive appendixdedicated to supplier evaluation. It is appropri-ate to become involved in supplier softwaredevelopment and QA processes only if there isreason to doubt the integrity of these this context, this article assumes thatsoftware and hardware are developed by thesuppliers within a sound Quality managementsystem. Therefore, gamp 5 stresses consider-ation of risk to patients with the assumptionthat risks related to other business issues arecovered by the supplier and the customer sstandard system implementation development of the gamp 5 risk man-agement Approach has its antecedents in theFMEA-based risk assessment tool published inGAMP 4 in 2001.

4 The Approach matured in the2005 ISPE gamp good Practice guide : ARisk-Based Approach to Compliant ElectronicRecords and Signatures with incorporation ofaspects of ISO 14971 Medical Devices Appli-cation of Risk Management to Medical expansion of these concepts and the fivestep Approach described in gamp 5 and thisarticle are fully compatible with the approachespublished in ICH Q9 Quality Risk Management (2005) and ASTM E2500 Standard guide forSpecification, Design, and Verification of Phar-maceutical and BiopharmaceuticalManufacturing Systems and Equip-ment (2007).Determining the risks posed by acomputerized system requires a com-mon and shared understanding ofthe following: impact of the computerized sys-tem on patient safety, productquality, and data integrity supported business processesReprinted fromPHARMACEUTICAL ENGINEERING The Official Magazine of ISPEMay/June 2008, Vol.

5 28 No. 32 PHARMACEUTICAL ENGINEERING MAY/JUNE 2008 Quality Risk Management Copyright ISPE 2008 Critical Quality Attributes (CQA) for systems that moni-tor or control Critical Process Parameters (CPP) user requirements regulatory requirements project Approach (contracts, methods, timelines) system components and architecture system functions supplier capability the company s risk toleranceThe order in which the above is applied is not as important asensuring that each area is addressed. However, it is impera-tive to understand several critical issues. First, it is essentialto have a deep understanding of the relevant business pro-cesses and to understand CQAs of the should be noted that the concept of CQAs is not have been a part of Six Sigma, Mechanical Engineeringand Software Engineering Quality practices for years.

6 CPPsare also a part of Six Sigma. Thus, these concepts areapplicable in a far wider arena than in life science manufac-turing; they are an aid to understanding the risks associatedwith any business 5 relates how understanding of CQAs and CPPscan be applied to computerized systems in the life scienceindustry with the intent of using them to the development ofstrategies for validation and verification. With such under-standing, it is possible to identify potential areas of theautomation that may fail to perform to expectation, and toidentify those risk points that can be categorized as low orotherwise acceptable risk versus those that constitute unac-ceptable risk. It should be possible to reduce, or even elimi-nate, unwarranted work on low risk issues, freeing resourcesto be applied to more significant CQAs and CPPs are often identified and em-ployed in relation to manufacturing systems, particularlyprocess control or other computerized manufacturing pro-cesses, they are not frequently applied to non-manufacturingareas.

7 However, there is no reason why the concepts shouldnot be applied in other arenas; they can work just as well fora preclinical study as they do for a production line. Theapproach described in gamp 5 describes a framework thatcan be used in GMP and non-GMP areas equally of CQAs can aid in the development of failure ordefect scenarios in order to understand the downstreamimpact on the patient. With the scenarios identified, theability to mitigate the risk or impact of the failure can beevaluated, presenting the potential to detect and interceptthese faults before serious harm occurs. The ongoing moni-toring of not only the process, but the effectiveness of mitiga-tion for potential failure points, can help to reduce thelikelihood that the potential failure may become a reality,and if it does, to recognize it early and contain or minimize Use of Risk-Based ApproachesMany companies have been using a quasi-risk based ap-proach for years.

8 The typical dilemma with validation ofcomputerized systems has been deciding what to test, howmuch to test, and where should resources be applied toachieve optimum efficiency. Their validation processes oftenincluded risk assessments, but without a clear process forusing the results of these assessments, they tended to be justanother document in one of many binders of validationdocumentation. In lieu of a sound risk-based Approach , thesecompanies tended to err on the side of caution and conductexhaustive and costly validation documents have been used to help identifykey process components, often times weighting them toassign to them a priority based on their relative types of tools have been used to determine where tofocus resources and to identify the critical elements of ourprocesses.

9 Structured approaches such as root cause analysisand Kepner-Tragoe Analysis have been useful in the deci-sion-making process. The critical areas would be documentedand tested more than areas of lower criticality. Although theterm risk was not necessarily used, the concern was aboutthese critical processes operating properly and not problem resided in the fact that many viewed complianceas a black and white issue; zero risk meant compliance, andanything less was considered recently when 21 CFR Part 11 (August 1997) wasfirst introduced, many formal company assessments includeda risk filter where the importance of the electronic record (orsignature) was assigned a criticality factor. This was neces-sary as a part of triage, deciding what systems neededremediation first.

10 The higher the criticality, the more empha-sis would be placed on ensuring that the integrity of therecord was maintained. This was done not only for businessreasons, but to assure product Quality and subsequentlypatient of the Definition andUnderstanding of RiskRisk Management techniques have been in use for decades,early versions having their genesis in the 1940s. In the 1950s,military and aerospace industries began to apply risk ap-proaches in the form of numerous MIL-STDs. The 1960s sawthe creation of reliability engineering approaches ( ,FMECA and HACCP). Certainly, the surge in the softwaredevelopment and technology industries drove the develop-ment of standards, in part impelled by the Computer SecurityAct of 1987 and the Information Technology ManagementReform Act of 1996.