MARIAH DEGUARA-PAGAN ON THE KM/QRM/CONTROL STRATEGY RELATIONSHIP AND PFIZER’S PROGRAM

At a session on knowledge management at the ISPE/FDA/PQRI Quality Manufacturing Conference in June, Pfizer Right First Time Program Office Senior Manager Mariah Deguara-Pagan explored the relationship between KM, QRM and the control strategy and the program Pfizer now has in place to strengthen it.

I kind of have an interesting role. The Right the First Time Program Office: I am based in manufacturing, but I really partner on doing QbD. When Paige [Kane, then Pfizer Knowledge Management Director, now with Merck] said that this talk…on quality risk management and knowledge management might be a good fit for me, it really is very much my day job. So I am excited to talk about this, because when you think about it, we do have a pretty compelling story. Today I am going to share how we leverage knowledge management techniques that help us facilitate the quality risk management process. We have organized our knowledge and have really provided it into a platform risk assessment library for continued learning. That has helped us be more efficient and gain additional insight about our process knowledge. I admit when I started thinking about what I wanted to present – trying to figure out how big of an onion to peel – the reality is what we are always doing is trying to get to control strategy. Because I am working on new product development, that is my goal. At the end of all this time we work together on a team [on] what is a control strategy that manufacturing can actually deliver and actually controls what we need to control in our product?

If we think about what that looks like – how we are using quality risk management and knowledge management to enable that surety – well we all have the same guidances that we are living through. We are working from these ICH guidances, and I will start by introducing them to a degree. But what I will really spend my time doing is thinking about, once we get that go to start building knowledge, we have a proof of concept, what do we do with that oomph to start with the knowledge build. So I will talk a little bit about product specific knowledge, and I will jump into platform knowledge – what we do with that. I will touch on aspects of the systems we use. I will talk more about the software and less about the document management aspects. And then I will really ground this in risk assessments. How do they grow with time? How do they get to the risk control, so that eventually we can summarize it into a control strategy? And in order to keep me close to 25 minutes, I will try to focus just on platform risk assessment libraries.

What is Knowledge Management I figured I did need to start with knowledge management definitions. Of all the ones out there, the library definitions, the ICH ones, I really think that the American Productivity and Quality Center one is are the most meaningful to me….

A lot of people think that knowledge management is document management. It is a core aspect of it, but the real trick to it is, how do you get that knowledge so you can reuse it to provide value? So how does that knowledge get to the right person’s hand at the right time, and in a format that is actually useful and reusable, and not cost prohibitive or effort prohibitive. How do you really put knowledge into action? So that is why I really love that APQC definition. I, of course, had to show this Q9 graphic, just because I think this quality risk management typical process always makes you think Q9. By the way I was able to swipe some of these graphics from a regulatory workshop two weeks ago that ISPE did on QRM.

This one I like because it thinks about, yeah, QRM is risk management, but there is such a strong aspect of it that is risk communication. And that risk communication is really valid throughout the whole product lifecycle.

If I think about risk assessments year on year and how they change, especially as a new product develops, one of the things we are always concerned about is that short-term memory. We will go back to a risk assessment one year later and say: ‘What was that person thinking?’ Or even, I will go back to one I facilitated, and say: ‘What was I thinking a month ago? What does that number mean? We realize that we really do need to be pretty cognizant of our KM practices. Are we documenting the rationale? Is this something that someone can reuse and make sense of? I like this graphic about risk, because when you think about a risk prioritization number in the FMEA, the really traditional risk, and you are thinking about how severity, occurrence and detectability come together, you are thinking about this idea in a desperate moment, and how do all those pieces come together. And yeah, we know all the pieces need to come together so we can prioritize and get to this point of having a risk management approach that actually fits what we want to do commercially. But when you really kind of take a step back and think about the parts of risk, I like this idea that the failure mode actually trips you up quite a bit if you do not get it right. So I have had teams come back to me saying, ‘I have this FMEA.’ But when we look at the net they cast, and what inputs and failure modes they considered, they were not meaningful. They were not the right mix. Sure, they did severity, occurrence, detection, but they didn’t get the right failure mode. So if you work from a library, or a really strict systematic way to brainstorm those failure modes, then you have at least got the right starting point.

