1. The system is very old and doesn’t work well.

2. You don’t actually know what all your system is doing.

3. Your system is s data graveyard, a place where the data goes in to die and never to be able to be used for data sharing and knowledge management.

4. The system is a critical one and its technology is out-of-date.

5. Your needs have drastically changed since you purchased it.

Actually, I just copied these points from an older article of mine, but the article is a lot worder than just reading these points in this short form:

http://geometrick.com/n-l-how-to-know-when-upgrade.html

• The commercial products are more mature, although the marketplace is still very dynamic with merger and acquisition activity, and new players coming on to the scene.
• Electronic records can be used as evidence in court.
• ELNs really can be used for biology.
• The ‘Cloud’ is a remote server farm.
• Our vocabulary is being extended to include words such as Semantics and Ontologies.
• We need to share data and information across the firewall.
• Thin clients become increasingly important.
• ELNs can be as portable as paper notebooks.
• The need for standards is increasingly recognised.

But there a few things that remain unresolved:

• What is the difference between an ELN and a LIMS?
• What is a Laboratory Execution System?
• How secure is the Cloud?
• Will we ever solve the integration problem?

And of course, there are the permanent concerns about best deployment strategies, return on investment, and getting user buy-in.

Click the link for the programme for ELNs & Advanced Laboratory Solutions. The Download Centre contains a number of articles, presentations, podcasts and videos aligned to the ELN event.

Unfortunately, taking the wider view tends to be a theoretical exercise, since the platform and the set of tools that is required to satisfy the broader set of requirements doesn’t really exist, especially if you are looking at a best-of-breed approach. In fairness to some vendors, this approach does exist to some extent within an application (LIMS and ELNs); you but the generic capability, and plug-in additional functions to address specific requirements, but there are usually boundaries between the applications that present an integration challenge that will absorb a number of resources to resolve, without necessarily achieving desired quality and efficiency gains.

W.E. Deming’s point that the latest new gadget will not fix your quality challenges, may equally apply to the latest new application.

First of all, there’s a web-site that has to do with the topic of sharing scientific data that I ran across. I’ve only read a few postings but it seems interesting, although seems more focused on sharing things in an academic setting or between external companies. Still, here it is in case it might be useful to some of you:  http://scientificdatasharing.com/

Also, consider how you shared data when you had paper notebooks. Would you walk up and read someone’s notebook and then just use that data? Or, would you talk to the person, ask for their conclusions, and give them credit if you write a paper? (as opposed to reading their notebook, seeing the numbers they put in it, and putting them in your own paper that you’re publishing).

Some of this has to do with how much data is shared and when and since that is different for each company, the issues differ somewhat, as well.

If you have any interest in this topic, the person that asked the question is compiling information and might speak at one of the upcoming IQPC meetings, so watch for that topic. The topic would be an especially good discussion topic for one of the meetings.

In my opinion, there are two different sets of requirements that emerge from a progressively maturing marketplace. Most of the meetings held by commercial conference organisers tend to be based on a business model that is aimed at serving vendors’ interests by targeting prospects. The technical programme focuses on case studies and broader, state of the industry/technology-type content. In the laboratory world, we’ve seen these conferences become well established in the LIMS and ELN domains. However, the International LIMS Conferences disappeared some years ago. It may be just a matter of time before a similar fate awaits the ELN conferences.

Over time, and as more delegates progress from being prospects to becoming users, the requirements change. In time, a ‘user’ community emerges whose interests are directed not so much towards the purchasing process, but more towards business and technology trends. As a consequence the requirement for the content of a conference has a different focus; you could say the emphasis shifts from the past (this is how we did it, or this is how to do it), to the future (what’s coming next, what will it mean, and how will we cope).

This changing interest requires a different model with less emphasis on sales and marketing, and more on emerging or evolving business and technology strategies and trends. To a limited extent, this can be, and is, addressed through the online community. Blogs and discussion groups can deal with this up to a point, despite the restrictions of sharing opinion on-line when you are an employee. But there’s a good number of people who believe that face-to-face meetings are an ideal compliment to on-line communication, and this perhaps explains why there is a sense of frustration that this need is not being met very well at the moment. The challenge for the commercial conference organisers is whether they can evolve a successful business model to address this changing need. In the early part of the life cycle of the big LIMS and ELN conferences, delegates had more questions than answers. When there are more answers than questions, its time to move on.

The LIMS market has reached a sufficient level of maturity that (I suspect) we all know what a LIMS is, and what it does. The same is not true for ELNs. For most people, an ELN is far more than a replacement for the paper lab notebook; it needs to provide the generic capability that the paper notebook provides, but it also needs to replace the traditional cut and paste (scissors and tape) with sophisticated electronic interfaces to other laboratory systems and processes that serve specific laboratory disciplines such as chemistry, biology and analytical or Q/A. As such, the authoring tool at the hub of an “ELN’ is the equivalent of the paper lab notebook, and everything else becomes a number of integration challenges that collectively represent an electronic, or integrated lab.

One of these integration challenges is of course the LIMS, and for most organisations an interface between the LIMS and the ELN is a key requirement. The LIMS does all of the sample and test management, based around structured data; the ELN handles the unstructured and discipline-specific data. But the ELN market became a bit fuzzy with a small number of products (QA-ELNs) that were labelled as ELNs, but functionally were closer to a LIMS, albeit with a different type of workflow. The products were essentially built around an SOP-driven workflow that presented the user with the test procedure. Test results could then be added to the appropriate fields in the procedure, either manually, or by a direct instrument interface. Of course, a more typical ELN could be configured with templates that are able to replicate this type of workflow, so one of the impacts of the specialised QA-ELNs was to cause the mainstream ELN vendors to respond with this type of functionality. Having kept very much in the background, suddenly the LIMS vendors, saw the opportunity to extend their products to embrace the QA-style workflow by adding a layer of functionality to provide either a procedural driven approach, or to accommodate the unstructured data that is associated with an experiment.

