What are you searching for?

Sign in
Features

API Development & Problem Solving

Management practices for unforeseen API challenges

By: Cliff R.
Act 1: The Play Unfolds

How many times have you sat in a meeting and thought, “We’re reinventing the wheel here!”? Or, “Are these guys ever going to stop chipping flint?” Most scientists are well indoctrinated in the “scientific method” of problem solving, but there’s truly a time and a place for everything. The scientific method is founded in intellectual speculation: you hypothesize a solution, examine ways to test your hypothesis, and then, hopefully, draw a conclusion based on data from your experiments.

Now, fast-forward to a manufacturing environment where a problem has arisen with a chemical process. Suddenly, the plant management has two worlds colliding; the chemists generally want to start with first principles or pontificate what they believe the problem (and solution) is—and yes, this is coming from a chemist! Meanwhile, opposing counsel from the engineering team is thinking, “Here we go again.” Further, if the engineers are process engineers, they just want help with the problem at hand, and could not care less about the subtleties, intricacies, exceptions or mechanisms invoked by the chemists—”It’s not a science project; just solve the problem!”

If any of this seems to resonate or if you have been through this scenario, keep reading! This article will discuss problem-solving techniques primarily applicable to the chemical process development stage of API commercialization. No doubt, many readers will say, “This is just common sense,” or, “Of course—this is obvious.” Yes, it is; so why don’t more people practice it?


Act 2: Types of Problems
Before anyone shouts from the mountain that the logical advancement of humankind was predicated on the scientific method, then condemns the empirical wizardry of the engineering profession, let’s agree that problem-solving techniques vary depending upon a project’s maturity. For instance, in drug discovery, a well-disciplined approach to identifying drug targets or candidates is required (good luck, of course, would not be turned away at the door). In the research setting, the scientific method is employed in the relentless pursuit of solutions to extremely complex problems. A reliance on fundamental scientific principles and the work emanating from other researchers must be assimilated to “synthesize” information and new knowledge leading to progress. The ability to accomplish this is inherent in our scientific education, subordinated to the standards of scientific integrity and the application of the scientific method. Indeed, these are noble characteristics.

Now, let’s look at the practical output of that R&D investment: manufacturing. The drug candidate has passed through numerous hurdles—chemical process development, analytical characterization, regulatory filings, stability testing, analytical method validation, cleaning validation and process validation—and now, the drug is in manufacturing. There should not be any problems (right), but what happens when a problem does arise? We’ve all seen the fire drills and finger pointing, and heard the voodoo chants, mantras and folklore. Of course, this is all irrelevant and doesn’t help solve the problem. No wonder when the chemists are called in they start with data collection all the way back to earth, wind, fire and water! Typically, the “information” placed before them contains lots of levels of noise to weed through (including “manufacturing has screwed up again”). Taken together, it’s no wonder many plant managers have lost their hair.

Certainly, the above scenarios represent the two extremes of drug development: creation and maintenance. The creation folks (research) are usually not interested in the details that allow for robust and predictable manufacturing processes. The process maintenance folks (manufacturing) have their hands full with plant operation, production schedules and meeting cost targets on processes they had hoped were capable when they received them. Clearly, the process development function is the logical middle ground between the two factions and, when they investigate and implement solutions properly, many problems can be eliminated.


Act 3: The Problem-Solving Pathway
For the purpose of discussion, let’s examine the problem-solving process in reverse. Consider a process that has been successfully introduced into manufacturing, i.e., the validation activities have been executed and the results obtained passed the criteria established in the validation protocol(s). Previous articles 1 –3 on API Manufacturing Management Prac-tices discussed the requirements and characteristics of a capable manufacturing process. In those articles the fundamentals were provided on the use of control charts and the importance of careful API specification selection for yielding robust processes. With validation complete and a statistical basis available to describe the process’ performance (and stability), who’s responsible for solving any manufacturing problems? If you subscribe to Deming’s quality philosophy, the local work-force takes the lead 4 . Stated clearly, if a manufacturing process is in control and capable (in statistical control and providing material meeting specifications), then special cause (non-random) variation must be the culprit. The manufacturing team should be able to sort out the problem. Heaven help them if a sharp development chemist is called in to solve the problem. The corollary is less appealing to (this) chemist. If the manufacturing process was not robust in the first place, the chemist would do well to pre-drill the nail holes before appearing on plant premises to be crucified.

