QbD in Biologics: Genentech’s Success and Failure in Design Space Approval

Posted On

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..