Tech Transfer: Do It Right the First Time

What dooms many tech transfer projects is a failure to communicate and plan.

By Stephen Perry, Kymanox

Share Print Related RSS
Page 1 of 2 « Prev 1 | 2 View on one page

There are two groups in biopharma today: those who “get” tech transfer and those who don’t. For those in the first group, technology transfer is a mature discipline that follows a structured approach, with predictable outcomes. For those in the other, tech transfer is a perennially new frontier with surprises at every turn. In the biopharmaceutical industry today, surprises cost projects months or even years on the timeline and can add an entire multiple to the project cost.

This article will examine the best practices for ensuring success with tech transfer, and present the most important elements of a universal approach. Although it will focus on biotechnology tech transfer to a 3rd-party contract manufacturing partner, the same basic principles appy to any type of tech transfer, whether site-to-site, process scale-up or process scale down.

Each type of tech transfer project presents its own set of unique risks: When transferring a new process from the lab to the plant, new unit operations, different raw materials and new assays may be required. New processes must be well developed and understood (i.e., characterized) before they are transferred to manufacturing. This will require extra time, and may delay the initial transfer to manufacturing, but will speed up the overall process and the time it takes to achieve the overall objective.

With initial scale-up at smaller or virtual companies, there is often limited process history and overall organizational experience doing the transfer, limited knowledge of scale-up principles or models and scaling factors larger than 10X.

With site-to-site transfers, issues focus on different personnel, departments and often companies. As global tech transfer increases, there are different cultures, languages and time zones to contend with, and different standards and utilities.

Any successful tech transfer boils down to the following principles:

1. Robust information exchange, providing the receiving party with all information that is relevant to the process and associated assays.

2. Careful front-end planning and project management, with the designation of point people for specific portions of the project.

3. Ensuring that analytical assays are transferred ahead of the process

4. Performing small-scale verification at the receiving site. This provides confirmation that the information exchange was successful and allows the receiving party to be more self-sufficient going forward.

5. Always perform pre-GMP engineering runs.

6. GMP runs are the end game. Put your tech transfer project in context by defining GMP success and failure and don’t dismantle your team until success here has been verified.

None of these steps can be omitted without serious consequences. In this article, I’ll offer a few examples of the consequences of some companies’ decision to bypass any one of these steps.

To avoid project creep, it is extremely important to establish boundaries between development and tech transfer at the outset of a project. Tech transfer does demand some process adjustment, but when things go beyond mere tweaking, the process needs to go back to development. An extreme example would be changing the cell line specified for an expression system as part of the technology transfer.

Share Information

Let’s examine a case involving a manufacturer and a contract manufacturing company located halfway across the world from each other. Analytical assays were transferred to the CMO, but the sending party did not provide complete information and some of the information was out-of-date. In addition, there was no master document to track all the information and it was sent out piecemeal to different points of contact.

As a result, the CMO spent months trying to qualify assays based on the data sent by the manufacturer, but could not achieve reproducible results.

The partners decided to have an onsite visit, where the CMO learned that one assay required a very specific reagent made by only one manufacturer in the world (who had just stopped manufacturing the product). They also learned that the target pH of elution changed during one of the identity assays. No central point person had been assigned to stay on top of the data for this project; there was no information tracking or a way to validate information.

The on-site, face-to-face meeting was a great success, and the assay transfer problems were solved, but by that time, the company had lost six months of precious time.

The moral of the story? There is no such thing as “too much” or “too detailed” information. Such dedicated tools as assay summaries, detailed process descriptions, and bills of materials should be created and used . Other information from the sender, such as regulatory submissions, development reports, raw data, validation reports, etc., can be extremely useful. This work would have to be done anyway as part of the future process validation and to support regulatory submissions.

Remember that information must be packaged for the benefit of the receiver, including detailed and contingency information. It’s better to err on the side of too much than too little. Send over relevant raw data and let your CMO sort through it and decide.

Plan Your Project

Remember that tech transfer is a project and as such requires a plan. Ideally, there will be separate plans for the transfer of the assays and the the process as well as an overall project plan that ties everything together. Planning also should take risk management into account and ensure that tasks are prioritized and supported properly. By definition, these plans will be critical deliverables for your project.

Consider one CMO that transferred a process with a token plan. The company started tasks ahead of schedule and sent a “feel good” report to the management. Eventually, the sender insisted that a plan be put in place, but that plan didn’t reflect activities already performed and it wasn’t even followed. By that time, process performance was inconsistent with what had been previously achieved. The business relationship between the partners was severely damaged and the project ultimately failed.

Page 1 of 2 « Prev 1 | 2 View on one page
Share Print Reprints Permissions

What are your comments?

You cannot post comments until you have logged in. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments