Home > Informatics > Roadmap to a Clear Definition of ELN

Roadmap to a Clear Definition of ELN

The concept of an electronic laboratory notebook has been around for some years, but the actual definition of what it is remains elusive

Randy C. Hice

click to enlarge Figure 1: Many organizations are running separate ELNs for R&D and for QA, as well as a LIMS for structured instrument data.

Back in the late 1980s, my employer at the time, the now-defunct Digital Equipment Corporation (DEC), was getting their arms around what they were calling computer integrated new drug applications (CINDA). The need for CINDA was obvious; the U.S. Food and Drug Administration (FDA), it can be argued, errs on the side of caution, and some folk’s interpretation of stifling bureaucracy can be alternatively perceived as stringent safety precautions. No matter where your feelings may lie, the fact remains that new drug applications (NDA) are astonishing collections of paperwork, running untold thousands of pages. Those pages include extensive details regarding all phases of development and testing, exhaustive summaries and a great many diagrams. In other words, exactly what computers are so good at managing.

Of course, DEC’s thinly-veiled motives were to entice companies to buy more iron (hardware). The assumption at the time was that DEC’s computers and networking products would be hard to resist if DEC could provide rich enterprise applications. To quote the disembodied voice in Field of Dreams: “Build it and they will come.”

But those grandiose ideas crumbled under the sheer complexity of the requirements for such an application or, more likely, application suite. Remember, at the time, what we know as the Internet was in fact the last stages of Advanced Research Projects Agency Network (ARPANET), with the number of hosts totaling only 100,000 or so. In addition to the overwhelming challenge of defining the needs, the concept of collaborative computing was inhibited by the pronounced lack of any sort of a functional infrastructure and a fundamental inability to conceptualize the overarching application framework.

Road to the present
To be sure, if we connect the dots of the late 80s, the need for an “electronic notebook” was certainly noted, but few corporations or entrepreneurs considered diving into the rat’s nest. A decade later, progressive pharmaceutical companies certainly realized the need for collaborative computing, but were perplexed with the prospect that, while the cost of organizing increasingly complex research data was difficult to measure, it was probably easier than trying to measure the lost opportunity costs associated with an inability to share ideas, previous research work and resources within the research and development (R&D) pipeline.

Organizations have been trying to define the functional requirements for an electronic laboratory notebook (ELN) since around the turn of the millennium, but doing so amounts to shooting skeet: the art of trying to draw a bead on a target that is streaking across the sky. The true phenomenon is that the term “ELN” has become less defined than it was a decade ago, partly due to changing context.

click to enlarge Figure 2: A single unified platform can integrate ELNs used for R&D and QD data, together with data captured directly from instruments.

A couple years back, a few companies started to address the problem of standard operating procedure (SOP) compliance. There was a struggle to name the technology, and the first monikers bandied about included compliance management system. The term — and the technology — were more or less ignored by all but a small handful of companies, and a retrenching took place that resulted in the repackaging of the technology and the adoption of a new name: method execution system. Essentially, these systems force users to follow an electronic, script-driven version of the SOP to the letter. At those points where external data (instrument interface data, reagent lots, instrument calibration, perhaps even analyst training records) are required, the user clicks on a link and acquires the data from an instrument interface, external databases or adjunct applications. By using such a “scripted” approach, companies can demonstrate that an SOP was followed exactly as intended.

Of course, calling such a system an MES also presented a problem, since that acronym has long been associated with manufacturing execution systems. These systems actually serve as a go-between in the space between enterprise resource planning (ERP) systems and shop floor control systems as they snap up orders from the ERP and relay them to the machines on the floor to start a manufacturing process.

So, eventually, a few vendors morphed the name of their systems once again to laboratory execution system, or LES. However, this largely isolated term gained little user recognition, and the mainstream informatics vendors now are including this same functionality under the banner of ELN. So, we have come full circle to the genesis of this article; the term “ELN” spans the breadth of laboratory requirements from the pure R&D end of the informatics functional continuum, all the way to SOP compliance management. To avoid confusion, we’ll refer to SOP compliance management as ELN/MES, although this is far from a standard term for now.

Instrument interfacing
There are essentially two producers of ELN/MES:
• the original LES vendors who initially conceptualized the technological approach (we’ll call them “standalone” vendors for now)
• the mainstream informatics suppliers, primarily LIMS vendors, a few of whom have elected to incorporate the approach into their systems.

This development has resulted in competition in some cases, cooperation in others. To understand why, we must first look back to the most prominent point of intersection between the two providers of ELN/MES: instrument interfacing. If we eliminate all other potential points of conflict, instrument integration is a key natural battleground between the standalone LES vendors and the mainstream LIMS vendors.

