Advances in interfacing technology have provided users with more flexible options that are better able to meet a laboratory's unique and changing requirements
At Labtronics we are sometimes asked if we have a driver to interface to a certain instrument or a driver that will connect to a certain Lims.
It is a natural question as a driver can be a very effective tool for transferring data from a source to a destination.
Drivers can do this very efficiently because they are specifically designed to work within a very clearly defined and fixed application.
For example, a print driver is designed to transfer text data to a very specific destination; a certain make and model of a printer.
Printer drivers can even be quite sophisticated with the option and choices that they provide to the user.
How many copies do you want to print? Which pages? Are you printing in portrait or landscape? However no matter how sophisticated the driver is, it will only do what it has been programmed to do.
Your printer driver will work fine, as long as you don't make any changes.
If you need to move your printer to a USB port, or you upgrade your operating system, or buy a new printer, then you will need to change the driver.
This lack of flexibility in driver technology is the reason that drivers are not an effective solution for interfacing instruments to Lims, where each laboratory will have their own unique interfacing requirements.
On the instrument side, each laboratory may configure their instrument slightly differently, may run a different type of analysis or may require special calculations on the data from their instrument.
To change a driver to meet those requirements, the laboratory will need to depend on the company that provided the driver to customise it.
If the instrument software is then upgraded or the laboratory upgrades to a new instrument, they are right back at square one having to create a new customised driver.
The same issue exists on the Lims side.
A Lims is not implemented as a straight out of the box solution. Even simple customisation of the Lims means that a generic driver is not likely to provide the complete interfacing solution that the lab is looking for.
They are going to have to depend on custom coding to create the functionality that they need.
This was a problem that the Lims companies discovered in the early days of interfacing.
They started out by developing drivers to interface instruments to their Lims.
The problem was things kept changing.
Not every customer configured their instrument the same way, so the driver had to be changed to match the format of the new configuration.
Not every lab would do the same calculations on the data, so new drivers had to be developed to handle the different calculation possibilities.
Customers would implement their Lims a little differently, so the destination that the driver was reporting to kept changing.
Every change meant that more time and more money were being spent on customising drivers. This approach did not work because trying to apply driver technology to instrument interfacing is comparable to trying to work with a spreadsheet application that does not allow you to change the layout or format of the spreadsheet.
As long as you want to enter your data exactly as the spreadsheet requires, do exactly the same calculations and don't have any unique requirements - the spreadsheet will work fine for you.
However, as soon as you want to make changes, it is not going to be a practical or effective solution.
A better solution for interfacing instruments follows the principles that spreadsheet applications like Excel have employed, by allowing the user to have control over configuration of the interface.
Excel allows the end user to configure the application to do exactly what they want it to.
The end user can create, save and modify spreadsheet templates that define the calculations they want to perform, display the data that they need to see and generate the reports that they need.
This provides the end user with the tools that they need to ensure that their spreadsheet is doing exactly what they want it to do, without having to custom code their changes. At Labtronics we design our instrument to Lims interfacing solutions to be configurable, like Excel, rather than inflexible, like a printer driver.
LimsLink and LimsLinkCDS provide dialogue boxes, a drag and drop interface and calculation tools that allow for configuration of interfaces without requiring custom coding. The interfaces can be saved, like a spreadsheet template, and modified as laboratory requirements change.
Unlike a driver-based solution, LimsLink and LimsLinkCDS give the end user the power to configure their interfaces to match their needs exactly.
One of our customers recently told us that two of their lab technicians have used LimsLink to develop over 50 interfaces for instruments in their labs.
Having that capability has allowed them to automate data collection throughout their lab without having to incur the cost of custom coding a solution.
If all laboratories had the same specific requirements, then driver-based technology would be a very practical approach to instrument to Lims interfacing.
However, in the real world each laboratory has unique needs and requirements that are continually changing.
In that environment a rigid 'one size fits all' solution is not the best choice.
The better choice is a flexible solution that can be readily configured to meet each laboratory's specific needs.
