Ludwig Huber

In the early years, trying to champion and implement computer validation was quite challenging. The industry faced the unfamiliar installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ) concepts. The common reaction to computer validation back then was quite similar to the Kübler–Ross "Five Phases of Grief" cycle (1). Some readers may have similar recollections and probably have heard some of the following responses: 									

Phase 1, Denial: "Our mission is to implement systems, not to write documents and fill out forms," or "Who says we have to do it, show me the regulations." 

Phase 2, Anger: "We have years of experience in developing and implementing systems, we don't need !@#$*** validation," or "You are joking, you want me to do what?"

Phase 3, Bargaining: "Do we have to do all of those things?" or "Can we do this instead...?"

Phase 4, Depression: "This feels similar to paying a luxury tax," or "This is stressing me out, I don't have the time and resources to do all this work."

Phase 5, Acceptance: "Oh well, fine, if you really want me to do it, I'll do it."

Nowadays, although there are some who are still in the denial stage, the level of grief is more subdued, and the industry is more accepting. For many, computer validation has become a part of daily life, just like accepting and using the mandatory car seatbelt. The road to acceptance was not without its controversies. In the mid 1990s, many varied opinions led to confusion about the scope of computer validation. At one point, a computer's operating system (OS) was thought to be in scope and to require validation, and the OS vendor had to be audited. In another case, a consultant advised that a "change control" must be filed when replacing a printer's toner cartridge (now we know that consumables don't need change control). It was during this period of confusion that "common sense" became the buzz phrase and "it depends" were the first two words that preceded an answer to any computer validation question. 

We have transitioned from the "common sense" and "it depends" environment to a risk-based and risk-management environment, especially since the US Food and Drug Administration is on board with risk management (2). We hope that a risk-management approach will level off the inconsistencies inherent to the "it depends" approach. Only time will tell whether it will be successful. By this transition, however, it seems that along the way we have inadvertently proved Darwin's theory of evolution: we have evolved and transitioned from a less-structured environment to a more technically structured and scientifically minded methodology to computer validation. 

Origins of the computer-validation concept and approach

Although the concept of good manufacturing practices (GMPs) dates back to the early 1900s, current GMP regulations are mostly based on the practices that were revised in the mid-1970s, when the medical-device regulation amendments were introduced. It was during this time period that the manufacturing-validation concept (now known as process validation) was first discussed by FDA officials Bud Loftus and Ted Byers (3). In the late 1980s, the manufacturing-validation concept and approach of conducting IQ, OQ, and PQ were applied to computer validation. This approach was selected in part for the benefit of the relationship between industry and FDA. It was hoped that FDA would accept the computer-validation approach because it was already familiar with and accepting of the IO, OQ, PQ concept. Within the industry, applying  IQ, OQ, PQ to computer validation was challenging at first. This was at a time when validation concepts such as unit testing, module testing, and integration testing in information technology and software engineering already were being practiced. Interestingly, this IQ, OQ, PQ concept has withstood the test of time and is still prominent today, although some may have substituted and intertwined other types of testing into the fold, including unit and integration testing, as well as other variations of testing (e.g., site-acceptance testing and factory-acceptance testing). 

Perspective on regulations and regulatory guidance

Some believe computer validation has been mandatory for only a few years. Most computer validation practitioners believe it started in 1983 with FDA's publication of 

Guide to Inspection of Computerized Systems in Drug Processing

 (known simply as "The Blue Book") (4). FDA documents related to computer systems were published as early as 1976 and 1977, however (see sidebar, "Related FDA documents") (5–7). The 1976 

 provided inspectors with the following guidance (6): 

An understanding of computer operation, and the ability to use a computer, does not require a detailed knowledge of either electronics or the physical hardware construction. An overall view of the computer organization with emphasis on function is sufficient.  

Additional guidance was provided in the 1977 

 "The accuracy and validation of the program is one of the most important aspects of computer control" (7). 

Computer-validation articles published			

Clearly, FDA regulations and expectations have changed since the late 1980s. More detailed documentation is now required to support and verify a system's quality. FDA publications also have become increasingly specific (e.g., in clinical system guidances and those governing the food-processing industry) (8, 9). FDA has a better understanding of the technology and its capabilities as a result of its body of national experts on computer systems, as well as the proliferation of computer and automated systems in the industry. Several other countries also have computer-validation requirements in their GMP regulations (10, 11). 

A discussion about regulations would be incomplete without including 21 

 Part 11 regulations of electronic records and electronic signatures. In 1991, industry and FDA representatives met to determine how to accommodate paperless record systems under 21 

 Parts 210 and 211. Specifically, industry requested FDA's official position on substituting 21 

 Part 211, section 186 "full signature, handwritten" with an electronic signature (12). In response, FDA publshed its progress report 

Electronic Identification/Signature Working Group

 in 1992 (13). The report identified seven key issues: legal acceptance, regulatory acceptance, enforcement integrity, validation and reliability, security, standards, and freedom of information. The final regulation was published in 1997, and although the regulation is now 10 years old, discussions and issues still revolve around most of these points. Former FDA Commissioner David Kessler is believed to have said that he was surprised by the number of experts he found when he searched the topic of Part 11 on the Internet, especially because FDA was still trying to address and develop a better understanding of the implementation and enforcement of the regulation. Even more interesting in hindsight is how the initial request for FDA to address a specific section of 21 

 Part 211 has now evolved and encompassed all other aspects of the GMPs. 

Even now, some uncertainty about Part 11 regulations remains. A contributing factor to this confusion may be the fact that earlier FDA guidelines on the regulation were revoked in 2003 (14) and replaced by a single guideline (15) with the intention of adding other guidelines later. FDA's reasoning behind withdrawing these guidelines (

Docket 00D-1540 in Feb. 2003) was "to avoid loss of time spent by industry in their efforts to review and comment on Part 11 issues that may no longer be representative of FDA's approach under the new GMP initiative." Since then, no additional guidelines have been issued, but FDA is working on a Part 11 amendment (16).  

