LIMS Case Study

Segalstad Consulting has been a part in over two dozen LIMS projects over the years and with LIMS systems from suppliers such as SQL*LIMS from PE Nelson / Applied Biosystems (now LabVantage), LabWare LIMS, StarLIMS, Sample Manager from Thermo, Sapphire LIMS from LabVantage, as well as a few now-defunct LIMS systems.

Project sizes vary, as well as my involvement in them. In some cases I have just written the URS (User Specification), been involved in the system validation, while in others I have been instrumental in every step from the conception to the live system.

The most memorable project was one where H. Lundbeck in Denmark went from a completely paper-based workflow to a completely electronic workflow—in one giant leap that took a mere 14-18 months.

Lundbeck’s old workflow

The workflow was fully traceable and was based on paper, logbooks, and many layers of control. Every logbook for reagents, instrument calibration, etc., was checked before analytical results were signed off. There was an elaborate system for who signed off what in several layers, and many highly qualified people were involved in the controlling business.

The LIMS Project

The project group included some four to ten full-time employees during the project lifetime. A professional project manager who lacked laboratory background was responsible for the whole project. Additional project members were recruited from the labs and from the IT department, while I was appointed validation leader. The Quality Assurance group (QA) was heavily involved, but they were on the side of the project, as they should.


The project members were trained in validation by me during the project. Some of the training took place in a formal class, but I also made sure to follow-up with a lot of hands-on, on-the-job training.

System selection

Prior to soliciting bids, we spent a lot of time researching which suppliers should receive the URS. We based this qualification on requirements for functionality, like modules that some had and some did not, and also on which platforms they supported—in 1997 this was still an issue.

System selection was defined as three major parts:
• Writing the URS and assessing the answers.
• In-house testing of the top two systems.
Auditing the top supplier (the result was good so there was no need to audit the next supplier).
LabWare was chosen as the preferred system supplier. The contract issues were taken care of by the purchasing department, but that of course is also a part of the system selection.

System implementation

The supplier and the project group spent days together to create a Functional Specification to fit the requirements in the URS to this chosen system. It seemed like every point in the URS was answered with: “There are three ways of doing this. The advantages of the first one are xxx and the disadvantaged are xxx.” It is incredibly important to have a supplier representative who really knows his system.

When the FS was done, we started the implementation of analytical methods, specifications, reagents, products, and so on. We enlisted a new project member. His job was to connect and implement the many instruments in the lab. The implementation of the instruments included electronic logbooks and automatic reminders that it was about time to calibrate or maintain the instruments, and made the old paper logbooks obsolete. The same was done with chemicals, reagents, standards, et cetera. Each preparation was logged in LIMS, and concentrations were automatically calculated, and the reagents tagged with expiration dates, which made the old logbooks obsolete. Additionally, all sample preparation would now be logged in LIMS, all calculations performed automatically, and all connected instruments would send and receive the appropriate information.

System Validation

We created a validation plan and divided the validation effort into DQIQOQPQ (Development Qualification – Installation Qualification – Operation Qualification – Process/Performance Qualification). Furthermore, we defined each phase with a starting point, tasks to do during the phase, and how to determine the end point. Tasks included creating documents, implementing, and testing to mention some.

The validation plan also included a list of the Standard Operation Procedures (SOPs) to be written for the system. Additionally we made a list of all existing SOPs for the work-flow in the organization. Most of these needed revisions as the LIMS made the work-flow different from the old paper work-flow.

For each of the phases we created a qualification plan (DQ Plan / IQ Plan / OQ Plan / PQ Plan respectively), documentation that it was carried out, and a qualification report. The plan included acceptance criteria, and the report gave an overview of what had been done and if the acceptance criteria were met.

For the system testing, we decided to combine the OQ-PQ phases. We tested the system according to very thorough test plans based on the requirements in the FS. A traceability matrix showed the links between the URS-FS-Test plans.

System SOPs

The list of existing SOPs to be reviewed was continuously updated when there was progress in this work. We wrote almost twenty SOPs for LIMS. These included how to implement and qualify the static data, how to connect the instruments, how to maintain the system, and of course how normal users shall use LIMS in their daily work. SOPs in the IT department had to be changed to make sure that LIMS was a part of the change control there, and was included in the backup schedules.

Qualification Of the Template Parts

Templates are generally defined as the static data in the system. Each and every template was qualified according to the SOPs. The qualification SOPs included pre-defined checklists, which had to be filled in every time they were used. One specific instrument connection can be very different from another. Some of the SOPs therefore had optional testing, and it was up to each SOP user to use his or her understanding of validation to perform a good job. Training xref is important in these contexts, and I made sure that everyone involved in the project had been trained thoroughly. With the checklists predefined and approved by QA, there was no need to let QA read through a large number of test plans. But QA did authorize the test results.

Live System

The system went live, and with SOPs in place to ensure that the validated status prevailed. One of the most important SOPs is the Change control SOP. This will make sure that all changes are assessed for consequences before the change takes place. It also links to the qualification / validation SOPs and further on to the configuration management SOP if needed. Changes may be a result of errors, and there is also an error SOP which links on to the change control SOP.

The New Workflow

LIMS now has all information on what is going on in the labs. Controls are no longer a matter of checking everything, but to see that LIMS has not flagged any problems. The controller can also drill down into the more detailed information whenever needed. There are no longer any logbooks for instruments or reagents, and also no longer any lab notebooks that the analysts use for making notes. Everything is done directly in LIMS. And the group of people who used to control what others did in several layers now have more time for product development, develop analytical methods, and so on.


It was a big project and it led to a huge change for everybody’s work flow. The project would have been impossible to implement without top management’s support and trust in the project team. The information is now ready at everyone’s fingertips (provided they have the access), and the work is streamlined. The persons who used to control others in the paper-bases lab now have more interesting tasks than controlling what others have done. Not only that, but the turnaround time for the production process is only a small fraction of what it was before.