Instrument integration: driver or parser?

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.

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 maximise 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's experience is that there is significant 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.

Connectivity technologies - 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 ways (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. 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.

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 set up instrument runs and may need to manipulate the instrument worklists and send the reviewed results back to Lims.

In some integration applications with 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 drivers: FAQs.

How much custom and/or user programming is required? With drivers, no programming is required.

Real-world instrument links with parsers often require programming, indeed most parsers include some kind of scripting language which may already have been used by the vendor to create the Lims link. Aren't drivers more expensive than if I do the work myself? Drivers are invariably cheaper to implement.

For example CSols Lims and instrument drivers for commercially available products are provided free with initial purchase.

Installation and configuration takes only minutes and end-user training is minimal.

Parsers generally mean that laboratory or IT staff will need to spend time developing methods and potentially Basic or VBA scripts to parse the data and transfer it to Lims.

Parsers may also require the use of vendor supplied sub-routines to create and manipulate worklists from Lims.

These newly developed methods and scripts will all require validation in regulated environments.

Drivers or parsers: which have the widest range of applicability? Drivers can genuinely work with all instruments, Lims, CDS and other laboratory systems (SDMS, ELNs, etc), whatever the mechanism for communication demanded by the system. Parsers work only with a subset of systems.

Which are most reliable - drivers or parsers? Generally, output from laboratory instruments is not conceived by instrument vendors with parsing in mind.

Consequently, data streams from some may arbitrarily change when error conditions are encountered or changed situations pertain.

Drivers can trap such events and, for the more sophisticated systems, can query to see what the problem was.

Also, in situations where the instrument makes attempts at checking that data has not been corrupted (eg, putting checksums in the data), this would be verified within a driver, but require custom programming for a parser.

What about validation in the regulated industries? Since drivers have been produced against a full Gamp software development lifecycle, the validation effort that needs to be undertaken on-site is kept to an absolute minimum.

With parser based applications, even where there is no custom code required, significant effort has to be carried out to ensure that correct data is read and transmitted correctly in a wide range of scenarios - including error conditions, over range results etc What gives minimum user interaction? Both parsers and drivers can operate in a totally automated manner and, depending on the parent application, both can operate an entire link in the background.

Drivers do give the option though, of configurable user interaction where it gives benefits to the users.

One example is shown in the description of drivers.

Another instance would be in the targeted querying of Lims, for work to be used to setup an instrument run.

Some systems require logon before they will communicate.

How is this handled? Increasingly since 21 CFR Part 11 was introduced, both instruments and Lims require user logon before communication can occur.

Since drivers can handle this natively, no special effort is required to make this work. Parsers generally cannot handle this without additional programs. Should I choose a driver or parser based solution? CSols Links for Lims is shipped with both driver and parser technologies so that you do not need to make a choice over which is the optimal solution to purchase.

Driver technology can be used, for example, for mission critical, high throughput and complex operations which need to be simplified and automated and maintain compliance.

Whereas the parser can be used where you want to create simple point solutions for a new instrument or device. However it should be noted that CSols can provide drivers for brand new instruments in around two weeks.

All new Links for Lims systems are shipped with ready to run, validated driver-based solutions.

The CSols driver approach.

CSols's Links for Lims product utilises plug and play add-in drivers to handle all communications with instruments and Lims (they are also available for other systems such as SDMS, calibration systems, electronic notebooks, etc).

Each driver is developed, created and tested by CSols through its Gamp lifecycle based quality management system. CSols's ability to map technology against the working processes of each laboratory ensures that systems are guaranteed to do what you need from the point of implementation.

CSols provides a fully tested solution to meet your specific requirements an approach that minimises the validation costs of the system for customers in regulated industries.