LIMS is Dead! Long live LIMS!

During a discussion around the future of LIMS over at LinkedIn, one poster suggested that the term “WebLIMS” be stricken from our vocabulary. I tend to agree, for the reasons specified. Perhaps we should start a list like the one that comes out every January, listing terms that should be stricken from the language for misuse and overuse. The first one on my list would be the term LIMS, itself.

LIMS would qualify on the misuse grounds. The reality of every LIMS that I’ve seen(and I’ve seen all of the major ones) is that they are not at all focused on managing laboratory information. Rather, they are generally sample logging and test result recording systems. To argue that this represents “laboratory information” is like arguing that an engine is the entire car. The engine may be central and critical, but it is not what most users of the car interact with directly.

When a laboratory embarks on implementing a LIMS, there are very much competing interests on the part of the stakeholders. Unfortunately, this is often overlooked. It may even be that some stakeholders misunderstand their own interests. For instance, people who submit samples to an analytical lab think that by supporting the analysts’s request for increased efficiency they are supporting their own desire for improvement in their business processes. In other words, they substitute the analytical groups requirements for their own. However, simply improving turnaround won’t generally fulfill all the needs of the submitting groups. Does faster turnaround result in easier submission? Easier status updates? Easier data mining? Getting results faster is certainly a requirement, but it is not the only, nor necessarily the most important, to key sets of stakeholders.

If we look management, a similar problem occurs. For a service organization like an analytical lab, happy customers are the requirement, as is the collection of metrics that facilitate a true quality management program (you just knew I would throw that in there).

If we look at all of these additional requirements, we should realize a couple of things. One is that laboratory information is much broader than most LIMS really take into account, and the second is that we should rethink the process by which we implement LIMS. In other words, in order for LIMS to truly be LIMS, we need to do things and think about things very differently. No longer will simply slapping the latest interface technology, or installing yet another new LIMS fix the inefficiencies and challenges our analytical laboratories face. Many years ago, W.E. Deming made the point that the latest new gadget will not fix your quality challenges. That notion is as true today as it was then.

If LIMS is to be truly LIMS, it needs to be as concerned with metrics as with test results, with metadata as much as logging procedures. These cannot be secondary concerns, relegated to mere afterthoughts in the implementation process. Only once LIMS really addresses, and effectively, all laboratory information, will LIMS implementations begin to succeed.

Buy or Build?

Having just finished phase I of my eResume website, I was given cause to ponder the debate that you will hear around IT systems in most industries, but in particular in the pharmaceutical business. Do you buy a solution, or build it yourself. My website, as it turns out (and yes, it is very basic) consists of some built elements and some third party components.

It turns out that this was the best solution all around. While my javascript isn’t too shabby, it was much easier to locate a library that provided the functionality I needed. At the same time, I built my own style sheets so that things would be positioned the way I liked, and styled to my tastes. I could download a very complex style sheet, but then I’d have to figure out what combinations of styles would work to give me what I wanted, and suddenly the project would get to be a bit much. Similarly, my webhosting company recommends a php based form management tool for contact forms, and the like. However, there was simply too much functionality that I would have had to spend a couple of hours figuring out, vs. simply downloading one of the flavors of the FormMail Perl script from the web. In the Pharmaceutical systems sphere, you run into many of the same challenges. My deepest experience is with LIMS selection and development, so I’d like to reflect on these questions with regard to LIMS.

The preference, in my experience, has been to opt for the purchased solution. The greater the out of the box match with our operations, the better. Minimal configuration, and no customization. This is based on a sentiment you will often hear, and I’ve often said, over the last few years, that in the pharmaceutical industry our job is the manufacture of drugs, not IT systems. I hope to blog on this more in the future, but it occurs to me that we are, too, in the business of IT system development. The modern pharmaceutical company can barely operate without robust IT systems. So, it is, in fact, a part of our business. We therefore, need to be less hesitant to explore a build solution.

Early in my career, working for a small startup, I had limited staff, even more limited budget (not to mention limited off the shelf tools at that time), and a big job to get done. The natural solution was to engineer and build my own solutions. Those solutions lasted for well over a decade (with a major overhaul of all of them at least once). Because I ran the operations the tools were designed to support, there wasn’t the typical requirements headache that goes with system design and build processes. Over time, a member of my team and I attended a course on tech writing so we could develop top flight owners manuals, and we subjected the systems to a very rigorous validation process which helped us tighten up the systems even further. However, even in that environment, the time came to consider switching to more off the shelf solutions. The rationale is that these would, in theory, be easier to manage as we wouldn’t be responsible for coding, bug tracking and fixes. Also, as the supported departments were expanding, and we weren’t, our capacity to build new functionality was greatly limited. Of course, we still had limited budgets, even for system acquisition, so we tended to acquire purely off the shelf with very minimal configuration options. Because the solutions were completely off the shelf, they didn’t fit our operations very well. I’ve never seen an off the shelf pharma system that did that very well at all. One system was so unpopular that the “receiving” department (as in, receiving punishment) refused for a couple of years to give up the old system. On one occasion, I was able to identify a system with a significant amount of out of the box functionality, with limitless customization options, and a good price tag. Unfortunately, the fact that we would be the first adopter in our industry made the selection unpalatable to certain key individuals, and the system was never acquired. The alternative we were forced to implement was a narrowly focused solution, that was never very popular with it’s users.  When it came time to expand to additional groups, it didn’t fit.

In later years, I had an opportunity to be involved in the selection and implementation of systems that ran from customizable to configurable, and all with less than optimal success. Certainly, some of the difficulties were with the requirements process. In particular, the lack of willingness to execute business process evaluation, and re-engineer where necessary, is always troublesome. However, there were other more challenging issues. For the highly configurable system, we had a system with a sound data model and a pretty robust set of business logic. However, the interface was very outdated, and there was literally nothing we could do about it. The interface difficulties really render the system very unpopular with significant portions of the user community. All of the vast configuration options had to do with business logic and data models, and virtually nothing to do with the interface. The highly customizable system had an extremely complex development environment and some companies, in order to make things work properly, hired vast teams of developers. Of course, backing out those changes during the system upgrade, was nearly impossible

What was interesting is the system I mentioned earlier, that had nearly limitless customization options, was that such customization would be possible by smaller teams of developers, and would be much easier to accomplish. I think therein lies the sweet spot. Although most pharmaceutical companies have similar systems, they are not identical, and some customization (especially around interface design) is likely warranted. Further, the most ideal situation is a system with a robust API. This would enable the development team to create a layered (wrappered may be a better description) system where if the underlying system is modified may not result in much if any impact to the custom piece. The only remaining danger is for the development and maintenance teams to think that once delivered, further customization will never take place, so no allowance is made to support that activity. You would think that this is self-evidently an erroneous view, but it is not uncommon. Even predominantly off-the-shelf configurable systems suffer from this belief system.