Many a comedian has been asked where he comes up with his material. Invariably the comedian responds that he just has to watch people or read the daily paper and is provided with an overwhelming amount of material. With the right attitude, the same observation is true for R&D, process development and manufacturing situations. Unfortunately, the problems are rarely entertaining and can have severe consequences for the company and its customers. Despite the levity herein, responsible problem solving is a skill that must be developed and practiced with the same discipline as basic research, employing the scientific method.

Returning to the manufacturing problem and the condition under which the process is in control and is capable, what does happen often isn’t what should happen. If the development chemists are called in, they should request the control charts on raw materials, in-process tests and the final release testing results. If the chemists know they “delivered” a statistically robust process to the plant, they will be looking for special causes to the problem. It may be as simple as an excursion from the batch sheet’s instructions. If, however, the process was on shaky ground to start with, one can envision a whole series of committee meetings to study the problem (until management possibly forgets about it). Often the reality we face ranges from comedy to cynicism. However, it is clear: if the process is not in control and capable, but it’s still in manufacturing, either:

a) it needs to be fixed, or
b) management needs to live with the (unpredictable) results.

Informed and knowledgeable management should be able to make a clear distinction, and then make a decision.

So we started with problems occurring in manufacturing and began swimming upstream. Again, it should be stated that the commercial manufacturing processes should have been fully validated and only special cause variation should have led to problems. This is especially true since all the random variation problems were sorted out in the process development exercise and eliminated. Right?! (he said, facetiously)


Act 4: Process Development Problem-Solving Techniques
Problem solving at the development stage is the primary focus of this discussion. You can imagine the technical package and synthesis provided to the process development chemist by the medicinal chemistry lab. The responsibilities placed on these two groups are almost as different as the opening remarks about chemists and engineers. The medicinal chemists have succeeded in identifying a new drug substance worthy of commercial effort; now the development chemists have to succeed at making the API a commercial reality, meeting cost, schedule and performance criteria. Here is where many ask, “Can’t we just outsource it?” Of course you can, but the same work has to be done and the program’s financial success depends on how quickly and how well the process development work is performed. Let’s explore some fundamental problem-solving techniques used in the process development activity. Hopefully, the preceding scenarios set the stage for the value-add to the enterprise from disciplined process investigation.

Despite the facetious comments throughout, we are not supposed to check our brains at the door or forget all the chemistry we learned either in school, or the hard way (by solving problems). However, there is one truism to solving problems: you absolutely must have a measurement system that is capable of quantitatively discerning differences in experimental outcomes. Ideally, the measurement system should be able to detect differences an order of magnitude “smaller” than what you are trying to measure, but five to six times better is normally quite sufficient. Without an adequate measurement system, problem solving (or process improvement) is an exercise in futility. One can readily see that the measurement system itself, as a process, must be in control and capable. Of course, after stating the need for a quantitative measurement system, many ask if a qualitative test method is sufficient or even useful. As stated above, don’t check your brain at the door. If thin layer chromatography can detect a significant amount of undesired impurity present in an API, then one can certainly perform process investigations using TLC with the intent of minimizing the impurity. Eventually, a quantitative HPLC procedure would be required. The philosophy of using the tools immediately available is an article unto itself, but anything that helps to quickly and cheaply move a project forward can’t be all bad!

With a capable measurement system in hand, often the hard work is already completed. The following problem-solving steps are in order of general priority. For context and discussion, imagine you are working on a synthetic pathway to produce an API. Your synthesis has acceptable costs and cycle time; the process yield and API assay are good; the route can be directly scaled to production equipment. Just one problem: the impurity profile does not meet the desired specifications. What do you do? Everyone has an opinion, but how does the problem get solved as quickly as possible, in a definitive manner and at the lowest cost? Further, suppose this type of problem arises regularly: why don’t we solve the problem the same way every time? Let’s get started. The first step is to “split the dictionary.”


1. Split the Dictionary
The “split the dictionary” technique is based on the idea that, with very few yes or no questions, you can “guess” the word someone is thinking. The process goes like this: is the word in the front half (or the back half) of the dictionary? The answer immediately eliminates half the problem. Apply this principle a few more times and you have the first letter of the word. Now, perhaps switching to how many pages in the dictionary begin with that letter, ask the question: is the word in the first half (or the second half) of those pages? Proceeding until you have identified the page, ask: is the word in the left hand column or the right hand column? Is it in the top half of the page or the bottom half? Each question continually focuses down to the answer in a methodical manner and unequivocally eliminates part of the universe you have to search. Above, we alluded to this as guesswork, but in reality it is a methodical and disciplined technique to problem solving 5 .