In the early era of LIMS, instrument interfacing was largely handled by custom code, generally written in FORTRAN, and triggered from specific points in the application. These interfaces actually worked fairly well in their day, but the learning curve was steep, and no two interfaces were the same. Indeed, this was at a time when companies like DEC were writing custom device drivers, such as those required by printers, that we take for granted these days. So, it should come as no surprise that instrument interfaces were complex. But, as the demand for instrument interfacing from LIMS was ubiquitous even then, LIMS vendors were moved to improve their instrument interfacing approaches. Even so, they remained fairly stagnant, technologically speaking, for nearly a decade from the early 80s to early 90s. Later in the 90s, mainstream LIMS vendors divided into two camps:
• those who decided to develop robust GUI-based instrument interfacing tools, tightly integrated within their LIMS
• those who elected to team with “specialist” third-party companies to provide tools for instrument interfacing. To this day, a few mainstream LIMS vendors rely on third-party tools for instrument interfacing.

Nevertheless, for some vendors, tight integration of instrument interfacing tools seemed to make more sense. After all, why force customers to purchase multiple tools and/or incorporate multiple points of failure? So, the lines were drawn in the sand between the mainstream LIMS vendors and the standalone ELN/MES vendors on the instrument interfacing issue alone.

Lines of demarcation
Of course, in a general sense of the SOP compliance side of the equation, some middle ground still remains for mainstream LIMS vendors and standalone ELN/MES to tolerate each other, if not peacefully coexist. For mainstream LIMS vendors who have no current intention of incorporating SOP compliance technology into their products, some opportunity exists for cooperation. Conceptually, each vendor could pave the way for the other, if the needs of the customers included both LIMS and SOP compliance technologies. This synergy presumably is driven by the theorem that it’s best not to alienate any business channel in these tough economic times.

But the scenario whereby a LIMS vendor and a standalone ELN/MES vendor team up may be endangered. Companies are demanding more functionality from fewer systems for a number of reasons, including
• lower costs for licensing and support
• a simpler learning curve
• truly compelling simplicity of having all functionality tightly integrated

The current line of demarcation between the different flavors of electronic laboratory notebooks may be a moot point one day. The market will shape the applications and not the converse. If the recent history regarding the customer demand for the congruence of functionality into one informatics platform is any indicator, the mainstream LIMS vendors may push farther and farther into the R&D end of the informatics spectrum. To do so will require either a change in mindset, or at least a duality of purpose. LIMS have always been about raw sample handling and reporting horsepower. In this world, samples are king, but in the R&D world, samples may be throwaway intermediaries in the research continuum, and the playing field will require much more fluidity in drawing data together to be forged into a report or an FDA submission, not to mention the enabling of fluid R&D collaboration.

R&D vs. QC
The last element will be addressing the fundamental separation between research and manufacturing quality control (QC). R&D and QC groups have generally regarded each other as wholly unrelated contingents within a scientific enterprise. In a great many companies, the lack of any communication between R&D and quality is accepted as an artifact of a traditional natural boundary.

But is that boundary driven by tradition? A cultural imprinting upon the corporate DNA of the notion that R&D and quality naturally exist in parallel universes is nothing new. But the question remains: Is that an organizational constraint, or a technological one?

Indeed, at the highest levels in the scientific enterprise, R&D and quality are simply points in the research continuum that includes early stage activities such as molecular synthesis, and flows through clinical trials and, eventually, manufacturing, with a great many points in between. So, when the universe of the scientific enterprise is considered, the streams of R&D flow into the rivers of production. It is easy to see where the activities of R&D and quality are naturally skewed. Less obvious are those points of intersection whereby R&D and quality could benefit from an electronic collaboration of data. For example, late-stage R&D stability protocols will look very much like production protocols. Testing of pilot batches will utilize methods that will be used in commercial production. The possibilities are endless, and the convergence of functionality under a single roof removes the technological barriers, although the organizational biases may remain for some time.

Perhaps that will change in the near future. At the very least, if the scientific enterprise realizes that a single informatics solution could service R&D and quality without each being aware of the other, the economics and technological wisdom of having a unified platform can easily be rationalized. If, at some point in the future, opportunities for electronic collaboration can be employed to reduce time to market by allowing quality to draw on R&D data easily, the shape of the informatics universe will be changed forever.

Randy Hice is Strategic Consulting Director at Starlims. He may be reached at editor@ScientificComputing.com.

Acronyms 
ARPANET Advanced Research Projects Agency Network | CINDA Computer Integrated New Drug Applications | DEC Digital Equipment Corporation | ELN Electronic Laboratory Notebook | ERP Enterprise Resource Planning | FDA U.S. Food and Drug Administration | LES Laboratory Execution System | MES Manufacturing Execution Systems | MES Method Execution System | NDA New Drug Application | QC Quality Control | R&D Research and Development | SOP Standard Operating Procedure