Unity of purpose

Colin Thurston, LIMS product manager at Thermo Electron Corporation Informatics, discusses the improvements in data access and the QA decision process that can be achieved if all the instrument data system facilities are available from within the LIMS.

Within manufacturing environments, it is common practice for all quality testing data to reside within a Laboratory Information Management System (LIMS). The LIMS acts as the data aggregation point, allowing QA tasks and decisions to be made centrally, rather than requiring the decision-maker to access multiple systems to carry out this task.

The majority of the result data within any LIMS will have been generated by the instrumentation within the laboratory, entered either directly from the instrument or manually. It is typical for the LIMS to store only the final summarised results for each analysis carried out; for example, in a chromatographic analysis, the amounts of each component in the chromatogram are stored, but the data used to get to those amounts (e.g. peak area, calibration curves etc) are maintained within the chromatography data system (CDS).

Integration of analytical instrumentation with LIMS is essentially a selective integration - often instrument-sequence download and upload processes and key-results upload being the total scope of the interface between the two systems. After all, why store more data within the LIMS than is required? Not all the instrument data is needed to make the quality decision, and overloading the user with data would clearly be a hindrance, where a fast decision can lead to increased efficiency for the organisation.

But this argument holds only when the results all fall within the expected range and when everything is running to plan. While this represents the general situation, any incident (e.g. out of specification or missing results) that requires an investigation reveals the shortcomings of this approach. The QA operator needs to be able to see whether there is an issue with the data, the instrument itself, operator error or some other problem in order to make the correct quality decision.

This problem is essentially one of context. A single number stored within the LIMS does not provide any context for the manner in which it was collected; the associated samples and calibration standards; the state of the instrument etc. All of this information has remained within the data system in the interest of not overburdening the LIMS user, and it is only at the point of having to trace the source of the problem that this information becomes important.

This is the dilemma for the design of the interface between the LIMS and the instrument. For the vast majority of the time, the user needs to see only the distilled result to be able to carry out an efficient disposition process. To make the quality decision when an exception occurs, however, the user needs to be able to see much more information information that has been deliberately left in another system.

The traditional approach to instrument integration with LIMS is to address the normal situation where all processes run within their expected boundaries; thus limited data access for the QA user is usually sufficient and the users themselves are expected to look after any abnormalities. Some assistance is usually given by storing a pointer to the instrument data system alongside the result data.

Yet, any investigation still essentially becomes a manual process, requiring the users to locate the appropriate data system and search for the source data files themselves - provided that they are trained in how to operate this additional application. From a high level viewpoint, this seems to be a pragmatic approach to looking after the everyday situation, unless of course it happens to be your job to carry out the investigation!

True integration of LIMS and instrument data systems potentially provides the ultimate solution to this problem, allowing the user to start with the summarised results and, based on whether this passes or fails the acceptance criteria, to drill directly into the source data and the supporting information from the instrument data system, which would save significant time and effort.

Most organisations would identify the LIMS as being one of their mission critical systems within the production process; however, it is also important to recognise that it is the instrument data systems that supply the results that are used to make the critical decisions about manufactured products. Therefore, the LIMS and the instrument data systems should be considered as a single source of QA information for the enterprise, rather than in isolation.

Given that the majority of all instrument-derived laboratory data comes from chromatographic methods, the logical step is to make the chromatography data system the primary target for this level of LIMS integration. This would allow the user to view results, chromatograms in the context of their sequences, integration parameters, calibration curves and so on without having to change application or location.

complex data

It is the complexity of chromatography data and data systems that provides a technological barrier. To achieve this level of LIMS and CDS shared functionality, it becomes less an issue of integration of the two systems and more about embedding the CDS functionality and data within the framework of the LIMS.

Requiring heavy customisation of both systems to achieve this level of interoperability would be a hugely negative factor, and up until now has been one of the key reasons for not taking the systems integration to this level. A high level of customisation always comes with a high price tag; not only is there a significant initial cost for the implementation, but an ongoing requirement to keep the interface updated whenever either system is upgraded or modified, since any changes to the data model, hardware platform, database or operating system will also affect the integration of the systems.

Support and management costs of separate systems are significantly higher than for a single unified system, often requiring different personnel to manage each of the technologies. Personnel costs, in terms of user training, are clearly higher if users have two different environments to learn.

The financial benefits of embedding the systems together become immediately apparent, from both the initial and ongoing costs for the system. Typically, the implementation of LIMS and CDS within an enterprise is carried out as three separate projects. Each system is implemented and commissioned separately, and this is followed up at some point in the future with an additional integration piece.

unified project

A single combined system supporting both the LIMS and chromatography functions could radically change this picture to a single unified project with no follow-on integration step required. In terms of speed of implementation and costs for an organisation, this would obviously be a better way of doing things. Ongoing costs in terms of IS resources and user training would be significantly reduced, for example, since a single database could be utilised for all LIMS and chromatography data, separate system managers and separate servers would no longer be necessarily required.

And this is before considering the efficiency gains when users do have to carry out investigations to find the context around a result. If it is immediately possible to drill into the original chromatogram integration and calibration curves, the QA operator will be able to ascertain the root cause of the problem quickly and decide the appropriate action.

If, for example, a re-run of the analysis is required, it could be scheduled immediately for the laboratory analyst to process, thus reducing any on-hold time incurred for the manufactured material. The speed of making the analytical data available is key and therefore any reduction in the time taken to provide this data has identifiable financial benefits.

technical compatibility

Perhaps the ultimate question on this subject is whether this level of integration of LIMS and CDS is actually achievable. It certainly relies on the LIMS and CDS being technically compatible, which would reduce the need for a reliance on heavy customisation. If both systems support open standards for data exchange and application interfaces, then it is has a realistic chance of being achieved.

Application vendors who can address both LIMS and CDS markets have the greatest opportunity to provide a real solution for the manufacturing environment, giving users the LIMS and chromatography data processing capabilities they need, as well as completely integrated information to maximise the efficiency of the release decision-making process.