The outcome then is, if you are looking for a QA-ELN, there are three options; firstly to go with a specialised ELN dedicated to QA, secondly choose a mainstream ELN that offers a QA module, or thirdly choose a LIMS with ELN functionality. There’s no easy answer to this since your organisation’s specific requirements and existing infrastructure will have a big influence, but…..

If you do not already have a LIMS or an ELN, and compliance is a big issue for you, you will probably want to look at the specialised QA-ELNs. If you need to accommodate multiple disciplines in your ELN (chemistry, biology, QA, etc) then the mainstream vendors that offer a product with discipline-specific modules may be your first port of call. And if you already are a customer of a LIMS vendor who is now offering an ELN extension, then their systems may be the first to check out.

But perhaps the real issue here is our application-centric view of laboratory systems. The move by ELN vendors and LIMS vendors to offer a suite of functionality that operates on a single platform makes good sense. And if the platform were not proprietary, then it would make even better sense.

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.

There were two important themes that emerged from the main conference. The first of these was the thorny issue of integration which has bedevilled the laboratory software domain for years. Despite the heroic efforts of the few, the need for messaging and data interchange formats has never been addressed with sufficient inertia to generate any real progress.

The point was addressed by Michael Elliott (Atrium Research) with a renewed call to arms, based on the growing demand for data interchange between laboratory systems such as ELNs, LIMS and SDMs. Further presentations raised the same issue, but from different perspectives. Single-vendor solutions to the integration problem are being developed; in some cases, vendors publish an API; some products (ELNs and LIMS) are increasingly incorporating web services; but for a user community looking to implement and integrate best of breed tools, the challenge remains.

In another presentation, David Drake (AstraZeneca) talked about the Pistoia Alliance and the work currently being undertaken by member companies to develop an open ELN data query standard to support the interchange of data between CROs and their major customers in the Pharmaceutical industry. This new initiative does hold some realistic promise due to the limited scope of the project, and by a growing sense of urgency to solve the underlying business problem.

The other key theme in the conference was the increasing confusion over different brands of ELNs. Whereas Chemistry ELNs are reaching a level of maturity, numerous questions remain over how to address the biology market. Furthermore, the line between a process, or QA ELN and a LIMS is becoming increasingly grey.

The approach to dealing with biology hinges to a large extent around the use of Excel, widely recognised as the biologists’ favourite tool. The dilemma is whether to develop an ELN that wraps some generic functions around Excel in order to leave the biologists free to continue doing what they already do or whether to develop specific functionality, typically based on a spreadsheet format, but which addresses more tightly defined bioinformatic requirements. There are advocates of both approaches.

A further dimension to the biology question was raised by Seth Pinsky with the observation that biology ELNs are more or less dedicated to testing, whereas greater benefit could be achieved with the incorporation of more intelligence in order to address the evaluation of results and the generation of hypotheses. Seth left us with this question: is it possible to automate innovation or creativity?

The LIMS/ELN convergence question has no clear resolution. The underlying distinction is about workflows. Those ELNs that fall within this category tend to be procedure (SOP)-driven, i.e. the ELN presents the procedure, results are then entered and relevant calculations preformed, all in accordance with appropriate regulatory requirements. This same functionality can of course be incorporated in a LIMS, although this may represent a less typical workflow than the norm. The basic difference is in the infrastructure of the application. A LIMS is typically designed to handle structured data, whereas an ELN is typically designed to handle unstructured data. From a functional perspective, our application-centric view of laboratory systems seems to require us to call the ‘system’ a LIMS or an ELN, when what we are really dealing with is data capture, data processing and data management functions. How much does this matter to users? Difficult to say – perhaps it matters more to the vendors?

Overall, the conference had a slightly different feel than previous years. There is a growing sense of maturity about some aspects of ELNs, but the integration issue is starting to take on more and more relevance as users come to terms with the implications of working in an electronic environment. In particular, the Pistoia project will be watched with considerable interest.

http://outonalims.wordpress.com/2009/09/24/in-boston-laboratory-informatics-is-important-but-people-still-matter/

From going to give a free talk for a colleague to attending the Boston LIMS/Laboratory Informatics meeting, yesterday was a pretty good day. Both those events got me more information and excitement than I get from my on-line discussions or my e-mail.

A couple days ago, John Trigg was talking about conferences, YET AGAIN, in:

http://theintegratedlab.com/2009/09/conferences-again/

In fact, you’ll notice he and I talk quite a bit about getting out to conferences and how important that is. If you search TheIntegratedLab’s postings, you’ll find this out.

As I’ve said, before, I realize that many of you have had budget cuts that prevent you from going to the big conferences, but they don’t prevent you from going to local meetings. For example, in the Boston area, alone, there’s LIMS/Laboratory Informatics, ACS (American Chemical Society), ALMA (Association of Laboratory Managers), LRIG (Laboratory Robotics Interest Group). That’s just a very few of them! And, while a few do charge a modest fee, most of them are free to attend.

Just in the LIMS/Laboratory Informatics group, alone, we’ve had great speakers on biobanking LIMS, ELN issues, Wikis as LIMS, and on how to learn to run better laboratory informatics projects. The excitement at some of our meetings way surpasses the interest we show in any our our on-line discussions.

So, the on-line discussions are great for sharing information but just don’t have the same element of “chemistry” you get when interested people get together.