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

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?