A Perspective on Computer Validation 1

By: Rory Budihandojo, Steve Coates, Ludwig Huber, Jose E. Matos, Siegfried Schmitt, David Stokes, Graham Tinsley, Maribel Rios
n 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

Related FDA documents

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 FDA Inspector's Technical Guide 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 FDA Inspection Technical Guide Part II: "The accuracy and validation of the program is one of the most important aspects of computer control" (7). 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).