THE CHALLENGES OF DELIVERING QBD IN NOVEL RESPIRATORY DEVELOPMENT

EXPERT VIEW

Citation:  Belton D, “The Challenges of Delivering QBD in Novel Respiratory Development – Knowledge- and Risk-Based Approaches”. ONdrugDelivery Magazine, Issue 96 (Apr 2019), pp 18-20.

David Belton discusses the meaning of quality by design in novel respiratory drug delivery device development. He covers how, with more novel devices, prior knowledge may be insufficient for a standard FMEA-style risk analysis, and alternate science-based methods, such as functional mapping and knowledge scoring, can help in achieving QbD.

INTRODUCTION

There is currently significant development activity within the respiratory device arena, driven both by new drug development and the opportunity to launch generic equivalents. With new products, there is frequently a commercial business driver to develop a distinctive delivery mechanism. And for generics, because the patents on the drug expire before those on a device, there are opportunities to develop novel, non-infringing drug delivery systems to gain a competitive advantage. We have also seen the challenges of gaining regulatory approval for clone-type devices where a significant amount of knowledge needs to be gained to create a robust product.

“In fact, while the acronym QbD is often recited without much thought, it is actually a fairly profound statement. A clearer way to state it is ‘Quality. By Design’.”

Considering this drive towards highly novel devices and the accelerated launch of clone devices, this article covers specific challenges in achieving Quality by Design (QbD) of novel mechanisms. In particular it focuses on the relationship between risk-based and knowledge-based approaches in showing understanding and control of the device design.

QUALITY. BY DESIGN

To fully consider the challenges of developing modern respiratory drug delivery systems it is worth looking again at the core QbD guidance, ICH Q8. In fact, while the acronym QbD is often recited without much thought, it is actually a fairly profound statement. A clearer way to state it is “Quality. By Design”. This begins to convey the intent of QbD, which is that the quality characteristics are designed-in and well understood. For a drug product or device this naturally leads to the key concepts of design understanding, design robustness, manufacturing understanding and manufacturing robustness.

When we look at ICH Q8 for drug delivery systems, they are mentioned only fleetingly, described as “important to demonstrate that a reproducible and accurate dose of the product is delivered under testing conditions… which simulate the use of the product”. Reading on though we come across terms that should be familiar to anyone working in device design and development, including design space, design of experiments, process analytical technology (PAT) (now very much a part of Industry 4.0), process robustness and, of course, quality.

With respect to pharmaceutical development, the guidance identifies four examples of QbD’s systematic approach:

• Incorporation of prior knowledge
• Design of experiments
• Quality risk management
• Knowledge management.

The guidance also notes that the level of knowledge gained for science-based and risk-based submissions is key rather than the volume of data. It’s an interesting point that, in my experience around device development, I have heard the term “risk-based approach” probably ten times more than I have ever heard the terms “science-based”, “knowledge-based” or “data- based” approach. If you find this familiar as well, then I believe a more balanced approach to risk- and science-based knowledge is important, and is particularly important with novel drug delivery devices to achieve Quality. By Design.

“The particular challenge here is that the more novel a design is, the less prior knowledge exists and the more those in the review, even experts, have to lean into making educated guesses and hunches.”

RISK AND PRIOR KNOWLEDGE

So why do I believe that a more balanced approach is required for development and risk management? And why is this particularly important to novel devices? It is generally agreed that the quality of a risk assessment is often dependent on the range of required skill sets and experience in the room when the risk assessment is carried out.

In the early stages of device development, prior knowledge and expertise are heavily relied upon to support risk assessments, as there will likely only be limited information available, such as sketches and rapid-prototyped working models. The particular challenge here is that the more novel a design is, the less prior knowledge exists and the more those in the review, even experts, have to lean into making educated guesses and hunches. This leaves open the risk of both gaps (unknown unknowns) and over-analysis of known, or “safe”, areas occurs.

There is then the potential for these early risk assessments to be used as the basis for later reviews, causing the gaps to remain unnoticed until late in a programme, by which point there are generally much higher costs associated with managing issues. Therefore, in taking a balanced approach to novel device development, it becomes more important to gain knowledge through science-based approaches to avoid the potential for gaps in risk assessment.

FUNCTIONAL REQUIREMENTS

There are a number of existing techniques to gain knowledge and define the functional requirements of a product. These come through documents such as user requirement specifications (URS), engineering design specifications, user event trees, fault tree analysis and mapping through use of trace matrices.

“In taking a balanced approach to novel device development, it becomes more important to gain knowledge through science-based approaches to avoid the potential for gaps in risk assessment.”

These documents are extremely effective at defining the functional requirements of a device, but do not specifically define how the device achieves those requirements. It is not uncommon for these functional requirements to be directly risk assessed. Where the functional mechanism is fundamentally understood this is not an issue.

When it comes to novel devices, it is more akin to asking: “Show me the device works by proving it doesn’t fail in all possibilities”. One way to visualise this is by trying to define the shape of a dartboard through risk-assessing all the ways the darts could miss.

To expand on this analogy, it is important to have the risk assessment to understand the consequences of not hitting the dartboard, but directly defining the shape and function of the dartboard seems to be a simpler, direct approach. Considering this in a devices context, a more straightforward, and QbD aligned, approach is to ask the question: “Show me the device works by showing me you understand how the device works”.

MECHANISMS FOR KNOWLEDGE DEVELOPMENT

