Rory Budihandojo

Compliance with quality regulations that protect patients' safety is a critical requirement for the pharmaceutical industry. Regulatory compliance goes a long way toward proving that a given product's target for quality has been achieved and documented. 

Pharmaceutical Manufacturing Handbook: Regulations and Quality

 is intended to help readers understand how to comply with regulations and how to adapta quality unit's routine activities to facilitate compliance.

In the book's preface, editor ShayneCox Gad says the book describes "allregulatory aspects and requirementsthat govern how drugs are producedfor evaluation (and, later, sale to anduse) in humans." The book's back coversays it contains "everything you needto ensure full compliance and superiorquality control."

The book's eight sections cover topicssuch as good manufacturing practices(GMPs) and other US Food andDrug Administration guidelines, internationalGMP regulations, quality,process analytical technology (PAT),personnel, contamination and contaminationcontrol, drug stability, andvalidation.

The book benefits from the work ofmore than 40 authors-respected academicsand industry veterans-whocontributed their years of expertise invarious topics.

The book's first two sections aredevoted to US and international regulationof GMPs. The first section describesFDA's GMP regulation andprovides a good reference to other pertinentregulations and guidelines suchas scale-up, postapproval changes, andPAT publications. These sections provideuseful advice for complying withregulations.

PharmaceuticalManufacturingHandbook:Regulations andQuality, ShayneCox Gad, Ed., Wiley,London, 2008, 856pp., ISBN: 978-0-470-25959-7

A chapter titled "Enforcement ofCurrent Good Manufacturing Practices"includes a surprising and illuminatingdiscussion about FDA's collaborationwith the Federal Bureau ofInvestigations during certain inspections.

The next section discusses variousaspects of quality. Despite offering detaileddiscussions, chapters about totalquality management, the role of qualitysystems and audits, creating and overseeingquality-management systems,and quality-process improvements arequite easy to read. These chapters alsoprovide materials that can be used in aquality operation (e.g., a checklist forperforming a quality audit).

The section dedicated to PAT offersa discussion about chemical imagingand chemometrics. Passages providedetails about the background of PAT,its benefits, and the various methodsof implementing PAT.

The comprehensive section aboutdrug stability provides readers a scientificunderstanding of how to determinea product's shelf life. This sectiondiscusses alternative accelerated testingmethods through variable-parameterkinetics studies.

The section about validation includesconsiderations of essential matters suchas analytical methods, laboratory instruments,and pharmaceutical manufacturing.This portion omits otherimportant types of validation, however,such as computer validation, processvalidation, and facility validation.

Nevertheless, this book is a valuablereference for anyone interested in drugstability, quality, and PAT. The contributors'expertise ensures that the bookshines in its treatment of those topics.It is not far off the mark to say that thebook contains "everything you need toensure full compliance and superiorquality control."

 is a computer validation manager at Boehinger-Ingelheim, 2820 N. Normandy Dr., Petersburg, VA 23805, tel. 804.504.8373, fax 804.504.8637, 

Articles

A new book explains process analytical technology, drug stability, and quality.

A Path to Quality and Compliance

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

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

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.				

The following are some of the questions that can be considered for this process:	

is the system COTS or custom developed (contracted out or developed in-house)?

does the system's acquisition involve the purchase of one or more than one system?

will the system be implemented at one location or multiple locations?

will the system be deployed as a standalone system or interfaced to other systems?

is the system new and recently marketed or has it already been in the market for an extended period of time?

has the purchaser had experience with this system?

has the purchaser had experience with the vendor?

will the vendor be used just for this one particular project or for future projects?

has the vendor been previously audited by your company or does the vendor have an audit on file with the Audit Repository Center?

can the vendor make high quality development validation available?

does the vendor have an established market history (is it financially stable)?

does the vendor have quality certifications?

does the system perform complex GxP functions (for example, you may not want to do an audit of a vendor for simple electronic balances)?

Other factors can also be considered and a weighting factor can be applied to each of those factors. The totalled result can be used to determine whether a vendor audit should be conducted. Having this type of process in place will expedite the process of computer validation by providing guidance as to which vendors must be audited.	

Process for accepting third party certification

