Good Automated Manufacturing Practice (GAMP) is now in the 5th edition as a published standard by the International Society for Pharmaceutical Engineering (ISPE).  Starting in 1989 (GAMP 1)  GAMP-1 webas a simple “V” model where the development of the system documentation has a counterpart in the qualification stage, GAMP has progressed commensurate with the development of automated systems in the last 15 to 20 years.  Back in those times, computer systems had defined if not limited specific duties such as a building automation system that controlled temperature and humidity or small controller on a process skid.  With advances in processor capabilities coupled with the explosion in the capacity of memory at decreasing prices - we find more things for computers to do.  GAMP 5 was developed to recognize the trend to multifunctional automation systems such as the building automation system also acting as a batch record data storage and management system and a calibration manager.  There is also an emphasis on the the increasing burden of the life cycle management of these systems.  15 or 20 years ago, high-end computer systems were being installed with virtually “no expense spared” efforts by the top pharmaceutical companies because it was easier to err on the err on the side of added capability than to leave something out that may be the target of an FDA 483 observation, or worse a warning letter.  Today, those efforts have left a legacy where the ongoing cost to maintain change control and revalidation for systems or their components that may not directly affect the drug chemical profile have become a large burden.  Coupled with the public pressure to enhance patient safety, product quality and data integrity is a real industry need to control cost.  Cost control comes in the form of:

  • Avoiding duplication in the documentation effort - specifically in the transfer of information from engineering and construction efforts to operation and maintenance efforts
  • Maximize the value of supplier activities - perform as much qualification as possible at the supplier’s facilities so that corrections can be made before the system is delivered on site and errors force unforeseen and expensive deployment delays
  • Perform a risk analysis for systems to quantitatively determine exposure through a numerical assessment system that allows appropriate and defendable decisions to be made on the level and extent of the qualification study so that such systems can pass an FDA or third party audit.
  • Use as much configurable software as possible. If little or no custom code is used, control of life cycle cost is greatly enhanced
  • With added complexity comes the need for adaptive development models.  If the traditional linear development model doesn’t fit a particular application, then a different model that addresses the specific needs of a project needs to be implemented

Our Approach

In 1993 a project for the deployment of a Distributed Control System (DCS) for a major pharmaceutical company was underway.  As with any project that of this magnitude and scope - complete replacement of the plant-wide automation system - unforeseen delays and expense are encountered.  It became apparent to the people implementing the project that in order to get back on schedule and reduce shutdown effects, a comprehensive information retrieval system was needed.  A significant delay in the development of the design documentation was the fact that similar if not nearly duplicate information existed in various reports, drawings and functional specifications.  Keeping all of the information aligned between the different presentations was a full time job requiring many hours of investigation into what information was current and what information was old.  It was decided that a database holding the current information was the way to solve the problem with reports from that database becoming the vehicle of the current information.  This data was needed not only by the constructors, but also the team that was configuring the software and the team responsible for validation.  Database Relationship1Common elements exist between the various operating database tables in a DCS.  The data that is held in these tables originates in the engineering design effort that defines the system operating parameters.  It all starts with a point list which provides basic information such as the logical point name, engineering units and the system where this unique point name lives.  Functions required by the DCS system include the Graphics Database where the system information is displayed in graphical form for easy user interface to the control system.  Also of importance is the trend database where the point value history is stored - vitally important if the system is to be used as a batch record historian.  In addition to the need for the information loaded into the DCS is also the need for the qualification of the system and the information must match between the DCS database and the validation data to be used to qualify the system.  Every piece of information must be correct or an exception report and correction process must be undertaken to rectify the problem(s) before the system can be accepted - resulting in delays and expense. 

The relationship of the project tables is important to ensure that information is correct across the project platform and this then becomes the Database Structure 1basis of the operation and maintenance system.  The box at the top of the diagram represents the location where the data is stored.  For Part 11 compliance, this must be a database engine that has change control capability.  The sub boxes represent reports from the database that have uses by various entities that make up the parts of a cross functional team often found in a pharmaceutical deployment project.  The Input/Output Assignments are of interest to the system configuration team and is used to load the operating database in the DCS.  The Sequence of Operation is also of interest to the configuration team but also the qualification team as part of their operational qualification for the system.  The Instrument Data is of interest to the construction team as they need to know what to purchase, but also to the qualification team for the Installation Qualification activities.  Eventually this information passes to the O&M staff who will take over the instrument calibration duties and eventual replacement under a like-for-like program.  The Drawing list is helpful for project management to track design progress as well as being the cross reference between the instrument list and where that instrument’s unique tag name is found on a Process and Instrumentation Diagram (P&ID).  This information is also necessary for development of the qualification protocols.

As the project progresses, more information is needed from the databaseDatabase Structure 2 to advance the project to completion.  Most of this information will be needed by the constructor, but this information is also useful to the qualification team who will be busy with finalizing qualification protocols during this stage.  The Wire Tag List can actually print the wiring labels found on each cable in control panels - one of the items to be checked under an Installation Qualification (IQ) effort aimed at verifying proper labeling.  In this instance, several opportunities for error have been eliminated between the wire schedules, wire labels and the IQ protocol.  This is the basis for the changes in GAMP 5.  The step for Instrumentation Calibration is critical due to the use of the system in a cGMP environment.  Obviously the system must be turned over with calibrated instrumentation, but the data can be ported over to a third party calibration management system that will need the Instrument Data as well as the calibration history and values.

Finally the project progresses to the qualification stage.  In many pharmaceutical projects, this is the stage where unforeseen delays can become particularly acute.  For the 1993 project, this approach put the Database Structure 3project back on schedule.  For another project, for another pharmaceutical company, the results were more dramatic.  An entire year was saved (ISPEAK, 1999) in the normal time it takes to develop the space to manufacture Phase II and Phase III clinical materials.  This was a project that had a short “fast-track” timeline and the database approach was the key to meeting the deliverable deadlines.  This is where the project can take on a full transition to the operational staff.  It is desirable to have the operations staff attend the qualification activities and perhaps participate in some of these activities - this has been some of the best training for people who have not been involved in the project on a day-to-day basis as a way to enhance acceptance of the project and lower total life cycle costs.  This is another major tenant in GAMP 5.

Copyright 2013 The Pivotal Point Group, LLC