And when I say severity, specifically for me in development, that is how I am engaging with my R&D folks and really getting into the science. What do they know about the product, and really the product quality and the impact on the patient? And when I get into occurrence and detection, I am really getting more into my R&D colleagues, and what do they know when they really think about historical knowledge, literature searches and deep models, and what can they tell me about it. So for me the FMEA is such a great way to pull together all of those types of knowledge. This one is a way to start thinking about getting everything together, right. So this quality risk management is going across the entire product lifecycle.

Probably like most of you guys, I really got into QRM when I was at manufacturing, when I was a shift leader defending some really annoying deviations, or when I was trying to improve cycle time. And that is how I really started thinking about risk management. But since I moved into development, I think of it much more as a proactive tool. So I am able to think about, when we are early in development, we are starting from prior knowledge. But then as we go into development and tech transfer, we are doing this huge increase in knowledge. It is a time when you actually have FTEs who get to spend time building knowledge. So using QRM approaches are giving them the systematic tools to identify, control, really create that process understanding, so that you do have a basis for continuous improvement years down the line when we have an improved product. And the pretty key part of that is using that institutional knowledge, that prior knowledge, from one product to another, so you are not reinventing the wheel often – a lot of us like to invent things ourselves. So that is a watch out. This last slide that I want share on the background is something that we had been sharing with our groups as we talk about control strategy. So an issue that we have when we are working first in human and we are trying to think about control strategy, it is really hard to think what is a meaningful control strategy when you are first in human.

We are saying to folks that even when you are working with a young product, there are things that you should be thinking strategically that can help us understand, ‘will this have a typical control strategy or does this need a novel control strategy? Is it different from platform?’ So we brainstorm a lot of different deliverables at milestones. What we realized when we would looked back at them was that a lot of these deliverables, if you actually have platform knowledge, a good amount of your work is done. You can focus on the exceptional areas, and you can really be a lot more strategic in your thinking about control strategy. So it further made the case for us to focus on the knowledge management and the risk management when we are in the development space.

Pfizer’s ‘Co-Development’ Process So there is a little background, and now we move over to the real example that I would like to share. This is really just looking at, how are we going to build control strategy? How are we going to establish and document knowledge? And although I not going to write the word QbD on this, it truly is how we are using science and being risk-based in our decision making. In Pfizer we have a specific approach we take called ‘co-development.’ It is obviously our own little Pfizerism, our own little word. The idea is that once we get proof of concept around phase 2B, depending on the molecule, we will have an early engagement with the team. That team is going to be purposely mixed between development and manufacturing. They are truly partners who stick together from that point through product approval.

I think I heard the statement earlier about the warranty on the product. That is basically the group that is keeping an eye on how that product is going to perform, and who is going to stand behind how the product was developed. That group shares accountability. I am sure that Pfizer is not the only group that does this, but we have different systems between development and manufacturing. We use two different Documentum systems. We have got a few differences there. But the ‘co-dev’ landscape gives us a way to share systems, and really figure out where should we actually harmonize systems versus where can we be different. It also gives me a place to do iterative risk assessments. And my role ends up being making sure that all of our teams have tools and facilitators to do that. Just to show you a picture of a co-dev team. I just want to drive home this idea that the co-dev team is both a mix of pharmaceutical sciences or development folks and a mix of manufacturing or supply folks. When we have a risk assessment, we will pull a mix of them together. We will get a little bit of a cross functional mix between drug substance and drug product to look at overlaps between how we each can improve or mess up the quality of a product. We will add in our global CMC, quality and statisticians, who will help us think about where we need to build process understanding. And then my group would supply one or two facilitators to help the team have those discussions – to adhere to some systematic approaches and to actually make people talk to each other. So this slide is actually going to give you some insight into how we actually do that. Specifically within biologics, we have pretty much written into stone that we are almost always have a minimum of three risk assessments during the development lifecycle. The first one is going to be once I have that proof of concept and I know where I am going to manufacture or I know enough about it, and want to drive my experimental planning. I am going to my first risk assessment using a cause-and-effect matrix. And I will show you a picture of that in a couple of minutes. And that is really going to look at that relationship between the process and how it impacts the quality attributes. Once that completes, and that helps me prioritize my experimental plan, then I will move over to updating that. So six months to a year later, I will come back and I will update my CME based on what I have learned. And then I will actually add in a failure mode effects analysis. Because by then I will have enough confidence that things make sense, so I can then add in some of that occurrence and detection, risk mitigation information and create a draft control strategy. Now luckily in biotech, I get to do my validation PPT batches prior to the filing. So I actually get to test drive that control strategy, my commercial control strategy. And I will do one more assessment to revisit my C&E, my FMEA, and everything, and do any fine tuning that we need. That will pull me into a commercial control strategy. So I have got this next cascade, which looks really nice. If you think about it with your resourcing hat on you would probably see that the one thing that you might worry about is, how much time does this take? Is this efficient? Is this effective?

