The Confusion Around COTS

In the software market for the biopharmaceutical industry these days, it seems that commercial off-the-shelf (COTS) applications are inescapable. Suddenly, everything is COTS. However, rapid proliferation of the term has far exceeded its actual availability. The terminology may have changed, but in most cases, the reality of system deployments has not. If a vendor claims to provide a COTS solution, what should a buyer expect? Better still, what should a buyer demand?

Richard Wagner

THE HISTORY OF LIMS AFFECTS US TODAY

To understand the current overuse, and in some cases blatant misuse, of the term COTS, a short recap of the laboratory information management system (LIMS) industry is in order. LIMS themselves did not originate in the pharmaceutical industry; they can trace their heritage to environmental laboratories. However, in serving one laboratory environment, vendors quickly realized that there were many similarities between laboratories in different industries, and aggressively marketed their systems to other sectors of business. To make the adoption of their solutions tenable in other industries, LIMS vendors worked to design highly adaptable systems, which was a logical approach. Customers were provided with a basic environment and database, and a set of tools with which to extend the system.

Building on Basic LIMS Platforms

At the time, most laboratories were completely paper-based, and their information management choices were restricted to two options: build something internally, or build something on top of a commercial LIMS platform. In many cases, the existing LIMS platform provided a good starting point, and could save the laboratory time and money compared with a completely customized solution.

In many cases, however, limitations imposed by a basic LIMS platform could actually prove to be complex or insurmountable barriers to a successful deployment, and custom solutions were not uncommon. The pharmaceutical industry saw many custom solutions developed due to the intense regulatory scrutiny and complex testing requirements of their day-to-day business.

The Trend Away from Internal Development

Commercial LIMS platforms continued to improve, however, and over the past 5–10 years it has become very uncommon for pharma companies to develop solutions internally, despite the fact that many significant gaps remain between the commercial, generic LIMS platforms and their specific business needs.

In the past decade, pharmaceutical companies have increasingly recognized that software development is not their core competency. Executive management encouraged their IT teams to seek commercial solutions to fulfill their needs as much as possible, and actively discouraged internal development.

Quick Recap

Customization and Configuration

LIMS vendors responded to this trend by claiming that their solutions no longer required "customization," but rather could now be "configured." This wordplay was, in many cases, nothing more than marketing. Pharma companies responded, knowing that customizing a LIMS system to suit their needs could represent greater effort than simply building one themselves, and hoping that this new "configurability" would reduce their deployment and maintenance burdens.

At this point, it is important to provide a clear definition of the difference between configuration and customization:

• Configuration: A configuration option should require no programmatic code at all, and be completely tested by the vendor before software release. Ideally, configuration should be done through the user interface, although in some instances, configuration files may be used, provided that appropriate testing has been completed.

• Customization: Customization is any form of programmatic code, including any and all varieties of SQL+Plus and Scripting.

Some systems made progress in offering greater levels of configurability. Unfortunately, however, in many cases vendors' claims of configurability were in fact based on customization. Wrapping a graphic user interface (GUI) window around a script does not change the fact that the script represents a customization. If it was not part of the original system, the component has not been tested, and the validation burden rests completely on the customer.

The purpose of this discussion is to provide a context in which we can examine the current trend of claiming that systems are COTS. This trend began in the past 1–2 years, as the Food and Drug Administration began using the term in presentations. The term COTS has been used in other industries for many years, particularly in engineering fields. It has been applied to software and hardware components. In our context, it is being applied to software systems, particularly LIMS. LIMS vendors are sometimes painfully aware of the impact of customization on system validation, deployment, and maintenance. The message vendors try to convey is that all that pain is a thing of the past. In some cases, vendors made significant progress; in other cases, the product has barely changed at all, despite marketing claims.

WHAT TO LOOK FOR IN COTS

So, what should a customer be looking for in a COTS solution?

The first step is to approach the term realistically. No solution will meet 100% of a company's needs out of the box. However, it should not be unreasonable to set a lower target of 75%, and optimistically look for greater than 80% success in meeting your functional requirements. The challenge is to evaluate whether the requirements presented in a demonstration are in fact included in the basic software system. Most LIMS vendors have demonstrated their systems for years, and are prepared to show what their systems are capable of doing. This will frequently include custom functionality that is not delivered as part of the core product, and is not documented or supported. Critical evaluation of the true out-of-the-box capabilities of a system must discriminate between what a system is "capable" of and what it truly delivers.

CHALLENGES FOR LIMS

In the pharmaceutical industry, there are several areas that have represented challenges for LIMS systems in the past that are excellent indicators of the scope and true capabilities of the basic product:

Product & Batch Management

Most LIMS systems are sample oriented. In order to accurately connect samples to a product of interest, many fields are typically added to the sample tables in the database to include information like potency, product identification, and formulation type. For a pharmaceutical LIMS system to be truly useful out of the box it should manage drug products and drug substances independently, then simply relate the samples to those products. The same is true of manufacturing batches; these should be independent entities, with their own set of properties, and are related to samples that represent those batches.

Microbial Load Testing

A common test required in biotech and pharmaceutical manufacturing is microbial load testing. This test is used extensively for both in-process and final quality control testing. At first glance, it may seem simple: Collect a sample, inoculate a growth medium in a plate or tube, and observe the number of colonies that form. To really support the testing, however, the software also must record the associated data that validates the test result.

Suitable software must make it simple for the end user to record that associated data as well as the end result. Questions to ask include:

• Can the user easily link related data (e.g., media lot, control plate results, diluent lot) in the system to the results without duplicate entry?

• Can the results be linked not only to the sample, but also to the manufacturing stage to which they apply?

• Are actionable results automatically communicated to the batch manager?

• Can one test method be used for in-process, release, and environmental monitoring testing?

Stability Testing

Most LIMS vendors targeting the pharmaceutical industry offer some kind of stability testing functionality. However, this functionality sometimes is too rigid to adapt to the reality of stability testing, particularly during research and development. Special considerations include:

• Can stability studies be altered easily to include additional timepoints or conditions?

• Can stability studies easily reference release data as time zero results?

• Can inventory material be easily tracked and managed?

• Can multiple packages be evaluated simultaneously, in multiple orientations?

System Extensibility

As previously mentioned, no system will be able to satisfy 100% of a customer's needs. With that in mind, it is important that the vendor provide capabilities to configure and, if necessary, customize the solution. Questions to ask include:

• What configuration abilities exist?

• What are the approval lifecycles, including

• Status cascades

• Security options

• Are there tools to extend the system without programmatic code?

• How can new properties and new entities added?

• What is required to design new GUI screens?

• Does the system employ an industry-standard programming environment that can be used when customization is necessary? Proprietary programming languages present significant challenges in terms of resource management.

CONCLUSION

Laboratory information management systems have clearly progressed significantly since their inception. However, much of their evolution has been realized through the capabilities they offer users for customization. While many vendors now include the term COTS in their marketing materials, that claim is not always substantiated.

The prudent pharmaceutical LIMS buyer should require clear evidence that truly applicable business functionality is offered out of the box, to avoid the need for extensive customization. There are specific areas that should be examined to determine how capable a system is. Buyers can review not only software demonstrations, but also available supporting documentation and support offerings. This will help to differentiate what a LIMS is "capable" of, and what it truly delivers off-the-shelf.

Richard Wagner is a product manager for informatics at Thermo Electron Corporation, 1601 Cherry St., Suite 1200, Philadelphia, PA 19102, 215.964.6020, marketing.informatics@thermo.com