Feature Story |
 |
|
|
For some, newer and slicker means trouble quicker: November 2004 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 software. 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 at raller@ladhs.org. |
|||
|
