Determining LIMS Functionality, Cost, and ROI: System Architecture Strengths and Limitations

Many organizations consider their laboratory information management system (LIMS) to be a mission-critical component of their overall corporate information system (IS)—whether the company is in a regulated industry, such as drug development or pharmaceutical manufacturing, or in a nonregulated industry, such as petrochemicals. LIMS provides the integral connections to these companies' laboratory data, instruments, analysis, and reports.

Photo: AUTHOR

Today, LIMS is in the fourth generation of its evolution, and many organizations must upgrade, supplement, or modify their LIMS to ensure optimum interoperability with the overall corporate IS infrastructure. To ensure successful management of the LIMS implementation and maintenance, selecting the best LIMS architecture for an organization is more critical than ever. It is a task that becomes even more complicated because many of the terms used to describe very different LIMS and system architectures that are used interchangeably. This article provides clarification of the terms as well as the capabilities of potential solutions.

From first-generation LIMS to web functionality

LIMS connects the analytical instruments in the laboratory to one or more workstations or personal computers (PCs). Analytical instruments, such as chromatographs, collect sample data, which is then forwarded to a PC, or further to a server, where the data are organized into meaningful information. This information is then stored to be mined by the laboratory and other departments, or it can be sorted and organized into various report formats based upon the type of report required. A full-featured LIMS will manage the various laboratory data collected from sample login to reporting the results and will address the needs of research and development (R&D) departments all the way through to quality management laboratories.

The first commercial LIMS was introduced and developed in the 1980s by analytical instrument manufacturers. This first generation LIMS placed laboratory functions onto a single centralized computer, which offered greater laboratory productivity and functionality as well as the first automated reporting capabilities. These systems were quickly followed by second generation LIMS, which used third-party commercial relational databases (RDB) to provide application-specific solutions. Most relied on minicomputers such as Digital VAX, but PC-based solutions emerged soon afterwards.

The increase in computer-processing speed, the enhancements in third-party software capabilities, and, the reduction in PC, workstation, and minicomputer costs paralleled the introduction of the commercial LIMS. These advantages drove a migration away from proprietary commercial systems toward open systems that emphasized user-configurability, rather than customization by the vendor. By the time the third generation technology was introduced in the 1990s, LIMS combined the PC's easy-to-use interface and standardized desktop tools with the power and security of minicomputer servers in a client–server configuration. That is, its architecture splits the data processing between a series of clients and a database server that runs all, or part of, the relational database management system. In the mid-1990s, the fourth generation LIMS decentralized the client–server architecture further, thereby optimizing resource sharing and network throughput by enabling processing to be performed anywhere on the network. When the Internet took off in 1996, the first web-enabled LIMS was soon introduced, followed by web-based and thin-client solutions.

Most of these thin-client solutions were developed in Java, and web-based systems on Microsoft's .NET platform. Some of these web-based systems leverage eXtensible Markup Language (XML), to transmit data between traditional client/server architectures and the .NET framework to offer a web-based application.

Thick-client, web-enabled, web-based, and thin-client LIMS

Understanding the differences between thick-client, web-enabled, web-based, and thin-client LIMS is challenging because the terms are often used interchangeably, adding to the confusion and making it difficult to develop a well-informed decision when it comes to choosing the "right" LIMS. These terms actually apply to very different types of platforms. And using them interchangeably can prove costly when organizations find out that their new software does not deploy or function as expected.

Thick-client is used to describe an application designed to run in a client–server environment, meaning that a portion of the software resides on the server, and the other portion resides on the user's workstation. "Clients" are essentially the PCs or workstations. Also known as a fat client, it is a client that performs the bulk of any data-processing operation and relies on its associated server primarily for data storage. A thick-client has the LIMS installed on the PC's hard drive. The thick-client connects to the database server, but the processing is done on the client side (See Figure 1). Each change to the configuration or the application must take place at the client level; that is, the modifications must be propagated to each individual workstation. To provide the interconnectivity of each of the end-user locations, thick-client LIMS rely on cross platform programs such as Citrix.

Figure 1

Web-enabled is used to describe the add-on web browser component of an application designed to run in a client/server environment. The web-enabled portion of the application may allow access to data from a web browser, but the user is limited to the product functionality that is available on the web portion of the system (see Figure 2). To access and exploit the full functionality of the application, users must have the local client installed on their desktops. To provide the interconnectivity of each of these end-user locations, the web-enabled LIMS must also rely on cross-platform programs such as Citrix. Similarly, modifications must be propagated to each thick-client.

Figure 2

Thin-client or web-based applications offer end-users full application functionality from a browser. A thin-client does not have significant hard drive or memory requirements, as it does not store or process data. The LIMS resides on the application server(s) while the thin-client simply presents the screen display and allows users to interact with the application server via a keyboard and a mouse. Configuration changes or customizations made on the server to the software are immediately universally available to all end-users. There is no need to propagate the changes to the end-user client or leverage regional servers with cross-platform programs.

A laboratory information management systems comparison

The distinction between web-based and thin-client solutions is the amount of software residing on the client. A true thin-client LIMS is an application written specifically to run on the web, with zero-footprint on the end-user client. It only requires a browser or "dumb" client terminal to run the application residing on the server. No downloads, applets, or other programs exist on the end-user client, other than the browser (see Figure 3).

Figure 3

Web-based LIMS built on Microsoft's .NET framework typically transmit data between the .NET framework and traditional client/server architectures to offer a web-based application. In such systems, the thick-client is somewhat hidden because it runs in a browser. However, there is more running on the client than just the browser. A .NET application that runs on the .NET framework installed on the end-user client is required to render the browser pages from the thick-client server. In essence, the browser is not showing HTML, but instead, is showing a thick-client-server-like application. In addition, these applications also rely on the local client for computer processing, and therefore require a rich, rather than, dumb end-user client (see Figure 4).

Figure 4

Trade-offs. Integrating a LIMS into the overall IS should take into consideration the company's current infrastructure, long-term plans for the IS, and investment in hardware and human resources to manage the IS. This decision, in turn, affects the cost of clients and servers, third-party software needed to connect these LIMS clients, and the resources needed to deploy and upgrade the LIMS. Furthermore, it affects the robustness and security of the application as a whole as well as the flexibility of the system to later modification. Depending on the answer and the trade-offs to be made, the organization may decide to use either a thin-client, web-based, web-enabled, or a thick-client solution.

Network bandwidth. Thick-clients and web-enabled solutions typically require less network bandwidth. Because thick-clients themselves do much of the application processing, they do not require an application server for processing. However, it is important to remember that the database will likely reside at the server level, so communication to and from each thick-client is still required. Additionally, regional hardware and software is required to operate the cross-platform programs such as Citrix that enable such networked communication. Web-enabled and some web-based systems offer a hybrid to this approach, depending on where the functionality resides (i.e., on the client or on the server).

Redundancy. Thick-clients provide some level of redundancy. In a simple LIMS solution that uses a single thick-client, if the server–network goes down, the client can still collect sample data and hold it on the PC's hard drive until recovered data can be forwarded to the appropriate server. In a thin-client application, redundancy is achieved through clustered application servers that provide load balancing and fail-over, a process that routes client requests to servers within the cluster. If one or more servers fail, client requests are automatically routed to other servers within the cluster so there is no break in service.

Performance. Thick-clients tend to have advantages in multimedia-rich applications that would use up a lot of bandwith if fully served. For example, thick-clients are well suited for chemical drawing and molecular modeling programs, which require a significant amount of computing power. With that said, new technologies such as AJAX (Asynchronous JavaScript and XML), are offering more dynamic user experiences than previously available over the web. Moreover, thin-client LIMS can be easily scaled by adding servers to the cluster.

Access. With a thin-client LIMS solution, users can access the LIMS from virtually any Internet-ready device. All of the laboratory's applications and data are maintained centrally, thus allowing any number of people to share them in a secure way by simply plugging in a thin-client browser. Thin-clients also enable connectivity by critical users external to the laboratory such as executives, customers, and partners. Moreover, thin-client solutions can leverage a "dumb" client or portable device, as opposed to some web-based systems that require a client to leverage the .NET framework to communicate with the server. Thick-client systems pose the most difficulty in enabling enterprise access. Such systems must be installed at each end-user client, and they have no remote access capabilities. Web-enabled systems offer some remote access, but only to the specific, limited functionality available via the browser.

Security. With thin-clients, all the applications and data are maintained on a central server. For leading thin-client LIMS, access is role-based and password-protected for security, complying with 21 CFR Part 11. Disabling a login account disables access to all company information. No application data ever resides on the client, hence files cannot be transferred to local hard drives and memory sticks.

Ease of use. A thin-client browser interface has the familiar web-site look and feel. Thus its use is intuitive, which keeps initial and ongoing training costs low. Because end-users are more comfortable with the interface and adoption is easier, the LIMS can be integrated with the organization's workflows more quickly. This enables organizations to leverage their investment and reap the benefits of enhanced productivity sooner.

Hardware, software, and IT costs. Thin-client solutions reduce the cost per user and IT manpower requirements while delivering a solution that is easily upgradeable and expandable (without interrupting business). Software updates are done once from a central server and are immediately available to all; desktop upgrades are not required. A thin-client LIMS enables an information technology (IT) team to deploy, maintain, and support only one central LIMS, thereby increasing return on investment. Thick-client and web-enabled systems require the IT team to upgrade all end-user thick-clients around the world, along with each of the regional servers and cross-platform programs residing on them. Although some web-based systems achieve some of the benefits of thin-client systems, there are added costs to maintain the .NET framework on each end-user client, especially on portable devices. Moreover, such .NET systems are tied to Microsoft's proprietary browsers and application servers.

Thin-client hardware is generally less expensive than thick-clients because they do not require as much local disk space, application memory, or powerful processors. The total hardware requirement for a thin-client system (including both servers and clients) is usually much lower as well. One reason for this is that the hardware is used more efficiently. A thick-client central processing unit is idle most of the time. With thin-clients, memory can be shared. If a LIMS application is being used by several users, it needs to be loaded into the random access memory only once on a central application server. With thick-clients, each workstation must have its own copy of the LIMS in memory. Ultimately, the real value of thin-client computing emerges through determinations of the "total cost of ownership," which includes not only the upfront price of the hardware and software, but also the much larger cost of installing, supporting, and updating the system over time.

Selecting the right solution

While the advantages of a thin-client strategy appear to be greater than that of a thick-client, that may not be the case for every organization in every instance. IT professionals must consider a number of variables pertinent to their particular organization. For example, consider a LIMS at a contract research organization that would like to provide secure Internet access for data entry, analysis, and reporting to external customers. It would be challenging to provide this capability with thick-client LIMS. Also, users should be aware that just because the application runs on a browser, it doesn't mean it is thin-client. Firms should also consider whether their external customers are running Internet Explorer with .NET, so they can support access to the firm's .NET LIMS. Do they allow .NET applications to be downloaded to their end-user clients?

Another consideration for firms to determine is whether the technology behind the LIMS is associated with a single vendor and whether that raises concerns with the firm's own IT organization. For instance, a firm might ask whether its IT organization wants to limit itself to technology proprietary to Microsoft? This means that the LIMS most likely can only use Microsoft browsers and Microsoft back-end web and application servers. In this case, an existing Linux or Unix environment would not be able to run the .NET LIMS, thus complicating assessment of the actual cost for using such a solution since it may preclude use of existing technology.

It may also be important to consider whether remote handheld devices are critical to the laboratory. If so, see whether the thick-client LIMS can run on a portable device and assess whether the necessary .NET support browser is available for PDAs and other handheld devices used in the laboratory. This can be a significant issue to organizations that conduct R&D in the field or perform activities such as environmental monitoring on the plant floor.

Summary

There are significant differences between thick-client, web-enabled, web-based, and thin-client solutions. Thick-clients are desktop client applications that connect to a remote database. Web-enabled solutions are more oriented toward thick or rich clients, and web-based solutions offer some of the benefits of thin-client applications. Thin-clients, on the other hand, are true HTML applications that do not require additional end-user client downloads, applets, or frameworks. Just be sure a firm knows what it's getting by being aware of the differences, advantages, and disadvantages of each type of solution in relation to its existing or planned infrastructure. Many organizations are choosing thin-client solutions and paving the way toward a simplified infrastructure that delivers lower cost of ownership, better usability, and less complexity. Above all, firms need to make sure the laboratory information management system it selects is the best fit for the organization.

Ron Kasner serves as the vice-president of corporate development for LabVantage Solutions, where he is responsible for directing LabVantage's long-term product strategies, global marketing initiatives, and business development opportunities. LabVantage Solutions, Inc., 1160 US Highway 22 East, Bridgewater, NJ 08807, tel. 908.333.0103, fax 908-842-0338, rkasner@labvantage.com.