Computer System Validation Manual

Documentation. Since the validation protocol is documentation intensive, existing documents, reports, vendor manuals, etc. should be used. The development of the protocol and the methodology used for validation should fit the existing management/committee structure whenever possible. Computer systems validation should not create a new documentation structure but rather pull together the necessary information for documentation and testing from that which already exists. 

Often, companies have a Computer System Validation (CSV) Manual that guides the validation engineer through the process of specifying, designing and installing a process control system, but the CSV Manual is frequently deficient in offering advice for a business system. 

Using either data-based computer systems [28,29] or manual methods, retrospective validation may be conducted in the following manner ... 

Once the mechanics of retrospective validation are mastered, a decision is required as to how data analysis will be handled. The illustrated calculations may be performed manually with the help of a programmable calculator and the control charts may be hand-drawn, but computer systems are now available that can shorten the task. If the computer route is chosen, commercially available software should be considered. There are many reasonably priced programs that are more than up to the task [17]. 

Computer systems employed should meet or exceed the validation requirements for the manual functions they replace. The new computer system must be at least as reliable as the computer system it replaces. Pharmaceutical and healthcare regulations do not mandate parallel operation of manual systems being replaced by compnterized systems. If a period of parallel operation has been decided npon, it shonld be mn with the pnrpose of demonstrating that the computerized system is better than the old manual system, and the manual system can be decommissioned. It is unacceptable, however, to rely on parallel operating as the sole basis of validation. The replacement system mnst be vahdated in its own right. 

A strategy for segregating integrated systems into those requiring validation and those that do not is considered here. This strategy can be extended to segregating distinct modules in large computer systems such as MRP II systems. A clear definition of system/module boundaries is required. This often prompts additional validation efforts for automated and manual interfaces. 

Validation should place a priority on critical processes and their associated computer applications. All computer systems should be considered critical unless reliance can be placed on an independent downstream system. A downstream system may be a manual... 

It could be difficult to retrospectively vahdate a computer system if there were changes and revisions that were not documented and the cumulative effects of many revisions had not been assessed. Lack of sufficient system documentation would make it impossible to perform meaningful retrospective vahdation. FDA concludes that the XXX and YYY systems lack adequate validation and therefore are unacceptable for use in the production of drag products. Please indicate whether you can perform a retrospective validation of XXX and YYY systems or rely in the interim on manual operations, which use source documentation until the new validated computer systems are functional. [FDA Warning letter, 2001]... 

So how much is enough validation There is no panacea, but a key step is concentrating effort where it is needed. Emphasis shonld be placed on validating the GMP aspects of the system. There are often jnst a few critical functions and components that affect product quality, supported by a collection of measnrements and manual interactions. The nature of any manual interactions will have a significant impact on the amount of validation required. Computer systems that only record the mannal control of a process will require less detailed validation than those that directly control a process. The collection of product data is another important factor in assessing the degree of control taken by a compnter system. 

Each container or grouping of containers should be identified with standard nomenclature and a distinctive code for each lot in each shipment received, which should be used in recording the disposition of each lot Each lot should be appropriately labelled and identified as to its status (i.e., quarantined, approved or rejected). This may be done manually or the status may be controlled by appropriate and validated computer systems. 

Computer systems and software products should be supplied with declarations documenting the evidence of software development validation. The user should also get assurance that development validation procedures and documents can be made available to the user. Critical formulae used in the analytical process should be documented in the user s operating manual. 

The replacement of the manual and safety logic by a ruggedized micro computer system would make the system more compact. However replacement of the safety logic by software will require considerable research and development effort to achieve the required reliability. Also the validation of this software poses a real challenge. 

The following flowsheet represents the simplest connections combined with good, inexpensive manual regulation required to execute valid experiments. This is the recommended minimum starting installation that can be expanded and made more sophisticated as need and budgets permit. The other extreme, a fully computer controlled and evaluated system that can be run without personnel will be shown later. The concepts, mentioned in Chapter 3, are applied here for the practical execution of experiments in recycle reactors. 

The relevant calculations are commonly handled poorly, because the equilibrium equations involved are difficult to solve manually (but not with computers). The few calculations that are actually reported in the biochemical literature use simplified methods of limited and frequently unknown validity. Large excesses of magnesium ion are frequently used in experiments, perhaps in an attempt to avoid such calculations. The relevant theory is well worked out and there are excellent reviews. The limitation appears to involve diffusion to the (mathematically) inexpert user, which is one of the motivations of building expert systems. 

A historical control database can take on many formats, from a simple spreadsheet (e.g., Microsoft Excel) to a fully searchable database that is interfaced or a part of the laboratory s computer data collection system. Most laboratories that conduct large numbers of studies according to GLP standards have a validated computer data collection system, and some of these systems automatically compile control data ftom studies so the user does not have to reenter the data into a separate historical control database. However, because of the inflexibility of the data acquisition systems, many laboratories still compile their historical control data by manually entering into a stand-alone database, such as customized spreadsheet format (e.g., Microsoft Excel). 

Before a system using a computer is brought into use, it should be thoroughly tested and confirmed as being capable of achieving the desired results. If a manual system is being replaced, the two should be run in parallel for a time as part of this testing and validation [13]. This means that every time maintenance has made an intervention in the equipment and any piece has been adjusted or replaced, a revalidation is required. This maintenance intervention could be in both hardware and software. 

In manual calculations, such problems could easily be spotted by an independent, critical observer, as one of the points made in the Study Director s statement shown in figure 34 (see page 271) will demonstrate. In an electronic system only an expert programmer, however, could be expected to deal with such issues, and furthermore only so, if he had full access to the source code. Therefore, the basic process for ensuring GLP compliance of an IT application is to demonstrate that the respective application does indeed perform the intended task in a correct way, and that it does so in the actual working environment of computer hardware and connected peripheral components and apparatus. This demonstration of the suitability for its intended purpose is obviously of fundamental importance, and this process is referred to as computer validation . In essence, such validation should provide a high degree of assurance that the system will meet its predetermined specifications. 

The control computer/DCS system consists of controllers, A/D and D/A converters, and the signal conditioifing hardware and software, i.e., filtering and validation. Each of these components requires separate evaluation. Table 15.5 lists possible problems with the controller/DCS system. One way to initially check controller tuning is to place the control loop in manual (open the control loop) and observe whether the controlled variable lines out to a steady-state or near steady-state value. Comparing the open-loop and closed-loop performance indicates whether the controller is upsetting the process. If not, disturbances to the control loop in question are the primary source of the upsets. 

The calculation process is lengthy if attempted by manual methods and is best programmed in a small desktop computer that can handle complex numbers. Such a programming exercise is simple to achieve. In order to screen various alternative cases it is possible to make some valid simplifications in the proposed system and to use a simpler calculation method. 

The computer based system should be subjected to an extended on-site probationary period during which the operation, testing and maintenance of the system should be as representative of the in-service conditions as possible. Where appropriate, the new system should be run in parallel with the old system for the probationary period, i.e. imtil sufficient confidence has been gained in the adequacy of the new system. The validation of operation and maintenance manuals should be... 

---