In software for the pharmaceutical industry, these days it seems like “COTS” (Commercial Off-The-Shelf) is inescapable. Suddenly, everything is COTS. However, the 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.

In order to understand the current overuse, and in some cases blatant misuse, of the term “COTS,” a short recap of the 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 industries. 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.

At the time, most laboratories were completely paper-based, and their choices were restricted to two options: build something completely internally, or build something on top of a commercial LIMS platform. In many cases, the LIMS platform provided a good starting point and could save the laboratory time and money compared to a completely custom solution. However, in many cases, the limitations imposed by the 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 in particular saw many custom solutions developed due to the intense regulatory scrutiny and complex testing requirements of their day-to-day business. Commercial LIMS platforms continued to improve, however, and over the past 5-10 years it has become very uncommon for even pharma companies to develop solutions internally, despite the fact that there remain many significant gaps 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 has encouraged their IT teams to seek commercial solutions to their needs as much as possible, and has actively discouraged internal development. 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 meet their needs could often 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 some 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 cases 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, Scripting, etc.

Some systems did make progress in offering greater levels of configurability. Unfortunately, in many cases vendors claims of configurability were in fact based on customization. Wrapping a GUI window around a script does not change the fact that the script represents a customization. If it didn’t come with the system, it was not tested and the validation burden rests completely on the customer.

The purpose of this lengthy digression was 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 FDA began using the term in presentations. The term has been in use in other industries for many years, particularly in engineering fields. It has been applied to software components and to hardware components. In our context, it is being applied to software systems, particularly LIMS. LIMS vendors are aware, sometimes painfully so, of the impact of customization on system validation, deployment, and maintenance. The message they try to convey is that all that pain is a thing of the past. In some cases, vendors have made significant progress; in other cases, the product has barely changed at all, despite the marketing claims.

So, the question is, 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 (OOTB). However, it should not be unreasonable to set a lower target of 75%, and optimistically look for greater than 80% of your functional requirements. The challenge is to evaluate whether the requirements that are presented in a demonstration are in fact included in the basic software system. Most of the LIMS vendors have been demonstrating 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 OOTB capabilities of a system must discriminate between what a system is “capable” of and what it truly delivers.

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 and 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, formulation type, and more. For a pharmaceutical LIMS system to be truly useful OOTB, 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 be related to samples that represent those batches.

Dissolution (USP 711) and drug release (USP 724)

There are several common tests in the USP and other national pharmacopeias that require multiple stages and logic for evaluating the results of the testing but dissolution is one of the most common, and most commonly lamented.

• Can the software easily handle multiple analytes and multiple timepoints when designing dissolution test methods and processing dissolution data?
• Does the software understand Q values and how to handle them?
• Does the software provide the flexibility to deviate from the USP guidelines where required?
• Are additional testing stages automatically created based on the collected results?

Stability testing

Most LIMS vendors that target the pharmaceutical industry have some kind of stability functionality available. However, it can sometimes be too rigid to adapt to the reality of stability testing, particularly during R&D. 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 simultaneously evaluated, 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.

• What configuration abilities exist?
  • Approval lifecycles?
  • Status cascades?
  • Security options?
• Are there tools to extend the system without programmatic code?
  • Adding new properties and new entities?
  • Designing new GUI screens?
• Does the system employ an industry standard programming environment 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 in the capabilities they offer 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 there is truly applicable business functionality offered OOTB to avoid the need for extensive customization. There are specific areas that can be examined to determine how capable a system is by reviewing not only software demonstrations, but also available supporting documentation and support offerings to differentiate between what a LIMS is “capable” of, and what it truly delivers off-the-shelf.