INSIGHTS on Data Management Systems: Ask the Experts
A Q&A with two laboratory data systems experts
Because our user-experts had widely varying experiences with data management systems, we asked them questions that reflected their situations.
Senior IT Specialist
Southern Research Institute
University of California,
Morse Laboratories, LLC
Q: What type(s) of laboratory information system(s) are you most familiar with, and for what types of lab work?
A: Provantis is an integrated Windows-based system designed for nonclinical evaluation studies. Instem Life Science Systems of Staffordshire, England, is the vendor and provides support from its Plymouth Meeting, Pennsylvania, location. Types of information include pre-study data (e.g., body weights), in-life activities (dosing, food and water consumption, weights), reproduction, and pathology. The system generates reports that include audit trails, data tables, and report summaries with statistical evaluations.
Q: Compare the system’s strengths and weaknesses
A: The system collects, stores, and reports toxicological, reproductive, and fetal pathology data, which are retrievable by study, animal, date, activity, or any other desired grouping. Complete audit trails are easily generated and provide all the necessary GLP requirements. As for weaknesses, a few elements may require extra time and familiarization. We look forward to the addition of full Windows functionality in the clinical pathology portion of the system that interfaces with the analyzers. It has been noted that access to online data review of gross and histopathology can be laborious; however, the essential security aspects of the system are part of this.
Q: Was there any notable pain, discomfort, or resistance when the system was first deployed?
A: When we first deployed Provantis in 1995, some users were uncomfortable with it and resisted using computers in the laboratory. The system, which was a DOS product, was not completely intuitive at that time, so there was a big learning curve for most users. The vendor provided good training, and the users now prefer the paperless data collection.
Q: How helpful was the vendor in resolving problems?
A: The vendor communicates with us regularly, always seeking input and ideas for upgrades. Problems reported to their help desk are usually addressed rapidly, and most are resolved. Others are marked for correction or enhancement in future upgrades. The support manager is always receptive to our concerns.
Q: Describe your experiences with LIMSs.
A: I have used LIMSs in two different companies, both pharmaceutical CROs. Company A concentrated on GLP bioanalytical work and dabbled in agricultural-chemical work. This company also built their data system themselves. Company B was split 50/50 on cGMP pharmaceutical work and GLP ag-chem work. Each company was at a very different stage in the development and use of their LIMS and held different philosophies with respect to use and implementation.
Q: Can you describe these differences?
A: Company A believed in putting significant resources into LIMS development and in pushing the limit of what the LIMS could do. Their system was home-built, and it was incredible. It was the fabric of the company and permeated every part of the lab. The LIMS tracked every sample and supply that came into the lab, every controlled document, every freezer/refrigerator and lab temperature, and right before I left the company, they rolled out a way for it to parse data for review and table development. The idea was to exploit the system to the fullest, even if that meant writing and validating code. Company B approached their LIMS much more conservatively, by purchasing and developing a commercial program. Initially, they allocated fewer resources for the LIMS, so development lagged. To their credit, as management recognized this, they allocated more resources to the LIMS. In all fairness, Company B was much more diverse, with more complex regulatory challenges.
Q: What kinds of resources were required to build and maintain a home-built LIMS?
A: The company had four dedicated programmers and one validation person who took care of the LIMS system. This was their “only” responsibility, and the LIMS system evolved as the work and needs evolved. I think that today the same ownership would make the same commitment to technology and a LIMS as they did then. Since there are more commercial systems available now, they might begin with that, but I think the commitment of resources would be the same.
Q: How responsive were your companies’ IT professionals in terms of adapting the LIMS to changing workflows?
A: Company B decided to purchase a LIMS system. Good idea, but the resources to develop and use the system were not initially put in place. As with a lot of companies, the IT group was expected to add this to their list of responsibilities and a LIMS group was not set up. The initial implementation took longer than anticipated, and when rolled out, the use of the system functionality was not where it needed to be. This caused staff support for the system to diminish, and there was less momentum to push the system forward. I have to add that senior management realized this, and more resources, in the form of programming consultants and such, were added to the project.
Q: If you were managing a midsized company today, would you build or buy?
A: That is a tough question. I think it would depend on whether I had staff to develop the program. If I did, I would relieve them of some other responsibilities. Two concerns would be regulatory compliance and validation and what happens if the programmer leaves. These concerns can be mitigated by validating the system as it is developed and insisting on GLP-level documentation during development. I think that developing it in-house is less expensive and provides greater flexibility and easier system evolution. Even as it grows larger and permeates more of the company, hiring several programmers would be cheaper than hiring the LIMS company consultants.