MAB Risk Assessment Library So what we have looked at – and we have done this both in small molecules and in bios, are there risk assessment libraries. The specific example I walk-through is the monoclonal antibody or the mAb risk assessment library. What happened is about two years ago, we started actively building this, because did get the challenge from our bios folks. Wyeth came in with a lot of bios experience. Legacy Pfizer came in with less. And we had to combine these two companies and figure out, what is our mAb platform? How do really get to be a best-in-class biotech company? And how do we leverage our size? We looked at how we had previously been doing our risk assessments, which was starting with either a blank cause-and-effect matrix that then a team had to have a lot of fun filling out. Or we would sometimes copy one from a similar mAb. We would add in all the rationale, and it would be really specific to whoever was completing that risk assessment. We would also have our meetings, which required some preparation, so that the face-to-face meeting was not like a sprawling five-day boring thing, which risk assessment can occasionally be. If you do your pre-work, you can then actually highlight the higher risk aspects, and talk about that, and focus your face-to-face meeting on that. Although we had figured out how to do things in the older paradigm, we recognized they were not as efficient and effective as they could be. The idea was, let’s move to platforms. Let’s start with our pre-populated platforms, the C&E matrix. We would really only focus our risk assessments on deviations from the platform. Actually a really big part of it is, because we got this big group of subject experts together from those two legacy companies and a couple of legacy geographies, which just had different opinions, we were able to get agreement on consistent rationales for why we thought we had relationships. So we got to take a little of the personality out of it. All of this meant that when you are doing your pre-work that you are cutting your pre-work time about in half. When you are doing your face-to-face meeting, same thing. You are cutting the time you need to talk about the C&E in half, because you are getting rid of the standard stuff. But what we do with the extra time is we actually focus in on what is higher risk, what is exceptional from the platform. So we actually tell folks, ‘don’t count on reusing your time. Instead count on focusing your discussion about what is exceptional and what needs the attention.’ The way we were able to get a little more out of it is that the R&D folks had realized that they had a bunch of silos of knowledge from all of the mAb’s they had developed. So they had experimentation that could definitely be optimized. So they looked across the series of experiments, and looked at where could they actually create an optimized experimental plan, and basically get rid of your big screen study and use your prior knowledge to create the typical optimized plan that really targets the process understanding you need. Same thing with prior knowledge: We had a ton of reports, and would you know which one to pull when you needed it? So instead, creating a single platform knowledge summary that is actually usable when you are writing your BLA, and you can actually refer to rather than refer to a whole bunch of products. We actually worked on this for quite a while. I was really impressed with the development teams that

worked on this. They took major ownership and a lot of people really stepped up to own their knowledge. And so the subject matter experts got together over the course of a chunk of time to really agree on what is our platform process. Once we understand that platform process, of all the quality attributes you have in the bios, you know, what percent of those are not profit specific? And can we actually agree on standard names for them, standard criticalities for them? And once you get that agreement on the basics, then you go into what is our process flow diagram, parameter names. What we would burn stupid time on, is this agitation or is this mixing? So agree on basic nomenclature, and that is the knowledge management part of it. And now that you have gotten to that part of it, you can actually get to the science, and get yourself ready for more of the QRM aspects.

So they scored cause and effect matrices together, added in the rationale, and did the hardest part of capturing the prior knowledge. So after that team ran out, we were able to pilot it with one product that went really well. We had to wait about a year until we had another product that was ready to be used again. It continues to go well, but definitely as we have more products use it and have really positive gains from it, we also do realize that we actually need to maintain our platform. You don’t just build it once and forget it. We are tuning the figuring out what we have learned, keeping track of what the experts have seen, and what has happened at scale as we have done more manufacturing. So we have seen that add value to continue to maintain the platform.

