PHARMA IT: LIMS
Commercial Packages Close the Functionality Gap
Recently, there has been a lot of interest in COTS. This is not a reference to the overwhelming desire to have a nap after lunch. This new buzzword in the pharmaceutical industry means commercial-off-the-shelf, and it is being used frequently in reference to software. COTS software is a hot topic because many companies are hoping that it will help to avoid a lengthy and costly validation process. Other advantages to COTS software could include reduced maintenance and training, and simplified upgrades. However, there is often confusion about what a COTS solution really is, and what the true validation requirements of such a solution would be.
A LIMS Primer
COTS are of particular interest for laboratory information management systems (LIMS). Historically, LIMS vendors have designed their systems as generically as possible, in order to appeal to as wide a market as possible across multiple industries. These systems offered basic sample- and test-management capabilities. In order to then meet any industry-specific requirements, vendors would normally provide tools that allowed the customer (or vendor-supplied or third-party consultants) to extend the system and the database.
In some industries, this approach was not problematic, as the basic functionality was close enough to their requirements to require little customization to the software. Unfortunately for the pharma industry, life was not quite that simple. Due to the batch-oriented production processes, complex specifications and test methods, and tight regulatory requirements, LIMS implementations in pharmaceutical RandD and QC have required extensive customization. Like a snowball, each additional requirement would generate an avalanche of additional work: specifications, design, development, testing and validation, documentation, and more. In addition, customers ran the risk of breaking their customizations when upgrading to new releases. From a timeframe perspective, past experience has seen LIMS implementations take as much as 36 months. In some cases, implementation dragged on for so long that projects were cancelled. It is therefore little wonder why COTS is of great interest in the pharma industry. However, the key question is: can there really be a COTS LIMS?
What is a COTS solution?
There are several "interpretations" of what determines whether a software system is COTS or not. The war of words often revolves around "customization" versus "configuration". Given the challenges of our industry, and the extensive impact associated with software customization, we will define customization as ANY manually written code that modifies the system behaviour. Whether the LIMS embeds a scripting language or requires custom functionality to be written in an external tool or environment, any written instructions to create functionality represents customization. This would include manually creating XML or HTML for web-based user interfaces, or stored procedures to automate work-flow processes.
Configuration, on the other hand, offers control over the software without requiring any additional code.
Take the example of automatically printing sample labels at the time of registration. In a configurable scenario, a COTS software system may include a checkbox in the setup options that activates label printing at sample registration time. In the customization scenario, a system which does not offer such a configuration option would require the system administrator to write code which triggers sample label printing at registration time. In the first scenario, the customer may rely on vendor testing as evidence that the label printing capabilities are functioning as designed. In the second scenario, there is no such vendor testing. The functionality has been implemented at the customer site in a specific instance, and would require complete lifecycle management and validation.
This is a small and simplistic example of the difference between configuration and customization. An excellent example of complex customization in a pharmaceutical LIMS deployment is dissolution testing for oral dosage forms. LIMS administrators reading this article may be cringing already, since dissolution testing represents a complex, multistage test that is typically not supported by generic LIMS. The majority of LIMS systems available require extensive customization to handle the stage to stage evaluation of results, as well as the cumulative results review that is necessary to assess whether or not the dissolution testing meets specifications. As noted before, this customization then requires similarly extensive testing, validation, documentation, training and maintenance. Many LIMS administrators have actually had to build dissolution testing functionality from scratch more than once, as their companies have moved from one LIMS platform to another.
One of the interesting things about COTS is the seeming contradiction between a trend towards more granular out-of-the-box functionality and the global trend towards standardization. However, this is not a contradiction at all when viewed at the right level of standardization in an organization. The fact is, one should only standardize where it is advantageous to do so. If a company has 25 manufacturing facilities worldwide, with a QC lab in each, standardization can have great benefit in harmonizing processes, and in reducing deployment and validation costs across those 25 sites. However, it wouldn't make sense to try and apply a tool designed for QC testing to a protocol-driven clinical bioanalysis laboratory, nor would it make sense to use an MRP/ERP system to manage complex testing and sample management. That is not "standardization", and for the end users it is more like abuse!
Can a Pharmaceutical LIMS ever really be COTS?
For years now, pharma customers have been asking why they continually need to rebuild what they consider should be standard functionality in their LIMS. Dissolution testing procedures, for example, are clearly defined in the USP and other pharmacopoeia, and have been for many years.
Yet vendors have resisted incorporating industry-specific functionality. The commonly cited reason is that they cannot incorporate industry-specific features into a product that is designed to be generic enough to be sold across industries.
Currently, however, some vendors are finally recognizing that solutions which can actually satisfy the pharmaceutical industry's business needs can be mutually beneficial. The truly novel aspect to the new solutions these vendors are developing is that, rather than trying to append stopgap solutions to aging architectures, they are developing innovative solutions to meet a specific business need from scratch. While formal data are not currently available, anecdotal evidence indicates that the majority of pharmaceutical customers would pay a higher licence fee for software with more application- or industry-specific functionality. This may seem improbable, but the advantages are numerous. Every feature that eliminates the need for custom development work provides significant savings during implementation and production use. Equally important, the reduced customization allows a pharmaceutical company to get a much better grip on the actual deployment costs and timeline, since there are far fewer opportunities for delay when customization is minimized.
Given the current situation-pharmaceutical companies are competing for sales in the same markets, they must satisfy the same regulatory agencies, and they face regulatory trends towards standardization as evidenced by the success of the ICH-a select few vendors have decided to design solutions specifically to address the pharmaceutical industry's needs. In addition to offering the benefit of little customization, these vendors are assuming the burden of following and implementing new regulatory and industry developments and trends.
However, there are several challenges to providing a true COTS solution to the pharmaceutical industry. The sheer volume of tests and results that need to be supported, the extensive calculations, and the wide variety of reporting requirements are all areas of high variability that seemingly do not mesh well with the COTS philosophy.
In the pharmaceutical LIMS world, it is highly unlikely that a LIMS can ever be completely, off-the-shelf. The wide variation in requirements and workflow between companies working on small molecules or in biotech, different routes of administration, differences between research and development and the production world make it virtually impossible to design a one-size-fits-all solution. Therefore, the real objective is not to find a panacea that will meet all of a company's needs. The objective is to minimize customization to the maximum extent possible. Be wary of any vendor that suggests that they can provide the perfect solution with no customization whatsoever... LIMS buyers who are promised a solution that requires "no customization" should ask their vendor to confirm that no additional code will need to be written.
When examining LIMS to assess the extent to which they may meet your requirements, do not expect to find a 100 percent fit. A realistic assessment will always identify some areas which represent gaps between the requirements and the out-of-the-box functionality available from a system. The important thing is to have a complete understanding of the vendor's strategy for closing the functional gaps. Tools to extend the software must be available; the vendor should be able to provide experienced analysts to assist in deployment; and the technology platform should use modern architecture and open standards to facilitate the required extensions. In addition, a COTS solution does not eliminate the burden of responsibility on the part of the user. While the validation effort may be greatly reduced, there will still be some effort required to provide reassurance that the system, as configured, is functioning according to expectations.
It is also important to assess the levels of compliance and flexibility inherent in the COTS solution. Historically, despite extensively customizing generic systems, pharma companies have been unable to implement one solution to concurrently meet the needs of the less regulated users, such as analytical RandD, and the tightly monitored production laboratories. The configuration of the system should include the definition of compliance rules based on the type of data being manipulated.
While the COTS philosophy has great appeal, it is important to understand that in the pharmaceutical LIMS world, it is unlikely that a system will be completely off-the-shelf. However, any LIMS that can provide much more extensive industry-specific functionality out of the box will be a great boon to LIMS administrators and users. The significant reduction in deployment time and costs, as well as the reduced risk associated with clearly defined pre-existing functionality can change the nature of a LIMS from an overhead expense implemented to provide regulatory compliance, to a truly effective business solution with measurable gains in efficiency and timeliness. The LIMS may not be a true COTS solution, but the drive towards COTS is already bearing fruit, and will continue to do so as more companies take advantage of solutions.