Why would you ever want to spend the time to re-enter results by hand, with the risk of human error on top of it, when the process could happen automatically and electronically?
When it comes to having result data imported into your system, nothing beats a custom "instrument interface". An instrument interface is a software process or software program utility that will handle the importing (INSERTING) of your result data (RECORDS) into your back end database (RDBMS).
Note: Please don't tell me that you are still using an MS Access based LIMS! Please tell me that the back end is an enterprise level RDBMS like SQL Server / Oracle / Sybase / MySQL.
Today you can get very good LIMS Software at a fair price from a bunch of affordable LIMS companies. These affordable LIMS vendors can easily provide you with informative online demos of their LIMS products.
Having this kind of a process set up for your suite of instruments is a no-brainer. Even if the initial cost per instrument to set this up is somewhere around $1500 in programming fees, think of the time you will save, EVERY DAY, for several years. Again, it is a no-brainer. - Add to this the fact that the the data will be recorded correctly, without the chance of human error creeping in.
Question: How much is that worth to you? How costly would it be to lose a large customer because someone hand entered a result of 222 ppb, instead of 22 ppb, and then the results were flagged to the state? Yeah, you can't undo that too easily, can you? - Goodbye large customer.
Does the idea of automating this process sound good to you? Would you like to step up and have your data automatically imported? If so, there are some decisions that you will have to make. This is because there several different ways that this process can be approached. They each involve varying degrees of end-user involvement. We will next discuss and explain the three different approaches/strategies to utilizing an instrument interface. Determining which way is ultimately best for you can actually vary from instrument to instrument, so you really need to think about this.
1. Simple (to end users) - Fully Automated - SQL Server Only - Maps to Existing Samples
This is the typical, most common form of an instrument interface and/or importation of results from a file that comes from another lab (contract lab).This configuration features all of the following components:
- The samples HAVE been logged into the system, by a human.
- The results will be automatically imported via SQL Server processes.
- There is no UI in which end users can "eyeball" the records prior to being imported.
2. Simple (to end users) - Fully Automated - SQL Server Only - Creates the Samples
This approach is less common than the first approach, as it takes more time to set up the processes. The samples are not created by and end user before hand, the interface takes care of this for them. This approach usually only works when the samples being imported are not heavily laden with metadata (sample properties).This approach features all of the following components:
- The samples have NOT been logged into the system. They will be created automatically by the interface.
- The results will be automatically imported via SQL Server processes.
- There is no UI in which end users can "eyeball" the records prior to being imported.
3. Super - Provides UI for Users to Inspect, Modify, Reject Records prior to Import
This is the least common form of an instrument interface, as it is the most complicated to set up. It is primarily reserved for situations where the data is "high maintenance" and needs to be visually "inspected" and "okay'd" by a human being..This configuration has all of the following features:
- The samples may have been logged in ahead of time by an end user, or they may not have been.
- There is an UI in which end users can "eyeball" the records prior to being imported.
- The UI may also allow users to reject records.
- The UI may also allow users to add lookup data to the system: customer records, site records, etc.