In addition to considering the need for vendor audits to inspect the quality of the product, alternatives - such as third party certifications - may be evaluated. The introduction by the US Food and Drug Administration (FDA) of a systems approach to inspection may facilitate the use of third party certification to evaluate the quality of the software without performing a vendor audit. Accredited certification bodies certify the quality of a product by conducting audits performed by independent external quality assurance agencies known as third party certification bodies.39 The certification bodies use technically qualified auditors who have been specially trained and subjected to professional selection. Having this type of process in place would expedite computer validation by potentially avoiding long discussions regarding the quality of the product. Instead, the audit can concentrate on the capability of the product to meet user needs.				

It should be noted that FDA does not currently recognize any third party certifications, including ISO 9001 certification. The industry must work with FDA to provide it with a level of trust in such a scheme before it can be relied on to mitigate the validation workload. In the meantime, the PDA effort (Technical Report 32) of vendor audits and the establishment of a vendor audit package repository centre39 should be considered as a means of satisfying the supplier audit requirement.	

Availability of a corporate data dictionary

To increase the efficiency of the process for making a decision and for information availability, the need for systems integration (for example, between chromatographic systems and LIMS or between LIMS and MRP) will increase and become more prominent in the future.		

To anticipate this need, one has to consider the development of a corporate data dictionary standard (for example, establishing standard definitions for terms such as sample, item code and unit of measurement, and creating a naming convention for products or data elements that will be shared between the computer systems). Building the data dictionary can be started whenever a new system is deployed or from the existing systems through the collection of data dictionary items from those systems. The collected data dictionary items from the various systems can then be compiled and cleaned (that is, eliminating redundancies and selecting a primary data item preference) to provide a controlled version of the data dictionary. When another system is being considered for deployment or acquisition, the data dictionary can be used to assess whether the data elements already exist in the dictionary or a new element must be introduced to the library. This data dictionary can also be used to support requirements development and will be an aid to system or vendor selection. For example, the data dictionary can help determine the complexity of integrating or interfacing new and existing systems.	

Simplifying the computer validation approach

Currently, almost all instruments or equipment being purchased contain a microprocessor, even those as simple as a pH meter. The level of validation (or qualification) of a simple microprocessor-based system does not always require the same level of validation effort that a more complex system requires. Hence, a simple conceptual process for determining the level of validation (or qualification) effort is needed. This concept is based on the premise that the level of validation (or qualification) can be categorized as needing either calibration, qualification or validation. For example, laboratory instruments or equipment that meet all of the following criteria can be categorized as needing calibration only:				

equipment or instruments in a COTS system

instruments or equipment not attached to an external computer or PC

if software is embedded in the equipment or instrument and only the vendor can load or change the software

no data are retained or stored by the equipment or instrument other than the current data analysis measurement

no data can be stored and retrieved, changed and stored again

the equipment or instrument is of the standalone type and not interfaced or integrated to other systems (if it is interfaced or integrated to other systems, then the total integrated or interfaced system must be considered when determining the level of validation or qualification).

After calibration, qualification must also be performed if the following factors are required to operate or use the equipment or instrument:	

calibration must be run whenever a sample analysis is performed (calibration is not the periodic type of calibration or performed on a preventive maintenance schedule)

final output (or result) of the equipment or instrument requires data processing or calculation based on the input of another sample or other data parameters obtained during the analysis of that additional sample

the equipment, instrument controls, monitors switches or other functions that are needed for that equipment to operate.

For an instrument or equipment that does not fall into these categories (that is, calibration or calibration 1 qualification), then validation is required. The level of validation can then be divided, based on whether the system is a custom-developed or a COTS system. For the custom system, a vendor audit, design specifications, programming standards and a source code walk-through and review may have to be considered and included as part of the validation activities. For COTS packages, much of this work will have already been done by the vendor (and verified through an audit). The criteria described above offer a conceptual depiction of the types of issues that must be considered when attempting to determine an appropriate level for validation activities.	

Validation data and test sets retention for regression data analysis

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.

The Future State of Computer Validation, Part II: Increasing the Efficiency of Computer Validation Practices

In Part II of this article, the authors discuss the types of specifications and the installation, testing, contingency planning, documentation, and implementation of required validation for networks.