Kyriakos Michailaros is Head of Drug Products Services at Design Space InPharmatics. With over twenty years of experience in exploratory, clinical phase and commercial projects within the pharmaceutical industry, Kyriakos brings a wealth of knowledge to today’s show. In this episode, Kyriakos, Ed, Meranda and Brian discuss product development reports, the important role that timing plays in these reports and trends in drug product manufacturing. Kyriakos shares specific examples from his career that showcase how influential these development reports have become with reviewers in the industry.
Hello, everybody, and welcome to CMC Live. This is the start of the NFL season tonight. The Chiefs and Texans. Anyway, Brian, who do you have?
Oh, it's clearly the Chiefs. Until somebody knocks them off, it's the chiefs.
Yeah, my son's a huge chief’s fan. How about you, Meranda?
Raiders? No [laughter].
“I think it's never too early, and ideally; you want to have the story of the development program pretty much summarized by the time you're making an NDA submission.”
No, you're one of those?
Hey, I'm not any of those. That's just what my dad liked.
So, this is a September 10th edition. Today we have Kyriakos Michailaros on the show, and we call him Q. He's not the Q from the Bond films, by the way. He's a drug product subject matter expert on solid oral doses, control releases, inhaled products. He's worked on creams, ointments, liquids, tablet formulations of all sorts. Twenty years of experience supporting CMO selections. He's been involved with due diligence process validation efforts, protocols. He's been a man in the plant, person in the plant these days. He holds an MBA in management, undergraduate chemistry from Lehigh University. He's also very fluent in Greek. In today's podcast, we'll talk about product development reports. We'll go over timing, the content, and trends in direct product manufacturing and these types during COVID. So, Q, let's get this episode started by going into some of your backgrounds. How did you get started and share some of your thoughts?
Well, how did I get started? I loved science. From the beginning, I was always a geek and interested in the basic sciences. But, going into college, it seemed like to major in chemistry or physics, you kind of have to go all the way to get a Ph.D. I wasn't sure if I wanted to go that far right off the bat and make that kind of commitment. So, I made a compromise and went into chemical engineering, which, you know, is still pretty science-heavy, but I thought it would give me good job prospects coming out of college. Sure enough, I got a job working in pharma right out of college, and I never looked back. It has been over 21 years now.
Q, given the background and the breadth of experience that you have, I had a question. I wanted to know, knowing some of the clients we have and some of the work you've done, in your mind, what would you say is appropriate timing for a development report? When is it too early? Is it too late? Is it ever too early or late? In your opinion, when is it a good time to start capturing development decisions, experiments, things like that?
That's a great question. The approach that is becoming more and more common these days to start immediately and have it be a working document is helpful. It saves time. It helps a development program sort of having a reference point to see where they stand, what is left to be done, and summarize the work that has been done so far. As far as too late, I mean, ideally, I think a development report should be in some close to final state at the time of regulatory filing, NDA filing, or ANDA filing, but it's not absolutely necessary. You know, we've worked on many submissions, where the source documents, the data that went into the submission was in source documents, and, you know, you have to go there and dig them out. It's a little bit more labor and time intensive. You have lingering questions about whether or not there was something, some aspect of development, that wasn't captured. Some document that you know isn't in the files shared by the client that you're working with on a submission. So, I think it's never too early, and ideally, you want to have the story of the development program pretty much summarized by the time you're making an NDA submission.
If you could expand on that in a minute. That's the regulatory piece and what feeds into a comprehensive filing and the development sections. What about on the manufacturing floor? So, you've got a process that starts off at a bench scale or a very small pilot scale, and now you're progressing through. I've heard arguments say, “Well, we're not GMP yet. So, we don't really need to have any sort of record of our product development.” But at some point, they intend to be that way. So aside from the regulatory benefits of having that, what about on the production side as you move through and ultimately up to validation and CQA and things like that?
Well, I mean, I don't necessarily agree with the argument that you don't have to summarize non-GMP work because what the development report and the submission eventually are intended to do is tell the story of duct development. Even though non-GMP batches may not have been evaluated in humans or may not have gone to clinic, many formulations and process development decisions are based on those non-GMP pilot scale batches. Those quick and dirty batches often determine what excipients you're going to use in your formulation. They determine if you're making a tablet that uses a granulation, which method you're going to use for granulation roller compaction versus, for example, fluid bed granulation or something like that. So, despite not being GMP, those non-GMP work steers the program, and for that reason, should be captured in a development report.
Fantastic. Obviously, there are advantages to having it under one roof and one report, but as you move into validation, creation of the protocol, things like that, do you often go back and refer to that? Or is there a delineation between, “At what point we stopped looking back at the past?” How does the content of that work it is way into validation?
I think, at the point of validation, you're essentially demonstrating the repeatability and reproducibility of your commercial process. You're demonstrating that it's reproducible relative to your registration batches, which may not have been a commercial scale. It's very common to do a SUPAC scale-up after submission and before validation. So, the validations are going to be showing equivalence in the process to your registration batches. Your registration batches are going to be the primary reference endpoints in your development report. Once validation is complete, you're generally going to be referencing back to the validation batches, but up to the validation, what you're trying to reproduce are your registration patches.
So, Q, I just realized, like two years ago, I wrote this blog. It's still on our website. I just found it. It's called, “Hey, Google, tell me about the importance of living development reports.” Can you talk a little bit about why your development report should be a living document updated?
“A good development program will do risk assessments at certain points along the way and assess. For the indication that we're going for, the dosage form, what are the major concerns associated with developing this drug product.”
It just saves a lot of time. You know, by having your development data and conclusions automatically downloaded to a common document, even if it's not necessarily formatted for flow and such, what you do have is one place that has all of the critical information upon which you're basing your development program. So, if you’re dealing with time, if you're having a meeting with the FDA, or you're planning some sort of filing, you know where to find all of your information, all of the relevant information that you have based your development decisions on. So, it saves a lot of time, making it easier for everyone to know where all of the relevant development information is.
So, your understanding of the requirements enables you to ensure that the project contains all the needed elements for success. That's great.
Then to go one step further, you said something that had me paused. I don't know many development programs that have been complete successes. Everything they've tried to explore, every avenue in process improvement/process development, how do you handle those things that necessarily didn't work? How do you capture that information? Or is it just, wasn't done move on?
A good development program will do risk assessments at certain points along the way and assess. For the indication that we're going for, the dosage form, what are the major concerns associated with developing this drug product? For example, there are trends in the industry towards going to direct compression of formulations for tablets, where basically a bunch of powders are blended and then they're just discharged and run on a press to make tablets, as opposed to a granulation process where all the powders are granulated together to make a different intermediate material. For a direct compression formulation, the main concern for a potent product would be de-mixing, content uniformity, and so forth. As long as the primary areas of risk are covered and have been appropriately characterized, namely, if you can demonstrate that your mixing process appropriately mixes your powders, and they don't de-mix during discharge and compression, and across the compression run by doing stratified content uniformity. You've addressed a major concern for that drug product. For example, with a chewable tablet, hardness is going to be a major concern. You're going to want to evaluate the hardness of the tablets. But if, for example, there's some data point that you've got a longer development program that was out of the ordinary or unexpected, it may not have relevance to the quality of the drug product. At that point, it's typically a business decision as to whether or not you want to spend the money to get an answer maybe or somewhat of an answer, but often, if the major risks are covered, that's the most important thing. Assuming that all the other regulatory requirements are being met, you can simply move on by assessing what the risks are and making sure that those are covered. If something's not critical, it can be delayed for later, or you can make a business decision as to whether or not to pursue it.
That's a good point. One of the things that we've had on a call with clients, or we'll have a client come in, and they'll inquire about a product. Let's say they're looking at multiple strengths, and this product has been around forever, and they consider it to be a slam dunk, so to speak. But then they start to run into issues, as they start experimenting with strengths and say content uniformity, things like that. You go back to the development report; what do you look for in a comprehensive development report? Because we're talking about this now, I think the importance of development reports has become relevant in the last few years. In the past, it was, “well, this person developed here, then it stayed in their notebooks, and then this one went over here,” and they never really talked to each other. So, I think you know the client, this was about four years ago, where their weaker strength had issues had CU issues, and when you go back and look at that development, how can you tell if it does check all the boxes, or if you do have to do additional experiments?
Again, this goes back to what are the major risks associated with the drug product you’re developing and in the formulation? So, in the example of, “no, you're making a common granulation of active, that's then being used in a tablet formulation at different levels to produce different tablet strengths,” the one variable you have among your tablet strengths is the amount of active that goes in them. So, it's important to see why the lower strength would be having issues with the others in a situation like that, don't you? In any situation where you're mixing powders and then compressing them, you run the risk of de-mixing. So, in a situation like that, what you would do is, what I would do, is do sieve analysis on the powder blend from the powder blend of the granulated active subcomponent and the overall formulation. What that will tell you is if you have a difference in concentration of active at different particle sizes of your particles, the reason why that's important is because the particles tend to de-mixed, and segregate based on size. So, at that point, if you know that my fine particles are rich and active, and my coarse particles have less active, what you want to do is ensure that your fine particles are continuously mixed or are appropriately mixed in the formulation, and that's notoriously difficult to do, fine particles are known to de-mix. So, by knowing that, “okay, this powder that I'm compressing, it may be uniform in terms of its content, but among the particles inside the powder blend, they vary according to size and concentration.” So, you can you've diagnosed your problem at that point, and maybe you have to take additional precautions. For example, another granulation step or fine-tuning your final blending process to make sure your portion of your particles that are rich, inactive, or you know the opposite maintains uniformity throughout your compression process.
See, I think it's important because this is a prime example where you had early development history, but you didn't quite understand the dosage forms that it was going to wind up becoming. Like that strength that we talked about that was added late and then ultimately taken away. We have had calls where clients are still determining their dosage form, and they don't quite know which way they want to go. They're dealing with the clinic and marketing and how they want to handle it. So, when you look at a development program, before that final decision is made, are there standard box checks you look for, for completeness, where you would advise a client look, “understanding that the final dosage form is decided, at a minimum, you want to look at ABC.”
Yeah, I mean, for any potent compound or any drug product with the active is, let say, “less than roughly 5 or 10% of the formulation, let's say less than 5% of the formulation,” uniformity and de-mixing is going to be a concern, especially if it's not granulated. This goes back to the product-specific aspect of the approach taken to development. For that type of product, you're going to want to look very closely at uniformity and make sure that appropriate characterization has been done around the blending the discharge of the blend, and the compression process, and stratified content across the compression run to show that you're not getting segregation during discharge of your blender and under your press. Another example would be a BCS class three or four compounds that may not be so soluble or so permeable through gastric membranes. For a product like that, your main concern is going to be dissolution, disintegration. For a product like that that falls into that BCS class, you will want to look very closely at the development of the dissolution method and the dissolution data at all stages of development to know that your dissolution isn't changing across scales; you have it appropriately characterized.
Okay, that was pretty technical. I'm processing that. I'm not a drug product person. I wanted to bring it back to something regulatory, which I used to be. Applying, you know, drug development report information into module three documentation is very important. It's often overlooked at the outset of a project because of the misconception that you don't need to write things down, and you don't need to bring in writers until you're ready to write your NDA. I think that thinking is a mistake, you probably agree, right? So, your experiences with companies that use disciplined, systematic approaches from the beginning. You know, they use project documentation to drive their approach, their strategy, their story. Can you talk about maybe some efficiencies, cost-effectiveness that comes through that versus companies who don't, some mistakes that you've seen?
“Particles tend to de-mix and segregate based on size.”
Well, the norm is not to have technical writers involved from early in the process. Normally, we get a jumble of somewhat organized or somewhat disorganized reports that may or may not be complete. From that, as a CMC consultant, we're usually tasked with piecing together the development story with that, and with those documents, and circling back with our clients to ensure that what we have is complete, and so forth. If you're taking the approach of using a working document and just keeping everything in one place, you're building efficiency into your development program by simply doing that. You're keeping everything organized, and it's easy to know what has been done, the data upon which decisions have been based, and what's missing because it's easy to reference the CMC at the ECD outline relative to your documentation and see what's missing.
Okay, so going back to that succinctness of documentation and being consistent from the beginning kind of emphasizes what you just mentioned there. Cost and time savings, you know, in the end, we wind up going back and rewriting things, and that takes time to do that and costs money. So…
I think for me, the money python line, and now for something completely different. There's the regulatory aspect, but let's say some of our clients, their main goal is to take a product so far and sell it, where they may not be in that filing. However, the due diligence part portion of this is, this is a viable project because the new partner intends to take it on and file. So, in the sense of, let's say, “That's the goal. Let's say the client says I'm going to take this so far past the IND, and then we're going to shop this to someone else.” Do you really need that development report?
Yeah, I mean otherwise, you're making the due diligence process more difficult. Without a central repository for all of the information, as I said before, the acquiring party is going to have questions as to, “what's been done? Is what I'm looking at complete?” Questions can arise as to, “this was done here, but I'm not sure why. I'm not sure what the rationale was.” So, in those situations, I think it's actually more important in a situation like that where you don't want to take a project all the way to completion to have a working document because you're not then scrambling to get something together that's coherent, if and when you enter talks with a potential buyer.
I think it gives the impression that your program is really in a state of control, even in the early phase.
Absolutely. That's a really good point. But, yeah, it's just a more conscientious way to be running your program. I think, you know, a savvy buyer would be able to recognize that.
Yeah, and it's unfortunately acceptable in many circles. We see it all the time when I report what any activities can be created after the activity has concluded, maybe even by folks that weren't involved with the activity.
It's a good point. One of the things that we've had a call for in recent months, more than we had in the past, is to come into a program that is working towards a filing date. Some of the more forward-thinking conscientious clients want a gap assessment done of their program. To really give them an outline of how ready they are for their filing, we've got two camps. You have one that says, “It's time to file, quick, get everything out of the closet and stick it in the submission.” There's another that says, “Okay, we have time here, and we want to really get a true understanding of where potential gaps or risks may be to our filing.” So, when you come in, and you represent the technical SME, and let's say we're moving towards an NDA. What do you look for? Because we talked about your technical experience, but you've got quite a bit of experience in supporting filings as well. You work closely with regulatory to develop those technical sections to review against the source information. What do you look for, in terms of a program and robustness, or regulations, but as we all know, sometimes they're a bit broad in scope? Now you've got someone, like yourself, that comes in with experience. What's your approach to something like that?
Well, for that, one thing you can't get around, and it could really delay the program, is if you have the appropriate stability information. So, I would immediately check to see if the packaging configuration they have finalized, in the formulation they have finalized, in the process they have finalized, is, in fact, what is up on stability and what they're basing their expiry-dating on. The reason that would be the first thing to look at is because it takes time to acquire stability data. It takes time to make batches and put them on stability. So, any remediation of a gap there is going to take some time. So, that's what I would look for immediately.
Another thing I would look for immediately is whether or not there's any indication of stability issues with the formulation of the dosage form because that's something that will be very expensive to remediate once you file. You're probably looking at refiling at that point unless it's a minor adjustment to the formulation. So, what I'm looking for are things that will take a long time to remediate if they're not there. Some other things are, have the process control parameters been appropriately characterized? Do they make sense for the drug product and the processes being used to make it? For example, if it's a direct blend process, is the blender, the blend time, the order of addition, have those all been looked at and shown to be repeatable and reproducible?
“Some reviewers, or it seems, can be primarily box-checking. Taking less of a holistic risk-based approach, which is kind of has been the trend for some time now. I try to focus on what is actually important for this particular product and has that been explored appropriately.”
So, Q, it sounds like from the beginning you're going to want to talk about, with any team or CMO or whoever you want to talk about, a basic documentation plan, right? You mentioned a few of the steps. Coming back from the regulatory angle, during examinations, reviews, any products missing (any good document explanations for decisions, or any of the historical chain of events), things like that create issues or creates red flags with the reviewers. Not having a plan sounds like your kind of on the wrong track before you even get to the development report. Can you tell us a little bit about the documentation plan? When is that timing? When does that need to be updated? You mentioned a few key things that you want to get in there to consider, even prior to when the timing comes up.
Sure, to kick off a project, somebody's going to be making a Gantt chart that lays out in front broad strokes the entire timeline from early phase potentially through filing. Some of the milestones along that path are excipient compatibility, finalizing your formulation, end of phase two, and potentially end of phase three. At those points, I think it's important to have at least a report or a risk assessment documenting the data collected and the conclusions and decisions made based on that data for the development program. Like I said before, it's common to have your data in disparate reports up until the time of filing. It's better to have them consolidated into a coherent story. Some of the milestones, again, would be documenting your formulation decisions. So, excipient compatibility or formulation report, a process development report that says why we chose this process over that. Ideally, a characterization report outlines your critical process parameters and demonstrates that you can consistently make the product.
Okay, any thoughts on product development reports and sections of module three? For instance, there's a lot of different conformance information, pretty much the story behind the story, in P2, the pharmaceutical Development Report. Any key areas to think about there?
For me, it would be product specific. So, a formulation, for example, let's say a formulation has some sort of excipient that's not commonly used, I would look in the P2 seconds to clearly explain the rationale and the data upon which decision to use this nonstandard excipient that was based, it's really product specific.
That's a great point, though. That's a reviewer’s perspective. If you were looking at this from the reviewer’s perspective, you would go right to that or look for that.
A good reviewer would do that, yes. I mean, some reviewers, or it seems, can be primarily box-checking. Taking less of a holistic risk-based approach, which is kind of has been the trend for some time now. I try to focus on what is actually important for this particular product, and has that been explored appropriately?
Because you never really know the type of reviewer you're going to get.
Yeah, and it is science-based?
Yes, absolutely. At the minimum, you need to check the boxes. You need to have the particular issues that are known for that type of formulation, for that type of drug product, for that type of packaging configuration. So, you need to have those issues pretty well covered because you can expect them to get scrutiny.
See, and I think that's a really strong point. That's where you can have a technical author take source information and plug it into the section as per the guidelines. However, you really need to make sure you need that technical input and oversight in conjunction with regulatory to make sure that the story holds water. To make sure it stands up. So, I think that point you just raised is a prime example of why you do something like that. That's very helpful. Thank you.
All right. I think I have a phone call on hold over here. Okay, I think it's Meranda Parascandola. She's calling, and she has a question for you.
Oh, she does. That's interesting. Did she relay what that was? Or?
No. Okay, welcome, Meranda.
So actually, Q, I had a few questions for you. But you guys kind of laid them out. I was going to ask you if they weren't doing a living development report, compiling it together, piecemealing it from some of these notebooks, some of these notes, the previous owners, is that something that they should look at doing? So, if they have all of their pieces and in different ways, should they pull the puzzle piece together for the agency to review?
I mean, it's rare for the agency to sort of outside of a, for example, a pre-approval audit, where they show up at the door of your manufacturing facility and ask to see those things. It's rare for an agency to request source docs. So, I absolutely do think that, at the minimum, if you're not going to have a working development report, what you need to have is a working document repository with a file structure that can be easily followed so that you can go back and know what you have, and piece together a report or a submission from that.
Okay. [pushes button] “That was easy.” Now we get to my favorite part. We switch this up all the time. It's called the lightning rounds. Whoo. Q has substantial experience in the manufacturing facilities to have it. Was it King as well?
Yeah, I worked at Rhône-Poulenc Rorer, before it was a Ventus. I worked at Teva for quite a few years. Then, after that, I worked for a subsidiary of Johnson and Johnson called Alza. Then back to a company called El Pharma, which was acquired by King, which Pfizer then acquired, and then Teva again, before getting into the consulting game full time.
So, in the spirit of the lightning round, we can ask you any technical question about solid orals, process development, anything like that. Any trends you've seen in the last six months, even with the lack of travel and the kind of culture change in the world. Brian probably can ask better questions, technically, though. So I'll save my one last one for the end. Brian, any questions you had about solid orals that you always kind of wanted to know, or maybe just heard a lot, and you just want a different opinion? Or see what his opinion is?
Yeah, no, I think I do. I have a couple. So, can you explain to me the term friability and what it means in tablets? I worked a little bit with it, and it's something that I don't know if a lot of people know much about it, but it's typically an eyepiece. I mean, it's an in-process control, typically, right?
Yeah. So, friability is just a measure of the erosion of your tablets during what would be expected to be normal handling. So, to measure friability, what you do is take a set number of tablets, it's common to do 30, put them in a device that's going to tumble them for a specified period at a specified rate, then you dust them off after that, and you reweigh them. Ideally, they weigh pretty close to what they weighed before you tumbled them. If your tablets are prone to erosion, you're going to get more weight loss, the edges on the tablets will chip off, you're going to lose that material. Typically, you want your friability to be below 1% or 2%. It's particularly important if tablets are going to be pan coated because they're tumbled extensively during a pan coating process. They're tumbled usually for an hour or more. It's pretty common. So, you don't want to be rounding off your square tablets in the process of coding them. It’s just a measure of how durable your tablets are, how resistant they are to erosion during handling.
When you talk about tablet manufacturers, what is and how are coatings applied? I hear that term all the time, and when you look at a tablet and pull it out of a jar, there's several coatings and thickness and things like that. How is that done?
The most common way – there are some variations on this theme – but the most common way is pan coating. Essentially what pan coating is you can think of a pan coater similar to a clothing dryer with a spray function inside. So, you put the tablets into a clothing dryer, then inserting your arm, spray paint them as they tumble in the dryer. As they're tumbling, there's warm air coming in one side, and you're applying the spray to the tablets. They're moving through this zone, where a mist of spray is applied over time. Then they're blown with hot air, and then spray is applied and blown with more hot air. So, over time, for an hour or so and many tumbles later in the machine, the tablets are evenly coated without clumping together. So, you want to fine-tune your spray rate, fine-tune your inlet air temperature, fine-tune your gun-to-bed distance, and atomizing air pressure, which is, you know, something that controls your droplet size. It's very important, too big of droplets aren't going to dry fast, and they could lead to tablets sticking together, and you could have one big piece of granola almost inside your coater.
There's also a less common technique. It's more antiquated. It would be pan coating but using sugar by hand. Actually, some over-the-counter products are coated with a process similar to this, where an operator actually ladles in some sort of coating liquid that's typically a sugar solution with some sort of colorant or an opacifier like titanium dioxide. The tablets are tumbled without airflow. It's more of an operator technique-driven method. It's the old way it used to be done decades ago.
Literally sugarcoating it. Okay, I've got one more, sugar in the pan.
That's right. Yeah.
You can keep going, Brian. You're on a roll.
In your experience, what is the wackiest drug product dosage form you've come across where you scratched your head and said, “Well, how did whoever think this was a good idea.” So, what's the wackiest dosage form you've come across?
I've come across a situation where I was working on a rheumatoid arthritis product, working on the generic version of it, and the innovator filed for pediatric exclusivity for a rheumatoid arthritis product, which I thought was kind of interesting because I didn't even know that was possible for small children to have rheumatoid arthritis. We won.
In terms of dosage form, I worked on some pretty unique orally disintegrating tablets made by a process known as a triturate machine. Essentially the formulation is primarily synthetic sugars, with other excipients in there. What you're doing is almost making something like a Smarties candy that's going to be able to dissolve in the mouth relatively quickly. It was a unique process. You don't see it very often. That's probably the wackiest dosage form because those tablets were uniquely brittle and friable. I mean, they're made to dissolve very fast in your mouth before you even swallow them. Yeah, that would be one.
So handling was a problem?
Okay. Yeah, who doesn't like Smarties, by the way? They're like a rival. They can go up against Reese's cups.
Yeah, they've been around.
Yeah, I know different formulations, obviously.
“If you're not going to have a working development report, what you need to have is a working document repository with a file structure that can be easily followed so that you can go back and know what you have, and piece together a report or a submission from that.
You're talking about the Smarties, the stuff that you draw on chalkboards, right?
No, oh my goodness. No. It’s pure sugar.
That’s what it reminds me of. It’s chalk.
No, no, anything except that.
Necco wafers? I used to work next to the Necco plant in Boston and the original Necco plant.
If you want to settle your kids down, if you're busy, just give him a couple of Smarties, and you'll see.
Oh, we're a Sweetart family.
All right, I have a question, Q. Actually, I grew up in the era of quality by design, QBD, right? I was never really familiar with the drug product side because I never worked in manufacturing and big pharma created this, actually some guy named Kaoru Ishikawa, do you know him?
Ishikawa diagrams? Yes.
Yeah, fishbone diagram. So, there are myths and facts about this? Can you talk about this? What is this fishbone diagram?
Well, it's a way to break down contributing factors to a particular output you have. Let's say tablet dissolution. Many factors could affect tablet dissolution. If you're having an issue with the dissolution of your tablets, you might want to prepare an Ishikawa Diagram to try to steer you where to look, steer you where to try to diagnose the problem. The dissolution would be the end of the fishbone diagram, and you would think, “Okay, what aspects of tablet production go into the solution?” Well, broadly speaking, you could at least say, “Formulation process storage conditions,” and then you can break those down further. You can break it down into degree of disintegrant, degree of super-disintegrant, granulation endpoints, binder selection for the formulation. You could come up with in-process disintegration as a proxy for your early dissolution time points for the process. You could come up with compression force tablet hardness as contributing factors from the process side into dissolution. You could look at hot and cold conditions and packaging configurations from the storage and how your dissolution varies with those things. Applying prior process knowledge, once you break down the contributing factors, as far as they make sense, you apply prior process knowledge to rule some things out and concentrate on what you think could be the causes of the issue. After going through this exercise, you could say, “Okay, we think that from the formulation standpoint, we think the degree of super-disintegrant is important. From the process standpoint, we think that hardness is important. In the storage aspect, we think the amount of moisture permeability in the packaging is important. You would do further work to demonstrate which of those things contributes to your issue and the degree to which they're contributing.
Okay, like other industries using it to design your product and weed out quality defect prevention. To me again, it looks like a fish’s skeleton. The problem is at the head, and the causes for the problem are throughout the body. It was always interesting to me. Brian, any other technical last-minute jokes?
No, I'm actually not that funny.
Any zingers? Do you have any Yogi-isms?
No, I really don't have – I'm not that funny. But, um, yeah, like I said after Jim Mencel quoted Yogi Berra, it's all kind of downhill from there. I don't know. No, I think this was really good. It was very helpful to me to hear you go through this.
Well, thanks. It's fun.
So now, more than in the past, the developer reports and conformance sections of the pharmaceutical development pieces afforded the opportunity to craft discussions for the reviewers. Put forward arguments, talk about explanations and justifications in the program so that supported data could be highlighted and less than stellar findings can be put in perspective. But, again, these reports and these sections influenced the perspective of their viewers more than in the past, so it's preferable to tackle some of these difficult issues head-on rather than wait for reviewers to notice the problematic data during the review.
So once again, Kyriakos Michailaros live from Brooklyn, New York; I forgot to mention that I still haven't been able to visit you; obviously, the last couple of months have been different, right? Thanks so much, you know, we appreciate it. We look forward to you coming back. In our next episode, we'll have none other than the famous Hedley Rees, author of many, many books. One of them I think I wrote a chapter for. Hedley brings a lot of information, history, and experiences to supply chains. This is definitely one you're going to want to check out. Hedley will be live from the UK.
FDA CMC regulations and guidance are simplified through examination, real-life experiences, and risk-based advice. This podcast hopes to educate sponsors and individuals on agency-related regulatory CMC matters. We will focus on the critical CMC issues and build programs that enhance drug development. CMC topics will include Regulatory Starting Materials, API and Drug Product Process, Formulation Development, Supply Chains, Analytical Controls. Advocating and interpreting CMC Strategy, directing CMC Operations and Quality Assurance oversight in conjunction with developing CMC submission content that represents the best interests of emerging biotech. NOT INTENDED TO BE PRESCRIPTIVE ADVICE BUT RATHER AN INTERPRETATION THAT IS RIGHT FOR YOU. Since 2007 we have provided our partners with innovative strategies and exceptional advice intended to enhance program development, product approval, and marketing presence.