Whitepapers

Instrument Interfacing - The Great Paradox of LIMS?

Journey around the country and walk through even some of the most elaborately equipped laboratories and it will not take long to encounter a paradox, perhaps the greatest paradox of laboratory automation.  Roughly stated it is this:

(1) Manual transcriptions of laboratory instrument data and subsequent checking for accuracy is a time consuming, error prone, tedious and essentially anti-human activity.

(2) LIMS instrument interfacing eliminates this entire step, with associated improvements in accuracy, throughput, turn-around time, employee job satisfaction and costs.

(3) Only a small minority of labs have implemented instrument interfacing even when they have a comprehensive LIMS installation.

Some of you are of course saying that this is not a real paradox, but bear with me as we follow the old saw “When faced with a paradox, examine the hypothesis.” 

Certainly it is possible to find people for whom the manual transcription and checking of data provides a great deal of inner joy, and who consequently do it with excellence, but I think we can dispense with that as a significant factor in the paradox.

For the most part the issue revolves around (2) and boils down to “Is the view worth the climb?”  For a variety of reasons the inclination seems to lean naturally toward “No.”  Here are some of the myths which I believe tilt the table in ways contrary to the best outcome.

Myth 1:  Instrument interfacing has a high initial investment. 
Reality:  It all depends.  Instrument interfaces can be simple and low cost.  A uni-directional non-intrusive configurable COTS interface that simply captures an instrument or CDS report and uploads its analyte values and raw data file to the LIMS can be licensed and configured for less than a month’s worth of transcription and checking time.  On the other hand, an instrument interface can consist of an elaborate bi-directional communication with tight integration to LIMS data on standards, batches, patients, and testing protocols, capture entire CDS methods, and include extensive handshaking according to a proprietary or standards (e.g. ASTM E1578) based protocol.  In this extreme the cost can multiply many fold.  Here the 80-20 rule can be quite useful in deciding how far to go.

Myth 2:  Instrument interfacing won’t work for us because we almost always review and often intervene to re-process or even re-run the analysis or parts of it.
Reality:  There are a variety of ways to readily allow this kind of review and re-run process in an instrument interfaced system, either before releasing data to the interface or via provisions of the instrument interface package itself.  These are standard provisions in most COTS interfacing packages.

Myth 3:  We have a huge set of instrument methods.  We can’t afford to configure an instrument interface to handle all of them.  A variation on this says that our instrument methods are in a constant state of flux as we deal with new situations.  We can’t afford to also re-configure the instrument interface or have it frequently fail.
Reality:  With sufficient pre-knowledge of such behavior, a single instrument interface configuration can be set up to robustly handle a wide range of actual behavior.

Myth 4:  Instrument interfacing is ultimately a system integration job involving multiple vendors, a lot of interchanging of specs and requirements, and a lot of hassle to pin down who is responsible for what, with the inevitable finger pointing.
Reality:  Many LIMS vendors can act as single source providers of the entire instrument interfacing solution including complete hardware and software connectivity.  Such solutions tend to be much less expensive and hassle free both in the initial project and for ongoing support.

Myth 5: We require a validated GxP system and validating an instrument interface is too elaborate and expensive.
Reality:  The validation of configuration based COTS software is substantially less demanding than custom systems, and this includes instrument interfaces, particularly of the simple type described under Myth 1 and when dealing with a single vendor source.  It is likely the vendor can provide templates and examples of many of the required validation protocols. 

Of course it is wise to keep in mind that every myth contains an element of truth. Certainly the types of instruments, number of each type, usage levels, quantities of analytes, the value of rapid turn around to the enterprise, etc. must be taken into account to determine if the justification is there. But it is time to separate myth from reality in evaluating the prospects for instrument interfacing as part of any LIMS installation.  The benefits can be substantial.

Larry DeHeer 10/1/2009

Your World Is Integrated, Why Aren't Your Systems ?

In the late 80’s I had the unforgettable experience of working in the corporate IT Applied Architecture Committee for a Fortune 100 company.  This could sound pretty impressive, except that it mainly boiled down to finding a way to get a large number of applications all across and up and down the supply chain to work together seamlessly.  The problem was absurdly illustrated by a picture we took of a process control room with 5 different terminals/applications lined up in a row, with process operators moving between them in order to control the process.  One colleague far more clever than I added a “Level I Integration Solution”, a custom operator’s chair – simply push a button marked “LIMS” and you instantly arrived in front of the LIMS screen.  It had become obvious that the world was integrated, why weren't our systems?  We had to train the application Tower of Babel we had built over the years to communicate.  Some believed the holy grail of integration was to be found by building a massive data model of the world and then CASE based applications would flow forth like tin soldiers marching in formation.  “It’s the data, stupid,” was their creed.  Others focused on standard interfaces, dealing with everything from coherent transport to standardized, even internationally standardized messaging.  “It’s the interfaces, stupid” was their cry.   Still others claimed “Open Software” as the one true religion of integration.  But the practical solution that won out in the end was pretty simple – purchase the fewest possible commercial applications with the broadest suite of internally integrated business function coverage that best fit into a rational architecture of functionality, often giving up “best in breed” for a manageable integration task, usually then consisting of relatively simple interfaces.  Although it is not particularly elegant, much has been accomplished using this approach, both in terms of significant IT budget cutting and improved business effectiveness.

Twenty years have passed, an eternity in the world of computer technology.  Yet when I enter the laboratories of the small to medium and even larger enterprises today, it is as if I am entering a time warp and it is déjà vu all over again, or even worse.  For there I encounter an array of often ad-hoc point solutions and an army of technicians and chemists referencing, logging, transcribing, cutting, pasting and otherwise struggling with a vast array of paper logs, Excel spreadsheets, Access applications, Word Documents, and a set of stovepipe commercial applications for instrument control, project/product management, MES, document management, ELN, LIMS, metrology, chemical inventory, employee qualification management, proposals, orders, purchasing, invoicing, etc.  Day to day transaction processing is a struggle, timely and accurate decision support information even more difficult to produce. When it comes time to further automate a function, the approach is to find the best application and buy it - chemical inventory this year, LIMS next year, document management the year after, etc. Integration of systems is a rarity, integration across departmental boundaries even more rare.  There is a lot of sub-system optimization, producing a total system that is far from optimized.  In all this one must wonder, where is the advocate for total system optimization for business? Clearly not all vendor offerings are created equal when it comes to breadth of functions, integration features, and ability to act as an integration partner, but these considerations are often an afterthought at best in the application acquisition strategy and selection process.

In casting about for a better way, my gaze must fall on the IT organization and call for some serious mission re-evaluation.  From all appearances that mission today is to architect and furnish infrastructure and insure that applications are compatible with it.  Where then is the application architecture to deliver total system optimization and maximum business value? It is seldom in evidence. But when acquiring applications, whether home grown or commercial, it ought to be front and center stage in the selection process, and the IT organization is its most natural champion and advocate. I do not mean to trivialize the challenge for an organization whose skill set is usually more narrowly focused on IT technology.  But the old saw applies, “When you do not know where you are going, any path will take you there.”  As in many areas, a good beginning may be simply to start asking the right questions. 

Is it all worth it, can value be added, especially for the smaller enterprise?  Of course every enterprise and every industry has a different “lay of the land” that affects the answers to these questions.  I remain convinced, however, that the enterprise that architects its application suite for integration will also architect a significant competitive advantage into the future in both the cost and quality domains.

Larry DeHeer 3/16/2009

Does Your LIMS Support Barcode Labeling?

Few features of a LIMS can do more to simplify, streamline and improve quality in the laboratory at less incremental cost than machine readable labeling technology (barcode, RFID). How often have we not asked or answered the question “Does your LIMS support bar coding?” As with most LIMS issues, there is a whole world of detail hidden in that seemingly simple question and answer.

First of all, what are we labeling? We immediately think of samples, but what about pre-logged samples, sample containers, aliquots, equipment/instruments and their components, inventoried and bench top reagents, inventory storage locations, laboratory standards and their dilutions, personnel id badges, shipments, sampling points, etc.? The list can get even longer when the LIMS also tracks versioned documents, production batches, etc. Are we labeling individual instances of things, or types of things, or both? For example, it is often convenient to label a sample container as a type (e.g. sampling point / sampling time) so that multiple containers can be pre-labeled using a more durable and permanent label, and reused interchangeably without re-labeling in the field.

Another key issue revolves around how the production of barcode labels must be grouped. Once again we first think of the single sample label printed on logging. But efficient operation often demands that labels be easily printed in groups, such as collection containers in a collection route or pre-packaged kit, aliquots in a batch, individual pigeonholes in a storage array, etc. In these cases there is often a particular order of printing that must be followed as well for reasonable operating efficiency.

One can also miss key details about label formatting. Is more than one label size/layout, or more than one label format for each item needed (e.g. top and side) and if so does the software properly end up using the right printer(s)? Is the formatting flexible and configuration driven or fixed in firmware? Are there fixed limits to the related tables and fields that can be included on the label which would require custom programming to overcome? Are images required and can they be referenced via configuration? Can labels be printed to the proper remote printers when printed by a non-interactive task on the server (e.g. autologger)?

Modern technology has made machine readable labeling almost a no-brainer for any LIMS installation. However, attention must be paid to a large number of details if the LIMS software is to deliver this capability with the expected benefits.

Larry DeHeer 2/27/2009