How does this apply to our theoretical impurity profile problem? Ask the same kinds of questions (as a reminder to the chemists, don’t speculate or draw mechanisms); write out a logical “split the dictionary” program. At what step did the impurity appear? Did it arise before or after filtration? Did it arise during the reaction? Before reflux or after? Does it reach a steady state concentration? As you can see, “splitting the dictionary” can substantially reduce the operating universe so that you can locate the needle in the haystack.


2. The Control Experiment
Let’s take a tangential detour for a moment. Often in a development effort, a clever shortcut or novel transformation is observed using the latest and greatest chemistry, processing technique, etc. Typically, this “discovery” is after a problem has arisen and the “white knight” rides in with their solution. Let’s face it: our culture loves heroes and quick, dramatic solutions to problems. Well, if comedy and cynicism were the prevalent modes earlier in this article, add in skepticism here. Management should always ask for the control experiment to be performed side-by-side with the new solution. In context of the impurity profile problem, the control experiment may identify that the new procedure indeed minimizes or eliminates the impurity, but at the expense of other requirements. Solving one problem while creating others is not a solution.

As a rule, always run the control experiment; this ap-plies to chemical or physical transformations. As examples: run side-by-side reactions of the “old” catalyst with the “new and improved” catalyst, then test the results against all the release criteria (performance), total manufacturing cost and impact to the schedule. Another case may be the claim that this grade of solvent will reduce the impurities in the isolated product. Demonstrate it by running the control experiment. We have all seen variations on this theme; the list of examples is endless. Just run the control experiment.


3. The Parts Swap
After “splitting the dictionary,” sometimes the simplest technique to solving a problem is to perform a “parts swap.” It’s a derivative of the control experiment and a further refinement of splitting the dictionary. Essentially you are evaluating special cause variation. As an example, return to the impurity profile problem: why not try different lots of the raw material and see if the same profile is observed? If an identical profile is observed you cannot draw a conclusion; unfortunately, you cannot logically draw a conclusion if different results are obtained. Why? Identical results from different starting material lots may indicate the process will only provide the result obtained—the process is robust, but not producing what you want. You can’t say if it’s a raw material problem or a process problem. If different results are obtained from different starting material lots, the process may be a random number generator—but it is a strong clue to solving the problem. At this point, aren’t you glad you can count on your measurement system, so that it’s not one of the variables too? So, how can we sort out if the problem derives from the raw materials, the process, or something else? Stay tuned; that’s in the next section.


4. Separate the Components
If you think of a problem as resulting from either random variation or special cause variation, then you have another “split the dictionary” decision tree. All processes have random variation and it’s the kind we usually can accept and deal with by using process improvement techniques. In a development program, the goal is to establish a stable process and demonstrate that it operates according to design by accommodating random variation. Once stable, the process often can be manipulated to provide the desired results (a capable process). The process development group is charged with accomplishing both tasks.

It’s not news that essentially all the variation in chemical processing arises from the process components of: materials, methods, machines, measurement, people and/or combinations thereof 6 . By definition, the measurement system, as a process, must be in control and capable to really solve the tough problems encountered in API development. Having a capable measurement system still leaves plenty of areas to test, eliminate or fix. One technique for separating a process’ components is to expose the raw materials, intermediates and the products to the reaction conditions. For instance, in the impurity profile problem, you could use various means to purify a sample of the final API to the desired specification limits. In a small test experiment, subject the API to the identical process conditions where the impurity was first observed. If the impurity arises, it’s a strong clue to the worst skeptic that the process is the culprit. Similarly, raw materials and intermediates can be tested singularly or in combinations with one another to further elucidate where the impurity arises. Just remember: correlation is not necessarily causation. After practicing these techniques, the master problem solvers test themselves by logically solving problems in as few steps as possible.


5. Demonstrate the “On/Off” Switch
Once you’ve identified what you believe is the solution to the problem, it’s time to do the ultimate control experiment. Demonstrating you have identified the on/off switch to the problem is an extremely powerful technique to the development team and to management. It clearly and unequivocally indicates you have solved the problem and know what controls it. To perform this demonstration, you perform side-by-side experiments with the old parameter set versus the new set. Ideally, a third experiment is performed too, whereby it is doped (or duped) into providing either good or bad material.


