During A Tech Transfer, There Is No Substitute For Boots On The Ground

By Ray Sison, VP of pharmaceutical outsourcing and tech transfer, xCell Strategic Consulting

Here’s a situation that may sound familiar to process engineers: A campaign of three registration batches is scheduled to start next week at a new CMO so far away that getting there requires crossing borders (but only if management approves travel). A full design of experiments (DOE) to characterize the process was constrained by API inventory, budget, and timelines, so only two engineering runs for range-finding and one scale-up batch were permitted, with marginal results. If the outcome of the registration batches seems preordained, it was.

This scenario played out during one of my tech transfers several years ago, shaping my approach ever since. The process was an aqueous suspension with a tortuous multistep wetting/dilution involving pastes, heated side-kettles, homogenization, and other brute force methods followed by several hours of bulk mixing before filling. Internally, the team determined the process was viable and ready for transfer and scale-up; optimization would be addressed later. We relied heavily on the assumed experience at the receiving CMO. They claimed to have produced similar products with the same API and assured us the described process was within their core competency. Due to competing priorities, I was unable to participate in the early work onsite. Fatal mistake.

After the initial batch proved to be subpotent, investigations were ordered and carts of supplemental samples were tested. Then, mitigation plans and protocols were created to characterize the process for follow-on batches. Change orders were hastily approved, but it was too late by then to save the timeline. Alas, the registration batches were delayed, impacting the critical path, clinical plan, and filing schedule. Over the next several weeks, intense scrutiny was given to the multistep API wetting/dilution, where the smart money said the error would be found. Finally, we agreed to tag-team visits, putting boots on the ground to oversee additional planned engineering batches.

To everyone’s surprise, it turned out the API loss occurred not during the challenging wetting steps, but rather when the second-shift operators would skim foam off the bulk solution during the lengthy final mixing step. The operators claimed it was common practice to skim persistent foam from bulk solutions, so they hadn’t recorded it in batch records during scaled-down previous runs. Despite my fatigue, I could clearly see the suspended drug particles in the foam due to their color. Subsequent testing confirmed and quantified the observation.

What did I learn from this? More importantly, how did I react when discovering the root cause, and how did I implement corrective action?

1. BE THERE.
Don’t take a back seat by phoning in guidance during or after the fact. Make your case to participate actively, to collaborate on the process, and to go to the site during critical operations. Go. Conventional wisdom these days says geography doesn’t matter. But if budget or time constraints limit access, communication, and the transfer of knowledge, then yes, geography matters. Technical difficulty of a process and anticipated level of collaboration during the transfer stage must be considered and budgeted during the CMO selection process. If I wasn’t there, how long would it have taken to discover the undocumented action deemed to be a common practice? Every time I go on-site, I learn something new about a familiar process and position myself to communicate directly with the team from a position of expertise. Do not forgo that level of control.

"Make your case to participate actively, to collaborate on the process, and to go to the site during critical operations."

RAY SISON
VP of pharmaceutical outsourcing and tech transfer, xCell Strategic Consulting

2. FIND COMMON CAUSE.
In other words, create a rapport with your CMO’s operators, scientists, engineers, and team members. Face time is an opportunity to find commonality and build relationships that carry forward throughout your career. What else are you going to do during a six-hour mixing process? How better to assess technical capability than to work through a root cause analysis (RCA) and debate solutions? I’m no psychologist, but in general, people work harder, cooperate more, and are open to your ideas when they like you. Engineers get a bad rap for lacking soft skills, but I say it’s not true if we start on common ground with each other — like process engineering. Which leads to:

3. BE KIND, BUT EMPOWERED.
It would not have been a far stretch to write up the operators for failure to record actions in the batch record or to hold them accountable for batch failure. But unless there is clear negligence or deviation from written procedures or instructions, step up to the role of the SME and prioritize the transfer of knowledge. Educate and guide. Be empowered to halt operations, initiate investigations, and change the batch record or protocols where necessary and appropriate. In the past, I’ve requested authority by QA beforehand to sign off on documentation changes on their behalf in real time while on-site. More recently with cloud-based apps, QA can review and approve changes from their cell phones if they cannot be present.

4. PREPARE TO FAIL.
To the extent possible, put aside competing priorities when arriving on-site and be well-prepared and focused. Give off positive energy and optimism — it will be contagious — but don’t get caught flat-footed when things go sideways. Set the tone when solving problems. In preparation, review the terms and conditions in the master agreements on conflict resolution relating to batch failure, out of specification (OOS) results, investigations, and other sections that govern operational events. Review this with the team during the project kickoff so the expectations are understood by all parties. More immediately, pregame and rank-order different failure scenarios when developing tech-transfer protocols and build in extended/optional sampling plans. The impact of last-minute change orders in reaction to unanticipated events can be significant, if not disruptive, to project management and workflow. You can’t catch them all, but you can be better-prepared.

5. ADMIT IGNORANCE (AT LEAST SOMETIMES).
You can’t know everything. You can’t predict the future. I’ll paraphrase something I heard once: We often project infallibility in ourselves while looking for the first sign of vulnerability in others. Instead, be open to others’ ideas. Understand the solution space when making process changes. Often this is constrained by regulatory considerations; process changes must be negotiated and assessed by the cross-functional team. Thoroughly discuss the impact and implications process changes will have on quality, regulatory, and clinical objectives.

6. TAKE CARE OF #1.
Be there both mentally and physically. Travel takes its toll. Processes often span multiple shifts. Young engineers may believe themselves to be invincible with no concession for weakness, but, if you’re in this for the long haul, get the proper rest and support to see an operation through from start to finish, i.e., tag-team with other scientists/engineers if you know critical activities will start early and finish late. Educate and build trust with the CMO’s technical team, learn from each other, and remember that transfer of knowledge will always be a two-way street.

There is an ever-growing body of information, best practices, and philosophies on tech transfer written by many of my colleagues willing to share their experiences. In speaking with some of them while writing this article, the subtext of our ideas often points to improved communication. Whether it is in the documentation, project management practices, or execution, if the goal is a transfer of knowledge, the vehicle is communication. It cannot be underestimated how simply being there will improve the likelihood of success or shorten the troubleshooting cycle.

Now go.