The ILA is looking for support from a number of end-users and vendors for two reasons:

• to keep the cost per sponsor low, and,
• by having broad support to form a solid basis for moving forward once the work is done.

If you would like to change the way lab automation is done, you can begin by reviewing the document and letting the ILA know what you think at: ILAinfo@InstituteLabAuto.org

“DevCon” is nerdy developer-speak for “Developer’s Conference” so it’s definitely not a conference to attend if you’re merely interested in using the iPad in your lab.

I wanted to point-out that one of the speakers is from a place called “Big Nerd Ranch” and, as someone that does program, I particularly thought that sounded intriguing. 

Just this past week, one of the software vendor’s consultants at my customer was sitting around thinking and suddenly turned to me and said, “You know, I bet there are some great uses for the iPad in a laboratory” to which I immediately replied, “Yes, it’s a great sample tray!,”and then I snickered. I just can’t stop perpetuating that joke. I guess that shows the inane level my sense of humor dives to.

But I might have to stop this silliness. In the LIMS/Laboratory Informatics group in LinkedIn, I just saw the title “The iPad Makes its Way Into the Research Lab” to which I struggled but did hold-off making a post just to point-back to John’s “sample tray” posting ( http://www.linkedin.com/newsArticle?viewDiscussion=&articleID=136348746&gid=36640 ).

And, to make things yet more serious, there’s a real application really using the iPad ( http://blog.biodata.com/2010/06/13/the-ipad-makes-its-way-into-the-research-lab/ ).

Also, to be fair to John, he did also make another posting about the iPad where he did not use the term “sample tray” anywhere (drat!) (http://theintegratedlab.com/2010/05/the-ipad-in-the-laboratory/ ).

And so, as we get new technologies, there is usually eventually someone that discovers a great use for it. And, when that doesn’t happen, the technology doesn’t take off and disappears from our horizon, regardless how “cool” we might have thought it was when it came out.

The course presented at SmartLabs Exchange outlined a systemic approach to automation, tracing its evolution from the days when quantitative chromatography was based on cutting out peaks and weighing them, to current requirements for integrating disparate laboratory instruments, systems and robotics into a unified laboratory ‘solution’. Considerable emphasis was placed on process and workflow understanding, the choice of technology infrastructure and the role that systems such as LIMS and ELNs can play in facilitating integration. From a manager’s perspective, the introduction of laboratory automation is equivalent to introducing a small scale ‘scientific manufacturing’ operation and therefore warrants appropriate policies and practices. Good planning plays a critical role in the deployment of laboratory automation, based on well-defined goals and business justification.

The course provided an excellent overview of strategic approach to laboratory automation. Full details of the public course schedule offered by the Institute for Laboratory Automation can be found here.

With regard to the technical content of the meeting, one of the underlying themes was the continuing debate about the overlap between LIMS and the growing number of ‘Q/A ELNs’. Presentations from LabWare, Velquest, LabVantage and Waters tackled this issue head-on. It is interesting to note that after staying away from the ELN market for some years, a number of LIMS vendors are now adding ELN functionality to their products to move into this market space. The underlying strategy seems to be one of offering existing (LIMS) customers the ability to extend their implementations by adding ELN functionality, rather than purchasing a separate ELN system and facing the subsequent interfacing issue. This approach has its strengths and weaknesses which I’ll look into in another post.

For the first time in one of these meetings I sat through a workshop on Software as a Service(SaaS). SaaS is currently in the hype cycle when it comes to laboratory systems. But with an increasing number of commercial offerings and some potentially significant benefits to customers, it is becoming increasingly important to get some clarity around the benefits and limitations.

Laboratory automation, as an ‘engineering’ function, got a good exposure, and I’ll put together a separate post or two on this topic. The concern is that there is very little formal education that specifically addresses this topic, despite the fact that it represents a significant challenge for most laboratories.

My participation included a workshop on the subject of ‘Managing User Resistance’; here’s my slides.

Overall this was a good and enjoyable meeting and a refreshing change from the more passive style of conference that serves the laboratory integration market.

He and I agreed that the terms are fairly meaningless, right now – that our industry needs to either redefine the terms to reflect the new products or to abandon them, entirely.

With this being a time when many labs are getting ready to start their Fall work, and a new round of product selections, we hear many people complain that this is just too confusing.

Here’s my usual tip, and these are the same tips I give all of those who want to do this, themselves, regardless whether we’ve been in such transition or not:

1. Don’t get hung-up on the terms. They don’t mean much.
2. Focus on functionality.
3. Plan to spend lots of time on this. By the time you’re done, you’ll be an expert, too.

My own opinion on this is that our current terms reflect old ways of doing business that we’re replacing. As we’re making our transition away from old processes, let’s stop using terms that reflect those old processes to define our new path.

This seems like a digression from the main topic, but it’s just a way to lead you to it. The simple answer is this: this is time-consuming and hard. Period. Read lots of articles to get yourself started and spend a lot of time on it.   –or-  Hire someone to do it.

Hey, I said “simple” not “easy”!

Solid state drives are now available in terabyte sizes, but are more expensive than their more traditional counterparts. However, a couple things might offset that higher cost:

1.                Solid state drives use much less power. The fellow that I spoke with said that the power consumption of a solid state drive was 90% less. I went to the Internet to verify this but did not find an exact verification. I found many charts to showed overall power consumption savings, but nothing that addressed this exact number. So, this might be the case but I cannot independently verify it.

2.                In areas where the per-square-footage building costs are high, floor-space is at a premium. Solid state devices take up much less room. In areas such as Cambridge, Massachusetts, USA, where the per-square-footage costs are extremely high and companies struggle to squeeze into smaller rooms and buildings than in other areas, space is a premium and footage costs can be significant savings costs.

Also, from looking around, it seems that the read times of these devices are much higher than that of the traditional drives, as well.

So, will solid state devices take over for Cambridge, MA, USA data warehouses and other large database applications where reads are quite high, and where both power and floor space costs are high? Or, can they be costed-out to make sense for less costly physical areas and for applications where writes are heavy, as well?