There are two main approaches for knowledge development:

• Predictive modelling
• Physical testing.

Predictive Modelling

Predictive modelling covers a wide range of tools. This includes complex analysis, such as finite element analysis (FEA), computational fluid dynamics (CFD) and tolerance models, through to understanding spring rates, frictional movement and similar activities. These methodologies have proven to be very powerful in performing rapid design iterations early in design and in being used to support understanding throughout the development lifecycle of a device.

Physical Testing

Modelling of parts through various rapid prototyping methods is becoming the norm in development. As these, and later more industrially representative samples, are tested in development, they can provide physical validation (or sometimes otherwise) of theoretical models. The two approaches are highly complementary and allow for real life issues to be found and models to be refined to predict results in many more scenarios than can usually be manufactured.

At a basic level these types of models and tests are made on core functions of a device – for example, steps of preparation, dosing, delivery and counting. With complex respiratory devices, there are usually multiple components and interfaces working to deliver a core function. Often, these components contribute to more than one function within the device. The next layer of understanding is being able to understand the performance characteristics of these individual interfaces. If they can be optimised, understood and controlled, that moves us significantly towards having a well understood design that is robust and can achieve high quality levels.

STRUCTURED FUNCTIONAL RELATIONSHIPS

So far, I have discussed the risks in risk-assessing a novel device where unknown unknowns may exist, and also covered the ever-improving standard approaches in defining functional requirements and functional knowledge. The way these are often managed is by then using this functional information to (returning to my earlier dartboard analogy) define all the “missed darts” and not the dartboard itself via a risk assessment.

Personally, this led me to consider why we do this. There are the obvious answers, such as: “These are what the policies/guidances/regulators tell us to do”, “We need to understand the risks” and the like. One other reason is that a risk assessment, particularly failure mode and effects analysis (FMEA) which is most commonly used, is an excellent way to structure the information. There is a clear distinction between a failure mode, potential causes and effects which connects a requirement not being met (the effect), and the source of the problem (the cause). This then leads to another question – why do we need to flip these functional modes into failure modes in order to describe this, or put another way, “What is the opposite of an FMEA?” Would it be easier and more thorough to have a process that described structured functional relationships rather than failure modes?

FUNCTIONAL MAPPING

The solution to this “opposite FMEA” is a functional map. The basic concept behind this is that rather than describe all the things that can go wrong with a device, it is used to describe all the things that need to go right to achieve a function. This can be a powerful tool as, by definition, this is a finite list. By using a mapping process, similar in many ways to quality functional deployment (QFD), top level functions can be connected effectively with ever more fundamental design features.

“The process of creating a functional map in a broad-based team encourages improved understanding of the design and allows the participants to think about a device from a different viewpoint than they might normally otherwise.”

For example, starting from a top level function, you can go to a contributing interface, a component, a surface and a dimension. By looking at specific device functions, a functional map also allows for identification of where a feature may be performing more than one role. Typically, this happens where a feature is performing both a primary and secondary function. A risk analysis will often focus on the primary relationship to the detriment of the second, which may have different control requirements or design space.

An effective functional map also acts as a thorough guide to connecting functional requirements in a URS through to support FMEAs. There is also a more general benefit, which is that the process of creating a functional map in a broad-based team encourages improved understanding of the design and allows the participants to think about a device from a different viewpoint than they might normally otherwise.

KNOWLEDGE SCORING

A further benefit of functional mapping is that is provides a structure to perform a knowledge assessment across the device, and can be used to identify gaps in knowledge. Similar to the functional map utilising the same cause and effect approach as a FMEA, one approach for a knowledge assessment is to look the FMEA scoring methodology, such as severity and occurrence. There is a less direct link in this comparison, but there is benefit to defining metrics that can be scored, and have similar action limits set as in an FMEA. When looking at knowledge scoring, the two requirements identified were:

• Knowledge level
• Strength of relationship.

Knowledge Level

The knowledge level can be scored based upon the precision and level of understanding of a relationship. The scoring should be based on data. At the highest end is having a fully predictive model which closely aligns with observed physical models. Also in this category are functions that can be based on fundamental physical properties. Lower knowledge levels would be partially predictive models, empirical data from a limited design space and, at the bottom, no data at all.

Strength of Relationship

Whilst the knowledge level score is completely data-driven, the strength of the relationship can be a mix of evidential data and expert judgement. It is likely that not every aspect of a device and every potential contributing factor can be fully investigated, and focus is needed on key relationships. In essence, this scoring allows for a sense-check of “Does it matter?” In much the same way that you might separate control, noise and experimental factors in a design of experiments, this score looks to categorise the likely strength of the relationship from all factors described in the “What needs to go right?” set.

Via this knowledge assessment, core functional gaps in understanding where there is believed to be a strong relationship with limited data can be identified and closed as early as possible in development. This complements an FMEA in defining where more knowledge is required, as well as where assessed risks need to be proven correct or not.

SUMMARY

In some devices there lies the risk that the more novel the mechanism, the less prior experience is of value in FMEAs, which can potentially lead to the risk assessment containing gaps that present their own risk to development. Existing knowledge processes, such as theoretical and physical modelling, remain good practice to both define and understand the functionality of a device. However, there is an opportunity to enhance this through the application of data-based functional maps and knowledge scoring alongside more classic FMEA-style risk-based approaches. This can support improved, faster design processes and deliver the robust QbD products that the market demands.