Type a search term to find related articles by LIMS subject matter experts gathered from the most trusted and dynamic collaboration tools in the laboratory informatics industry.
Title: Laboratory Informatics: Information and Workflows
Author for citation: Joe Liscouski, with minor editorial modifications by Shawn Douglas
License for content: Creative Commons Attribution-ShareAlike 4.0 International
Publication date: April 2024
NOTE: This content originally appeared in Liscouski's Computerized Systems in the Modern Laboratory: A Practical Guide as Chapter 3 - Laboratory Informatics / Departmental Systems, published in 2015 by PDA/DHI, ISBN 193372286X. This is reproduced here with the author's / copyright holder's permission. Some changes have been made to the original material, replacing some out-of-date screen shots with vendor-neutral mock-ups, for example. In addition, note that some specifications for network speeds are out-of-date but the concerns with system performance are still realistic.
Laboratory informatics refers to software systems that usually are accessible at the departmental level–they are often shared between users in the lab-and focus on managing lab operations, and lab-wide information rather than instrument management or sample preparation (Figure 3-1).
|
Differing from standard office applications (e.g., word processing, spreadsheets, etc.), laboratory informatics software solutions include the:
Before we get into the details of what these technologies are, we must establish a framework for understanding laboratory operations so that we can see where products fit in the lab's workflow. The products you introduce into your lab are going to depend on the lab's needs, and given the complexity of vendor offerings and their potential interactions and overlapping capabilities, defining your requirements is going to take some thought.
These products are undergoing a rapid evolution driven by market pressures as vendors compete for your business, partly by trying to cover as much of a lab’s operations as they can. If you look at functional checkboxes in brochures, they often cover similar elements, but their strengths, weaknesses, and methods of operation are different, and those differences should be important to you.
We are going to start by comparing two different types of laboratory environments: research labs and service labs (laboratories whose role is to provide testing, and assays, for example, quality control, clinical labs, etc.). That comparison and subsequent material is going to be done with the aid of an initially simple model for the development and flow of knowledge, information, and data within laboratories (Figure 3-2).
|
The model consists of ovals and arrows; the ovals represent collections of files and databases supporting applications, and the arrows are processes for working with the materials in those collections. The “ES” abbreviation notes processes that bring in elements from sources outside the lab. The first point we need to address is the definition of “knowledge,” “information,” and “data,” as used here. We are not talking about philosophical points, but how these are represented and used in the digital world. “Knowledge” is usually reports, documents, etc. that may exist as individual files or be organized and accessed through applications software. That software would include DMSs, databases for working with hazardous materials, reference databases, and access to published material stored locally or accessed over internal/external networks.
“Information” consists of elements that can be understood by themselves such as pH measurements, the results of an analysis, an object's temperature, an infrared spectrum, the name of a file, and so on. Information elements can reside as fields in databases and files. Information can be provided as meaningful answers to questions. Finally, “Data” refers to measurements that by themselves may not have any meaning, or that require conversion or be combined with other data and analyzed before they are useful information. For example, the twenty-seventh value in a digital chromatogram data stream, the area of a peak (needs comparison to known quantities before it is useful), millivolt readings from a pH meter (you need temperature information and other elements before you can convert it to pH), etc.
There are grey areas and examples where these definitions may not hold up well, but the key point is how they are obtained, stored, and used. You may want to modify the definitions to suit your work, but the comments above are how they are used here.
The arrows represent processes that operate on material in one storage structure and put the results of the work in another. Processes will consist of one or more steps or stages and can include work done in the lab as well as outside the lab (outsourced processing, access to networked systems, for example). It is possible that operations will be performed on material in one storage structure and have those results placed in the same storage level. For example, several “information” elements may be processed to create a new information entity.
Initially, we are going to discuss the model as a two-dimensional structure, but those storage systems and processes have layers of software, hardware, and networked communications. In addition, the diagram as shown is a simplification of reality since it shows only one process for an experiment. In the real world, there would be a process line for each laboratory process in your lab, and the “data” oval would represent a collection of data storage elements from each of the data acquisition/storage/analysis systems in the lab. Each experimental process would have a link to the “knowledge” structures catalog of standard operating procedures (SOPs). As we start to build on this structure we can see how requirements for products and workflow can be derived.
The material covered in the Lab Bench chapter (Chapter 1) fits the model as shown in Figure 3-3 (the model used in the Lab Bench discussion is shown as well; it is represented by the light-/heavy-grey lines in the K/I/D model). The sample preparation and pre-instrumental analysis work is shown as the light-grey / heavy-line portion of the “Measurement & Experiments” process, with instrumental data acquisition, storage, and analysis displayed with the darker grey/heavy line (which may be entirely or partly completed by the software; the illustration shows the “partial” case). Not all experiment/instrument interactions result in the use of a storage system. Balances, for example, may hold one reading and then send it through to the information storage on command, where it may be analyzed with other information. The procedure description needed to execute a laboratory process—the measurement and experiment—would come from material in the “Knowledge” storage structure.
|
What we are concerned about in laboratory informatics is what happens to the data and information that results either from data analysis or information gained directly from experiments.
By its nature, research work can be varied. SOPs may change weekly or more slowly, and the information collected can change from one experiment to another. The information collected can be in the form of tables, discrete reading, images, text, video, audio, or other types of information. The work may change depending on the course of the research project. Aside from product support on the lab bench, the primary need is for a means of recording the progress of projects and managing the documents connected with the work.
Until recently, that need was met through the use of paper notebooks, with entries dated, signed by the author, and counter-signed by a witness. The researcher would document the work by handwritten entries, and instrument output would be recorded similarly or have printouts taped to notebook pages. Anything that could not be printed and pasted in would have references entered. There are a few problems with this approach:
The intellectual property recorded in notebooks is of value only if someone knows it exists, and that it can be found and understood. There is another point that needs to be mentioned here that we will reference later: lab personnel consider entries in paper lab notebooks as “their work and their information.” To the extent that it represents their efforts, they are right, but when it comes to access control and ownership, the contents belong to whoever paid for the work.
Research work is sometimes done by a single individual, but often it has several people working together in the same lab or collaborating with researchers in other facilities. Those cooperative programs may be based on:
Whether we are looking at single individuals or cooperative work, each of those situations has an impact on the way knowledge, information, and data is collected, developed, shared, and used. For example, take a look at Figure 3-4 below.
|
The figure shows three researchers working on individual projects, contributing to, and working from, a common data set; this could in fact be one data system or a collection of data systems from different sources. The bottom arrow represents data coming in from some outside source.
Regardless of whether this is an electronic system or a paper-based process, there still is the following set of requirements:
These points form a basic set of requirements, that will be expanded, for any shared knowledge/information/data repository. If we extend the model to having the three individuals combine their “knowledge” sets into one shared repository, the same issues apply; they may be collaborating on a research project. The standardization of file formats is simpler since most “knowledge” is recorded as text and the processes for working that kind of material have been addressed, at least well enough to be readily workable with existing tools.
Service laboratories—those that do work supporting other departments, labs, etc. such as quality control, clinical chemistry, and so on—have a different set of operational characteristics. The model for service labs is very similar to that of research with one distinction: the “Synthesis” process is absent (Figure 3-5). That process is the one used to develop new knowledge. In the case of service labs, that knowledge is represented by test or assay procedures. Those procedures normally come from other sources and are not usually developed by service labs. One departure from this view is contract testing labs which may, as part of their contract, be tasked with procedure development. Analytical research groups are another, but while they may have some service lab work, they are also doing non-routine work that includes method development, and function as a specialized research-service laboratory.
|
From the test submitter's point-of-view, they request test/assay work and wait patiently for the results from service labs. Those requests may be sporadic depending on the environment the lab operates in, or regularly scheduled as they would support a production process, with requests going to quality control.
The perspective from inside the lab is a bit different. Test requests arrive that may or may not be accompanied by the material to be tested. In both cases, the samples are logged in, prioritized, and scheduled for work. If the samples are not there, they are either collected (may be part of the lab's work) or put on hold until the samples arrive, then they are added to the work queue. As part of the lab operations, there is a need to:
Aside from the use of scientific instruments, much of this behavior may seem to be typical of a variety of service-oriented operations. That point will be addressed later. The nature of service lab operations is highly structured and routine. You could move from one service to another, regardless of industry, and aside from the details of testing, feel comfortable with the routine.
The most time-consuming part of service lab operations is managing the workflow and keeping track of incoming and outgoing test requests and samples. It is bookkeeping work. Without the aid of computer systems, it is a matter of manually logging samples in—transcribing information from request forms into log books, using the same log books to find out what work needs to be done, and so on. Most of the management effort revolves around the logbook, including logging samples out, so time is wasted waiting for access to that book.
There is another characteristic service labs have that is not always shared with research environments: the need to communicate with other groups. Service labs don’t exist as independent facilities, and they have to be able to send and receive documents from other groups. In a research organization, it is the research lab themselves, while in production environments it is raw material receipt (i.e., certificate of analysis approval and testing), process control (i.e., in-line testing, product quality), shipping (i.e., certificates of analysis, product release documents), and customer service (i.e., product lot specifications).
Not all lab situations are as cleanly divided as described although many are. In small research operations, you may find both sets of characteristics in one operation, all under the heading of “research.” The laboratory workflow model for that situation is shown in Figure 3-6.
|
The illustration shows a research group on the left with a common “data” resource, and storing the results of their work in a common “knowledge” structure (common in collaborative work) that can consist of reports, SOPs, materials catalogs, and so on. Each researcher works on their experiments and the dedicated testing group provides characterization / analytical services where needed (the testing group would get its SOPs from the research knowledge base, it may also develop its own).
One thing that is important to note is that the words “information” and “data” appear on both sides of the diagram. A sample may be submitted to the testing group to determine its purity. Using instrumental techniques, UV spectrophotometry or chromatography for example, results in the testing groups “data,” which is then analyzed to give a purity value which is recorded as “information.” When the results are transmitted back to research, they may reclassify the status of the value to “data” due to the nature of the experiments being done.
The point here is to contrast different operating characteristics of labs so that we can later show how informatics products fit differing laboratory workflows. In reality, multiple informatics products may be used by both types of labs, some with a stronger emphasis on one over another depending on the features the products have and how they help you work. Some are better suited to the inherent flexibility required in research, others fit the laboratory management requirements of the service lab, and still others will find useful applications in both. It is a matter of understanding what your needs are now and where they might go in the future. The next section will look at product capabilities and use so that you can match your needs to potential solutions, and be able to evaluate characteristics that can impact their implementation.
Figure 3-7 shows a set of five laboratory functions and four key informatics technologies, with the approximate dates that they came on the market. Since we are looking at technologies from multiple vendors with variations in functionality, the dates are guides. Over time, the technologies noted have evolved due to requests from customers and market pressures to remain competitive in the marketplace. Along the way vendors have closed shop, kept their place in the market, and also merged with other companies with products merged, retired, or remained active.
|
One thing you’ll notice is that there are no product technologies in Figure 3-7 for “Document Management” and “Experiment & Test Execution.” Document management had been considered as a text document management issue and addressed by commercial software used for that application, the same type of software used in other departments. The initial product for experiment and test execution began with Velquest’s SmartLab (Velquest is now part of BIOVIA as of 2014), which was offered in the early 2000’s as a laboratory notebook: “VelQuest's electronic Laboratory Notebook using the SmartLab (electronic Process Management & Compliance) software, with a primary focus on the Procedure Execution module including data review and data reporting.”[2] As the ELN market developed, the product was recast as a LES, first by Velquest, then by Accelrys.[3]
As you will see, the market has been undergoing rapid changes since the 1960s. Those changes have been due to:
We’ll discuss the technologies in the order they came onto the market, which will help you understand how these products developed over time. Their appearance was spurred by people's experience with the earlier products, and vendors worked to fill gaps in offerings by upgrading existing products or creating new ones. One point we will address now, from the user's perspective, is the difference between the ELN and the LIMS.
In the case of an ELN, information is largely organized by experiment or research project/program. The content of an ELN is varied depending on the nature of the work being done, but it is typically heavily text-oriented. ELNs are widely applicable to most lab environments, with specialized variants for biology, chemistry, etc. ELNs are primarily a tool for recording descriptions, measurements, results, plans, experiments, and research projects. They can be viewed as a shareable (if desired) electronic diary.
With a LIMS, information is organized by sample (or samples within a test series such as stability or formulations work). The contents are usually numerical values but may also contain brief text entries. The use of LIMS is normally limited to organizations that provide testing services in a wide range of industries and are heavily used in quality control. LIMS is primarily a workflow/workload management tool with the ability to record the results of testing on samples. The LIS is a variation of LIMS targeted for the clinical and healthcare markets.
You’ll also note that descriptions for research work (such as the one above) are less detailed than those for service labs. Research work is very flexible, and the structure behind the work depends on the industry and how the lead researcher chooses to go about organizing programs and projects. Service labs have a consistent structure and behavior between industries and the type of work being done (clinical, analytical, physical testing, etc.) and as a result, are easier to describe. Figure 3-8 can be applied to almost any service lab in any industry. Trying to come up with a similar diagram for research with the same level of generalization would be difficult. This has an impact on vendors and the products they develop: the better characterized a process is, and the wider the application, the more likely they are to invest in product development.
|
The sequence of computer-based product development in scientific applications isn’t an accident. Vendors began with what they knew—instruments—and built products to improve their use. In informatics, LIMS came first, because service lab environments were well characterized and understood by the vendors. In sample preparation and the application of robotics to lab work, microplate support systems have seen wide and rapid development, while general-purpose applications are well behind that development curve. The development of ELNs has been less aggressive than LIMS, because of the variability of the underlying processes. If you want products developed, give the vendors a well-characterized, widely applicable process with enough potential sales opportunities to justify the work.
This was the subject of the Lab Bench chapter, and for the most part we’ll leave it at that. The only point we will make is that as instrument data systems (in some cases, most notably chromatography) took on the ability to support multiple instruments with a single computer, those systems took on rudimentary sample tracking capability. It wasn’t at the level of a commercial LIMS, but it was sufficient to manage multiple samples with multiple users and their worklists.
There is one point that we need to make that will apply to all the material in this book: questions that will be in the back of your mind are “How does that relate to my lab needs?” or “How can we make use of that?” Before you consider questions like that, you have to know how you want your lab to operate/function and what your requirements are. In order for you to be successful in applying products to lab work, you have to understand what problems you want to solve and how a given product's capabilities relate to them. There is always the possibility that some technology will come along and change the way you look at lab work. In order to appreciate that possibility, you have to understand your overall plan for technology usage.
In the 1960s, instrument vendors and a few lab people were experimenting with interfacing computers and instruments. These systems were noted as “data stations.” In the 1970s, Perkin-Elmer Corporation began the development of a computer system to address laboratory management problems and created the first commercial LIMS. The intent of the name was to put some distance between it and the data stations it was selling and give the impression of covering all of a lab's needs. To put things into some temporal perspective, the ELN, a text-processing-heavy application, was in the future; word processors were just coming on the market. LIMS was a poor choice for a product name since users expected it to cover all “laboratory information,” including budgets, vacation schedules, documents, and any information they might have in the lab. What it did do is help track samples.
Within quality control and analytical laboratories, managing sample flow was a significant problem consuming people's time, and addressing it was a worthwhile effort (Perkin-Elmer’s – ‘P-E’ - instruments were used in chemical analysis and as a result, these labs were natural marketing targets). (The problem was described in the service lab section above and the workflow view shown in Figure 3-8.) The P-E product was the first of a long list of products to address the same issue, some with overlays to handle specific markets. One list[5] contains over one hundred products. Among the specific markets are the:
Tailoring LIMS to address these activities can significantly reduce the amount of effort needed to manage testing and drastically reduce the amount of data entry required. One common application is product stability testing, as noted above.
A project is created where a series of samples are placed in controlled environments (i.e., temperature, humidity, etc.) and tested according to a schedule that can run to hundreds of sample-test combinations; a stability overlay asks some basic questions and then generates the test regime and logins needed to support the work. Without this type of application overlay, each sample would have to be logged in individually, opening the possibility of data entry errors and requiring someone to check each entry and correct mistakes, a time-consuming, labor-intensive process.
The following illustrations and descriptive text, provided and used with permission by LabLite Systems LLC, show a data entry screen (Figure 3-9a) and a search screen (Figure 3-9b).
|
|
Another is the clinical industry. One point that needs to be addressed is the difference between a LIMS and LIS. They are very similar systems in terms of function and capability. LIMS is used in a much broader market (e.g., life sciences, environmental, chemical, oil and gas, etc.), almost everywhere except clinical environments. LIS are rarely encountered outside clinical labs because of their close ties to patient records and healthcare. Some LIMS vendors will try to sell their products into clinical labs claiming that their offerings are technically more sophisticated and using current technologies. That said, there are two basic but significant differences:
The following list is a set of functions that you should expect a LIMS to support, the information is from the Laboratory, Scientific, and Health Informatics Buyer's Guide[6]:
A more extensive set of functions can be found in the ASTM E1578-13 standard, including those that extend beyond LIMS and LIS.[4] Both LIMS and LIS have functions that support the model in Figure 3-8. That said, there are a few additional points worth noting.
Systems provide functions for sample logins that include:
Event-driven actions can be tied to the login process as well as other events. For example, if samples haven’t arrived in the lab, an “event-driven action” can notify lab personnel when the samples arrive, and their status changes from “waiting” to “in the lab.”
The next few illustrations (Figure 3-10a-c) are mock-ups of LIMS screens. These replace the original out-of-date graphics. The data shown in the illustrations is made-up sample information used for demonstration; if it doesn’t seem “real,” it isn’t.
|
|
|
In early systems, “data entry” was a manual process of reading information from a paper notebook or computer printout and retyping it into the LIMS via a data entry form. Even though systems have been improved to permit electronic transfer of data—particularly in LIS supporting HL7 communications protocols—you still find people manually entering data. This fails to take full advantage of the potential for increasing productivity by having people do work that could be done by systems, and, requiring additional work (a second person checking entries) to avoid transcription errors.
The reliance on manual data entry quickly generated a demand for electronic transfer of information between LIMS, instruments, and instrument data systems. Some of those connections were made by customers, and others were provided by vendors. The LIS and LIMS market approached the problem from different directions depending on how they viewed the marketplace: LIS were entirely focused on clinical and healthcare operations, LIMS vendors wanted to cover everything else (chemistry, oil and gas, pharmaceuticals, biotechnology, manufacturing QC, etc.) and clinical labs where they could. Although a working diagram (Figure 3-11) looks the same for both cases, the mindset is completely different.
|
Let’s begin with the diagram on the right, a clinical system based on a LIS. On the lab bench there are a variety of instruments and data systems that communicate with the LIS, and the LIS in turn communicates with patient records and hospital administrative systems. That situation is repeated in most hospitals. The lab runs a standard suite of testing that may be expanding beyond traditional blood, urine analysis, and so on; Waters Corporation for example has introduced mass spectrometry systems for clinical laboratories.[7] This repeated model consists of a relatively limited range of procedures that is run in the labs (compared to the chemical industry, for example, which can use a wide range of procedures), with connections to a functionally common set of applications outside the lab, coupled by a key communications element created a unique ability to connect lab instruments to LIS in a manner that doesn’t exist outside of clinical systems. The ability to make those connections has changed the way lab work is done, and improved the economics of lab operations. For example[8]:
Between 1965 and 2000, the Consumer Price Index increased by a factor of 5.5 in the United States. During the same 36 years, at our institution's Chemistry Department the productivity (indicated as the number of reported test results/employee/year) increased from 10,600 to 104,558 (9.3-fold). When expressed in constant 1965 dollars, the total cost per test decreased from 0.79 dollars to 0.15 dollars.
That key communications element—the development of communications standards—was driven by the cost of lab operations and an industry-wide effort to address problems with lab economics. Clinical labs have the charges they can assess for work set by contracts. In the 1980s, it became clear that the costs of running a lab were going to exceed income. The problem was addressed by instituting successful “total laboratory automation” (TLA) programs. The programs were based not only on automation (which could have been done on a task/workstation level) but also upon integration of laboratory systems to achieve a higher level of performance that could not have been gained otherwise.[8][9][10][11][12][13][14]
Integration through communication standards like HL7, noted earlier, provides the key element in making automation capable of achieving its potential through error-free information interchange. Imagine the lab bench section of Figure 3-11 without the lines (thick black) connecting instrument systems to the communications service; all of the interactions between the instrument, instrument data systems, and LIS would be manual (i.e., read from here, type it in there). Integration through communications standards makes TLA work and provides instrument and computer systems vendors with a fundamental architectural infrastructure integration element that they can rely upon to make systems work together. This was an industry-driven initiative that was supported by vendors and provided a reliable mechanism for the electronic exchange of information.
Note that when we talk about “communications,” we are covering more than the plug in the back of a device. For communications to occur, we need a means of:
Think of it as part of the postal system. The postal system gets mail from one place to another using different transportation methods. The envelope holds the routing information, and inside is the actual message you want to transmit. You also have to have the ability to understand the message, the language used, the format and so on. (Different instruments of the same type will use different command structures and message formats, and a device receiving a message in the wrong format—akin to getting mail in a language you don’t understand—will lead at best to an error message return or an ignored message. At worst, it may interpret the message and do something you would have preferred it didn’t.) If any of those elements are lacking, communication doesn’t occur.
Some devices cannot incorporate sophisticated communications protocols such as HL7; they have network connections but not higher-level industry-specific software. In those cases, “middleware” is used (Figure 3-12). Middleware is software (see Figure 3-10) that acts like a translator that interprets communication standard protocols/messages for devices that can’t handle them. Middleware is bi-directional so communications can occur in both directions (device to HL7 capable software and back).
|
Middleware serves the same function in LIMS to instrument connections; however, the LIMS-instrument communications protocol (layers above the network interface) is up to the vendor.
Once you move from the HL7 support of the clinical laboratory to the industrial research and testing labs, things are a lot different. The left side of Figure 3-9 shows the organizational environment that a typical lab might encounter. The major difference between the left and right sides of the illustration is that while the right is well characterized, the left is generalized: products from the lab bench on up through the department and inter-department levels might be communicating with anything. The lab-bench-to-LIMS options are wide open (including in-house / contractor-developed systems), and the LIMS to the world outside the lab may be taken to the warehouse, accounting, process control, etc. systems from a variety of sources.
Initially, not knowing what a product might be asked to communicate with left the vendors with few options. The one taken from the instrument/data system level was to produce files plus a means of sending them and letting them go at that, i.e., let the user take it from there. Most users became acutely aware of instrument/data system communications when they wanted to install a LIMS and put pressure on the LIMS vendors to connect with lab equipment; it was either have the vendor do the work or use internal/contract resources. Lacking any drive toward industry standards for communication and integration, each vendor approached the issue in their own way. As a result, installing a LIMS without instrument connections provides one level of difficulty, while adding links to instrument data systems and robotics controllers substantially raises the level of complexity, cost, and effort.
Some LIMS vendors provide a suite of instrument/data system interfaces for their products, a list of devices and systems with software to support command/control and data interchange. The software is supported by the vendor, and they may also provide application programming interfaces (APIs) for situations where you want to connect something that isn’t part of their offering. If you are interested in connecting a lower-cost device (e.g., balance, pH meter, etc.) and the vendor supports a model different than the one you have, it may be less expensive to buy a compatible one rather than trying to interface the one on your bench; we’ll get to why in a moment.
Other LIMS vendors provide little support for external devices. These are often low-cost systems that are attractive due to their low initial investment but may be costly when faced with support and customization work.
Interfacing instruments/data systems to LIMS (or any informatics software for that matter) is costly for the following reasons:
Communication standards have a significant impact on your lab's ability to work, and it is something the industry needs to address.
At a minimum, when installing a LIMS or LIS, you can expect a fair amount of work before it goes into operation. Information specific to your lab has to be entered: test information, methods of identifying samples, support for barcodes, personnel information, materials used, etc., (refer to the ASTM E1578-13 standard for details). The software is a blank slate and has to be initialized before it becomes useful. You will also have to face the full set of requirements for systems qualification and validation to ensure that the software is ready for use and meets regulatory requirements.
Those validation / regulatory requirements are there for your benefit. You are going to put a tool in place that is going to manage your lab's ability to work, to know what work has to be done, and to send and receive information from instruments and data systems. Being able to prove that it is ready for the work will give you the confidence needed to trust its ability to support your lab.
People also have to be educated in the systems used, and the need for education will be continual as new people come into the lab and changes are made to the system. You want to make sure that people are ready to use the system, and that they have confidence in themselves and their ability to work with the software. Fear of failure, and making mistakes that can’t be erased (regulatory considerations) is a serious concern when introducing new software into a laboratory. Classroom training is one thing, but there is nothing like hands-on experience to solidify what they’ve heard elsewhere. One recommended approach is to have available two versions of the system: one is the actual "live" system used for production work, and the other is a training system that people can learn on, make mistakes, try things out, etc.; it will remove the fear of working with something new by letting them practice on software that can absorb mistakes without any consequences. This educational system can also act as a test bed for new ideas, software, and instrument interfaces. Having two copies of the system may have an impact on license costs, so make this part of the system negotiations with the vendor. (Note: Some IT entities do not understand the need to have a practice system. It is necessary to ensure a smooth transition from one LIMS to another. It is also useful to run the old system and the new LIMS side by side to develop production history.[a])
A few pages back we noted that from an operational point of view, service labs' operational functions were similar to operations in other service businesses. That point hasn’t been lost on enterprise resource planning (ERP) vendors; ERP software is widely used in integrating and managing business operations. Several packages have quality management (QM) modules that help companies keep track of quality issues, control charts, data management, instrument calibration, product inspection, audit management, etc. That said, the question that is raised is “Can this software be adapted to meet the functions provided by a LIMS?” You will not be too shocked to find that ERP vendors say “yes,” a view that is supported by several IT consultants; just search “LIMS ERP” in your favorite search engine. The champions of the ERP-as-a-LIMS view often come from corporate functions (often referred to as the C-suite). They see:
ERP vendors support the position, as do some stand-alone LES vendors who see LIMS as competition for their market space (the LES-ERP combination would replace the need for LIMS, as they see it). They do have a perfectly valid point: how it applies to you depends on how your lab operates and wants to operate. As we’ve noted before, the key to evaluating the discussion with respect to your lab depends on thorough technology planning and, if you are considering a LIMS, well-defined and researched product requirements documents.
The ERP-as-a-LIMS concept fits the capabilities of 1970s and early 1980s LIMS systems, as well as many of the low-cost modern offerings. However, several issues need to be evaluated, and some are diagrammed in Figure 3-13.
|
The first is how sample information is entered into the system (i.e., descriptive information about samples; in LIS it has to be coordinated with patient information records, which may be referred to as sample meta-data). If it is a manual entry done directly in the lab or via remote access, one sample at a time, either ERP or traditional LIMS will suffice. A problem could occur with ERP systems if support was needed for stability or formulations testing, or other specialized analysis sets. LIMS can handle these, ERP systems may have them or they would have to be developed.
Handling the results of an analysis is another issue. Entering test information is not always as simple as doing the test, and entering the result; there are variations in the process that depend on how the lab operates and how tests/assays are performed:
These are tasks that LIMS are designed to do as a result of decades of experience. ERP-LIMS will require programming to accomplish the same work or use an intermediary package such as a LES or ELN.
Another area of concern is the interactions between the LIMS / EPR-LIMS and other informatics products/functions such as SDMS, ELN, LES, and laboratory inventory management. LIMS vendors, particularly those that provide one or more of these products, provide interfaces for most of these functions.
In order to make an ERP-LIMS work, some software development is going to have to be done, even if it is just a matter of bringing components together with a workable user interface on a manual transaction processing level. As we move toward more sophisticated laboratory operations, the extent of the work required increases substantially. This raises a simple question: is the group that is going to take on the work up to the task? This isn’t a challenge to competency; it would be the same question if the work was done by LAB-IT professionals. The issue comes from the demands on IT organizations by corporations looking for support. We are talking about building and supporting a sophisticated applications system that will require development/upgrade trouble-shooting support for the life of the product. Will competition for resources by other parts of the company push the development of the application further and further behind schedule? This is a consideration that needs to be addressed before the project begins. There have been suggestions that ELN, LES, and other third-party products could be used to solve the instrument connection problem[15], and that would work, but at the expense of adding the additional products. If they were already being considered for purchase, it is a moot point.
There are two additional items to note:
On the topic of LIS-ERP, Dennis Winsten of of Dennis Winsten & Associates, Inc. brings up an interesting point: using a common underlying software structure would improve information integration across the enterprise, and it would.[16] However, we do have to be careful that using that common software basis, and giving easier programming access to laboratory data, doesn’t subvert the data review and approval process that is part of service laboratory work.
The availability of an ERP-based LIMS does provide another avenue for obtaining the systems support service laboratories need. Information integration can be solved by common underlying products and by effective information interchange. Evaluating the ERP-base LIMS option, as well as evaluating traditional LIMS, has to be based upon objectively developed product requirements, and those should include short- and long-term needs as well as support requirements.
(Note: When this piece was first written in 2014, SaaS was beginning to make serious inroads into laboratory computing. At that point, there were concerns about the viability of the infrastructure which has since been put to rest. Today in 2024, SaaS definitely has an established role in laboratory informatics. However, the issues of climate change and security have become a reality. The technology works, but planning for failures in some geographical regions subject to severe weather is needed.)
In September of 2013, David Pogue[17][18] wrote an article about a shift in the funding model for some well-known software packages. Both Microsoft and Adobe have adopted a subscription-based funding model resulting in your renting software (Adobe’s Creative Cloud, and Microsoft Office) instead of paying a one-time license fee (one time for that version, upgrades may be an additional charge). While the monthly fee isn’t significant compared to the cost of licenses for add-on software, the fees aren’t fixed, and over time can become an issue. There are some additional points. First, the consumer can become a live beta-tester for software without being aware of it as vendors update products at will instead of monthly or annually. Secondly, if you stop the subscriptions, you can lose access to the files you developed with those applications; the files will still be there, but you won’t be able to work with them.
The reasons behind this change in policy are about revenue streams. When desktop computing was developing and sales of systems were moving at a rapid pace, there was a substantial income stream from new users and those eager to keep software up-to-date because of new features. The downturn in the economy, a drop in people upgrading systems software, and a shift from desktop to tablet computing have moved vendors to look for new ways of supporting software development. The same issues are affecting vendors of laboratory informatics systems, who also see customers reluctant to pay the up-front cost of hardware and software, and long-term IT support costs. If they could lower the cost of access to the software, eliminate the costs of hardware and installation, and relieve the stress on IT support, more labs would take advantage of what they had to offer. SaaS could provide a workable solution.[19]
The basic software offering is the same as an on-site offering. There is no hardware cost for hosting the LIMS, no installation cost since the vendor is hosting the software on their remote system, no upgrade fees or effort, and as long as we are focusing on LIMS transactions alone, no IT support requirements. The time frame from the start to the working system depends upon the work involved in initializing the system (e.g., entering tests, samples, user information) and educating people on the products use. You have access to a fully functional LIMS, at least as far as lab operations and workflow are concerned. From the standpoint of the models we’ve been using, the situation looks like this:
|
This figure is very similar to Figure 3-5 except that the LIMS function is off-site, on a remote server, somewhere. That off-site detail makes a big difference in how the system might perform.
There are some differences between LIMS via SaaS and a LIMS hosted on your site. Of note is that there may be limitations on the modifications that you can make to the software; we’ll contrast two implementations: private structures (private cloud over the internet) and multitenant. With a private structure, you are working with your own copy of the software package, the same situation as if you installed it on-site. You should be able to make whatever changes you want, within the guidelines the vendor provides; since the vendor is going to be making updates and upgrades as needed, changes made outside the guidelines may be in jeopardy (just as it would if the software were on your site, in cloud-based systems you don’t have a choice about updates/upgrades). In multitenant structures you are sharing the underlying software with other groups, each is isolated from the other so that they can’t view your data. It is similar to the difference between single-family housing and apartments. In the former, it is your house and you can do what you like (within building codes). In the latter, you can customize your apartment as long as you don’t compromise shared elements (utilities, structure, etc.). The purpose of building codes is to protect the infrastructure and ensure that construction is done according to current standards; vendor programming guidelines are there to ensure that you don’t compromise the integrity of the system and that the changes survive updates/upgrades. That difference will become important if you want to connect instruments or other software packages.
Another difference is a result of the remote location of the servers hosting the software. To be more specific, it is the nature of the connection between your lab and the remote server: via the internet. The internet is big, with lots of users, lots of transactions successfully completed per minute, all of which become a bunch of statistics when the transaction you are trying to carry out fails. Interestingly as this is being written and researched, a site was accessed that contained information about the predicted growth of the internet (bullets below) and had an interesting link. When the link was clicked, the following came up:
|
Clicking the browsers back arrow to get to the original page, gave the same result. When we encounter problems like that, we can take corrective action; automated systems have to be programmed with the proper course of actions. The data the original site was reporting in 2010 included[20]:
- Between now and 2020, the amount of digital information created and replicated in the world will grow to an almost inconceivable 35 trillion gigabytes as all major forms of media–voice, TV, radio, print–will complete the journey from analog to digital.
- Last year despite the global recession, the Digital Universe, set a record. It grew by 62% to nearly 800,000 petabytes. A petabytes is a million gigabytes. Picture a stack of DVDs reaching from the earth to the moon and back.
- This explosive growth means that by 2020, our Digital Universe will be 44 times as big as it was in 2009. Our stack of DVD’s would now reach halfway to Mars.
- Most of the digital universe begins with an action by a consumer–an email typed on a laptop, a digital photo taken at a wedding, a movie downloaded from Netflix. In fact more than 70% of the Digital Universe this year will be generated by users–individuals at home, work, and on the go.
- The social media invasion has just begun. IDC estimates that by 2020, business transactions on the internet, B2B and B2C, will reach 450 billion a day.
All of that is competing with your work.
The key issue is that the internet, for all it offers, is not completely reliable (the error rate is very low, but there) and how that affects you is what you have to evaluate before taking advantage of SaaS informatics, and to what extent you use it. If the connections in Figure 3-12 were severed even briefly, how would it impact your work? Can you build in backup / fail-over procedures to overcome that event? Potential problems with network access are not uniformly distributed over all users; much of it is a function of geography and climate (where you are, where your hosting service is, and whatever is in between). The causes of internet service issues include:
If you are considering SaaS as a service offering, consider all the factors involved, it isn’t just the informatics technology alone, but the ability to use it consistently in a real-world environment and planning for problems. Given all that, there are effective uses for SaaS implementations:
|
We discussed middleware earlier in the context of managing instruments and informatics systems with differing communications protocols. Middleware software can serve an additional purpose in the SaaS communications environment. Note that on both sides of the dotted line we’ve added a representation of a storage structure with the words “Journaling, Store & Forward.” Journaling is a function of storage systems that records all transactions so that a system administrator can see what activities have been going on. That can also be used to keep track of communications and if a transaction were attempted and failed, that would be recorded. In the event of a failure, “Store & Forward” functions keep track of information that should have been sent (store) and send it in the proper order when the communications link is restored (forward). Those functions are on both sides of the system so that communications in both directions can be successfully resolved and updated. If you are considering this technology, planning needs to be done in the event of short- and long-term outages so that the impact on the lab’s operations is minimized.
Another issue that needs to be understood is that of security. By placing laboratory data on an internet-accessible system, it is vulnerable to hacking, but then so is your corporate system unless it is disconnected from outside networks. When asked, vendors will stress the level of security service that they provide and may make the statement that their security is at least as good as that of your corporate systems. You’ll have to decide how comforting that is. Intellectual property is a valued resource, and you, and your company, will have to determine how much risk is appropriate. Your IT staff may be able to help you evaluate the technical side of the issue. The legal department will evaluate the risk to intellectual property.
There is at least one more role a SaaS LIMS can play, and security is part of it. If your company makes extensive use of outsourcing work for testing, a SaaS LIMS can be used as an intermediary for you and the outsourcing company(s) to exchange information without giving them access to your internal systems. Test requests, results, work status, etc. can be managed using an external LIMS with data integrated into your in-house system under your control.
Several legal issues come into play when you consider SaaS on cloud-based storage systems. On the surface some appear obvious, such as who owns the data, can you get copies of the datasets if you terminate the contracts, what are the service provider’s responsibilities in the event of equipment failures or acts of nature? There are also considerations about the service provider’s role if a subpoena is files against your company or another company storing data on the same server. A full discussion of these points is beyond the scope of this book, and for that matter the author; as a starting point consider the works of Gray[22], Wagreich[23], Van Eecke[24], and Hogan Lovells[25], and do a search using your favorite search engine. This doesn’t diminish the capabilities of the technology, but it might impact your ability to use it.
As you might expect, this is a complex issue and there are additional details that have to be considered. A series of articles from R.D. McDowall[26][27][28][29] discusses the good manufacturing practice (GMP) implications of SaaS and cloud systems.
There are vendors who are providing software that can be used in a variety of scenarios including in-lab, shared on-premises, and cloud-based deployments.
The ability to have access to laboratory information wherever you are in the lab is attractive. A tablet, for example, can be used to enter information into a LIMS, look up the details of sample requests or search for method references without having to go back to a desktop or laptop system. In a 2011 presentation by Meier[30] the use of an iPhone and tablet (Motion Computing Associates C5/F5) were discussed and found:
In-Vivo pharmacology’s Sleep EEG lab made extensive use of the F5 and F5v (tablet models), used for:
The study also found the camera attachment to be useful, avoiding the need for paper printouts, scanners, etc. for imaging. Although the work was focused on an ELN, similar results could be expected with a LIMS / LIS or LES system. Despite these successes, there are issues abput mobile devices that need to be addressed:
The primary function of a LIMS/LIS is sample tracking and assisting lab personnel with the day to day workflow management in laboratories whose principal activities are to test samples according to a fixed or slowly changing set of procedures. These labs work as a service supporting other organizational operations and include quality control, clinical chemistry, pathology, analytical chemistry, product stability, formulations, etc. They may also be part of research labs, providing routine testing in support of research work. The primary focus is the sample, and information is organized by sample, or by patient-sample in healthcare. This differs from ELNs, which are organized by project or experiment.
While the basic focus of the products are consistent and built around sample tracking and supporting services, the technology is expanding due to competitive pressures among vendors and a desire on the part of vendors to provide an integrated set of services. Where “laboratory information management system” / “laboratory information system” was an overstatement of product capabilities in the early days of its development, current products are beginning to fill that description by incorporating document management, procedure execution, personnel management, and other functions. The technology has limitations when handling large files (e.g., images, chromatograms, spectra, etc.) but that is changing.
There are over a hundred products within this technology set. Implementations include onsite systems, cloud (SaaS) product offerings, and development based around EPR systems. While the product technology has been in development since the 1970s, there is still a lot of room for innovation. LIMS / LIS often have a rapid payback in terms of avoiding the need to increase head-count, providing better and faster services to the groups they support, better management of intellectual property, and increased efficiency of laboratory operations.
The key element needed in approaching a LIMS / LIS project is a well-researched and thought-through product requirements document. If this is the first LIMS system in a lab, the process should include a thorough evaluation of laboratory operations, with the intent of identifying and addressing deficiencies in lab operations and processes. A LIMS can improve the operations of well-managed laboratory, or amplify the problems of a poorly organized facility.
Initially educated as a chemist, author Joe Liscouski (joe dot liscouski at gmail dot com) is an experienced laboratory automation/computing professional with over forty years of experience in the field, including the design and development of automation systems (both custom and commercial systems), LIMS, robotics and data interchange standards. He also consults on the use of computing in laboratory work. He has held symposia on validation and presented technical material and short courses on laboratory automation and computing in the U.S., Europe, and Japan. He has worked/consulted in pharmaceutical, biotech, polymer, medical, and government laboratories. His current work centers on working with companies to establish planning programs for lab systems, developing effective support groups, and helping people with the application of automation and information technologies in research and quality control environments.
LIMS forum content by LIMS forum members is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work at www.limsforum.com.
