OR WAIT null SECS
© 2024 MJH Life Sciences™ and Pharmaceutical Technology. All rights reserved.
Pharmaceutical Technology Europe
Baselines are one of the most useful tools in the 'validation toolbox'. They can be used for a variety of tasks with great success. This article will examine how they can be used and for what.
Baselines are one of the most useful tools in the 'validation toolbox'. They can be used for a variety of tasks with great success. This article will examine how they can be used and for what.
Regulations (21 CFR Part 11) require companies to be able to present a snapshot of an installation at a given point in time. Most firms do this by managing changes (which are also required by the regulations), but the vast number of them makes it very difficult to present the data for a single system within a reasonable amount of time and limited effort.
A Utah medical case describes how a company, unable to show that system changes had been tracked continuously, was subsequently unable to present specifics about any given baseline in the production facility.1 This lead to several 483s (cGMP noncompliance notice forms) and a law suit. GSK was asked by the UK authorities about the configuration of a system before and after a specific change, which again suggests that the authorities are interested in baselines.
The Parenteral Drug Association (PDA) Technical Report 18, Section 3.1 suggests: "An inventory should be created of all computer systems being used within the appropriate business area (company, department etc.). It should be a dynamic inventory representing, at any point in time, all systems currently in use. A regulatory inspector often asks for this inventory as one of the first questions during an inspection."2
FDA regulation 211.184(c) provides further enlightenment as the regulation is not related to end user products alone, but also to production, production facilities and the system used in the production process:3
"An individual inventory record of each component, drug product container, closure, and for each component, a reconciliation of the use of each lot of such components. The inventory record shall contain sufficient information to allow determination of any batch or lot of drug product associated with the use of each component, drug product container, and closure."4
The glossary to this article can almost be considered a step-by-step guide to creating a baseline. First, establish a list of systems and the units they consist of. At this point it is important to consider the setup. You may want to describe the hierarchical structure of the entire company or merely the structure of a single system (Figure 1).
Figure 1 Example of structure for a large company.
It is essential to decide upon the level of detail required in the documentation; for example, for a computer system, do you need the serial number and type of the hard disk? Maybe. It depends on what you are going to use the system for. If it is specifically for regulatory reporting, you may not. The size, type or serial number of a hard drive is not critical, but the collection of such information could be useful for maintenance purposes as well. Daily use of the information will — provided it is updated regularly — ease system maintenance because the required information is readily available not only to an inspector, but also for those maintaining the system. They will be able to retrieve the information about which hard disk they need for a support job without actually taking out the hard disk from the machine or even going to the specific machine.
Glossary
Of the information that could be collected it is necessary to determine what is most important. Generally, it is wise to consider three scenarios :
To determine what data must be recorded for a baseline, their purpose must be considered (Table 1).
Table 1 Example of a generic structure capable of containing both file and printer servers.
When the structure and detail level have been decided, the first CII draft may be noted. At this point, the individual components of the systems are entered into the CII list (Table 2).
This draft CII list requires a baseline (based on the CII lists, which are reorganized into a protocol) to be compared with Table 3.
Creatively used, and given the flexibility of some sort of system to manage it (and I emphasize that a baseline system is NOT Word, Excel or the like, which are programs), baselines could also be used for controlling backups. Figure 2 shows how a specific configuration can be derived from the baseline by extracting the information for a given point in time. It shows that you will be able to present, based on a baseline report for any given point in time, exactly which backup to restore, on which system, and what hardware.
Consider the advantages of being able to readily present this information from the baseline used for the daily system maintenance.
Table 2 The CII list.
Fully implemented, the baseline may be used for other purposes too. Currently, the authorities are interested in equipment requalification and process revalidation — the CII report or the baseline report will help with this. Because the reports list all the changes that have occurred within a single system, it is possible to provide the change information almost immediately. Also the product annual review, which is very much in the sight of the authorities, can benefit from the baseline report, as it shows the system has been in control continuously.
Table 3 The baseline protocol.
The baseline can not only provide information about the production system at any given point in time, it can simultaneously highlight differences between two points in time. This is not only beneficial for computer-related systems, combined with a calendar the baseline can be used for calibration and preventative maintenance.
Figure 2 Logical view of several configurations held in several baseline documents.
Used properly, the baseline can be one of the most important tools for tracking system changes. The debate during an inspection will shift from how a system looked before and after a specific change, to the deeper and more profound questions about how many minor changes makes a major change, and was the change corrective, adaptive or perfective, but these matters are beyond the scope of this article.3
Christian Stage is director of QA product development at QAtor, Denmark.
1. www.fda.gov/bbs/topics/news/2004/new01102.html
2. PDA Technical Report No. 18, Validation and Qualification of Computerized Laboratory Data Acquisition Systems, 1995.
3. US Food and Drug Administration, 21 CFR Part 211 — Current Good Manufacturing Practice Regulation for Finished Pharmaceuticals (2005) www.fda.gov/cder/dmpq/cgmpregs.htm
4. US Food and Drug Administration, General Principles of Software Validation; Final Guidance for Industry and FDA (2002) www.fda.gov/cdrh/comp/guidance/938.pdf
5. C. Stage, Pharm. Technol. Eur. 17(10), 18–22 (2005).
Related Content: