SubscribeThese days, in the pharmaceutical industry it seems like 'COTS' (Commercial Off-The-Shelf) is inescapable, especially when it comes to software. Suddenly, everything is COTS.
However, the rapid proliferation of the term has far exceeded the actual availability of COTS solutions. The terminology may have changed, but in most cases the reality of off-the-shelf 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.
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 the benefits of their systems to other industries.
To make the adoption of their solutions tenable in multiple 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 data management choices were restricted to two options: build software 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 home-grown 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 home-grown 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 rare for companies, even pharmaceutical ones, to develop solutions internally. Yet there remain many significant gaps between the commercial, generic LIMS platforms and a customer's 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.
According to Karl Yorgey, who brought Watson LIMS from Thermo into the Bioanalytical labs at Johnson & Johnson, "J&J has taken a position that if we can buy an off-the-shelf solution, we will." Watson pioneered the development of off-the-shelf functionality in a LIMS, and is now the most-installed solution for Bioanalytical labs in the industry.
Many LIMS vendors have responded to this off-the-shelf 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. Still, pharma companies responded, knowing that customizing a commercial LIMS system to meet their needs could often represent greater effort than 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 what the difference is 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, however, 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, with COTS, 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, either off the shelf or out of the box (OOTB) another term gaining popularity. However, it should not be unreasonable to set a lower target of 75% and, optimistically, look for greater than 80% of your functional requirements to be met by the base system. 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. It is built upon implementation, at additional cost and time, as well as risk.
Critical evaluation of the true OOTB capabilities of a system must discriminate between what a system is 'capable of and what it truly delivers. For example, Thermo's Darwin LIMS delivers as standard the ability to conduct stability studies, dissolution testing, content uniformity testing and batch and product management functionality typically only offered as add-on modules or customizations to a generic LIMS.
In the pharmaceutical industry, there are several areas which have represented challenges for LIMS systems in the past that are excellent indicators of the scope and true capabilities of the basic product:
1. 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, 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.
2. 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?
Figure 1: A simple multipoint, multiple analyte test definition dialog.
3. 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?
4. 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 out-of-the-box 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.
About the author:
Richard Wagner has been developing purpose-built pharmaceutical software since 1999 when he joined InnaPhase Corporation, which was acquired by Thermo in 2004. Previously, he worked for 10 years in contract research. He is behind the creation of Thermo's latest LIMS for pharmaceutical manufacturing R&D and QA/QC Darwin LIMS. To see a brief presentation on Darwin by Mr. Wagner, please visit www.brainshark.com/thermo/darwinkeynote.