QbD in Biologics: Genentech’s Success and Failure in Design Space Approval
Earlier, I posted why the 1st Biologics failed in full QbD submission. Now Genentech has been redeemed and is pioneering Quality-by-Design in biologics / biotechnology / large molecule / biopharmaceuticals.
Dr. Lynne Krummen of Genentech (Roche) kindly shared her experience with 2 products: Perjeta and Gazyva. Both were full-QbD submissions. Perjeta’s design space was not approved. Now Gazyva’s design space has been finally approved.
In her talk, she mentions:
-
Why design space was rejected and approved
-
Challenges in justifying results for scale-up (2 L to 12,000) experiments in biologics
-
Tech transfers between different sites
-
Importance of multivariate study (Design of Experiments – DOE) approach
Of course, due to confidentiality, the technical details are not mentioned but you will get an insider’s view of the strategy.
In the near future, I will interview Lynne for further details, so subscribe to the email list (on the right) to get the latest updates.
Summary Quote:
“But the degree of regulatory flexibility we’re going to get really has to be earned. And it’s going to be proportional to the amount of justification and data that we can actually put on the table. In addition, anything that takes a risk based decision that take something out of pre-approval oversight, it’s still in the inspectional oversight but out of preapproval, is going to be highly scrutinized.”
Takeaway Lessons:
1. Have an exhaustive list of CQA’s and CPP’s. Don’t cherrypick them based on (assumed) criticality.
2. Consult with regulatory agencies early and be transparent about what you know and do not.
3. Have a solid post-approval control strategy (even if much uncertainty is unresolved).
4. Plan to iterate your risk assessment after you get data.
My Raw Notes: (includes details on the points mentioned above)
“Lynne: (new PPT file lost) Well thank you, sorry about that, thanks for the patience.
It’s really just a few minor changes from this one so it should be fine.
I’m pleased to be here today to talk to you about our experience
at Roche Genentech with quality by design and what we’ve been
doing over the last several years to try to understand how to
fully implement the concepts and the ICH guidelines.
We’ve had a number of practical experiences now; we have been
some work in the post approval arena with change protocols like
Christine was talking about. But what I’d like to focus on is
actually our experience with two original marketing applications
that we’ve filed globally.
They are for two products; the first was Perjeta the second one
is new product, Gazyva. Perjeta contained a design space
proposal, but only in the regions, ICH regions where we filed.
We weren’t quite sure what the sort of acceptance would be
globally for the concept. But actually we found that it creates
a very good framework for thinking about how to describe our
process and control strategy.
So Gazyva’s filing actually had design space proposals in all of
the global filings. In any case, both filing are global, filings
contained the same process descriptions, parameter ranges and
control strategy proposals.
So Perjeta at this point has been approved by almost all global
health authorities. We were in a collaborative review program
between FDA and EMA in Japan, sat in on that as an observer. And
while we received separate lists of questions and the process
was relatively invisible to us, we didn’t see a lot from it.
It was pretty obvious that there was influence and that was a
good thing because I think it led to some amount of
harmonization. And in general the QBD based control strategy
that was proposed for Perjeta was accepted globally with some
modifications in terms of limits, but pretty much globally.
US and EU did not approve the design space approval in that
application, those some other countries did. The concept that we
developed for design space, we fit into module one in the
Japanese NDA and that was approved as well. We figured out a way
to sort of make those things consistent.
We took the lessons that we learned from the Perjeta application
and tried as best as we could to apply them to the Gazyva
application. I’ve given this talk a couple of times before and
I’m happy to say that I have a different ending now. Which is,
that last week the FDA approved Gazyva, and they approved both
the QBD base design control strategy and the design space, which
was very gratifying for us.
The application is still under review in other jurisdictions and
we’ll see how much progress we’ve made there. So I’m going to
talk today a little bit about the lessons we learned as we went
through these various marketing applications, about what is
important in terms of how to present information, what level of
detail and how to put together the information into an
application so that it’s clear what the risk picture is around
the product.
I’ll also present my sort of perspective on why QBD is important
in a foundational element of overall life cycle risk management.
So I’ll start back with the pilot program.
The Perjeta application was in the QBD pilot program for the FDA
and we had a number of meetings with them and with European
health authorities and a couple of other global health
authorities.
And the main focus of those meetings was really the development
of risk assessment methodologies that address key questions of,
how do you classify risks commonly associated with processing
and control strategy development.
And really, what it is, is having subject matter experts take
their deep knowledge of the process and try to clarified how
they made decisions.
Also, how they would bring in platform knowledge, literature
information etc. so that we can create a common decision making
framework and common language around how we’re designing our
processes, how we’re making decisions about process parameter
classifications and how we ultimately design the control
strategy.
And we had quite a bit of discussion in these meetings about the
classifications, the definitions of scorings that kind of thing.
Overall our approach really has been designing a risk based
control strategy for the process. And we started out asking
what’s important about the product to the patient? What are the
CQAs?
Then trying to figure out what are the right levels of those
attributes that allow the safety and ethnicity profile to be
realized. We then used that information as we designed the
process to figure out what the impacts of the process are on
those CQAs limits as well as what is the stability profile of
the various critical quality attributes.
That all goes together really to design an attribute testing
strategy that is based on the logic of what you know about your
process and what you know about your product. So at Genentech
and Roche, the approach that we’ve taken to designing the
process and coming to the control strategy is really shown in
this particular slide and our goal was really to do a process
wide application of QBD.
So it starts out with identifying the CQAs for the product,
determining the relevant levels and then looking at each unit of
operation and performing scaled down experiments, either univarite
or multivariate. Where in some cases, worst case, in
order to really understand how the process parameters for each
unit operation impact the CQAs that are relevant at that unit
operation.
And the note there just says, that I think it really is state of
the art to use multivariate experimentation, QBD or not and to
explore these types of interactions unless you can justify
otherwise.
So since we were trying to… claim a design space at the end of
the day. We also realized that CQAs can be modified by multiple
unit operations and that it was important that we knew that the
product’s quality was appropriate at the end of the process, at
the drug product’s stage.
If we had design spaces around various unit operations, that
when we worked at the extremes of those, we would still produce
product at the approximate quality. And so after we did our unit
operations studies, we added some linkage studies to ensure that
that was all okay.
And then of course we also did the add scale consistency runs
that are associated with normal process validation. So at the
end of the day, if we’ve correctly identified our CQAs and their
acceptance criteria and used them to design our process, then we
do have what I think is an overall control strategy.
I’m trying to see if we have a pointer up here at all, I don’t
think so.
We do have an overall control strategy that consists
of both parametric control as well as appropriate control of
attributes, either through specified testing or perhaps through
monitoring.
And if we had designed the process in a multi varied way and had
the data to support it. I think that could also lead to a design
space claim. And what that means at the end of the day is that
the overall control strategy is really a risk management
strategy for your product. And I think this is very consistent
with the goal of QBD, to build product quality into the control
of the process.
So we created a risk assessment tool that we call the Attribute
Testing Strategy tool. That takes into account first of all, the
criticality of the attribute. Then secondly, the impact of the
process on that attribute to determine how that attribute ought
to be treated in terms of the testing strategy.
And what happens when you look at an overall risk map of the
process, is you find that the most highly critical attributes,
or the attributes that are least well controlled are the ones
that show up in your lot release testing run on stability.
Others that are more medium bucket, we have created a category
of monitoring just so that we can assure ourselves as we go into
commercial manufacturing, that our assessment was correct. And
then for the lesser criticality or the very highly controlled
attributes, we proposed no testing.
So when we went through the pilot program meeting about each
meeting was sort of geared towards a certain risk assessment and
as we went through we got feedback about how to improve the risk
assessment that we walked in the door with, to make it more
acceptable in terms of managing potential uncertainly and
residual risk.
That started with the CQA identification risk ranking and
filtering tool. We added uncertainty scores so that not only we
were looking at the impact of the CQA, potentially on the
patent, but how certain we were of the knowledge we were using
to assess to that. We also came up with some business rules
where certain scores that fell sort of on the critical,
noncritical continuum defaulted to a critical level.
The next thing we did was considered, when we sent the
acceptance criteria for the CQAs, if we had multiple CQAs but
all impacted potency or all impacted pharmacokinetics. To make
sure that we were considering that in setting the acceptance
criteria for the individual attributes.
We also narrowed those ranges to target ranges to use for the
design of the process. When we defined the CPPs, after the
process categorization experiments, we used we thought a
conservative way to identify the CPPs. Saying that a process
parameter would be a critical process parameter if it showed an
impact of 10 percent movement towards the final tolerant target
range for that CQA.
I’ll talk a little bit later about why we took that conservative
approach but we were really trying to separate out what was
noise from what was really a practical impact of that parameter.
I already talked about the linkage studies and then we rolled
all this information together, we determined which CQAs we
needed to consider for the control strategy. We said anything
that we can form, we need to consider on stress studies or other
things like that. So we had a relatively inclusive approach to
that.
Then finally on the theme that others have been talking about
this morning, we decided that we needed to include a post
approval lifecycle management plan that would allow us to talk
about how we’re going to verify or validate changes within the
design space after approval.
So for Perjeta, we had three main goals, one we wanted to use
sort of the risk based control strategy attribute testing design
to reduce redundant non value added QC testing. We wanted to
argue for wider acceptance criteria for certain critical quality
attributes that we felt had platform knowledge or even clinical
knowledge from other projects that could be used to widen those
acceptance criteria.
We wanted to obtain a design space. And I think we were pretty
successful in the first two of those buckets. We were able to
justify removal of some tests, we were able to argue for the
creation of a monitoring bucket for some attributes that weren’t
as critical and keep those off of the lot release testing. And
we could extend some ranges for CQAs.
But we weren’t successful with the design space proposal and
there were a number of reasons for that. All of which taught us
I think pretty important lessons. The first one was that we had
considered binding Perjeta to its target as a mechanism of
action, but not fully considered the fact that the molecule
could elaborate ADCC as a mechanism of action when we identified
the CQAs.
What that meant was that there was a CQA that was missing that
could be important for the activity of the molecule. And as you
saw the sequence that I went through, if you missed a CQA, then
you don’t identify the CPPs that influence that CQA and your
control strategy is not appropriate. So that was problem number
one.
So we went to the agency for the post action meeting and we
said, okay if we had identify that, would the design space have
been appropriately justified. And the answer to that was
unfortunately no and there were a number of reasons for that.
Which I think are quite important.
The first is that we had followed the example in the aMab case
study of defining the design space as the combination of all
critical process parameters. And that was one of the reasons why
we had that sort of conservative cutoff.
We excluded the non-critical process parameters from the design
space and said those could be managed in the quality system. I
think that was in retrospect a little too aggressive of a move
and what happened was, I think the agency got worried that CPPs,
that unit operations that don’t have CPPs, we could make changes
to without really reporting those to the agency and manage that
just within the quality system.
Also, they were worried about lack of oversight of the non CPPs.
And also it sort of had a trickle-down effect into thinking about
how you set up your experiments to identify those parameters
which had a significant impact on the CQAs and which didn’t.
Obviously you can narrow the ranges of those experiments to
where you don’t see an effect. And that can have the impact of
moving things off of the critical list. And so if you make a
very stringent definition of your design space, just around
CPPs, that raises these other questions about design and the
experiments. It just heightens, kind of, the risks that I think
regulators were feeling around that.
Another thing has to do with the confidence in the scale down
models, as Christine said all of this data is developed in small
scale. We’re not verifying the design space at scale for the
original application and we had more work to do around how to
convince the agency that our scale down models actually were
good predictors or at least of how process parameters would
perform. That the ranges that we identified at small scale would
translate.
This is probably the toughest thing for us. These are models
that we’ve been using for a very long time to predict process
development, to do post approval changes etc. But we hadn’t
really gone down the path of how much they could actually
probabilistically predict performance in a quantities fashion at
scale. And we’ve learned a lot about that, there are some
reasons why it does it, right?
The 2 liter reactor and a 12,000 liter reactor are kind of
different beasts. And there are some offsets that we may just
need to figure out how to deal with and verify. But there are
some maybe we can correct as well.
So all of those things were the issue and then the question
about, even if you had a design space, what does that mean to
you? How are you going to manage it post approval? So our lesson
is learned I think at this point, was really we have to invest
in thinking about the mechanism of actions and the analytics of
the molecule very rigorously early on.
It’s good to have discussions with the agency about; do we have
a common understanding of that before we set down this whole
pathway? But I also learned that regulators are also open to
moving away from traditional approaches to process and product
control.
But the degree of regulatory flexibility we’re going to get
really has to be earned. And it’s going to be proportional to
the amount of justification and data that we can actually put on
the table. In addition, anything that takes a risk based
decision that take something out of pre-approval oversight, it’s
still in the inspectional oversight but out of preapproval, is
going to be highly scrutinized.
How the design space is defined is quite critical. So we came
away from the first experience thinking that for biotech
products, design space approvals might be a pretty high bar and
I still believe that actually.
The other thing that we’ve learned I think became clear as time
went on that this whole idea of how are we going to manage the
knowledge and how are we going to manage change in a post
approval setting? And the design space discussion highlighted
sort of the broader concern I think about how health authorities
can assess the strength of a manufacturer’s quality system?
How well we’re going to be able to manage those kinds of changes
that they’re giving us flexibility for after the fact. The
picture of residual risk that the agency is accepting in the
dossier needs to be very clear. And quite frankly, the first
time we did this, we were so busy writing the dossier, that
printing it up in the end was something that was on the top of
mind.
But I think it makes a difference in how readable it is. And
there has to be something in the dossier that talks about how
we’re going to manage risk in a post approval setting. So risk
assessments are really important in everything we do.
I think quality by design for me, mostly means using risk
assessments to really understand where the risk is in your
product and your process. And I think they can be important to
paint the picture of how well you can make decisions yourself
and how well you can self assess change in risk management.
And really, it’s important to create a picture that looks very
solid, rather than a picture that looks like this. You have to
understand that each time we do a risk assessment, there is a
little residual risk left over, that’s probably never going to
go away but we have to have a very clear picture about how we’re
going to manage it going forward.
So for Gazyva, we did a couple of things, we conducted a pre
meeting, probably not as early as we should in development, But
this program was already pretty far along but we agreed on the
mechanism of action and what analytical methods, what bio assets
we were going to use to identify the CQAs.
We got that out of the way. We also enhanced our design space
definition, made it very clear that design space was for us was
the combination of all the non CPPs and CPPs that were presented
in the process descriptions.
In the Perjeta filing, we had presented all of the non-CPPs and
CPPs in the process decryption. It was just the design space
definition that was limited to the CPPs. We talked a lot more
about statistical and scientific basis of our scale models and
we tried to provide a more integrated picture of the overall
risk mitigation that was provided by various parts of the
control strategy.
We talked about a little bit more why we justify putting things
on control system vs. things that had a high degree of per
metric control. An important thing also was that we strengthen
the handshake between development and commercial. And this was
something that we hadn’t really fully done for Perjeta but had
more time to work on to really get our commercial quality and
manufacturing people, more familiar with the knowledge that was
developed during development and what that was going to mean to
them going forward.
I think internally that was very useful, I’m not sure that it
helped the review at all but internally it was a good thing. And
then we simplified and strengthen the palm plan.
I want to talk a little bit about what the PLM (Product Lifecycle Management)
plan that we came up with is. And this is just what we call it;
apologize for inventing a term but this is sort of where we’re bundling the
information and the filing that talks about how we intend to
monitor the product and the process in a post approval setting.
How we intend to manage change inside the design space and it
also can be where we talk about how we’re going to manage change
outside of the design space though the inclusions of some of the
things like protocols that Christine was talking about.
We also realized that the control system is a life cycle type of
thing and ICH even already had said, that you need to look
at this from time to time and update it. And we had sort of been
faced with an expanding legacy portfolio and needed to figure
out how we were going to do this.
So, commitments around how we might do that in the future are
also part of the palm plan for us. In a little bit more detail
for product and process monitoring, the palm plan and this is
really only like a 20 page document.
It’s not huge and it certainly doesn’t describe the quality
system at a level of detail where you would worry about change
management from a regulatory point of view. But it talks about
our approach to monitoring CPPs and non CPPs of the design space
routinely during batch review, as well as looking at excursions
and trends and how we would react to them.
It also talks about how we’re looking at key performance
indicators. It talks about how we monitor the specified CQAs and
make decisions on those before drug release.
It also talks about how we monitor CQAs that are not in the
controls system but are of medium criticality that we want to
trend to ensure that the data we developed and characterized in
the process preapproval actually translates into the commercial
environment.
It also describes how we manage change in a post approval
setting, it changes in case of Gazyva and focused on changes to
CPPs and non CPPs within the design space. And what we did there
was actually provide some examples of if we were changing non
CPPs vs. CPPs, if we were changing one unit operation vs.
multiple unit operations and how we might go about verifying
that.
In addition in some regions, particularly in the US but in EU as
well, we supplement this by adding comparability protocols that
talk about how we’re going to manage certain types of changes
after the fact.
I mentioned in the beginning that we had back in 2010 approved,
what we called an expanded comparability protocol which address
the ability to do site transfers for multiple drug substances to
multiple drug substance manufacturing sites. That is an expanded
comparability portal and it had certain products included in it
and every time we approve a new product, we add that to this
comparability protocol. So that we can facilitate site change.
I think you can see if we can have a design space approved and
we can foresee some of these more common lifecycle management
aspects, that you start to build a pathway to a lot more
efficient post approval change management. So this is the
beginning really of I think implementation of principles of
continued process verification and life cycle control system
management.
I think it’s important that we kind of continue down this path
because it’s just absolutely true. That process knowledge and
product understanding are going to grow during the life cycle of
the product. It’s unrealistic to believe that we’re going to
have mitigated all the risks that there are on the day that we
file the BLA or the NDA.
So QbD gives us the principles and the ability to talk about our
knowledge. How we look at our knowledge from a criticality
standpoint and make that transparent between the regulators of
industry. And provide a continuum between the process design and
then what happens in the post approval arena.
I feel like there have been a lot of benefits of QBD that have
been realized. And I know that QBD does not equal design space
and in fact people even get in trouble at Genentech if they say
it’s a QBD filing anymore. Because I think this is an
implementation of principles, of risk management, into process
design.
It’s been a really strong driver in the industry at least from
what I have seen. But the design space concept I think is a good
one because it’s pushing us to think about how we can actually
realize that concept. A lot of good things have come out of
that.
From my perspective at Genentech and at Roche, I think we’re now
doing more extensive evolutional process impacts on CQAs. I
think we’re looking at CQAs in a much more comprehensive way.
It’s driven DOEs to become state of the art. I think the fears
initially that design spaces may be huge, vacuous, big spaces,
actually hasn’t turned out to be the case.
When you’re doing multivariate experiments, the outcomes of those
are kind of by definition, narrower than the outcomes of one
parameter at a time. It’s allowed us to more systematically
identified CPPs and doing that in a much more meaningful way I
think.
I think that the overall control strategies and our ability to
manage those are stronger now. And all of that goes to supply
which I think is really the fundamental outcome of the
implementation of all of this. Is that once you’re in the
manufacturing arena, you have a robust process. I think there is
a really high incentive for regulators and industry to work
together to find ways to really take this to the next level.
I think we’ve laid a lot of good foundational blocks and it’s an
excellent way to move forward. So next steps what we’re doing,
we’re committed to continue implementation of the QBD paradise
across the Roche portfolio. And for us this is really important
because of the complexity that Roger talked about earlier in
terms of global change management.
There are many discussions going on in global arenas now about
quality by design and appreciating sort of this decision making
framework that quality by design allows you to talk about.
I believe it will simplify how we manage change or at least
create common views of, what are the most risky changes vs. the
least risky changes. So that we can spend the most time on the
more risky changes and maybe narrow the time lengths in places
globally for the least risky changes.
For us internally, we’re going to continue to fine tune our
concept and we’re making some improvements to the bio process
models to address this whole thing about scale differences and
offsets. Some of those are actually easier to do than others,
but the ones that are easy to do we are certainly going to
impairment.
I’m also seeing that it’s driving innovation in ways that I
think are really exciting. So trying to think about how we
generate this data at small scale, relevant to large scale but
more efficiently and faster and more cheaply. I think that’s
going to be another really good outcome of all of this stuff.
And lastly we’re starting to think very seriously about how,
when and why we apply the tools and the concepts to legacy
products.
As you said, I think there’s a lot of value there, there’s also
a lot of things to think about because the data sometimes, there
is a long history of data when you weren’t studying CQAs.
Now you’ve got to figure out what you do about that going
forward. So there’s a lot more to do there but I think we’ve
laid the foundation. So I just like to say thanks to a whole
bunch of people at Genentech and Roche, the list is really
getting long now.
Technical development teams and also to the health authorities
that gave us time, global health authorities to give feedback
and input to this concept. I think we’re learning a lot and we
will continue to learn a lot and I appreciate that. So that’s
it, thank you…
Moderator: I think we have time for one or two questions.
Sun: Thank you Lynne for sharing lessons and stuff for Perjeta and
Gizva, those are very helpful. My name is Sun Kim and I’ve been
implementing QbD as well. I have many questions but I’ll just
limit it to one.
When doing the risk assessment, which is one of the first steps
in QbD, you assigned RPNs (risk priority numbers) on the CQA’s themselves.
But when you look at how FMEA is originally used, shouldn’t you assign RPN
on the CPP’s instead?
Linking this tool to the control strategy, you would want (and can)
to control the process parameters, right? Not the CQA, the CQAs
are basically the outputs of what you control which are the
process parameters.
We find that it would be more practical to do risk
evaluation on the numbers on the process parameter and
show that linkage to the CQA… Instead of going directly to the
CQAs and assign RPNs because we know most of them (CQA’s)
would end up as high risk.
Lynne: I think your point is right, we don’t do FMEAs on CQAs or
RPNs because we don’t consider process control at that level. All we want to
know is if the CQA is important to the patient or not?
So we do a risk making and filtering that ranks the CQA and then
we add this, where did we get that knowledge on the certainty
score so we can’t have something be noncritical or lower
criticality but really all we know about that is the literature
or something like that.
So it keeps it above that line, I kind of think about the
control strategy, right? So the attribute risk
ranking and filtering tells you about severity to the patient.
The process assessment which is also more of a decision tree
than a FMEA, tells you about how well the process controls the
attribute. Then you put in your detections appropriately for
those first two inputs.
Moderator: One more question…
Bill: Good morning, thank you, I thoroughly enjoyed your
presentation. In particular, I liked what you
said about the linking experiments because it answers part of my
question.
What I want to get your thoughts about is, how did you figure in
your development, the variability of raw material quality
attributes and in process attributes.
These are very important, you have limited material when you
first start out and part of it is handled of course through the
life cycle. But I was wondering if that was also part of the
DOEs and how was that?
Lynne: Certainly, if you consider the output of unit operation A,
to be sort of the input
for unit operation B. That’s the perfect experiment and
sometimes we just do that at a worse case level and not do. The
individual DOES predict the worse case level for each unit
operation and then we run those.
If we find that we can’t accommodate the worst case, then you
might have some sort of an adaptive design space where certain
combination will not be allowed. For raw material variability or
starting material kind of variability, that’s kind of a tougher
question.
We do an assessment of all of the raw materials to see what
their criticality might be. And we try to include a lot of
variations as we do not only our DOEs but also our clinical
development.
For the most complex or the most challenging ones, we do have
some relevant experience. But that is a challenge I would say.
Moderator: Very good, thanks Lynne.
Please share your thoughts!
Subscribe to the email list to receive a practitioner’s view on implementing QbD..