Click on the advert above to visit the company web site

Product category: Measurement and Quality Software and SPC
News Release from: CSols | Subject: LIMS
Edited by the Manufacturingtalk Editorial Team on 01 June 2004

Instrument Integration With LIMS

When choosing a solution for your laboratory your main focus should be automation, rather than connectivity as correctly automating your instrument integration will maximize your return on investment.

It is important to understand that in most real-world situations, instrument integration is much more than mere connectivity Indeed, in most cases, the Instrument LIMS integration system has to automate everything that an analyst would have been doing manually, as well as handling the rather mechanistic issues of connectivity

Automation of all tasks previously undertaken by users, as data flows from Instrument to LIMS and back again.

In practice, the "automation" tends to be close to 90% of the application with "connectivity" accounting for only 10%.

Consequently, CSols recommends that when choosing a solution for your laboratory that your main focus is on automation, rather than simple connectivity.

Correctly automating your instrument integration will maximize your return on investment and improve quality at reduced costs.

However, there are also differences with respect to connectivity that should be taken into account.

Csols' experience is that there is misunderstanding in the marketplace about the relative merits of vendor solutions.

This article provides a clear overview of the key differences between the two approaches to connectivity.

Drivers and Parsers LIMS Instrument Integration products essentially take two different paths in handling connectivity issues drivers and parsers.

As you would expect, there are differences in the two solutions and this article considers the pros and cons of each.

Drivers :Most people are familiar with the use of drivers in Microsoft.

Windows.

If you get a new printer for example, you need to install and (possibly configure) a driver.

It takes a couple of minutes and the new printer and all its specialised features are available.

Drivers are sophisticated programs that handle bi-directional communications with the target device/system.

They can be operated in a variety of (typically dependent on the requirements of a particular link) and consequently, are fully configurable.

So for example, a Chromatography Data System (CDS) driver might be configured to have variable amounts of user interaction.

Perhaps the user might want to choose between whether height% or area% is reported on a run-by-run basis, or whether to view the chromatogram before transferring the results.

These, and many application related behaviours, are configurable.

CDS driver allowing user to select which peak units to report and to view chromatograms.

This functionality is used extensively in Pharmaceutical R and D but not in QA where no user interaction is the norm.

Each mode of operation is a configurable behaviour of the driver.

Absolutely no programming is required by the end user to make drivers work and, as with Windows Drivers, configuration takes only minutes.

Parsers: In the widest sense, Parsers are programs that read serially through a stream of data and break it down into its constituent parts.

In terms of instrument integration, this involves breaking down a data file or input from a serial stream into the various pieces of information that the application needs sample and component names, results etc.

Setting up the parser has to be done by the person implementing the system.

Effectively this means indicating (graphically or otherwise) what position the start of the sample name is, where it ends, etc The parsing rules may be set by the vendor/implementer, but in many cases are left to the user.

Parsing of even moderately complicated instrument outputs can take significant time.

Of course, it then has to be extensively tested and validated.

A bigger issue for parsers is in situations where the concept is just not applicable.

Even with simple serial instruments (the parser's biggest application area), there are many situations where a particular instrument demands that explicit conversations occur throughout data transmission.

Unlike drivers, parsers are inherently unidirectional and cannot handle such things in a standard way.

There are similar problems with instruments generating file-based results.

The secure files for anything but the simplest tend to be both complicated and possibly binary.

Partial extract of output from a CDS Result file the full file for a single sample can run to almost a hundred pages.

A parser to read this type of file would require explicit assistance from the manufacturer regarding its layout and the parser itself must be capable of translating the binary data.

The latter is not likely indeed parsing of these types of files is impractical.

One approach which may be possible for some instruments is to generate a (possibly custom) ASCII report and parse that.

This is likely to involve more work for the user and it generally involves real issues for data integrity.

Another rather suspect approach that is used, is to convert the instrument printer report to serial (with a hardware converter) and parse that.

However, with the advent of the FDA's 21CFR Part11 regulations and the greater data security demanded by it, increasingly instrumentation exposes its data through a Toolkit or API.

Communications in these cases must be via programs.

While communication of this type is ideal for drivers, it is impossible with parsers.

The trend towards instrument APIs continues to grow.

The way that systems based on parsers typically handle these situations is to require specific (often custom) programs to handle the communications.

These custom programs are often created using uncompiled basic source code or VBA scripts.

Of course these custom programs will require full control and validation within regulated environments such as those governed by FDA 21CFR11.

Even when file based parsing is possible, generic instrument data parsers are historically slow and can be exceptionally slow when they have to parse data from large files or files spread over several directories.

Performance is often orders of magnitude slower than drivers.

This can be a crucial issue.

Parsers provide a mechanism for users to perform "do-it-yourself" integration for a subset of simple analytical instrumentation.

The resultant solution for working laboratories (Including testing and documentation) will have taken considerable user time and will likely be less functional and possibly be more error prone than need be.

Going much further in terms of reliability generally requires coding (sometimes vendor supplied, often custom) to get things to work.

In the regulated industries, such solutions are prohibitively expensive from a validation point of view.

Note that when parsers are used they tend to be only half of the story as parsers only collect data.

Laboratory analysts need to also setup instrument runs and may need to manipulate the instrument worklists and send the reviewed results back to LIMS.

In some integration applications the generic capabilities, this functionality needs to be created by using a report writer or scripted code.

This functionality is delivered as standard with the alternative driver approach, Parsers vs. Request a free brochure from CSols ...

• CSols: contact details and other news
• Email this article to a colleague
• Register for the free Manufacturingtalk email newsletter
• Manufacturingtalk Home Page

Search the Pro-Talk network of sites