Fixing the Negative Perception of QbD

Quality by design (QbD), which has been with us for decades, is defined by the International Society for Pharmaceutical Engineering (ISPE) as a “systematic approach to development that begins with predefined objectives and emphasizes product and process understanding based on sound science and quality risk management”. The main principles have been assembled by the International Conference on Harmonization (ICH), as laid down in well-known guidelines.

Today, QbD is interpreted by executing systematic multivariate analyses of interactions between process parameters and quality attributes using ‘design of experiments’ (DoE), as well as risk assessment approaches based on conventional failure mode and effects analysis. But the fact is that many in the  industry see QbD as costly, laborious and without the promised benefits of being able to freely act in the design space and do real-time release without regulatory oversight.

As an example, DoEs are currently treated like recipes; there is no real reflection on the actual design and strategic meaning. A lot of data are generated in a systematic way and results are presented in colorful plots with intuitive software. Instead, we should be asking many other questions: why did we initiate this experimental plan? Why did we choose the boundaries of the DoE? How do we document our decisions in process development, technology transfer and scale up? Where can results be used in a lifecycle including continuous improvement?

Very few QbD projects are launched because of economic drivers; instead the main incentive is the regulatory threat, given that only QbD filings are likely to be accepted by the year 2020. Why is QbD so negatively perceived?

In my view, we as an industry must understand that QbD is not only about executing risk assessment (following ICHQ9 – Quality Risk Management (ICH 2005)) and DoEs (following ICHQ8 – Pharmaceutical Development (ICH 2009) – or even ICHQ11 – Development and Manufacture of Drug Substances (ICH 2009)). What we need to understand is that QbD will only work with a clear integrated concept of knowledge management, as encouraged by ICHQ10 – Pharmaceutical Quality System. ICHQ10 introduced the concepts of quality risk management and knowledge management to help achieve the objectives of QbD. There are two steps.

First, we need to generate robust knowledge by analyzing where substantial knowledge can be obtained from the data, and understanding what information can be transferred – as platform knowledge – from process to process, site to site, and product to product. Such an approach results in robust “prior knowledge”, which is the ultimate key to any risk assessment and experimental design. We need tools that can convert data into information and knowledge and it is critical to compare experiment through normalization that is independent of initial conditions and scale. It may not be a task that can be automated; it will require an interdisciplinary team of technologists, statisticians and mathematicians – all facilitated by software. University curricula to create such ‘knowledge analysts’ are urgently required.

Secondly, we need to manage the knowledge we obtain and develop generic workflows that can provide, for example:

• a strong tie-in of risk assessment results with the initiation of experimental plan
• findings/knowledge of experimental results to reassess risk
• knowledge as platform knowledge
• knowledge as prior knowledge for regulatory filings
• sources for lifecycle management, which is targeted by the current development of ICHQ12 – Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management.

How do we get there? We need to start with proper representation of knowledge – beyond colorful plots and equations that can only be read by specialists. The difficulty is that technical knowledge (as found in correlations or mechanistic understanding, for example) must be simplified to attain the buy-in of the entire interdisciplinary team.

We hypothesize that the use of semantics and ontology would help to extract and manage knowledge. As an example, we recently analyzed how technical knowledge can be converted into ontological entities – turning a mechanistic model into operator language (1). We believe that ontologies, in turn, can also be used in interviewing team members to extract mechanistic knowledge. Hence, the knowledge of team members is extracted in a structured way and can lead to the construction of mechanistic models.

We strongly believe that the real value of QbD, including economic benefits, can only be leveraged when knowledge is made available in trivialized ontological entities and managed by business processes that follow ICHQ10 and ICHQ12. A  benefit of this QbD related approach would be the acceleration of on/off-boarding of team members, which is a very important task in all (pharma) companies independent of QbD.