For some, newer and slicker means trouble quicker:
Why labs should think twice before replacing an older but solid laboratory information system
Raymond D. Aller, MD
Conventional wisdom suggests that older computer systems should
be replaced. This maxim applies to hardware, and it can apply to software as
well if the software won’t permit you to upgrade to newer hardware. However,
the retirement age principle does not apply uniformly to laboratory information
system software. Replacing an old, well-established software package with the
"latest and greatest" may court disaster.
Whether a 20-year-old software package should be replaced depends on how well
it has been installed, maintained, and upgraded over two decades. If the laboratory
has relied on outside resources to update and provide major maintenance to the
system, it may be time for a change, particularly if the vendor has decided
to "sunset" the system. Keep in mind, however, that LIS vendors typically provide
yearly upgrades and updates, so a 20-year-old system may be running two-year-old
Some laboratories have been blessed with in-house support skilled at adapting
a system to fit local needs and to more effectively connect to other systems
within that environment. These individuals may be pathologists, clinical scientists,
or medical technologists—they more commonly are laboratorians rather than
information systems staff.
Management and owners of the laboratories that employ these professionals should recognize the unique strengths of their LISs and leave well enough alone. Regrettably, though, management sometimes interferes. The most common reason is that the laboratory has become part of a larger, multi-facility network. Although it is feasible to connect and interoperate existing, disparate LISs within such a system, it is commonly assumed that it must be more cost-effective to remove existing systems and implement a mega-system to serve all labs in the network.
Another issue arises when the laboratory’s system guru announces plans to retire. The responsible informaticist will have been training his or her replacement for years, but the laboratory’s owners may get nervous about the transition and conclude that it is time to install a modern, vanilla system.
Following are case studies that exemplify these issues.
A large teaching hospital implemented a laboratory information system to serve
its largely indigent population. Local support was provided by a creative doctoral
clinical scientist and his team, who kept the system operating at maximum performance.
A decade after the initial installation, the teaching hospital upgraded to
the latest version of the software, which continued to perform well. Then, 20
years after the initial software was installed, the hospital system decided
to implement a large, multi-hospital LIS software package from another vendor.
The hospital’s decisionmakers, however, did not adequately appreciate the extent
to which the previous software fit the laboratory’s atypical workflow. Consequently,
even though the new LIS was highly respected and installed in hundreds of complex
laboratory environments, implementation in this teaching hospital was highly
problematic. The system’s troubleshooting tools did not meet the laboratory’s
needs, and the complex interfaces between the LIS and HIS, which worked well
during testing, failed miserably when key demographic data was missing.
Local newspapers ran stories about the fiasco, conveying worries about compromised
patient care. After more than a year, and after Herculean efforts by the vendor
and laboratory staff, the major issues are finally being resolved.
A small independent laboratory needed an LIS. The pathologist owners asked
their junior pathologist to choose and install one. The junior pathologist selected
a hospital LIS and then modified the system’s programs to fit the independent
lab setting and provided all maintenance. (Twenty years later, the vendor of
the original hospital LIS still has not implemented some of the capabilities
built into the independent lab’s LIS.)
Over the next few years, the LIS contributed significantly to the lab’s growth,
leading the lab to acquire a 70 percent market share in the community. In time,
the junior pathologist moved to another practice in a different city. However,
before he left, he trained a medical technologist at the independent lab to
continue maintaining and building the system’s capabilities.
The owners of the independent lab eventually decided to sell out to a statewide
commercial laboratory. The new management made major changes, including replacing
the local LIS with a standard system used statewide that proved to be highly
problematic. The newly installed system provided unreliable report delivery,
unreadable reports, inaccurate billing, and, in general, a lower level of service
to clients. Consequently, clients left in droves, financials went south, and
the statewide laboratory eventually declared bankruptcy.
A regional hospital and commercial laboratory needed an LIS. The senior clinical
pathologist, having previous programming experience, persuaded an LIS vendor
to let him modify the standard software to fit his unique setting.
Over the next two decades the pathologist continuously built, enhanced, and refined the system to serve a regional hospital, commercial laboratory, and dozens of smaller, outlying hospitals. The pathologist incorporated into his LIS an array of unique and worthwhile features and capabilities, including a variety of billing rules and customized physician reporting capabilities. He even incorporated many of his enhancements back into the original vendor’s code base, but the vendor never activated these features.
The pathologist has since announced plans to retire. Although he had trained a medical technologist to provide ongoing systems support, the pathologist owners concluded that they would be better off purchasing a commercial LIS than sticking with the current system. So the owners purchased a well-respected system, installed it, and watched it crash. The commercial system didn’t have the knowledge or capability to implement the many special rules and features inherent in the locally maintained system. Since then, billings have fallen dramatically and clients have left. How this problem will be resolved remains to be seen.
Embedded in many older LISs are enormous banks of knowledge about laboratory
function, local conditions, and client preferences, as well as a variety of
other information. A new commercial LIS will not automatically contain this
knowledge, which goes far deeper than building a test list or client directory.
Often, such knowledge is embedded in program flow, or decision rules are integrated
into screen formats or database structure. LIS "rules engines" may not be capable
of embodying this business logic.
Dr. Aller is director of bioterrorism preparedness and response for Los
Angeles County Public Health Acute Communicable Diseases. He can be reached