I think I’d written an article in the past about generic labs and their unique situation with regard to their testing – the fact that tend to make a wider variety of products and, thus, tend to have more analyses to add into their LIMS (or methods into their ELNs). At IMACS, last week, I was talking to several contract labs and realized that, while they basically have the same problem, it’s much worse for them in a number of ways.
Ever-Changing and Faster
What’s uniquely worse for the contract labs over the generic drug labs is that they get their methods in, fast. A generic drug lab is developing drugs over some period of time. While it’s frustrating to handle all their analyses in something like a LIMS or ELN, it doesn’t have to happen overnight. With a contract lab, when a customer comes to them with something to test, that lab does often have an incredibly short timeframe with which to handle their new methods.
And so, while we complain about how hard it is to get analyses built in systems in an expedient manner, if we can’t find a way to do it fast, the contract labs can’t get their system ready as fast as they need to be in order to automate their data to be ready for their new customer.
On top of that, that new customer might change their mind. Or, they might only use that contract lab for a short time until the method can be done in-house. Think of this – it doesn’t pay for a lab to spend lots and lots of time building an analysis into its system to accommodate customers that might be gone, soon. But the problem is, they don’t know which ones those customers will be, necessarily, just that some percentage of their customers will fall into that category. That being the case, taking a long time (which means higher cost of implementation) isn’t a long-term option for contract labs. Tomorrow, I’ll write about one strategy labs are taking to address speeding-up the building of methods in their ELNs.
More Data Streams
There’s another big problem for contract labs, which includes contract manufacturers, as they have to do some amount of testing to send back to their customers, too. The problem is that they serve more and more customers that want to automate their data streams. I had written an article about this for “Contract Pharma” magazine which illustrates the basic problems of this situation: http://www.contractpharma.com/articles/2011/03/it8200focus-sharing-data
My point here is that when I speak to the CROs (Contract Research Organizations) and CMOs (Contract Manufacturing Organizations), I understand why they’re frustrated about the situation they’re in with regard to managing their data, serving the customers and potentially sharing the data with their customers. In the many discussions I had with some of the CROs at IMACS, last week, I’ve come to truly understand why they can no longer stand for long analysis building times – why that just won’t work for them – why they’re desperate for other solutions.
Unfortunately, what I didn’t say to them in our discussions is that the data sharing piece is worse than they think it will be. Most of the people I’d spoken with hadn’t gotten to that point, yet. They feel the crunch they’ll be in as their customer push them to share data, but not having started it, don’t quite grasp the abyss they’re about to fall into. I didn’t purposely hold back on them, it’s just that we often didn’t get that far in the discussions before being called back from breaks, for example. However, I hope some of them are reading this blog because I’ll speak about standardization in our industry again, probably in the next few days, and why promoting that probably helps them more than anyone else.