Control Strategy: A Feedback-Feedforward ‘Controls Hub’ for Risk, Knowledge, and Product Lifecycle Management

woods block step on table with icon Action plan, Goal and target, success and business target concept, project management, company strategy | ©Smile Studio AP - stock.adobe.com

Control is the ability to direct, regulate, limit, or manage something. For a pharmaceutical product, that something is product quality. It is essential that the required quality of a pharmaceutical product is clearly specified and produced consistently for every unit of medicine, in every single batch manufactured.

The International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use (ICH) defines product lifecycle as “All phases in the life of a product from the initial development through marketing until the product’s discontinuation,” in ICH Q8(R2), Pharmaceutical Development (1), and laid out the following three primary objectives throughout the product lifecycle in ICH Q10, Pharmaceutical Quality System (2):

• Achieve product realization (i.e., deliver products with the quality attributes appropriate to meet the needs of patients, health care professionals, regulatory authorities, and internal customers).
• Establish and maintain a state of control (i.e., use effective monitoring and control systems for process performance and product quality, thereby providing
  assurance of continued suitability and capability of processes).
• Drive continual improvement (i.e., implement appropriate product quality and process improvements, variability reduction, innovations and PQS enhancements, thereby increasing the ability to fulfill quality needs consistently).

The concept of product lifecycle management implies that it is dynamic and must be directed, regulated, and managed—or in other words—controlled as product and process understanding (knowledge) evolves. This is illustrated in Figure 1 and explained further in the sections that follow.

Figure 1. The life of a product is dynamic. (Figure courtesy of the author)

A control strategy is expected to provide the overall basis for consistently directing and managing key elements necessary to deliver the specified and required quality of a product. These elements are not only directly related to the product, but also have important interdependencies with enabling infrastructure (i.e., facilities, equipment, materials, processes, test methods, and monitoring) for manufacturing, testing, and managing the product.

Quality risk management and knowledge management provide the backbone for designing, managing, and sustaining all elements of a control strategy, and thereby the lifecycle of a product. Hence ICH Q10 refers to quality risk management and knowledge management as enablers (i.e., “processes that provide the means to achieve an objective” [2]), the objective being consistently producing a product of the required quality.

The concepts of product lifecycle, control strategy, risk management, and knowledge management have been around for almost two decades; yet it remains unclear how these might be practically connected, implemented, and sustained all through the dynamic life of a product, such that they provide the foundational bedrock for achieving the objectives laid out in ICH Q10.

This paper posits that a control strategy provides a practical framework for evidence-based risk management and knowledge management throughout a product’s lifecycle. The paper discusses what a control strategy is, including its components, why it is important to start its design during the first stage of the product lifecycle (pharmaceutical development), how it should evolve during the next stages of the lifecycle (technology transfer and commercial manufacturing), what does a control strategy look like for outsourced operations (i.e., contract development and manufacturing), how the control strategy can provide a feedback and feedforward mechanism for knowledge and risk-informed decisions, and, finally, how to manage the control strategy through a cGMP-compliant pharmaceutical quality system (PQS) in order to keep it “living”.

When established in such a manner, the practical framework of a control strategy can become the basis to maintain a state of control while driving continual improvement for any product through all stages of its lifecycle and maintain sustainable compliance.

The dynamic knowledge and risk context

Knowledge and risk tend to have an inverse relationship—as knowledge increases, it serves to reduce the level of uncertainty and unknowns, thereby reducing risk. Lipa, O’Donnell, and Greene developed a simple framework called the Risk-Knowledge Infinity (RKI) Cycle to link risk and knowledge, show how knowledge is both an input to and output from risk management, and illustrate how maximizing use of knowledge minimizes risk (3, 4).

An important goal of product lifecycle management is using the growing product and process knowledge (as a product moves from development to commercial manufacturing) to reduce risks to product quality and/or patient safety. Conversely, emergence of any new risks in the commercial manufacturing or technology transfer stages that were not known during product development add to the knowledge base and product understanding. This growing knowledge base allows risk-based and/or risk-informed decisions to be more data and evidence- based. The risk-knowledge flow dynamic is indeed an infinity cycle all through the product lifecycle and should be managed as such.

But how does one do this when knowledge and risks are dispersed and constantly evolving over drug substance, excipients, intermediates, container closure systems, and drug product operations? All these pieces that collectively constitute the “product and process understanding” for a product, should be available within a company’s PQS. But what can serve as a “hub” (i.e., an effective center of an activity or a network) to enable this dynamic flow between risk, knowledge, and lifecycle activities for a product?

A control strategy should function as a “hub” for the network of controls for a product

Connecting key ICH concepts. Good manufacturing practices (GMPs) for pharmaceutical manufacturing are legally binding in most countries. However, while GMPs provide the foundation for producing quality product by assuring appropriate management of risks throughout the the product lifecycle, there has been recognition that further definition of approaches that optimize operational excellence in pharmaceutical manufacturing would be beneficial.

Over the past two decades, the ICH guidance documents—ICH Q8(R2), Pharmaceutical Development, ICH Q9(R1), Quality Risk Management, ICH Q10, Pharmaceutical Quality System, ICH Q11, Development and Manufacture of Drug Substances (Chemical Entities and Biotechnological/Biological Entities), and ICH Q12, Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management—while not legally binding, have introduced concepts that enhance assurance of GMP compliance and are necessary for producing quality product all through its lifecycle and achieving quality excellence in pharmaceutical manufacturing. Some key concepts introduced by the ICH guidance documents include product lifecycle management, pharmaceutical quality system, quality risk management, knowledge management, product and process understanding, design space, continual improvement (of process performance and product quality), and control strategy (1, 2, 5–7). The ICH guidance documents are integrative and have built upon each other in referencing these concepts as relevant.

Nevertheless, it is also important to acknowledge that practically connecting the implementation of all these concepts in product management, quality management, and manufacturing operations is not straightforward. In fact, there is limited guidance on how to implement all of these related concepts in an integrated manner for a single product, let alone to optimize sharing and use of knowledge across multiple products. ICH Q8(R2) is clear in that, while defining the design space for a product is optional, a control strategy is not.

Elaborating upon the concept of a control strategy, this paper focuses on how it can function as a powerful “hub” for product lifecycle management, risk management, product/process understanding and knowledge management, and continual improvement. The control strategy can function as this “hub” if one were to think of it as a core part of the nerve center that consolidates the set of controls that are necessary to consistently produce quality product.

Basics of a control strategy and how it can be a powerful “hub” for the entire set of product controls. ICH Q10 defines a control strategy as, “a planned set of controls, derived from current product and process understanding that ensures process performance and product quality. The controls can include parameters and attributes related to drug substance and drug product materials and components, facility and equipment operating conditions, in-process controls, finished product specifications, and the associated methods and frequency of monitoring and control” (2).

So, a control strategy is not just end-product testing and specifications. The ICH Q10 definition is more encompassing and includes product-specific elements (drug substance, drug product, materials, components, in-process controls, product specifications, testing, monitoring) and non-product specific elements (facilities, equipment). Every product and process should have a control strategy including some site-specific aspects (e.g., multi-product cross-contamination facility, utilities, and environmental controls). It is important to note that a control strategy is essential, but it is not the only aspect necessary for a product batch release decision.

Figure 2 was developed to pictorially depict the elements and objectives of a control strategy making it a “hub” for the consolidated set of controls necessary to consistently produce quality product.

Figure 2. Objectives and elements of a control strategy. (Figure courtesy of the author)

The author’s choice of the term “hub” is deliberate in that:

A control strategy should not be thought of as a single document that lives within the PQS and contains all the relevant knowledge for a product. That would not be practically achievable simply given the dynamic nature of each of the elements and the growing volume of knowledge as a product moves through its lifecycle. An overall product control strategy is built from several different control strategies all working together to produce and manage the product in a state of control (e.g., control strategies for each unit operation, analytical testing control strategy, cross-contamination control strategy, monitoring strategy, raw materials control strategy, environmental control strategy, cleaning control strategy, microbial control strategy, etc.). It can be easier if conceptualized electronically, with each control strategy element being a distinct virtual e-document, and the consolidated set of e-documents form the control strategy “package” for a product. An example of a possible document architecture/package that can constitute a control strategy are provided in Figure 3.

Each control strategy (consolidated set of controls for a product) provides a framework that allows it to serve as a feedback-feedforward nerve center or “controls hub” for effective risk-knowledge flow across the various constituent elements—all with the sole purpose of consistently producing quality product.

Such a consolidated mapping of all documents that constitute a control strategy for a product, as shown in Figure 3, would be practically useful for timely product lifecycle management, knowledge management, and risk management. It is also important to note that not all elements of a control strategy may appear in a standard or common way across different products, even if the products might have some shared platform-based aspects. It is entirely possible to use different approaches to build a control strategy. For example, a control strategy with real-time release testing (RTRT) or process analytical technology (PAT) for a tablet will likely look quite different in terms of testing, monitoring, process parameters, and equipment controls compared to the control strategy for a tablet with conventional end-product testing. The result in terms of product quality may be exactly the same, though, for both tablets with their respective control strategies. This underscores the importance of strong product and process understanding, knowledge management, and risk management when designing, maintaining an optimal control strategy for a product, and continually improving it throughout the product’s commercial life.

Figure 3. Example of possible documents architecture/package for a control strategy. (QTPP is quality target product profile. CQA is critical quality attribute. CPP is critical process parameter. DS is drug substance. DP is drup product. QA is quality attribute. SOP is standard operating procedure.) (Figure courtesy of the author)

Building and managing a control strategy

Product-specific elements of a control strategy. The pharmaceutical development of every product starts with prospectively defining the quality characteristics of the product that should be achieved to ensure the desired quality, safety, and efficacy; this is the starting point noted in Figure 1. Aspects such as the intended use, route of administration, dosage form, strength, bioavailability, stability, etc. are considered. This summary of the desired quality characteristics for a product is known as the quality target product profile (QTPP) (1).

Product and process knowledge and understanding to achieve the desired QTPP—in terms of identifying, understanding, and adequately controlling relevant attributes (for drug substance and drug product materials and components)—starts being built from early on during pharmaceutical development. It continues to grow as more experience is gained through technology transfers and commercial manufacturing, as illustrated in Figure 1.

All quality attributes (QA) of a product are desired, but not all are critical. Understanding the knowledge and risks associated with each QA helps determine its criticality to product safety and/or efficacy, and thereby the level of control necessary for that QA. A critical quality attribute (CQA) is “a physical, chemical, biological, or microbiological property or characteristic that should be within an appropriate limit, range, or distribution to ensure the desired product quality” (1). During development, it is expected that CQAs for the drug substance, excipients, any intermediates, and drug product are identified; a risk assessment is useful for this purpose. As an example, a risk assessment that ranks impact to safety/efficacy and uncertainty in terms of available data/knowledge can be used to relatively rank severity of each QA from most to least critical. The lesser the data and knowledge on a QA initially during development, the higher the risk associated with it. This should guide development studies to generate data and better understanding of the less-understood QAs. It is quite common for QAs with low understanding to be initially categorized as preliminary CQAs and be changed to non-CQAs when enough data has been accumulated to provide the supporting evidence for their recategorization. Several QAs require mandatory testing per regulatory requirements; these should be considered as CQAs by default.

Once identified, it is essential that limits, ranges, acceptance criteria, and/or tests for the CQAs are developed, well-understood, and controlled for the product. The other non-CQAs or less critical QAs can be evaluated too, just less frequently. Development studies are designed to generate knowledge on how to deliver the CQAs, what are suitable ranges for each CQA, what and how to design the process to best control each CQA within the appropriate ranges. It is also important to show clear relationships and linkages between a QA/CQA and the control strategy (e.g., characterization, comparability testing, process validation, in-process control, lot release testing, stability testing, monitoring, etc.). This becomes the starting point for the product related elements of an initial control strategy.

As mentioned earlier in this article, there might be various possible approaches for the design of a control strategy. Modeling different control strategies during development can provide useful knowledge on which approach might provide the most comprehensive controls coverage for a product.

Non-product specific elements of a control strategy. Non-product specific elements of a control strategy involve aspects such as facility, utilities, equipment, cross-contamination controls, cleaning, general (non-product specific) microbial controls, general (non-product specific) analytical test methods, etc. These are applicable across products and are not unique to any one product. Risk assessments form the basis for identifying, assessing, and controlling risks that can impact product quality and/or patient safety. It may often not be straightforward to directly link non-product specific risks to each product, yet without assessing, controlling, and managing them, it is not possible to assure consistent delivery of quality product.

The non-product specific control strategy elements are mostly associated with a manufacturing facility, and are applicable regardless of product. They can be developed independent of the product-specific control strategy elements. A determination should be made for each manufacturing facility and general analytical testing controls on what non-product specific elements are important to control. Appropriate risk assessments should be used, and data generated even for these non-product specific elements, to guide the development of relevant control strategies (e.g., cleaning control, microbial control, facility and environmental control, cross-contamination control [for multi-product facilities], etc.).

To elaborate further upon this point, the following specific example would be useful. Most manufacturing facilities tend to be multi-product, and it is essential to avoid cross-contamination between products due to facility layout aspects, personnel, material, equipment and waste flows, common utilities and environment, shared areas, tools, instruments, consumables and supplies, etc. During the technology transfer of a new product into a multi-product facility, any risks specific to product and process fit in the new facility, cleaning, product-specific unit operations or equipment, analytical testing, etc. are assessed and mitigated as part of the transfer. However, all potential avenues of cross-contamination may not be comprehensively assessed for each new product introduction into a multi-product facility. Therefore, it is highly recommended that a multi-product cross-contamination risk assessment be performed and a cross-contamination control strategy be established. Each time a new product is introduced into the facility, it should be evaluated against the cross-contamination control strategy to identify and manage any new risks that might be introduced by the new product to other products in the facility, or vice-versa.

Control strategy for outsourced operations. It has become increasingly common for companies to outsource development, manufacturing, and/or testing operations to contract development and manufacturing organizations (CDMOs) or contract laboratory organizations (CLOs). The accountability for the product license and, therefore, product quality (and safety and efficacy), remains with the marketing authorization holder (MAH), even when aspects of product development, manufacturing and/or testing are outsourced to a CDMO or CLO at any stage of the product lifecycle.

The CDMO and/or CLO become responsible for those elements of the control strategy that are a part of the operations outsourced to them, whereas the rest of the control strategy elements may remain within the purview of the MAH. In such instances of outsourced operations, the MAH and CDMO/CLO should partner closely in developing, updating, and managing the elements of the control strategy that are within their respective scopes of work. Having said that, the MAH remains ultimately accountable for the product and therefore, the consolidated set of controls that form the control strategy for a product, even when the elements of the control strategy are fragmented between the CDMO/CLO and the MAH. This is why it is essential that outsourced operations are set up and managed as open transparent partnerships (as opposed to fee-for-service contractual relationships) between the CDMO/CLO and MAH in terms of timely interactions, communications, and decision-making when it comes to assuring product quality and availability.

The following example illustrates how the different control strategy elements may be fragmented between a CDMO/CLO and MAH and how it would need to be managed.

Example. Product and process development are performed by the MAH; product is manufactured by a CDMO; analytical method development, validation, and testing is performed by a CLO; final product release is performed by the MAH. In this example:

• Development, design, and validation knowledge of the product and process, and, therefore, the product-specific elements of the control strategy, reside with the MAH.
• The unit operations, and non-product specific elements of the control strategy (e.g., facility, equipment, utilities, multi-product
  controls, cleaning, etc.) are owned by the CDMO.
• The analytical testing control strategy elements are owned by the CLO.
• The annual product review, monitoring, and overall product management is owned by the MAH, with the CDMO and CLO providing input into it from their respective control strategy elements.

As noted, overall, the MAH remains accountable for product quality, safety, efficacy, and availability. However, all three players—MAH, CDMO, and CLO—need to manage the risk-knowledge dynamic not only within the scope of their respective control strategy elements, but they also need to effectively manage this dynamic between and across their relevant control strategy elements, for instance, when a change is made, or a deviation or trend is observed. This is because the different elements of the control strategy tend to be inter-connected and an impact on one aspect of the control strategy may have an
influence on others.

The control strategy is inherently a risk management and knowledge management strategy

In addition to knowledge being developed through development studies, good risk management based on available knowledge along each step of process development is important for guiding development studies. This is a direct practical application of the RKI Cycle—the level of uncertainty and/or knowledge on a QA determines the level of risk—this helps determine the studies needed to fill the knowledge/understanding gaps and to determine if a QA is critical as a CQA or not—which then helps identify suitable process and/or testing controls for the CQA in order to reduce the risk/ impact to product quality—and the risk-knowledge cycle continues throughout the development stage. Thus, fundamental risk management and knowledge management collectively drive the build-up of data and risk-informed product and process understanding to ensure the design and optimization of a robust manufacturing process with well-defined controls that can consistently deliver product with the desired quality (including safety and efficacy).

The objective of process design is to define a commercial process that can consistently deliver safe, efficacious product that has all the required quality attributes. The expected output is a control strategy in addition to master production and control records.

Figure 4 provides an example of a structured risk-based approach and successfully implemented to establish the product-related elements of a control strategy. Once the QTPP is defined, a risk-based approach can help determine which QAs are critical to product quality (i.e., CQAs) vs. not. As process understanding is gained through development studies, the ability of the process to control a CQA determines how best to control it. For CQAs associated with high and/or medium process impact, in-process control or release testing would provide the best assurance of control. For some QAs associated with medium- or low-process impact, monitoring the attributes, independent of batch release, could provide the appropriate level of control. Finally, for non-CQAs with low criticality, no testing is necessary. The interplay between knowledge and risk is evident when making these determinations.

Figure 4. Example of a structured approach to establish a control strategy (product-related elements). (QTPP is quality target product profile. QA is quality attribute. CQA is critical quality attribute.) (Figure courtesy of the author)

This risk-based approach is relevant and useful even during the commercial life of a product. As more data and knowledge are gathered during commercial life, it can be the evidence that is used to re-assess if any QAs need to be reclassified as CQAs or non-CQAs, which in turn would trigger an update to the testing and monitoring controls that were established during the development stage.

Feedback-feedforward through the control strategy “hub”

ICH Q10 defines feedback as “the modification or control of a process or system by its results or effects” and feedforward as “the modification or control of a process using its anticipated results or effects.” It further states that “feedback and feedforward can be applied technically in process control strategies and conceptually in quality management” (2).

The approach to and content of a control strategy (product-specific and non-product specific elements) are expected to evolve during the product lifecycle. Scale-up, technology transfers, and manufacturing experience can lead to refinements for the control strategy, for instance in the following cases:

• As knowledge grows (e.g., enough data and evidence are accumulated on a QA to change it from a CQA to a non-CQA or vice-versa).
• New risks are identified (e.g., impact of increased variability of a process parameter requires its range to be controlled more tightly, new product introduction).
• New technology becomes available (e.g., new PAT that allows in-line monitoring of a process parameter, QA, or CQA, so end-product testing is not needed any more, or a better analytical technology will improve sensitivity or speed of testing).
• A new microbial contaminant is identified in a facility or a process (e.g., a new test needs to be added to detect it).
• Raw material change or raw material supplier change introduces a new impurity (e.g., characterization and control of the impurity is deemed necessary and new test method needs to be developed and validated for the impurity.
• Process changes need to be made to increase manufacturing yields.
• New signals, trends, quality, or compliance issues are detected through the PQS (deviations, complaints/adverse events, annual product review, operational metrics review, management review, etc.).
• A continual improvement opportunity is identified.
• New regulatory expectations are added (e.g., testing for nitrosamines).

All these instances should function as feedback or feedforward triggers to evaluate current knowledge/understanding, determine if/how the current risk profile for a product might change because of it, and what updated or new controls might become necessary in order to maintain a state of control. It would also be useful to review the control strategy as part of the annual product review or when making changes to determine if any updates to the control strategy, including continual improvement, might be warranted. Completion of a production campaign also offers a good opportunity to at least consider any lessons learned or new knowledge that might be of relevance for a control strategy update.

Using the control strategy as a nerve center for the network of controls necessary for a product allows it to function as a feedback-feedforward “hub” for effective risk-knowledge flow across its constituent elements. The triggering event would determine what aspects of the control strategy need to be probed, considering the new knowledge, and changed risk profile. This would enable timely knowledge and risk-informed decisions for the product and the relevant elements of the control strategy. Without this dynamic and timely feedback-feedforward, it becomes impossible to attain the cGMP and ICH Q10 objectives of achieving product realization, establishing and maintaining a state of control, and facilitating continual improvement.

Lipa’s RKI Cycle provides a practical means to activate and operationalize the feedback-feedforward power of a control strategy all through a product’s lifecycle. Several case studies showing this application particularly during technology transfer and commercial manufacturing have been published by Lipa, Mullholand, et al. (8). The paper explains several nodes in the RKI Cycle and how different events during a product’s lifecycle can initiate the RKI Cycle at different nodes, based on the level of available information and knowledge and an understanding of associated risks; this is depicted in Figure 5 (8). Some examples of such events include a change, failure or error, corrective action, preventive action, improvement, implementation of a new technology, tightening of a specification, process optimization, annual product review, data trends, etc.

Figure 5. Potential nodes (entry points) in the RKI Cycle (8). (Figure courtesy of the author)

Application of the RKI Cycle in conjunction with the dynamic feedback-feedforward power of a control strategy “hub”, should trigger the following questions (this is not a comprehensive list):

• What is the level of knowledge and understanding associated
  with the event?
• What prior knowledge or data might be available about this event from this product or another product?
• What aspects of a product(s) might be potentially impacted?
• Does it change (increase or decrease) any current risks for a product(s), or introduce new risks? If so, in what way?
• What controls are in place to mitigate the risk(s)? What enhanced or new controls might be needed?
• What elements of the current control strategy (product-specific and non-product specific) need to be assessed?
• Does the current control strategy address the potential impact of this event? If yes, how? If no, what activities or studies need to be initiated to acquire the data/evidence/knowledge needed to make decisions?
• What does the new knowledge of the event and/or the data generated to understand it, indicate?
• What updates are needed to the control strategy to mitigate the impact of the event?

Managing product risks and knowledge is ultimately all about assuring and maintaining a state of control such that product of the desired quality can be delivered consistently. If it is all about control, then what better means to assure this than to use the control strategy as the
“controls hub” for a product?

Managing the control strategy in the PQS

Once an initial control strategy is established during the pharmaceutical development stage, it will need to be refined, updated, and managed all through the product lifecycle.

As noted earlier, a control strategy should not be thought of as a single document that houses all controls for a product. Instead, it is a consolidated set of all controls necessary to consistently produce quality product, and these controls may be found in different quality and operational documents. For outsourced operations, some elements of the control strategy may even reside with a CDMO or CLO as discussed earlier.

This raises some logical questions, including: where does one find this consolidated set of controls? and how do you manage this dynamic set of controls in a timely manner based on the constantly evolving knowledge and risks for a product/process, such that product quality is assured at all times? The answer to both questions is within a cGMP compliant pharmaceutical quality system (PQS).

The ICH Q10 model for a PQS is structured and applicable across all four stages of the product lifecycle—pharmaceutical development, technology transfer, commercial manufacturing, and product discontinuation, in a phase-appropriate manner. The model includes four elements—process performance and product quality monitoring (PPPQMS), corrective and preventive action (CAPA), change management, and management review—as well as two enablers—quality risk management (QRM) and knowledge management (KM); all governed by clear expectations for management responsibilities across all lifecycle stages and across the four elements and two enablers (2).

All components of this ICH Q10 PQS model provide the structure necessary to document and contain all controls necessary to assure consistent product quality. The PQS also provides the structure to dynamically manage changes and updates to any of the controls, when triggered by an event as discussed in the previous section.

Figure 2 described the different product-specific and non-product specific constituent elements of a control strategy. For each of those elements, based on the level of knowledge and risk, a list of controls will be identified. Figure 6 depicts how these various controls identified within the product-specific and non-product specific elements of a control strategy may be documented and implemented via different components of the PQS.

Figure 6. Implementation and management of the control strategy in the pharmaceutical quality system (PQS). (CPV is continuous process verification. CPP is critical process parameter. SOP is standard operating procedure.) (Figure courtesy of the author)

Three examples are described below to illustrate how the PQS would be used to document and manage the consolidated set of controls (product-specific and non-product specific) that form the control strategy for a product.

Example 1: change to a product CQA. The initial list of CQAs, their ranges, and controls are defined and documented in development and characterization studies during process design and in process qualification and process validation reports. These documents typically reside in and are managed through a company’s document management system which is governed by the PQS.These documents lead to the definition and documentation of the initial product control strategy (i.e., CQAs, their limits, test methods, and specifications). Let’s assume during the commercial life enough data has been generated and assessed during annual product reviews (APRs) (documented in APR reports managed via the document management system) to demonstrate that a CQA is well-controlled and that the initial specifications defined during development can be tightened to better represent the commercial process variability. The product control strategy becomes the relevant element for this triggering event. The change management element of the PQS would be used to document an assessment of the change, provide all supporting data, assess any risks and associated controls, and capture any regulatory or product quality impacting considerations and decisions. The change management system would also document and trigger any actions needed (such as updates to product specifications, manufacturing batch records, batch release documents, trainings, need for any regulatory submissions, etc.) via the change implementation plan. The completion of those actions, any unintended consequences, etc. would be documented as well, and the change would be closed after satisfactory implementation of the change. The PQS would also be used to document any post-implementation reviews needed.

Example 2: a quality issue during product manufacturing. Deviations from approved procedures can occur during manufacturing, testing, release, or supply of a product. Any deviations are typically documented in a discrepancy (nonconformance) management system. For this example, let’s assume a deviation occurred during the blending unit operation for a tablet, so the unit operation control strategy becomes the relevant element for this triggering event. An assessment of the deviation, any potential impact to product quality for this (and other relevant products), actions needed to respond to the deviation including management of potential product impact, new studies or data needed, etc., are documented in the discrepancy management system. If a risk assessment exists for the blending unit operation, it would be reviewed to determine if an existing risk has changed or if a new risk might have been introduced, and what updated or new controls might be needed. All this information is included in the discrepancy record. The deviation is not closed until all relevant decisions have been made, including updates to the unit operation risk assessment, the need for relevant corrective and/or preventive actions, and any updates to relevant procedures, training, etc. The corrective and/or preventive actions identified are documented and their implementation managed via the CAPA system.

Example 3: continual improvement through implementation of a new analytical technology. A product can live in its commercial life for more than 20 years, and it is not unexpected that during that long lifespan new manufacturing and analytical technologies emerge. Let’s assume for this example that one of the analytical tests to ensure appropriate concentration is an in-process sampling and control by ultraviolet (UV) analysis. A new in-line UV analysis technology provides the opportunity to perform real-time concentration monitoring, thereby eliminating the need for in-process sampling and holding the process until UV analysis results are obtained to confirm concentration of the active ingredient. The product testing and in-process control strategy become the relevant elements for this continual improvement-triggering event. Development of the in-line UV test method, including generation of method comparability data, and method validation are performed and documented through method development, method validation, comparability studies, and reports via the document management system. Development, qualification, and validation needed for the new technology are performed and documented in suitable development, qualification, and validation reports. Implementation of the new UV analysis technology in-line is assessed and managed via the change management system, including the need for any regulatory assessments and/or submissions. Relevant SOPs, test method, calibration, and routine maintenance documents are established within the PQS via the change management system.

Conclusion

This paper connects key concepts from ICH guidance documents and explains how central and invaluable a control strategy is for product lifecycle management. This is possible only through use of good knowledge management and quality risk management, which are appropriately described in ICH Q10 as enablers. Both knowledge management and quality risk management provide the basis to determine the level of product and process understanding that exists and when new data or evidence is necessary because of certain triggering events that can then provide continued assurance of product quality.

While the concept of a control strategy is described in ICH Q10, Q8(R2), and Q11, there is no guidance available on how to practically develop, implement, and manage a control strategy through the entire product lifecycle. This paper clarifies details of what a control strategy is and operational aspects of how to build and manage a control strategy within the PQS and ensure sustainable compliance. It further provides examples to demonstrate how a control strategy can function as a powerful “controls hub” for a product particularly during technology transfers and the commercial manufacturing stages of a product’s lifecycle.

Disclaimer

The views expressed in this paper are those of the author and do not represent the views of their employer.

References

1. ICH. Q8(R2) Pharmaceutical Development, Step 4 version (ICH, 2009).
2. ICH. Q10 Pharmaceutical Quality System, Step 4 version (ICH, 2008).
3. Lipa, M. J.; O’Donnell, K.; and Greene, A. Introducing a Model and a Framework to Unify the Pharmaceutical Quality System Enablers Quality Risk Management & Knowledge Management. Articles 2020, 102.
4. Lipa, M. J.; O’Donnell, K.; Greene, A. Knowledge as the Currency of Managing Risk: a Novel Framework to Unite Quality Risk Management and Knowledge Management. Level 3 Journal 2020, 15 (2). DOI: 10.21427/4mzp-vn67
5. ICH. Q9(R1) Quality Risk Management, Final version (ICH, 2023).
6. ICH. Q11 Development and Manufacture of Drug Substance (Chemical Entities and Biotechnological/Biological Entities), Step 4 version (ICH, 2012).
7. ICH, Q12 Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management, Final version (ICH, 2019).
8. Lipa, M. J.; Mulholland, V.; O’Donnell, K.; Greene, A. Exploring the Risk-Knowledge Infinity Cycle (RKI Cycle) Across the Product Lifecycle: Case Studies Demonstrating the Link Between Knowledge and Risk in Technology Transfer and Commercial
   Manufacturing. ISPE iBlog 2021.

Editor’s Note: This article was peer reviewed by a member of Pharmaceutical Technology’s® Editorial Advisory Board.

Submitted: May 11, 2023

Accepted: June 22, 2023

About the author

Emma Ramnarine, PhD, is Executive Director, Product Management & Development Operations, US Biopharma Operations at Boehringer Ingelheim Fremont, Inc.

Article details

Pharmaceutical Technology
Vol. 47, No. 10
October 2023
Pages: 30–46

Citation

When referring to this article, please cite it as Ramnarine, E. Control Strategy: A Feedback-Feedforward ‘Controls Hub’ for Risk, Knowledge, and Product Lifecycle Management. Pharmaceutical Technology 2023 47 (10).