This is an excerpt from the September/October 2013 issue of InTech magazine by Harmik Begi, Gregory Bischoff and Josh Gangl of Amgen. To read the full article, please see the link at the bottom of this post.

With the historical success of blockbuster products, the biopharmaceutical industry has required large manufacturing capacity with single-product facilities built to produce large volumes of a single blockbuster drug. More recently, however, with the changing business and regulatory environment, facilities have to be more flexible and capable of producing multiple products. They need to have shorter production campaigns, facilitate faster changeovers, and concurrently manufacture different products to meet the more diversified pipeline demand of small volume productions.

Furthermore, balancing capacity and efficiency across an organization’s manufacturing network, as well as producing clinical and commercial batches in the same facility for faster time to market, has introduced additional dimensions of flexibility. Therefore many single-product facilities have been converted to multiproduct use, and innovative companies have been leading the charge on flexibility.

Single-to-multiproduct continuum

As the industry transitions toward multiproduct and multipurpose manufacturing facilities, one major challenge lies in how to change the facilities built for a specific product. For discussion purposes, the following generalities about the manufacturing facilities can be made.

• Drug substance – trending away from single-product facilities
• Commercial facilities – one to six products per year, increasing with a shift to include clinical products (i.e., products meant for clinical trials)
• Stand-alone clinical facilities – five to 12 products per year, not including multiple variants or processes for some products
• Process development – 10 to 15 products per year, comprised of technical development and production support/investigation runs per product
• Fill finish (drug product) – typically multiproduct, but may have dedicated lines depending on final delivery medium or other factors

Manufacturing automation implications

Multiproduct facilities require flexible automation. Flexibility is measured in many ways and applies to all aspects of the automation system, including the batch software design and physical architecture. Ultimately, the measure of flexibility is cost of change. Higher cost of change is driven by increased complexity. Complex changes have higher resource demand, require more time, and inherently bring increased risk to existing operations. Therefore, a less flexible automation is less adaptable to multiple products.

Differing industries drive the types of change that are required between products; it is important to recognize how different products affect the automation platform. With biopharmaceutical processing, products rarely leverage all the existing process functionality and equipment, many times driving process or equipment changes between products. Therefore an adaptable automation system is a key factor in meeting the flexibility demands of the business.

The ISA-88 batch standard lays out a framework to meet multiproduct demands. It defines modular levels of a software structure for batch processes. It is cardinal not just to embrace the software structure outlined by the standard, but accurately defining (or "right sizing") where and how control is accomplished across the defined layers ultimately leads to meeting the flexibility demands.

Design best practices

The practices below are central principles of the central multiproduct goal: future new product introductions (NPIs) require only recipe changes.

Dedicated recipe(s) and corresponding documentation for each product-this gives the most flexibility, particularly in the more complex automated unit operations in the facility. It establishes a clean framework on a per product basis for all of the stages in the product's life cycle (see figure 2), as well as subsequent NPIs.

• Caveat: strive for common cleaning (clean in place [CIP]) and steaming (steaming in place [SIP]) recipes, when required for the equipment. This allows a simplified recipe design, particularly because CIP and SIP can essentially be treated like any other utility provided the end points are achieved. This model may require cleaning and sterilizing to the "worst-case product" when there are differing product requirements.

Simplify recipe variables and product changeover processes (i.e., recipe parameters/formulas)-minimize the number of variables, provide good context/naming for each of them, or provide an automated changeover process/recipe to avoid mistakes and ultimately to ensure product quality and data integrity.

Balance phase size and complexity according to process steps-a batch architecture best practice. Some facilities have very long and complex process-based phases, so struggle with how to simplify and drive complexities to the appropriate realm without affecting current validation and process steps. Another ideal is to reduce complexities such that day-to-day, or product-to-product, operations staff members do not require deep understanding of the batch configuration to achieve streamlined NPIs.

Good ISA-88 and operational design-ISA-88 by design is a much-needed framework and parameterization concept for batch processing across all industries, and as such is not overly prescriptive in the biopharmaceutical manufacturing space. One of the key enablers for many facilities and projects is an additional abstraction layer concept to be applied to the software framework. See figure 3 for a pictorial representation of the following layers.

• Product and operational specifics are handled in the recipe layers (e.g., product X requires five flush steps, where product Z requires 10).
• Process design aspects are primarily handled by the phase classes. This should focus on the individual process steps that a unit operation must execute to manufacture a product (e.g., transfer in, CIP).
• Equipment specifics are handled in the equipment module and control module layer (e.g., skids A and B differ by five valves).
• Class-based, or object-oriented, design can give huge time and cost savings at all layers of software configuration. Be careful not to take the concept too far (e.g., higher-level entities, such as phase classes, may be best dedicated to specific unit classes), which can significantly affect regression testing and implementation through the life cycle of the facility.
  • Hold, stop, abort logic should be common to an entire unit class, when possible, as there are typically only minor differences between each for an individual unit module.
   
• Flexibility for unit-to-unit transfers and communications is often overlooked until too late in project delivery. Complexities can plague a facility. A standardized and streamlined method can significantly reduce complexity and architectural constraints observed from disparate methods.

Iterate operational requirements into design, within the above frameworks.

• Considerations include: What does a recipe mean to operations? Will the facility be running at the procedure level? Are there campaigns and manufacturing execution system (MES) integration? Does the facility require more flexibility at the expense of consistency and elimination of human error? These questions need to be answered earlier than traditionally done, or the operational and manual impacts are significant for the resulting batch/code architecture (complex work orders and standard operating procedures [SOPs]), the true cost impact of which is difficult to characterize without years of running the facility and subsequent NPIs.

Provide product context for operations at all times. How does an operator know what is in each vessel? What is the state of each vessel or line (clean, dirty, sterilized, etc.)? This can be as simple as human-machine interface (HMI) design, but can also include manual or even electronic signage from the control system. Security can also be a challenge, especially with portability becoming more prevalent.

Economics and project comparison

The following observations can be made from multiproduct conversion projects.

• Transitioning from one to two specific products is very expensive (NPI).
• Adding additional products may get cheaper, but may remain costly if initial practices/systems/testing are not improved.
  • Organizations need to accelerate the shift to an overall multiproduct model as soon as possible.
   
• Regression testing-testing to verify changes do not affect the validated state and product quality for products already being manufactured.
  • Varies by design and can be costly-typically cannot fully test, so a risk-based approach is paramount. Sometimes companies have to live with the risk, which puts a burden on the automation and engineering staff to prevent loss of product.
  • Risk assessments become paramount, and may span areas previously not considered.
  • Offline simulation is a potential enabler in this space, provided a realistic process model is developed and maintained.
   
• Relative automation costs are primarily driven by necessary equipment additions for new products (e.g., adding a centrifuge that was not required for the initial product).
• Product changeover-planned campaign changeover from one product to the next (e.g., Product A to Product B and back to Product A).
• Plant and equipment downtime is expensive (labor and opportunity costs).
• Project comparison-following the principles outlined in this article has been demonstrated to significantly reduce costs on subsequent NPIs over time. Figure 4 shows the relative bulk NPI cost avoidances observed as a facility advances from the initial NPI to subsequent NPIs, with a 50 percent savings observed for the third additional product.

Additional challenges to consider

In addition to the best practices outlined previously, the following challenges need to be considered. Concurrent production considerations:

• How do operations people know which product is being run on every piece of equipment? How do you ensure the correct manufacturing procedures are being followed? It is a challenge to ensure signage, HMIs, and manufacturing procedures are accurate and always understood for every product and context. Equipment-use records and integration with other systems, such as MES, are also a consideration, but are beyond the scope of this article.
• NPI in facilities running both clinical and commercial products-differing product characterization, tech transfer, and timelines typically need more flexibility for clinical, yet often timelines are accelerated.

Develop a plan for maintaining per product recipes when making many products over time.

• Product reintroduction and obsolescence-all configurable code and related documentation need to be maintained over time. Some facilities have hundreds of old product recipes in unknown condition. Facilities need a formalized approach and continued oversight and management of the life-cycle areas depicted in figure 2.

Develop a plan for how to handle product-specific parameters. Sometimes many parameters are necessary.

• Recipe parameters, product specific tuning, etc.-does this belong as a formula, a changeover recipe, or something stored in the continuous realm? There are no easy answers. Much of this can be designed into the configurable software or via the functionality of the process control system, but these aspects need to be considered early and throughout the design process.

Balance process phase size and content.

• Flexibility is required for multiproduct production, so distill these down to basic process functions-e.g., rather than one large process-phase chromatography step, develop much smaller and more nimble process steps: bind, elute, etc. Be careful about balance here-if you go too small, or lose the ideal that phases should be process-focused rather than equipment-focused, the recipe layers increase in complexity significantly. Therefore the balance is to break phases down into the most reasonable process steps that neither includes specific equipment details nor product specifics. Facilities that do not accomplish this will typically be plagued with various operational and automation issues for the remainder of the process control system's life.

