PAT slaps pharmas with control system aftershave

Though users in other process industries have seen it coming for years, Process Analytical Technology (PAT) is now bringing similar improvements and benefits to many pharmaceutical applications.

Share Print Related RSS
By Velumani (Lou) A. Pillai and Martin Warman, Pfizer Corp.

HEY, HEY! The control system train has pulled into the pharmaceutical station! All aboard! Though PAT most directly applies to pharmaceuticals, its effects will be felt in other industries regulated by the U.S. Food and Drug Administration (FDA), such as food and beverage, as the FDA tightens its regulatory grip to include all ingestible products.

PAT’s benefits included reduced production cycle times, improved manufacturing efficiency, reduced rejects, and increased production uptime. PAT can also speed time to market for new products, improve operator safety, and improve relationships with regulatory agencies.

Encouraged by the FDA, the pharmaceutical industry is seeking to accelerate its manufacturing innovations. While it continues to spend on research and marketing, the pharmaceutical industry lags behind other automated process industries in manufacturing productivity.

     FIGURE 1: PAT MODE: MONITOR

In the second paradigm, “Control” the CQA are monitored and controlled to limit or manage process variance within the design space and to ensure end product quality. The PAT software usually will be interfaced to Process Control Systems (PCS) that perform this control. (Click chart to enlarge)


To improve productivity, there is growing enthusiasm in pharmaceuticals for PAT, an FDA initiative to improve manufacturing efficiency and product quality, while also harmonizing regulatory expectations. PAT provides a framework for designing, analyzing, and controlling manufacturing. The PAT initiative focuses on the principles of building quality into products and processes, as well as continuous process improvement.

New century, new hope
Historically, innovation in pharmaceutical manufacturing was largely constrained by regulatory uncertainty. With the subsequent launch of its GMPs for 21st Century initiative, the FDA began calling for innovative approaches for process development, manufacturing, and quality assurance (QA). This was a paradigm shift that required quality to be designed in and not tested into products. Designing quality into products requires a comprehensive understanding of the process, including the impact of product components on process variability, along with mechanisms to manage the process.

Continuous improvement is a critical element in a sound quality system. The FDA expects pharmaceutical manufacturers to implement continuous improvement through the PAT framework. In addition to continuous improvement, the PAT framework also encompasses risk assessment, knowledge management, and on-line analysis.

Though the FDA published guidance on Pharmaceutical cGMP’s for the 21st century to enable innovation and continuous improvement, specific GMP regulations have not yet changed. Despite this delay, the FDA is providing science and risk-based guidance related to GMPs.

FIGURE 2: PAT MODE: CONTROL    
In the third PAT paradigm, “optimization”, the process variance is reduced and process capability optimized by running controlled Design of Experiments (DoE) on the CQA’s. CQA’s can be predicted based on history and performance of the process using a set of relationships that have been modeled using mathematical models (set of equations).  The predictions can be made available to the PCS’s for timely control. (Click chart to enlarge)

Consequently, PAT will help pharmaceutical manufacturers design, monitor, control, and predict process performance. Many of these functions are now implemented separately, but PAT promotes an integrated environment that combines modeling tools for design/analysis, process analyzers, and process control/optimization. Knowledge of all these functions is required to efficiently apply these technological innovations to pharmaceutical manufacturing.

So, how do we in the pharmaceutical and other regulated industries implement PAT successfully? How do we hop on the control system train?

We must first bridge several gaps in existing infrastructure and control system architectures. This article presents a strategic framework for managing this transition effectively. We also identify a new standard PAT software platform that will supplement and improve existing control system architectures.

PAT monitors, controls, optimizes
The most basic implementation of PAT is process monitoring. This involves monitoring critical-to-quality (CQAs) variables to build process knowledge, establish process variance, and set the design space in which the product is robust (See Figure 1 above).

The next level up in PAT implementation adds control to the basic process monitoring functions. CQAs are now monitored and controlled to limit or manage process variance in the design space to ensure product quality. PAT software must be interfaced (See Figure 2 below) to a process control system (PCS) that performs real-time control.

The highest level PAT implementation adds optimization to the monitoring and control functions (See Figure 3 below). Optimization reduces process variance and optimizes process capability by running controlled “Design of Experiments” on the CQAs.

     FIGURE 3: PAT MODE OPTIMIZE

Optimization reduces process variance and optimizes process capability by running controlled “Design of Experiments” on the CQAs.
(Click chart to enlarge)
 

CQAs can be predicted based on history and the performance of the process by using a set of relationships that have been created with mathematical models. These predictions can be made available to the PCS for timely control.

PAT standardization fights complexity
A typical PAT System incorporating monitoring, control and optimization (See Figure 4 below) needs to acquire data, control the process, run prediction models, and display results. This implementation is easy to handle with one instrument, but grows exponentially more complex in typical applications with hundreds or even thousands of sensors and analyzers. Each instrument has its own process and instrument configuration, data modeling, method builder, and data analysis capability.


FIGURE 4: PAT SYSTEM BLOCK DIAGRAM

(Click chart to enlarge)


MOST PHARMACEUTICAL processes are multivariate, which means multiple process measurements are needed to characterize a process, adding yet more inputs to the quality system. The system also needs to function at different levels of compliance: Development, during PAT application development; Information, during PAT application optimization; and Release, during PAT application execution.

One of the main problems is that each instrument vendor offers its own proprietary software, resulting in unique PAT applications. This situation was tolerable in PAT’s infancy, but in future PAT applications this proprietary model won’t work.

As PAT applications proliferate, implementations with custom interfaces, point-to-point interfaces, custom modelers, and PAT data islands will be unwieldy. To aid multi-factorial analysis, it’s imperative that PAT applications interoperate in the control and modeling space.

Because of this need for an integrated environment, we propose that a PAT software standard be established. This software standard should include a standard user interface to setup and run instruments, a common modeling environment, and one environment to build and configure analyzers. It should also include bi-directional communications with PAT data storage systems.

Availability of a PAT software standard could help end-users develop and deploy new measurements by:

  • Reducing validation costs for PAT devices
  • Minimizing deployment time for PAT technology
  • Improving PAT system robustness
  • Reducing custom interface code
  • Providing flexibility to repurpose PAT devices based on evolving needs; and
  • Improving scalability and extensibility

Common PAT software architecture
A functional map implementing a PAT software standard (See Figure 5 below) shows the Instrument and Sensor Interface has a common interface for all process sensors, analyzers, and instruments. The control, operation, analysis, retrieval and prediction functions all use the PAT Common User Interface. During on-line operation, the user interface provides access to select appropriate methods, and generates results from predictions versus time.

The interface also reports status of prediction alarms and instrument alarms with appropriate alarm management functions. In off-line mode, the interface provides access to the method builder, PCS configuration, and Design of Experiments setup.

The user interface manages the PAT hardware configuration, and performs analyzer calibration functions. Any data retrieval from data storage takes place through the interface.


FIGURE 5: 

(Click chart to enlarge)


Building PAT methods
To acquire, process, and execute real-time predictions, a PAT method needs to be created. This is usually created off-line and executed on-line in real-time. The method builder controls active modules, and adjusts integration time, exposure time, and signal gain or amplification. It also handles summations or averages of each data acquisition to generate a spectrum.

Once the analytical information is generated, the method acts on this information via various mathematical pre-treatments and prediction engines. The traditional approach uses quantitative models. Single or multivariate models generate calibration models, real-time analytical data, and predictions.

However, the need to generate these values is driven more by perception than necessity. This is changing and qualitative and trend models are now widespread, inspiring the term “process signature.”

All data should be stored in a way that’s easy to access for analysis. Raw data files should be converted to a standard format such as Analytical Information Mark-Up (AniML, ASTM E13.15).

Events and context-based process data from other sources also should be available. Data storage must handle structured and unstructured information. Implementations can include existing data storage mechanisms, but these may need to be scaled and extended to new types of information. This data storage can be integral to the PAT software or it can be a part of a common data repository.

How do we get there from here?
Creating a PAT software standard will require committed suppliers and end-users working together. We anticipate that common functions will be identified first, and that products will then emerge. We also propose that end-users take advantage of standard PAT software when it’s available.

The first step is to standardize complex measurements. Spectroscopy methods are routinely adapted for PAT. Examples are near infra-red (NIR), Raman, UV-visible, fluorescence, and acoustic. Measurement technologies suitable for pharmaceutical needs must be identified. This will help suppliers meet implementation challenges and simplify deployment.

Presently, we spend a lot of time specifying a measurement for a process application. We would like to see standards created that will reduce required time, and make time commitments more predictable.

In the most advanced implementations, PAT systems are used for monitoring, control, and prediction. In these cases, data needs to be exchanged with systems that perform analysis, control, decision making, and reporting. A good first step for data exchange in advanced implementations is to create standard ways of trading data across existing systems.

Control system architecture impacts
We’ve heard about several efforts to build master plans for deploying innovative measurement technologies. Most are done in isolation without considering effects on control system architecture, existing applications and infrastructure needs. However, any master planning effort has to consider these impacts.

The master planning effort must align strategies and derive specific objectives for infrastructure, applications, integration, and PAT systems. To do this effectively, all functions must be mapped to domains. New functions, such as process optimization and process improvement, should be considered.

For each of these functions, impacts on level and approach to automation must be considered. This master planning exercise will help end users understand their business’ readiness to embrace continuous improvement outlined in the PAT framework.

We all have to deal with existing systems and infrastructure, even when creating PAT software standards. We’ll have to exchange data with existing systems for process control, enterprise resource planning, laboratory information management, and manufacturing execution. A unified schema is critical to facilitate data exchange among these platforms.

Several organizations have developed schemas focusing on standard data related to functions of relevance. These include Analytical information Markup Language (AniML), Batch Manufacturing Language (BatchML), and Business to Manufacturing Markup Language (B2MML). While these schemas have been around for awhile, corporate schemas must be developed to use them effectively. Schema validation services for the entire pharmaceutical industry also will be required to support new PAT software standards.

To facilitate pharmaceutical manufacturing process improvement and innovation, application architectures bow geared to corrective action must instead focus on continuous improvement. Current application architecture domain models must evolve to address continuous improvement.

    

REASONS FOR IMPLEMENTING PAT

1.  Reduce production cycle times
2.  Increase uptime
3.  Speed time to market for new products
4.  Reduce rejects, scrap, and re-processing
5.  Improve operator safety
6.  Improve relationships with regulatory agencies

For risk analysis and mitigation, the root cause of all deviations must be ascertained, so all deviations aren’t treated equally. For process design, it’s necessary to use measurements to determine what’s critical to quality using design of experiments and correlations.

Process understanding requires that knowledge about the process be available for easier analysis. These considerations require revisiting accepted application architectures that support only procedural compliance.


  About the Authors
Velumani (Lou) A. Pillai is senior manager/team leader for Drug Product Integrated Automation Solutions with Pfizer Global Manufacturing -- IT.  He is working on developing standards, and global IT programs to support widespread adoption of Pfizer’s Right First Time Initiative including Process Analytical Technologies. Martin Warman is senior manager/team leader with Pfizer Global Manufacturing’s Process Analytical Support Group, Global Technology. He leads the team responsible for developing and rolling out standardized PAT systems to support Pfizer’s Right First Time Initiative.
Share Print Reprints Permissions

What are your comments?

You cannot post comments until you have logged in. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments