Intended audience: People new to automation projects, maybe in startups, and in particular, students.
Objective: To give them a starting point for organizing and planning projects.
Why would this be important? If you don’t have a solid starting point, you’ll never get anywhere. This is in part educational, helping define the initial stages of planning and direction setting.
This requires a little bit of explanation, particularly since the site is focused on Laboratory Systems Engineering (LSE). The original article was written in 2006. At that point we were focused and introducing automation into the laboratory and basically getting things to work. Integrated systems was a gleam in our eyes but distant in its realization. Some projects worked a lot didn’t.
It’s now 2024 (2025 in a few days), and things have changed. Our field of view has broadened to include multiple systems and multi-departmental inter-connects. As a result the narrow focus of 2006 had to become more encompassing, hence the shift to LSE. Most of what the article says still applies, the differences are in the level of skills and education needed. We need people that can straddle the lab and IT spaces, and provide useful insights into inter-system and inter-departmental design and implementation.
The goal of this brief paper is to examine what it will take to advance laboratory operations in terms of technical content, data quality, and productivity. Advancements in the past have been incremental, and isolated, the result of an individual’s or group’s work and not part of a broad industry plan. Disjointed, uncoordinated, incremental improvements have to give way to planned, directed methods, such that appropriate standards and products can be developed and mutually beneficial R&D programs instituted. We’ve long since entered a phase where the cost of technology development and implementation is too high to rely on a “let’s try this” approach as the dominant methodology. Making progress in lab technologies is too important to be done without some direction (i.e., deliberate planning). Individual insights, inspiration, and “out of the box” thinking is always valuable; it can inspire a change in direction. But building to a purpose is equally important. This paper revisits past developments in instrument data systems (IDS), looks at issues that need attention as we further venture into the use of integrated informatics systems, and suggests some directions further development can take.
There is a second aspect beyond planning that also deserves attention: education. Yes, there are people who really know what they are doing with instrumental systems and data handling. However, that knowledge base isn’t universal across labs. Many industrial labs and schools have people using instrument data systems with no understanding of what is happening to their data. Others such as Hinshaw and Stevenson et al. have commented on this phenomenon in the past:
Chromatographers go to great lengths to prepare, inject, and separate their samples, but they sometimes do not pay as much attention to the next step: peak detection and measurement … Despite a lot of exposure to computerized data handling, however, many practicing chromatographers do not have a good idea of how a stored chromatogram file—a set of data points arrayed in time—gets translated into a set of peaks with quantitative attributes such as area, height, and amount.[1]
At this point, I noticed that the discussion tipped from an academic recitation of technical needs and possible solutions to a session driven primarily by frustrations. Even today, the instruments are often more sophisticated than the average user, whether he/she is a technician, graduate student, scientist, or principal investigator using chromatography as part of the project. Who is responsible for generating good data? Can the designs be improved to increase data integrity?[2]
We can expect that the same issue holds true for even more demanding individual or combined techniques. Unless lab personnel are well-educated in both the theory and the practice of their work, no amount of automation—including any IDS components—is going to matter in the development of usable data and information.
The IDS entered the laboratory initially as an aid to analysts doing their work. Its primary role was to off-load tedious measurements and calculations, giving analysts more time to inspect and evaluate lab results. The IDS has since morphed from a convenience to a necessity, and then to being a presumed part of an instrument system. That raises two sets of issues that we’ll address here regarding people, technologies, and their intersections:
1. People: Do the users of an IDS understand what is happening to their data once it leaves the instrument and enters the computer? Do they understand the settings that are available and the effect they have on data processing, as well as the potential for compromising the results of the analytical bench work? Are lab personnel educated so that they are effective and competent users of all the technologies used in the course of their work?
2. Technologies: Are the systems we are using up to the task that has been assigned to them as we automate laboratory functions?
The purpose of this piece is to introduce people who are not intimately familiar with laboratory work to the basics of laboratory operations and the role that informatics can play in assisting scientists, engineers, and technicians in their efforts. The concepts are important because they provide a functional foundation for understanding lab work and how that work is done in the early part of the twenty-first century (things will change, just wait for it).
This material is intended for anyone who is interested in seeing how modern informatics tools can help those doing scientific work. It will provide an orientation to scientific and laboratory work, as well as the systems that have been developed to make that work more productive. It’s for people coming out of school who have carried out lab experiments but not corporate research projects, for those who need to understand how testing labs work, and for IT professionals who may be faced with supporting computing systems in lab environments. It’s also for those who may be tasked with managing projects to choose, install, and make informatics tools useful.
Figure 1 shows the elements we’ll be discussing in this piece. The treatment of the technical material will be on the lighter side, leaving in-depth subject matter to other works. Instrument data systems will be covered lightly, as any serious discussion becomes lengthy and discipline-specific very quickly; additionally, that material has been covered in other works.
| Figure 1. Elements we’ll be covering |
LSE is intended as a multi-disciplinary field of work encompassing an understanding of:
The relevant science. This is necessary because the LSE would connect with laboratory personnel and their work environment, understand what they are doing, and translate their needs into working systems. This could be a specialization point for an LSE in electronics, life science applications, physical sciences, etc. However, the basic principles of data acquisition, processing, storage, analysis, etc., are common across sciences, so moving from one scientific discipline to another would not be difficult.
Laboratory Informatics includes LIMS, ELN, SDMS, LES, IDS, digital communications connections (serial, parallel, GPIB, etc.), relevant protocols, analog data acquisition, and related processes etc.
Robotics, including electronics and mechanical engineering principles, and the application of commercial systems to lab work.
Information Systems Technologies, including hardware, operating systems, database applications, and communications. LSEs would not be a replacement for or duplication of traditional IT services. They would bridge the gap between IT services roles and applying those technologies to lab work. In many lab applications, the computer is just one piece of a system that is only fully functional if all the components work together. While this is less of a concern when a system (instruments and computers) is purchased and installed by the vendor, it becomes a significant problem when mixed vendor solutions are being used, for example, the connection of an instrument data system to a LIMS, SDMS, or ELN.
Their skill set should include working with teams and the ability to lead them in the successful development, execution, and completion of projects. This would require interpersonal skills to work with people at various management levels.
Part of the LAE’s role is to examine new technologies and see how they can be applied to lab work. Another is to assess the lab’s needs and anticipate technologies that need to be developed.
An earlier version of this skill set was described under “Laboratory Automation Engineering,” drafted in 2005/2006**. In the almost two decades since that article was released, laboratory informatics and information technologies have become more demanding and sophisticated, requiring a change in the field’s name to reflect those points.
It would also be helpful to have a background in General Systems Theory – This field of work will help LSEs and those they work with describe and understand the interactions between the laboratory informatics systems used in laboratory work. Why is that important in this context? Laboratory Informatics is an interconnected set of components that ideally will operate with minimum human intervention. General Systems Theory* will help describe those components and their interactions.
In addition to laboratory instruments and equipment, vendors have created software products to assist lab personnel in their work. Some acquire and process data from instruments, some help manage that data, and others manage the lab’s workflow. The bottom line for these systems is to improve productivity, reduce the amount of manual labor and time required, and, at the same time, provide better results. Those benefits are only possible if you understand the software systems, how to use them, and their limitations.
Education is a big part of people’s problems working with laboratory informatics. What are the components, how do they fit together, and how do I use them effectively are just a few of the questions that need to be addressed. That is the point of the following article. I hope it serves you well. If you’d like to discuss it, send a note to “joe.liscouski@gmail.com” or “joe.liscouski@laboratorysystemsengineering.com.”
This guide’s intent is to help the science student and instructors understand the roles that laboratory informatics plays in scientific work and to give them a starting point in learning more about the subject.
Purpose:
Main Topics Covered:
2. Levels of Knowledge in Laboratory Informatics:
3. Informatics Tools and Technologies:
| Key Systems | – Laboratory Information Management Systems (LIMS) – Electronic Laboratory Notebooks (ELN) – Scientific Data Management Systems (SDMS) |
| Other Tools | – Laboratory Execution Systems (LES) – Instrument Data Systems (IDS) – Robotics for automation – Data acquisition and control |
| Data Governance and Integrity: | – Frameworks like ALCOA-CCEA ensure data reliability – Regulatory requirements |
Sources for the article:
Laboratory Systems Engineering 