Putting the Knowledge to Work Now we go over to the slightly more techy side of it. All of that knowledge is great, but how do you actually put that in people's fingers? So we have them use the software called Pharma Investigator. You can really use whatever works for you. The reason we went for this is it was something web-based. And it is something that I can give anyone at Pfizer read access to, and they can get in and they can view knowledge, and all of the knowledge is product specific. Author access [can be granted], and they can mess around. And even if I have five different sites who are making product, they can all enter what is going on with them. We have been using that to keep track of our quality risk management and a bit of knowledge management. The way it works as we have got some foundational aspects captured in a flow diagram. We have our quality risk management tools, the cause and effect and FMEA. And then we have a few different summary studies. Once we have captured that QRM info once, you can then rearrange it into a fishbone diagram, into a functional relationship table, into some different summaries that you would ideally use to help with an investigation or as you are writing your filing. And we also have ways to hyperlink into our Documentum system or authoritative source location. Just to give you an idea: A Process Flow Diagram (PFD) – sure this unit operation at the protein A step is just the steps that it takes to do that chromatography…. This is actually from our mAb platform. I am actually going to look at a given elution buffer, which is highlighted, and I am looking at specifically a parameter within there, the buffer pH. The detail at the bottom are primary info fields about that elution pH. So I can keep track of what is my proven acceptable range, what is a hyperlink

to the report where I demonstrated that PAR. Anything that we need to keep track of, I can keep track of it. I might capture it here, or I may capture it in the C&E, or I might capture it in the FMEA. But it gets updated in any of those locations and reused and visible in any of those locations. And so although a tool like this takes more effort from your people, the thing that usually sells this is that you can reuse the knowledge. Anything that has a little pyramid attached to it means that that knowledge is reused elsewhere. So for example anything elution pH is also reused in a cause-and-effect matrix, which is what I will show you now. So you are going to see that elution pH on the left as an input. You are going to see my quality attributes on the top as outputs with waiting. And in the middle you will see the relationship….And on the right you will see a final score. So at Pfizer we use numbers. That is why we use a C&E matrix, and this is just an example of how it looks. But because I have this computer system platform to keep track of all my QRM aspects, my folks have a way to capture for my standard mAb, what does that high, medium and low score look like when it is not intuitive, why something is a yes or no relationship, or just in the middle. That is when they would add rationales. So all those yellow sticky notes are the rationales to guide you to think about, where do I possibly need to build knowledge depending on what I am in the platform. And then the far right side is the total score, which should help me think about – okay, something with a high score technically has a big impact on product quality or performance. Do I know enough about each of those? It does not mean that I need to know more, but am I comfortable with the package I have about them. That is why cause-and-effect informs my experimentation. And one thing I personally like about because I like to reuse is the cause and effect is basically just a whole bunch of fishbone diagrams. So if I have an investigation after the fact, I can just go and pull out whichever quality attribute is misbehaving, and I have the start of my investigation. And this is a thing on the manufacturing sites – they love this, because this puts them in contact with the scientist who worked on the product five years ago. Just to show you the next steps: A year later, the FMEA gets written. It is created directly from that C&E – the same first two columns of the C&E. We are reusing those failure modes from the cause-and-effect matrix, which came from the process flow diagram. We are adding in that occurrence and detection information that would not have been part of the C&E. So we are getting more disparate knowledge combining together. We are also putting in the rationales that actually give this meaning. I recently had a team push back and say, ‘we don't have time to do anything more than scoring. We are not going to talk about the cause for this to occur or the control.’ And I said: ‘Then don’t do that FMEA.’ I do not care about a…number. I care about the factual discussion. An FMEA is super, super detailed. It is really process focused to the nth degree. And the point is that at the end of this you have to take a step back. You actually have to say: ‘ O.K. I have been working on this project for years. I need to summarize this for validation, for my filing. Let me rearrange the knowledge from a quality attribute perspective instead of a process perspective. Let me think for each quality attribute, if I look across the process and all my raw materials do I have confidence that I have identified those critical few areas where I really do need to focus? And can I tell the story in a compelling manner in my filing, so that the regulator can follow it? Can I tell the story in a way that manufacturing will agree to what I have asked them to do and commit to post-approval?’ So that is how it all comes together, and how the knowledge gets summarized….

So that is really where I wanted to end. I just wanted to give you guys a demo of how we build the control strategy, all of the different ways we think about, once you get knowledge, how can you put those pieces together. How can you get to risk control, and thinking about it from that perspective of platform knowledge. So that is where I am going to end, just acknowledgements to some of my colleagues who worked on QbD, Right First Time, and some new products.