Chilling Tales of Tech Transfer Gone Terribly Wrong

Am catching up with many things . . . videos and articles from a visit to Wyeth in Pearl River last week, notes and videos (and, yes, they are getting better) from an unusually informative panel discussion at the Emerson Users Exchange meeting in Orlando with FDA’s Helen Winkle and Ali Afnan . . . Look for new updates on our web sites soon.

In the meantime, am in beautiful Raleigh for the Bioprocess International conference, which features an outstanding list of speakers and topics, including tracks devoted to tech  transfer and Quality by Design.

Just in time for Halloween, yesterday we heard from Stephen Perry, president and founder of Kymanox, a company that specializes in transferring biological processes to contract manufacturing organizations. Perry, a new dad and a process engineer who formerly worked at HGS and Diosynth, fancifully entitled his presentation “Tales from the Crypt,” a collection of tech transfer studies gone wrong. (Could he have been paying homage to Edgar Allen Poe, who, we hear, was finally given a proper burial in Baltimore last weekend).

Perry emphasized the importance, not so much of designing the perfect process, but of saving data from past mistakes and “what went wrong.” There’s a story behind each failure, he said, and that material can be extremely useful to a CMO partner trying to scale up your process. Don't worry. You won't lose face in sharing the data, he suggested, instead you may save your organization millions of dollars . . .

Unfortunately, there is a group of people who still don’t “get” tech transfer, Perry said. Pressured by senior management to show activity and results, these types continue to throw things “over the wall.” 

Things may look good at first. He mentioned a case where the first engineering study went so very well that the company ordered special logo gift bags for everyone involved in the project. Then came scaleup, where nothing worked . . . the project was eventually abandoned at great cost and waste.

Moral of the story: Pay up front, or be prepared to pay, a lot more, later. As he said, tech transfer has become far more predictable within the past five years, and success depends on two things: data transfer and communication. Don’t be afraid to send your CMO partner too much information, including raw data. They’ll sort through what they need. The typical problem, he says, is too LITTLE information being sent, or in too cryptic a form.

Another lesson: don’t confuse tech transfer with development. So, if you decide, as one client did, that you want to change the cell line you’re using, that’s a process development project. The two areas need to be distinct, he warned.

Remember that the information will be used by someone outside your organization . . . he likened the process to giving driving directions to your visiting in-laws (which, of course, presumes you don't want them to get lost . . . ) Be as specific as possible.

He also mentioned the fact that some critical data (from such things as hold time studies) is tedious to gather, but critical to the CMO. 

Perry emphasized the importance of assay transfer in case number one – a client transferred analytical assays from one part of the world to another, but did not provide all data and what was sent was out of date, and sent, piecemeal, to different people.

The CMO spent months trying to qualify assays but didn’t get results. Finally, after an expensive and time-consuming onsite visit, it was learned that one assay required a very specific reagent with only one supplier in the world (who had discontinued supplying it).

Also, the target pH of elution during one identity assay changed . . . there was no central point person, no information tracking and no way to validate the information.

Six months were lost on the project.

We will be writing more on this, and interviewing Stephen later this week, so stay tuned.

Consider the snippet of dialogue below. If this resembles the way tech transfer goes on within your organization, Perry suggests that you become an agent of change, and convince management of the need for front-end attention and careful planning and project management. As he emphasized, there’s no need to be defensive about sharing data.

This company’s contract partner was attempting to program a bioreactor:

CMO - We need to program the reactor for the water runs. What are the proposed operating process parameters?

Sponsor - We are still tweaking the process and I can’t tell you right now.

CMO - Any hints?

Sponsor - Not really. Whatever we will tell you will change, so there’s no point in telling you right now.

CMO – Well we have to put something in the program so we’ll just take our best guess at it . . . 

More, soon.