A VALID PRESCRIPTION
7 Apr 2000
As the pharmaceutical industry becomes more competitive and manufacturers are striving to reduce costs and increase efficiency, the use of computer systems is increasing both at the manufacturing level (PLC & DCS systems) and at the corporate level with business system (ERP) installations.
At the manufacturing level the computer systems are designed for a relatively `local' set of requirements. In comparison the requirements for a corporate business system can take on a truly `global' nature with a far greater degree of complexity.
Companies using computer systems for manufacturing and business operations must be able to demonstrate current Good Manufacturing Practice (cGMP) to the regulatory authorities and comply with regulations such as the US Federal regulations on electronic records or signatures, and the EU directive 91/356/EEC2.
To achieve compliance the computer system needs validating, a process which has been defined by the US Food and Drug Administration (FDA) as `establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes.' This is a complex procedure for any system, but pharmaceutical warehouses have layers of complexity within their business systems which call for particular methods and systems for validation.
Warehouse operation
At first sight the computer system automation of a warehouse within a pharmaceutical manufacturer or distributor does not appear to be crucial or incredibly exciting. In a wider perspective, however, it is one of the most critical areas. If a cGMP problem does occur, the warehouse can have a significant impact on the whole or major part of the business.
For example, imagine two manufacturing sites, each with three production lines, which send products to a single warehouse and distribution centre. A cGMP failure on a single production line will only affect its associated product. However, if a cGMP failure occurs at the warehouse this could have an effect on all of the production lines at both sites. It also brings into question the cGMP status of product which is in, or has passed through, the warehouse and results in a financial penalty or product recall.
Specific to warehouse and business system implementations, is the concept of system cut-over. This is the instance when control is passed from an `old' system to a `new' system. Many months can be spent in preparation for this event, although it may take only a day or two to execute the cut-over and transfer data such as stock quantity, warehouse location, shelf life, batch history and expiry date to the new system.
However, once cut-over has been completed and the warehouse has become operational, it can be difficult and sometimes almost impossible to revert back to the `old' system if severe problems are found with the `new' system. Therefore, it is critical that a pharmaceutical warehousing system is correctly validated prior to cut-over and the new system going live.
Each pharmaceutical manufacturer or distributor executes similar functions to run their businesses, although the processes within each function vary. As a result virtually all of the business systems installed to a greater or lesser extent are made up of `bespoke' elements within standard systems, thus increasing the challenge of validation.
Various software elements are incorporated into warehouse business systems, some of which are standard and some of which are bespoke software. Examples of these include server operating system, application software & modules; PC operating system and application software; and barcode scanner and printer software.
Each software system or program must be assessed against the good automated manufacturing practice (GAMP) guidelines for software categories, to determine the level of validation required to ensure cGMP compliance. Bespoke systems are classified as GAMP category 5 (the most complex), and require the highest level of validation.
On the surface, warehouse operation is a simple matter of goods in, goods out. In reality it is very complex. Several functions need to be addressed for validation, including corporate to warehouse systems interfaces; warehouse to corporate systems interfaces; inter-site transfers; stock maintenance and stock counting.
GMP assessment
A GMP assessment should be held to determine which business functions and software applications are subject to cGMP regulations and thus require validating. A multi-disciplined review team is a vital component of a successful validation. A suggested team would comprise a review facilitator, validation expert, warehouse manager/system owner, QA manager, IT specialist and warehouse system provider.
The first step is to identify the cGMP issues that are potentially impacted by the use of warehouse business systems, such as lot traceability records, product shelf life, storage conditions, goods in inspection and quality status. The second step considers the threat to cGMP arising from the warehouse's business processes, its supporting functional behaviours, system interfaces with other computer systems and the physical and software platform that supports it.
Each of these are assessed for cGMP criticality by using the system design documentation. This assessment should be executed in a logical way, such as following the business processes sectional references in the URS. This ensures that all items can be assessed and allows the GMP criticality to be traced through to validation, including installation qualification (IQ) or operational qualification (OQ).
The results of the assessment should be tabulated as `cGMP critical', `Not cGMP critical', or `Outside the validation scope'. This last case arises when the function concerned is delivered through an existing system that is already validated and is not changed by this project. Where an element is identified as `Not cGMP critical' it is essential to document why this is the case.
As described earlier, computerised warehouse business systems are very complicated, especially when interfacing with external systems. This complexity can increase if the new installation upgrades or replaces an existing system, since existing live data must be transferred at cut-over.
In general there are three categories of data required for the operation of a warehouse business system: static data, loaded into the system prior to start up, which is not expected to change over time; master data, which can change over time but typically by addition of records rather than changes to existing records; and dynamic data, which frequently change over time and can be seen as `real time data', such as stock quantities and transactions.
Each data file identified as GMP critical must be uploaded into the new warehouse business system. The upload of the data files should be phased, which allows commissioning and testing of the warehouse system to follow a logical schedule. For example, the static data should be uploaded before installation qualification commences.
Once the data has been uploaded it needs to be verified as correct. This can be a significant task, as the data files can contain thousands of records. The methods used reflect the scale of the task. For a small datafile documentary, for example, it may be acceptable to verify data by cross-checking, whereas on very large files, an electronic automatic upload process could be used.
Going live
Having completed the IQ and OQ, the warehouse business system should then be prepared to go live. Because of the finality of a business system cut-over, we have introduced the business system specific `cut-over' qualification (CQ) - a process that provides a high degree of confidence that the warehouse system will be successful when it goes live. This qualification includes ensuring all validation documentation, protocols and reports are reviewed and approved where required, all cGMP critical recommended actions are resolved and systems are in place to monitor the performance of the warehouse business systems during the performance qualification (PQ).
This PQ, approximately three months after the system goes live, consists of functional tests and visual inspections that demonstrate the correct performance of the warehouse system. During the PQ phase, evidence is collated to demonstrate the performance of the warehouse system. At the end of the PQ phase, members of the warehouse validation team review the evidence collated and complete the associated PQ test scripts.
Once the PQ is complete, the warehouse system validation report can then be produced. This provides a detailed summary of the validation activity as a whole and can be presented to the regulatory authorities as required.
For the validation to be completed successfully there must be effective communication within and between the client, system supplier and validation experts. As each of these parties use many internal functions, there can be many personnel working on the validation exercise. Communication must be frequent, consistent and allow for two- or three-way dialogue. The success of the validation exercise ultimately depends on the commitment, mutual trust and professional integrity of all parties involved. PE
David Thompson is a validation consultant with Eutech