While FDA published its official regulations and guidelines, the industry also was actively addressing computer validation. In the late 1980s to the early 1990s, the Pharmaceutical Manufacturers Association (PMA, now Pharmaceutical Research and Manufacturers of America, PhRMA) Computer System Validation Committee (CSVC) led by Ken Chapman was the industry's main forum to discuss computer-validation issues. One series of discussions about system-development life cycle (SDLC) methodology resulted in the selection of the waterfall life cycle model (see Figure 1). In the mid 1990s, a variation of this waterfall model, the V model, became more popular (see Figure 2) and is still the model of choice. Looking back, there is no significant change in the computer validation SDLC. This is rather surprising because in some cases, using other methodologies might be advantageous (e.g.,

rapid prototyping methodology, which involves configuring how software should operate first, then documenting the final configuration and functional operation, followed by the software's operational verification). 

Figure 1. "Waterfall" life cycle method.			

PMA also published other computer validation related articles, mainly in 

, which has published more than 40 articles about computer validation. Historically, this publication played a key role in shaping and spreading understanding of computer validation in our industry. Even individuals from FDA published articles in the journal back then (17). Sadly, this is no longer the case because, for better or worse, FDA is now stricter about allowing its employees to publish. (A list of computer validation–related articles is online at 

Figure 2: "V model" life cycle method.			

The PMA CSVC was dissolved in the mid 1990s, and the US Parenteral Drug Association (PDA) became the industry's main forum. Part of PDA's computer-validation committee efforts focused on software-supplier audit and the creation of an audit repository center (ARC) (18). The ARC concept, however, has had varying success. Currently, the repository is managed by Syntegra. Since the late 1990s, the main industry forum for computerized systems validation has been the ISPE good automated manufacturing practice (GAMP ) group. The GAMP guideline is widely considered to be the 

 pharmaceutical-industry standard in computer validation. The current GAMP 4 version introduced the risk-management concept into computer validation in 2001, aligning with FDA's effort on GMPs for the 21st century. Currently, GAMP is working on version 5, which is slated for publication in late 2007 or early 2008. It is important to note that GAMP 4 explicitly excludes 21 

 Part 11, although a separate guideline has been produced. 

The healthcare industry has actively addressed Part 11 regulations. ISPE/GAMP and PDA both have published guidelines on Part 11, hoping to help clarify the implementation and compliance to the regulation. As discussed previously, there was much confusion about the implementation of Part 11 when it was initially introduced. Accordingly, PDA arranged a public FDA conference about Part 11 in June 2000 (19). The conference reinforced the public's concerns about Part 11, and based on industry's reaction, FDA issued the final guidance on Part 11 in August 2003 (15). FDA also scheduled a Part 11 public hearing in June 2004, again allowing the public to voice concerns and suggestions about Part 11. Unfortunately, President Ronald Reagan's funeral fell on the same day as the scheduled public hearing date, and the day was declared a federal holiday. The meeting was therefore cancelled and never rescheduled, prompting industry, as a "21 

 Part 11 Coalition" to file a public petition letter in September 2004 (20). Since then, there has been a semblance of calm on the topic as FDA considers rewriting Part 11 and industry adjusts to a risk-based approach. The resulting decline in the number of Part 11 483s may be related to the fact that FDA is citing the predicate rule directly, rather than Part 11. Until the new amendment is issued, FDA is indeed showing enforcement discretion regarding the implementation of Part 11. It should be noted, however, that Warning Letters with severe consequences were sent to Able Labs, MDS Pharma, and Ranbaxy, and the warnings related to electronic records, even though Part 11 was not mentioned. 

Perspective on enforcement and observations

We can understand FDA concerns about computer systems as we look at the following examples. The "Therac-25" medical-device software went awry between 1983 and 1987, overdosing patients with X-rays (21). FDA stopped the use of the device. According to the recollection of the authors, Wyeth Laboratories Inc. is believed to have received the first computer validation–related 483 from Center for Drug Evaluation and Research (CDER) in October 1983 for a lack of documentation for the validation of a computer system used for the statistical analysis of data. In the late 1980s, the generic-drug scandal caused concern because data had been falsified. One of the authors served as a witness in a grand jury investigation of the generic-drug scandal. Interestingly, Phil Piasecki, a former FDA official who later worked in the industry, once told one of the authors of an observation he made on computer systems. He noticed that the red light of a dehumidifier in a data center was on. After inquiring about the dehumidifier's purpose, he cited the company for not having a standard operating procedure (SOP) for its use and maintenance. 

These examples illustrate the wide range of enforcement actions and levels of impact on patients' safety (from serious to limited and indirect impact). Since the mid 1990s, we have also seen numerous observations relating to computer-validation issues, ranging from "the system is not validated" to "the SOP is not followed." Since the early 2000s, however, it seems the number of observations has decreased. Between 2000 and 2005, the number of Warning Letters issued decreased by 50% (22), perhaps resulting from a shift in FDA's focus after the 9/11 attack in 2001 to homeland security and food safety (23). At the same time, FDA faces a decrease in budget spending (24). 

FDA's presentation titled "Data Integrity, Another Looming Crisis," revealed its recent enforcement has focused on record integrity (25). The presentation made it clear that based on recent inspection findings, FDA would refocus on the integrity of e-records and train inspectors in this topic. Despite challenges that FDA faces, it has increased significantly the understanding and knowledge of computer systems in the industry. The agency actively participates and has a Computer System National Expert representing FDA in industry forums (e.g., GAMP), as well as providing computer validation training courses internally and through selected providers. Hence, although we are now seeing fewer computer-validation 483s, partly because FDA is citing predicate rules instead of Part 11, these 483s are more meaningful and should not be interpreted as a reflection of relaxed enforcement. 

Perspective on computer-validation practices

The Standish Group's "Chaos" reports, indicate that "incomplete requirements and specifications" and "changing requirements and specifications" are two of the top three "project challenged factors" for computer-system projects (26). This assessment seems to hold true in today's computer-validation practices. An informal poll conducted by the authors indicates that user requirements are the main challenge when validating a computer system. User requirements have been a factor since the early years of computer validation. Nonetheless, the general understanding about how to conduct computer validation in the industry has increased since the 1990s, and most companies now have groups or departments dedicated to computer validation. Since the introduction of the Sarbanes–Oxley financial regulations for a publicly traded company, more and more information technology (IT) departments have established compliance groups. It is generally accepted now that IT infrastructure must be qualified to meet growing regulatory requirements across the business. 

FDA has published more than 30 documents related to computer systems and computer validation, and the term 

 is no longer foreign to the industry. Computer-validation practices and regulations are evolving and reaching the maturity stage of other validation disciplines, even if more recently it seems that the efforts on computer validation and Part 11 compliance are less apparent than before. This complacency might be a result of the wait-and-see attitude toward what the new Part 11 regulation amendment might bring and may also result from the perception that computer validation–related 483 observations have decreased in recent years. 

The intent of Part 11 regulations was to allow businesses to be more efficient, to enable automation, and to generate less paper documentation. Yet, these goals have not been fully realized. Most companies addressed how to meet and comply with the Part 11 regulations, but they did not necessarily develop business strategies to take full advantage of what the regulations allow the companies to do. 

As technology evolves, computer validation also will change. We will see what the next 10–30 years bring. Could we see programmable drugs based on nanotechnology? For example, one article suggests that nanodiamonds could be useful in biological applications such as carriers for drugs (27) or perhaps as bioerodible implants with programmable drug release (28). Computer validation will need to be continuously simplified, standardized, and automated while reflecting the growing complexity of designed and engineered drugs and delivery systems. 

The authors thank Alan Kusinitz, managing partner of SoftwareCPR, and George R. Smith Jr., FDA consumer safety officer at CDER's Office of Compliance, for their input and review. 

 is the computer validation manager at Boehringer-Ingelheim Chemicals and a member of 

 is the director of computer system quality assurance at Wyeth. 

 is a compliance expert at Agilent Company. 

 is manager of manufacturing systems and process automation at Bristol-Myers Squibb. 

, is the quality director at GE Healthcare Global IT. 

is the life sciences manager at Business & Decision. 

*To whom all correspondence should be addressed. The scope of this article is specific to the healthcare industry and to the view of the authors or FDA, which may not necessarily reflect the view of the companies where the authors and reviewers are employed. 

Rory: "I was in the UK, going to school." 

www.businessballs.com/elisabeth_kubler_ross_five_stages_of_grief.htm

 3. IVT Proposed Validation Standard VS-2, Computer System Validation, IVT 3 (2002). 

Guide to Inspection of Computerized Systems in Drug Processing (

ITG Subject: The Computer in FDA-Regulated Industries (

www.fda.gov/ora/inspect_ref/itg/itg23.html

ITG Subject: The Computer in FDA-Regulated Industries Part II Computer Hardware (

www.fda.gov/ora/inspect_ref/itg/ itg29.html

Guidance for Industry: Computerized Systems Used in Clinical Trials (

www.fda.gov/ora/compliance_ref/bimo/ffinalcct.htm

Articles

This article provides a historical review of computer validation in the pharmaceutical industry within the last three decades, evolving from the early years' initial concept and approach to today's current practices. Also included is how the regulations and industry have progressed in addressing the topic of computer validation.

A Perspective on Computer Validation

This article describes how to adopt risk-based approaches for the validation of commercial computer systems used in the regulated pharmaceutical industry. This paper will help to guide readers through a logical, risk-based approach for computer system validation. It offers recommendations on how to define risks for different system and validation tasks and for risk categories along the entire life of a computer system. The scope of this paper is limited to Commercial Off-the-Shelf (COTS) systems and does not include risks typically involved during software development.  

The article contains two parts. Part one deals with risk assessment, in which we discuss approaches to categorizing computer systems into high, medium, and low-risk levels. (These levels serve as an example. Any ranking of levels of risk that is relevant to the product and the manufacturer may be substituted. The thought process of ranking is the same.) Part two offers recommendations for validation steps for the different categories as defined in part one. 

Computer systems are widely used in pharmaceutical industry for instrument control and data evaluation in laboratories and manufacturing. They are also widely used for data transmission, documentation, and archiving. When used in regulated environments they should be formally validated. The main compliance-related purpose of their validation is to ensure accuracy and integrity of data created, modified, maintained, archived, retrieved, or transmitted by the computer system. In addition, a computer validation, typically, is a pre-requisite to obtaining reliable system operation and the highest system uptime, which are business requirements of the industry. Depending on the complexity and functionality, validation of computer systems can be a huge task. 

The efforts for validation should be balanced against the benefits, which means the amount of work should be in line with the problems that can occur if the system is not fully validated. The mechanism to balance benefits against investments is risk assessment in which we define the extent of validation according to the risk a specific computer can have on data integrity, and ultimately, product quality and safety. The risk-based approach should enhance industry's ability to focus on identifying and controlling critical functions that affect product quality and data integrity. 

Industry task forces have recommended risk-based approaches for validation for a long time. For example, Good Automated Manufacturing Practice (GAMP) has a chapter in its "Guide for Validation of Automated Systems in Pharmaceutical Manufacture"(1). Also, the United States Food and Drug Administration has recognized the importance of risk-based compliance. This became most obvious when the FDA announced its science and risk-based approaches as part of the Twenty-First Century drug Good Manufacturing Practice (GMP) initiative in 2003 (2). 

"We will focus our attention and resources on the areas of greatest risk with the goal of encouraging innovation that maximizes the public health protection," said FDA Commissioner Mark McClellan at an FDA–industry training session (8). David Horowitz added, "there are two elements to a risk-based approach to inspections: We need to go to the right places and we need to look at the right things" (8). 

One reason for this risk-based approach is FDA's limited resources to inspect all manufacturing sites every two years.  

"We have over 6000 domestic drug facilities and the number of GMP inspections that we have been able to inspect has declined by about two thirds in the last 20 years. So we can't take the chance that we are squandering our limited resources on lower risk facilities. That would prevent us from doing a minimum level of scrutiny and oversight and working with the higher risk facilities," Horowitz said (8). 

In the meantime, FDA has begun to allocate its resources based on risk. For example, beginning in the fall of 2004, FDA began using a risk-based approach for prioritizing domestic manufacturing site inspections for certain human pharmaceuticals. This approach should help the Agency predict where its inspections are likely to achieve the greatest public health impact (2). 

The FDA is not only taking advantage of the risk-based approaches, but also encourages the industry to do so, for instance, in software and computer validation. The industry guidance on 

General Principles of Software Validation

The selection of validation activities, tasks, and work items should be commensurate with the complexity of the software design and the risk associated with the use of the software for the specified intended use (3).

The same guide has also specific recommendations on what is expected for lower risk systems:  

For lower risk devices, only baseline validation activities may be conducted. As the risk increases, additional validation activities should be added to cover the additional risk. 

The "FDA Part 11 Guidance on Scope and Application" states:  

We recommend that you base your approach (to implement Part 11 controls, 

 validation) on a justified and documented risk assessment and a determination of the potential of the system to affect product quality and safety, and record integrity.  

The most specific advice for risk-based compliance of computer systems came from the Pharmaceutical Inspection Convention's, "Good Practices for Computerized Systems Used in Regulated Environments" (5). It has several recommendations related to risks:  

For critical GXP applications, it is essential for the regulated user to define a requirement specification prior to selection and to carry out a properly documented risk analysis for the various system options. This risk-based approach is one way for a firm to demonstrate that it has applied a controlled methodology, to determine the degree of assurance that a computerized system is fit for its intended purpose.  

The inspector will consider the potential risks, from the automated system to product/material quality or data integrity, as identified and documented by the regulated user, in order to assess the fitness for purpose of the particular system(s). The business/GXP criticality and risks relating to the application will determine the nature and extent of any assessment of suppliers and software products (5).

Basically, this means the FDA and other agencies expect a risk assessment for each computer system, otherwise full validation is required. Companies without justified risk assessments will not be able to defend their selected level of validation. The real value in a comprehensive risk-based validation approach is in doing exactly the right amount and detail of validation for each system.  

The principle is quite clearly illustrated in Figure 1. Costs for validation increase when going from no validation to 100% validation. Full validation for a COTS system would mean, for example, the testing of each function of the software under normal and high load, across and beyond the expected application range, and this for each possible system configuration. In addition, whenever the system is changed, may it be computer hardware, operating system, or application software, full revalidation would require that the same tests be rerun. 

In today's rapidly changing computer environment, this could possibly mean that the system would be used 100% for testing. At the same time that testing increases, the risk of unexpected system failure decreases, because errors found during testing can be corrected or work-around solutions can be found and implemented.  

The optimum testing is, obviously, somewhere between zero and 100%. The range depends on the impact the software or system has on (drug) product quality. For example, a system used in early drug development stages will have a lower impact and require less validation than a system used in pharmaceutical quality control.  

In the past, companies frequently have applied the principles of such risk-based validation, but the rationale behind it was not documented and the approach was not implemented consistently within a company. The extent of validation depended more on individual validation professionals than on a structured rationale. As explained earlier, in new guidance, the FDA suggests that industry base the extent of its validations on a 'justified and documented' risk assessment.  

Most confusing to the industry has been finding a structured way to prioritize risks. The FDA has been asked frequently to prepare a matrix of regulated processes indicating the level of risk associated with each. The FDA has made it very clear that this will not happen, because each situation is different. However, they have released criteria to be used in making these determinations. These are defined as: impact on product quality and patient safety.  

General advice came from FDA's John Murray when he answered questions concerning FDA's expectations at the Institute of Validation Technology (IVT) Computer System conference in May 2004: 

Really, I don't recommend you do a detailed risk assessment on every record in the building. I think you need to set up a systematic way of doing it—and you are going to put certain records in certain categories from the very beginning. If a record is used to release product and this record is incorrect and you release an unsafe product – I would make that your highest category, direct impact to public health (15). 

Risk-based validation takes two steps: Define the risk category—for example,  high, medium, and low—and define the extent of validation for each category according to guidelines as laid out by the company.  

One final comment before we start with risk-based approaches. The model proposed in this paper has two objectives. The first is to get started quickly to take immediate benefit of the risk-based approach. Start with a qualitative risk assessment based on experience with the same or similar systems and gain further experience for full risk management for later implementation. The second is to fulfill FDA requirement of basing the extent of validation for each level on justified and documented risk assessment. 

It is quite obvious that there are no generally accepted models to copy, and there is no universal solution. Each company must figure out the answers for itself because success really does depend on the unique situation of a company. The model suggested in this article is just one example for implementation. The FDA would allow many others. For example, this model suggests three risk categories: high, medium, and low. It also would be acceptable to have only two: high and low, or five and more. All models would be accepted as long as the approach is justified and documented. 

Approaches for risk assessment and management

The National Institute for Standards and Technology (NIST) has defined the term 

The probability that a particular threat-source will exercise (accidentally trigger or intentionally exploit) a particular information system vulnerability and the resulting impact if this should occur (12).

The types of risks a pharmaceutical company deals with include patient risk (safety and efficacy of drugs), regulatory risks [FDA 483's, Warning Letters (WLs), product recalls, 

], and financial risk due to, for example: inability to get products approved for marketing, inability to ship finished products, or consequences of unauthorized disclosure of trade secrets and private information. 

Risk management is the entire process from identifying and evaluating the risk to defining risk categories, and taking steps to reduce risk to acceptable levels. Risk assessment includes the first two parts: analysis and risk evaluation.  

There are a number of standard risk assessment techniques available and widely used in the industry. The most important ones include the Failure Mode and Effects Analysis (FMEA) approach, Fault Tree Analysis (FTA), and the application of Hazard Analysis and Critical Control Point (HACCP) methodology. All three methods have been described in brief by H. Mollah (9). 

An approach widely used in medical device industry is based on the International Organization for Standards (ISO) 14971.10 While FMEA and FTA are based more on quantitative, statistical data, the ISO approach is more qualitative in nature. The concept is to determine risk factors based upon their likelihood and severity, the mitigation of those risks, and monitoring and updating the process as necessary. 

The model, as described by GAMP (1) is similar but adds detectability as another criterion: the more likely the problem will be detected, the lower the risk. Labcompliance has developed an extensive risk management master plan using the concept as described in the ISO standard (10). 

For the scope of this publication, we follow the approach as described in the ISO standard. The model presented in this paper is more qualitative than quantitative and is very much based on the experience of users, validation groups, and auditors either with the same or with similar systems. For the scope of this paper, we introduce readers to the concept of full risk management, but then only focus on risk assessment. However, bear in mind that some of the current validation tasks, such as vendor assessment and even testing, are already steps towards the mitigation of risks involving computer systems.  

Risk management of a commercial computer system starts when the system is specified and purchased, continues with installation and operation, and ends when the system is taken out of service and all critical data have been successfully migrated to a new system.  

The approach we take is to divide risk management into four phases, as illustrated in Figure 2. 

Figure 2: Risk management (used with permission).			

The phases include risk analysis, risk evaluation and assessment, and ongoing evaluation and control. 

 Define computer system components and software functions. Identify potential hazards and harms using inputs from system specifications, system administrators, system users, and audit reports.  

 Define the severity, probability, and risk of each hazard, for example, by using past experience from the same or similar systems. Determine acceptable levels of risk and identify the hazards that would need mitigation to reach those levels. Identify and implement steps to mitigate risks. 

 On an on-going basis, evaluate the system for new hazards and changes in risk levels. Adjust risk and mitigation strategy as necessary. 

These activities should follow a risk management plan and the results should be documented in a risk management report.  

The first step in the risk management process is the risk analysis, sometimes called risk identification or Preliminary Hazard Analysis (PHA). The output of this phase is the input for risk evaluation. Inputs for risk analysis include:  					

Risk analysis and evaluation of software and computer systems is a good tool to optimize validation costs by focusing on systems with high impact on both the business and compliance.

Risk-Based Validation of Commercial Off-the-Shelf Computer Systems

In 1997, the US Food and Drug Administration issued a regulation"Rule 21 

 Part 11," that provides criteria for the acceptance of electronic records, electronic signatures, and handwritten signatures (1). FDA issued the guidance in response to requests from the industry. With this regulation, electronic records can be equivalent to paper records and handwritten signatures. The rule applies to all industry segments regulated by FDA that include good laboratory practice, good clinical practice, and current good manufacturing practice. 

It is anticipated that electronic records will be more cost effective for the industry and FDA. In addition, the industry expects the drug approval process will be shorter and access to documentation will be faster and more productive. The Part 11 rule requires: 					

that companies only use validated computerized systems;

secure retention of electronic records and instant retrieval;

user-independent, computer-generated, time-stamped audit trails;

system and data security, data integrity, and confidentiality through limited, authorized access to systems and records;

secure electronic signatures for closed and open systems;

the determination that individuals who develop, maintain, or use electronic systems have the education, training, and experience to perform their assigned tasks.

This article provides an overview of the rule's key requirements and discusses FDA's new approach and narrower scope of Part 11. Although it presents the current interpretations of the rule and its enforcement, it is important to note that such discussions are ongoing. Frequently updated information is available at 

. Additional information  also is presented elsewhere (2). 

				"All computer systems used to generate, maintain, and archive electronic records must be validated to ensure accuracy, reliability, consistent independent performance, and the ability to discern invalid or altered records." 

This condition applies to new and existing systems, but is not new for operations using computers in a regulated environment. Most companies have developed strategies for implementing computer system validation.  

Nonetheless, older systems can be problematic because they require a formal evaluation and a statement about their validation status (3, 4). The extent of validation depends on the system's complexity and its effect on product quality and data integrity. Under 21 

 Part 11, older systems that cannot be validated should not be used.  

Secure retention of electronic records to instantly reconstruct the analysis.

				"Procedures should be in place to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. Records must be protected to enable their accurate and ready retrieval throughout the records retention period." 

The agency should be able to trace final results back to the raw data using the same tools the company used when those data were generated. This task is probably one of the most difficult for which to implement requirements. In some instances, records must be kept for ten years or more. Because computer hardware and software have a much shorter lifetime, one can anticipate problems complying with this paragraph.  

Under the original interpretation of Part 11, each record had to meet this requirement. In addition, records had to be retained in their original form for the full retention period, as required by the predicate rule. This interpretation has changed with FDA's new scope, however.  

Depending on a company's business practices, a record's value over time, and the justified and documented risk assessment, the new interpretation enables companies to copy the electronic records to paper or to standard electronic formats such as portable data format (PDF). 

"Procedures should be in place to limit the access to authorized users" 

Limited access can be ensured through physical or logical security mechanisms. Most companies already have such procedures in place. For logical security, users typically log onto a system with a user identification (ID) and password. In addition, physical security such as key locks or pass cards is recommended for high-risk areas (

 data centers with network servers and archived data). Procedures should be carefully documented and validated.  

User-independent, computer-generated time-stamped audit trails. 

"Procedures should be available to use secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying" 

This paragraph has been the subject of much discussion such as how audit trails should be implemented and about what information should be recorded. An important distinction is that the word 

 means independently from the operator. The main purpose of the audit trail is to ensure and prove data integrity. If the data have been changed, the computer should record what has been changed and who made the change.  

The audit trail functionality should be built into the software and is especially important for critical computer-related processes with manual operator interaction. Under the new scope of Part 11, the implementation of electronic audit trails should be risk-based, justified, and documented.  

Use of secure electronic signatures for closed and open systems. 

				"The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to determine record and signature falsification" 

The main purpose of this requirement is to link electronic signatures to relevant electronic records and the record signer. The system should recognize the signer with a user ID and password. Procedures and technical controls should ensure that the signer is uniquely identified. This rule not only requires the development of procedures, but also necessitates behavioral changes for using ID codes and passwords. Sharing a password with a colleague usually is much less taboo than teaching somebody how to copy a handwritten signature. But under Part 11, both actions have the same consequence. Software also should recognize any change to a signed record, most commonly through linking the electronic signature to the electronic audit trail. 

Use of digital signatures for open systems. 

				"Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the confidentiality of electronic records from the point of their creation to the point of their receipt. Such procedures and controls shall include those identified for closed systems, as appropriate, and additional measures such as document encryption and use of appropriate digital signature standards to ensure, as necessary under the circumstances, record authenticity, integrity, and confidentiality" 

This rule requires software for document encryption and may also require hardware and software for generating digital signatures. Typically, computer systems used in pharmaceutical operations are closed systems that do not need digital signatures. Conversely, an example of an open system is analytical data generated by a contract laboratory that are transmitted to a sponsor through the public Internet. Examples of how open systems can be used are described elsewhere (2). 

 Part 11 has been in place for eight years and enforced for six years, companies are still confused about how to implement it.  

For example, the regulation, earlier draft guidance documents, and early interpretations from FDA defined an electronic record as, "any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system" (1, Par. 11.1 [b]). But, the rule makes no distinction among the types of records or their criticality.  

FDA requested Part 11 compliance for all such records that were generated or stored on a computer and could ask for such records at inspections. With this very broad interpretation, full implementation was very expensive and for some applications, it was impractical. In some cases, companies decided to keep paper records because of the anticipated additional complexity and cost involved with implementing the technical control required by the rule. This outcome clearly was not the original intent and spirit of the rule which was issued to protect public health and enable new technology to be used. 

With the release of the draft guidance on scope and application of Part 11 in Feb. 2003 (5), FDA promoted a new, narrower approach. With the final guidance released on Sept. 3, 2003 and FDA's announcement to reexamine Part 11 and initiate a new rule-making process, this narrower approach became official and probably will be the basis for an updated regulation in the future.  

The guidance states that Part 11 applies when:  					

the record is required by a predicate rule (

 Part 211 and electronic training records in 21 

the electronic records are used to demonstrate compliance with a predicate rule (

 electronic training records for compliance with 21 

Part 11 applies in one or both of the following situations: 					

when electronic records are used instead of paper;

when persons make printouts but still rely on the electronic records to perform regulated activities.

Figure 1 illustrates the decision flow to determine which records fall under the scope of Part 11. This figure has been presented several times by FDA staff Part 11 experts. First, we check if the record is required by and  can demonstrate compliance with the predicate rule. 

 Figure 1: Steps to determine whether records are within the scope of Part 11 (7).			

Next, we determine if the record fits in the new, more-specific scope of Part 11. The main criterion is whether the record is maintained in electronic format in place of a paper format or in both electronic and paper formats, and whether people rely on the electronic records to perform regulated activities. A 

 is any activity required by an FDA regulation. For example, analytical test results must be recorded according to FDA's 21 

 Part 211. In this case, the regulated activity is not limited to signing the record (

 a paper printout of an electronic record). It also includes all steps from data acquisition and evaluation.  

Finally, we make a risk assessment of the criticality of the records and document the result. Based on the outcome, appropriate Part 11 controls are implemented.  

The final criteria is to evaluate the risk the record has on product quality and data integrity. Examples of high-risk records are electronic batch records and analytical records of final product testing. Errors at this stage will not be identified and cannot be recovered before the product ships to the market. An example of low-risk records are electronic planning documents such as cleaning or maintenance schedules. Electronic standard operating procedures could fall into the medium- or low-risk category, depending on the procedure's effect on product quality. The International Society for Pharmaceutical Engineering has published a list of such risk classifications (6).  

Justification and documentation of Part 11 compliance 

As explained previously, the implementation of some Part 11 controls should be based on criteria such as: 					

where the record is required by predicate rule;

whether a regulated activity depends on the record;

effect of operator interaction on data integrity and product quality.

If Part 11 controls are not implemented, FDA must review a documented justification that explains why not. Every company is advised to prepare such documentation.  

An example of such documentation is shown in Figure 2. A computerized analytical system used in a pharmaceutical quality control laboratory is reviewed as an example. 

In 1997, the US Food and Drug Administration issued a regulation"Rule 21 CFR Part 11," that provides criteria for the acceptance of electronic records, electronic signatures, and handwritten signatures (1). FDA issued the guidance in response to requests from the industry. With this regulation, electronic records can be equivalent to paper records and handwritten signatures. The rule applies to all industry segments regulated by FDA that include good laboratory practice, good clinical practice, and current good manufacturing practice.

21 CFR 11 Overview of the Final Document and its New Scope Ludwig Huber

The objective of this article is to attempt to look at the future state of computer validation principles based on current events and trends in regulations, business practices and technology. This crystal ball approach will prepare the industry for the future by establishing a current-state best-practice foundation of computer validation principles as well as improving computer validation practices.

Part I of this article was published in the March 2003 issue of 21 CFR Part 11: Compliance and Beyond. In this issue, Part II discusses the potential advances and changes that must be made for computer validation to remain innovative and relevant to the industry.	

Improving the future of computer validation infrastructure

With the increased need to conduct computer validation, there comes a need to improve the efficiency of how computer validation is performed. To have better efficiency in computer validation practices, a better infrastructure for computer validation practices is required. In addition to an existing computer validation programme that may already have been established (for example, the availability of an inventory list of the systems, a master plan on the validation status of the systems or a prioritization of how the systems are going to be validated and procedures for conducting computer validation), the following are some conceptual approaches that can be considered for building the future infrastructure (please note that these concepts are simply food for thought).				

Use of a commercial off-the-shelf (COTS) screening requirements document

The current computer validation practices for preparing a full and thorough requirements document before system purchase may hamper the effort of purchasing a system in an expedient manner. In addition, the current operational lifestyle for new systems acquisition is mainly related to the purchase of COTS software, which typically means there is an existing client base and, perhaps, some familiarity with the product. The concept of screening requirements is the use of a high-level requirements document to select a vendor, which enables a purchase order to be issued and then allows the system acquisition process to begin. Once the vendor is selected, the strategy is to work with the vendor in acquiring or developing the specifications document. The potential for developing and using a screening requirements process can only be considered for purchasing a system that meets all of the following criteria:		

a COTS system (one that is not a customized, contracted or an in-house developed system)

not a new system (that is, it is not version 1.0; there is an established, regulated client base)

a system for which the principle of functionality and operation is already known (for example, a high performance liquid chromatography system)

a similar system is already available in-house

a system for which the requirement specifications can be furnished by or co-developed with the vendor.

As with other types of software systems, a risk factor is involved in the use of this screening requirements concept. Those risks may vary from system to system, from project to project and from company to company. From a computer validation perspective, the main risk factor to be considered when using this concept is the capability of it meeting the basic objective of computer validation: providing documented evidence that provides a high degree of assurance that the system reliably and consistently does what it is designed to do. When this concept is applied, and the above criteria are met, the basic objective of computer validation can still be met. Mitigating the risk arising from this approach can be done by ensuring that the system is qualified to meet business needs (for example, through testing). Hence, incorporating and meeting business needs should be included in validating the system.	

Process for evaluating the need to do a vendor audit

This section is not intended to introduce a concept regarding how a vendor audit should be conducted, but rather to introduce the concept of determining whether there is a need to conduct a vendor audit (or the type and level of the audit). Having such a process will define a consistent approach for evaluating vendors and expedite the decision making process.				

Part I of this article was published in the March 2003 issue of 21 CFR Part 11: Compliance and Beyond. In this issue, Part II discusses the potential advances and changes that must be made for computer validation to remain innovative and relevant to the industry.