Is Tech Transfer Broken? Can the Principles of QbD Fix It?

While scant data exists to suggest how efficient, or inefficient, technology transfer is within drug manufacturers' development efforts, it's pretty clear that most companies hardly have tech transfer down pat, and still others just don't get it at all. That's a recurring theme in a podcast posted on PharmaManufacturing.com yesterday, in which tech transfer experts Stephen Perry, Russ Somma, Emil Ciurczak, and Paul McKenzie offer harsh criticisms of the tech transfer projects they've witnessed first hand. And thankfully they offer advice as well.

Sometimes the problems are simple--development teams just fail to write critical information down in their notebooks, "something they should have learned in college!" Ciurczak says. But the experts also make clear that practices associated with Quality by Design--namely, proactive risk assessment and data management--can eliminate problems in the early stages of development and facilitate later transfer. Perry notes how developers typically send data on successful process studies to their partners, but not data from failed studies that can be just as enlightening.

Perry is the author of Pharmaceutical Manufacturing's January cover story on doing tech transfer the right way, and he suggests that one thing that often dooms tech transfer projects (internal or external) is the inability of the technology sender to share necessary information with its partner:

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.

One of Somma's mantras is simplifying tech transfer, which seems to run counter to the idea of providing as much detailed information as possible. He, as well as Oracle's Arvindh Balakrishnan, explain how this paradoxical challenge can be overcome in a podcast which is now the lead feature on our PharmaQbD.com site.

Finally, Centocor's McKenzie is a proponent of recipe-based development as a means of ensuring consistency throughout scaleup and as handoff occurs between partners. Here is a summary of McKenzie's philosophy from last fall's Bioprocess International conference, as well as a blast from the past: Pharmaceutical Manufacturing's September 2007 cover story featuring McKenzie in his days with BMS.

The success or failure of tech transfer is hard to measure, but that doesn't mean that it shouldn't be a key focus of initiatives to accelerate and lessen the costs of drug development.

Can Microsoft Fix What Ails QbD Efforts?

As QbD matures, so do IT offerings that bill themselves as the answer to drug manufacturers' drug development prayers. Manufacturers' challenge is clear: how do we take all our disparate, siloed R&D data from past and present and (cheaply and easily) use it to leverage our ongoing development efforts? As the ability of software to integrate and manipulate data from multiple formats improves, this massive challenge becomes more of a reality.

Of course, there is money to be made in bringing order to chaotic drug development data, as is evidenced by the companies getting into the market. Last week, I talked with Arvindh Balakrishnan about Oracle's efforts, and before that spoke with Blue Reference's Paul van Eikeren about his company's QbD IT consortium.

Microsoft looms large as well, and today we posted my interview with Jim Karkanias, Senior Director of Applied Research and Technology for Microsoft Health Solutions Group, about its Amalga Life Sciences solution.

Amalga is Microsoft’s attempt to make drug R&D data readily available, integrated, and robust, with the advantage that it leverages the Office format that is familiar to virtually everyone within a given organization. In the interview, Karkanias uses the example of a multidisciplinary team that is tasked with performing a gene expression study of a certain disease to illustrate how R&D will realize Amalga's potential. The fact that Amalga integrates relational and graphical data is what sets it apart, Karkanias says.

Merck is one of the companies helping Microsoft to develop Amalga LS. We'd love to hear more from anyone who's had experience with those solutions from the companies mentioned above, or other companies in the QbD IT space as well.

--Paul Thomas

Oracle's Balakrishnan: Towards an Integrated QbD

Another person who has his finger on the pulse of QbD, and whom I've spoken to a few times in the past six months, is Oracle's Arvindh Balakrishnan. We spoke again last week to touch base, and the focus of our discussion was Balakrishnan's belief that QbD is at a turning point in that many manufacturers have gone beyond the "hodge podge" approach that defined earlier QbD efforts and now have coordinated, corporatewide QbD programs.

Here is the audio of the interview.

--Paul Thomas