PAT slaps pharmas with control system aftershave

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).