We began this series with a discussion of the preparation required before writing your autoverification rules. In this second article, advantages and disadvantages of the various software options are reviewed, which will help you define where to put the functions of autoverification-in the instrument, the LIS or in middleware. Pros and cons of starting the project in a high-volume area of the lab versus a low-volume area also are explored.
The autoverification process involves at least two laboratory software applications; one in the instrument that performs the tests and another in the host that communicates with the instrument, sending it orders and receiving results from it. There may also be a third software application, called middleware, which, at minimum, connects the instrument to the host. This is illustrated in the Figure, where the host is identified as an LIS. This figure also illustrates that the LIS is responsible for communicating with the clinical system, which may be a hospital information system (HIS) or some other form of electronic medical record (EMR). Each of the three laboratory software applications may include some functionality that supports autoverification, which ultimately sends verified results to the HIS or EMR.
At a minimum, the LIS must have the ability to flag results that need review and allow for release of acceptable results in batches. If your LIS does not have this functionality, you cannot proceed with this project until the LIS is replaced with one that does. Ideally, autoverification functionality will also include the ability to configure it to allow results to flow through it without prior review by a qualified laboratorian. This includes a way to process data from instruments and a way to make choices about how results are evaluated, by instrument and assay. For instance, you may want to set it up to hold for verification all results accompanied by an instrument error flag or hold all results outside of the analytical range of the assay or within the critical range of the assay.
In part one of this series, we recommended that you collect all the information you currently use to decide if a result can be verified or if it needs further evaluation. Next, determine if it allows you to configure all of the data you collected. For example:
• Does it allow you to configure autoverification based on different critical or repeat ranges for different patient locations or physicians?
• Does it allow you to automatically order a rerun with a specific dilution?
• Does it allow you to take action based on specimen type or on results from more than one instrument on the same sample?
• This is the time to also look around the instrument workstation for notes posted there to remind your operators about manual workarounds they need to take for certain situations that require special handling. Does your LIS allow you to configure it so that all these little posted notes can be removed?
Another factor to consider is the level of complexity and length of time involved in creating rules in the LIS. If the LIS does not support everything you need or is overly complex to use, you may be able to perform some functions in the instruments.
As many automated analyzers offer both flagging capabilities and decision rules capability, some level of autoverification may be implemented here, especially in a department where you have a highly experienced and skilled staff who can manage the performance of the instrument and the maintenance of the rules configuration. This is most likely to be a reasonable option with the newest instruments in your lab, as vendors have been enhancing that functionality in the last few years in response to the demand for autoverification. Your instrument may do a good job of managing reruns for you; however, when you explore this option, you may find that your instrument is actually performing autoverification functions via external process control software called middleware.
Where expert user technology, essential for the autoverification setup, is not entirely available for the LIS or the instrument, middleware may be the best solution. Middleware offers very robust expert user options and is often easier to configure. It also offers the ability to produce a message for the instrument operator, defining the problem that caused the result to be held for verification. The flagging capability of the various instruments is used, but the decision rules are built in the middleware rather than in the LIS or the instruments. This avoids duplication of setup within multiple software products.
Validation and on-going maintenance of the autoverification process is also a factor in this decision. Troubleshooting where a result is released that should have been held for review will be much easier if all the factors that control the process are located in one software product. On the other hand, a rule that reflexes a new test order based on the result of a test (i.e., if a screening test returns a positive result, order a definitive test to confirm) may have to reside in the LIS if the LIS will not accept orders from a third-party application.
Where to Start
The decision about what part of the lab to begin your autoverification project in relies on a number of factors that vary from one lab to another. A common place to begin is with automated chemistry assays. This area usually offers the advantages of high test volumes, clearly defined reference ranges and delta checks, the ability to define intermediate ranges for abnormal results, and the flagging capabilities of various automated analyzers. Success at starting with a high-volume area of the lab can have a big impact on customer satisfaction due to improved turnaround time.
You may decide to start with hematology because the department is getting new, highly automated instruments and the supervisor is experienced with the implementation process involved with that instrument's capabilities. Given both a new instrument and a new process, you may want to consider a staggered implementation to help technologists reach a satisfactory comfort level in the instrument's operation.
A more conservative approach might be to start with an established coagulation instrument, since this involves a very small number of tests and only one specimen type. The final decision may also be influenced by the need to improve workflow in a specific area of the lab due to staffing shortages, increased test volumes, increased test menu or all of the above.
Grace Pfeiffer is implementation consultant, Data Innovations North America, South Burlington, VT.