Naming conventions need to be reconsidered and standardized. Product names should be confined to recipes (if a product name is embedded deeper, there will be confusion or worse). Equipment should not be named with any product context (no more "Protein A" naming, as the device may have more than that single purpose).

Lessons learned and applied practices

The following are additional lessons learned and applied practices of some of the design best practices and ideals outlined previously.

• Simplify phase and recipe code as much as is practical.
• Naming should be equipment specific, not current process or product (e.g., Chrom Skid 1605 rather than Protein A Chrom Skid).
  • Do not be afraid to break phase classes at unit boundaries. Sometimes the desire of an automation engineer or team is to reduce to as few classes as possible. While there are some benefits to this, unless the design is perfect, it may limit the flexibility needed at a later date and may force regression testing in unanticipated areas.
    • In some cases, it makes sense to break classes to reduce complexity or allow flexibility.
    • Engineering balance-a strong batch lead should be given the opportunity to partner with the unit operation process engineers to balance such things as early in the design as possible.
     
   
• Simplify shared equipment where possible.
  • Does CIP need to be batch based, or can it be treated more like a utility? This is sometimes driven by process or equipment design, but the trend is toward driving these complexities down in the control layer and making them very simple requests from the batch equipment.
   

Greenfield multiproduct facilities

New facilities typically are not being purpose-built for single dedicated products today, and therefore would be best served by considering the aspects and lessons learned in converting from single-product to multiproduct facilities presented in the sections above. From a high level, it would be in the best interest of greenfield facilities to:

• build and design with multiproduct philosophies, and consider them for nearly every decision made
• consider operational philosophies very early and throughout the design process to get the right balance for the software/batch architecture
• engage packaged skid and original equipment manufacturers early in the design process so they are following multiproduct principles that align with the facility's operational needs

Process technologies advancement

A key consideration in bioprocess facilities is the advancement of process technologies and their impact on automation and the overarching driver of enabling multiproduct capability. Multiple advances have driven these changes, including single-use technology and the concentrations of product produced at a given equipment scale. Both affect automation and need to be considered as facilities aim for multiproduct production.

Single-use technology performs process operations in disposable materials, i.e., sterilized bags and tubing. This eliminates the automated cleaning and steaming that is typically highly automated and often complex. Therefore, a simplification of the recipe structure is derived. The process operations still require thoughtful design between the equipment/process/product layers of the batch design-this aspect does not change.

Other paradigm challenges that arise with single-use technology are the operational models that play a key role in the automation recipe design. For example, with the high involvement of operations personnel establishing and monitoring unit-to-unit pathways via tubing, the batch design is simplified in some ways.

With higher concentrations of product material, equipment scales are reduced. It may no longer be necessary to use 20,000-liter tanks; 2,000 liters may suffice. As equipment size is reduced, a facility's ability to move or replace equipment becomes more achievable, driving an equipment portability requirement. While batch recipe design is rather agnostic to equipment scale or location, automation architecture will be affected. The ability to move or replace equipment is a consideration for the automation architecture. This drives controller software segmentation, controller locations, and I/O strategies (including bus technologies). An automation architecture that can accommodate equipment change with minimal burden will better adapt to multiproduct, where equipment changes are typical.

Drug product/fill finish

Drug product facilities are typically built for multiple products, but may have dedicated lines depending on the final drug delivery medium or other disparate dosing and packaging requirements. In either case, many of the drug substance manufacturing automation practices discussed above translate directly to the design of fill finish facilities. They provide the flexibility demonstrated by industry trends to be more nimble, flexible, and cost effective in introducing new products.

Additional trends underscore that similar pressures and requirements are being seen in fill finish facilities, with vials and syringes now being filled in the same lines. As original equipment manufacturers (OEMs) are typically more prevalent in this space, OEMs would benefit by adopting parameterized batch logic and other frameworks provided by ISA-88 and the practices highlighted above.

The evolution of the biopharmaceutical industry has necessitated the conversion of many facilities to multiproduct manufacturing. Automation is a key enabler for a facility to achieve multiproduct flexible operations. The best practices and considerations outlined in this article are a framework to make the transformation to or the initial establishment of multiproduct operations in the most cost-effective manner.

About the Authors
Harmik Begi, director of information systems at Amgen, has more than 22 years of experience in the biopharmaceutical and food/beverage industries.

Gregory Bischoff, principal IS automation engineer at Amgen, has 20 years of automation experience and is responsible for delivering the automation work stream for large-scale capital projects in a corporate role.

Josh Gangl, operations IS platform lead at Amgen, has more than 15 years of process engineering, process automation, and manufacturing information systems experience.