6. Avoid OFAT Experiments
One factor at a time (OFAT) experiments can lead you astray quickly; they are to be avoided. There’s a whole field of mathematics dedicated to operations research and with a little license it can be summarized thus: simultaneous optimum solutions arise from solving multiple factor problems simultaneously. At the process development stage, there are a series of techniques for investigating the key parameters influencing product quality. The designed experiment techniques are statistically based and range from full factorial experiments to truncated versions (e.g. Plackett-Burmann factorials). In a relatively few number of experiments, the process investigator can determine the impact of a huge number of process variables on the API’s quality and establish some confidence in the range of random variation. An in-depth description of these techniques will be deferred to a later article, however several references are provided for the curious reader 7 –12


7. Conveying Information
Once the problems have been resolved to the chemist’s satisfaction, it is often necessary to present the findings to other team members and to the plant management. This should be an easy task: just imagine having a standard “split the dictionary” solution tree that you have presented at the weekly team meetings. Each week you have indicated where you are in the experimentation and the results. As the solution unfolds using the above problem-solving techniques, there’s little chance for second-guessing or speculation. The coup de grace is demonstration of the on/off switch.


8. Implementation
Our discussion has been directed primarily to problem solving at the development stage. One approach chemists can use to assure solutions are implemented well in the manufacturing environment is to recommend that specific control charts be maintained. As we recall, the development chemist should be providing stable and capable processes to the manufacturing group; the proper tools must be in place to assess if this is true. In a GMP environment, some statistical information can be gathered during the validation process, then accumulated as each batch is prepared 13 ,14 . This information is then readily available for the annual quality review and DMF update. Should a problem arise, a quick review of the control charts can often determine if the culprit is random variation or the result of a special cause.


Business Realities
Today’s business realities make companies move quickly and with determination in establishing market presence. Financial success may depend on hitting specific launch dates and cash flows, and problems arising in drug substance (or product) development can have serious consequences. Face it: very few projects proceed without problems. However, most projects have the same developmental components. A systematic problem solving approach within the company’s culture provides three major benefits:

1) it relieves stress in the organization by eliminating irrational fear;
2) it serves as a communication tool across functional groups; and
3) it will solve the problem, usually with the lowest cost and in the shortest time.

Alternatives are not acceptable in today’s economic environment. The cliché that success breeds success is a good principle for management to practice and orchestrate. When complex problems must be solved (and solved definitively), the methodology and tools provided by management can be a key element to success.

Notes

1. “API Management Practices: Use SPC to Improve Financial Performance”; Cliff R. King, Contract Pharma, Jan/Feb 2001. Back
2. “API Management Practices: API Specification Selection”; Cliff R. King, Contract Pharma, Jan/Feb 2002.
3. “API Management Practices: Closing the Gap Between Innovation and Commercial Manufacturing”; Cliff R. King; Contract Pharma, Jan/Feb 2003, p. 32. Back
4. “Process Improvement for Chemical Processes Seminar”; QualPro®, 3117 Pellissippi Parkway, Knoxville, TN 37931. Back
5. “Statistical Engineering Management Overview”; Shainin Consultants, Inc., P.O. Box 20977, Carson City, NV 89721; 1993. Back
6. “Watch Out for Nonnormal Distributions of Impurities”; William A. Levinson; Chemical Engineering Progress; May 1997, p. 70. Back
7. “Design and Analysis of Industrial Experiments”; Thomas D. Murphy, Jr.; Chemical Engineering; June 6, 1977, p. 168. Back
8. “Salvage That Experiment”; James N. Cawse and Noushin Izadi, Today’s Chemist at Work; June 1992, p. 24.
9. “Design of Experiments”; Kimberly K. Hockman and David Berengut; Chemical Engineering, November 1995, p. 142.
10. “Statistical Software Speeds Process Troubleshooting”; Richard Mayes and John Ganjei; Chemical Engineering, December 1995, p. 115.
11. “The New Mantra: MVT”; Rita Koselka; Forbes, March 11, 1996.
12. “Mixture Experiments Hold the Keys to Formulation”; Wendell F. Smith, Jr.; Today’s Chemist at Work, February 1996, p. 18. Back
13. “Control Charts, Tracking Changes Over Time”; Preston Poulter; BioPharm International, March 2003, p. 52. Back
14. “Process Variability or Process Capability”; Ronald W. Miller and David Unger; American Pharmaceutical Review, Spring 2002, p. 26. Back

Keep Up With Our Content. Subscribe To Contract Pharma Newsletters

Topics