Return to Braley Consulting Services, Inc. Home Page
It's an old story - just when you purchase a brand new computer system that model
is discontinued. At least that's the way it seems in the personal computer arena.
While it's not uncommon to replace PCs every three or four years, the LIS situation
is not as straightforward. This is important since long term planning - however tentative
- is crucial in any healtHcare organization and one part of planning is to anticipate
major capital expenditures.
In the mainframe oriented business world of the past, five years was considered a normal life cycle for most systems. It is obvious that the LIS market is different since few lab computers are replaced in five years. Most - even primitive early systems - last anywhere from seven to fifteen years.
There are a number of reasons for the unusual life expectancy of an LIS. In the typical 1970's mainframe world, computer hardware could be replaced without necessarily replacing the software. So frequently, "systems" were not replaced but hardware was. In fact some business software has survived for decades and through countless hardware upgrades and replacements. This was possible because there was some degree of portability in these systems, i.e. the software would work on a variety of central processors. In reality it was not quite that easy. Often there were hordes of programmers behind the scenes patching, converting and rewriting programs to make it all happen.
Laboratory computer systems have typically not been ported from one platform to another. The complexity of the systems and the dependency on the underlying hardware have made this virtually impossible. Of course processors are upgraded, terminals added and memory increased from time to time but most users do not see this as a system replacement. A laboratory system then lasts as long as the software is usable.
The fact that changing laboratory computers is so difficult and time consuming means
few departments are anxious to do tackle such a project. Most are inclined to use
systems as long as possible - or at least until they have forgotten the pain and
anguish of the initial installation. Combine this with the fact that vendors realize
users might very well switch suppliers if they are going to change systems and the
companies go to great lengths to keep their software up-to-date. Consequently, a
ten year old system does not have ten year old software. The monthly charges for
regular upgrades can be considerable but the alternatives - using the system as it
was initially designed or replacing it every three to five years - are unacceptable.
Given this background is it any wonder administration might ask "how can the system be obsolete? Haven't we been getting the annual updates?" This skepticism leads naturally to the issue of Justification. While most people agree that an LIS is justified in a modern clinical laboratory, justification for a replacement system is not nearly as easy.
If a system still runs, it presumably provides most of the benefits for which it was originally purchased. It may be slower - if it has reached the limits of its capacity - and it may be less reliable - particularly if the vendor does not provide responsive maintenance services. Exactly how much is improved response time worth? What is the value of reducing downtime from six hours per month to one hour? These are the kinds of questions faced by those attempting to justify a replacement.
Generally speaking an older system will not have the features and functionality of a new package. Unfortunately, few people outside the laboratory - and in particular those in a position to reject the justification arguments - will comprehend these differences. Non-laboratorians found it difficult to understand the basic functioning of the original system so it is not surprising that the subtle differences between systems may not make a convincing argument.
When the original LIS was installed, everyone knew the change would be traumatic. Most people felt that once the department was automated and the staff had experience with computers, converting to a new system would be relatively easy. This has not be proven to be the case. The source of the problem becomes obvious when the selection team documents their "needs" for a new system. Virtually everyone discusses needs in terms of "fixes" to the current system. The general assumption is that the new system will have the desirable aspects of the current system and correct most of the deficiencies.
In reality it is likely that some prized capabilities - either "what" the
system does or "how" it does it - will be lost when it is replaced. This
may be because no other system has those capabilities but it may also be due to the
fact that these features were not documented as part of the needs analysis. Because
current capabilities were assumed to be available, little attention was given to
them during the evaluation. Consequently, the chosen system may have fewer of these
features than others that are ranked lower merely because those features were not
considered carefully during the product comparison.
No matter why the features are lost, the problem is often not noticed until well into the conversion process. At that point the transition turns into a series of disappointments as the deficiencies are uncovered. No matter how many complaints users may have had about the previous system, it will never receive more praise than the first six months after it is replaced. In many cases this praise is for capabilities that were taken for granted and therefore not considered seriously in the selection process.
A relatively minor but still annoying problem results from system specific terminology. Anyone who monitors the LIS field on a regular basis is well-aware of this situation but most laboratorians pay little attention to other vendors once they begin to install a specific system. Is it any wonder then that many users believe a specific patient report is called the PCR - often without any knowledge of what the letters stand for - and also believe that all systems must have a PCR. To see how ingrained a given system can become just look at the meeting notes from an LIS committee or read the list of items people feel must be fixed in a new system. "We want to sort the PCR by patient location and add patient age to the LI report." While this may seem like a minor point it illustrates again how department is going to have to change more than most users understand.
Change is not just traumatic when going from a manual system to the first LIS. It can be just as difficult to change from a 15 year old system that has become a "way of life" to a new LIS.
Believing that "we're experts since we've been through it before" most laboratorians think that replacing a system will be much easier than the original installation. While familiarity with computer basics - and one system in particular - certainly aides the transition, other factors come into play that make the change every bit as difficult as the earlier installation. For one, the dramatically increased complexity of modern systems compared to their 1970's and early 80' ancestors makes the problem of procedure file definition and report formatting much more complicated.
The previous system went through several years of refinements and tuning to provide the capabilities currently in place. The replacement system must have most of those refinements in place at the beginning or many people will conclude they have taken a step backward. This situation will be exacerbated if there has been much customization on the part of either the user or vendor - customization which provides a very specific "look and feel" to the system which may be difficult to match with the replacement.
The difficulties caused by complexity and customization are magnified when the shortage of resources is taken into account. Cutbacks, reorganizations and mergers have typically left laboratories without extra resources to apply to major projects and the LIS installation suffers as a result.
A second factor that complicates the replacement is that limited phasing is possible. Early systems were installed over many years; chemistry and hematology first; microbiology a year later and pathology and blood bank modules stretched out even further. If all of these modules are now part of one system, that system will more than likely have to be replaced over a very short time frame. All departments must be up and running on the new system at precisely the same time. This in fact is an argument for purchasing laboratory modules and/or modules of the total information system as separate packages - possibly from separate vendors. Systems are easier to replace one piece at a time - and the smaller the piece the better.
A third complicating factor involves data conversion. When users installed their first LIS, there few attempts to "back load" historical records into the system. Blood Bank and Surgical Pathology were exceptions but even these were entered gradually - typically when a patient returned for testing. Most users today require that critical databases be converted before going live but incompatibility of databases makes this extremely difficult. The fact that a given vendor will replace only a very few systems of a given brand discourages that vendor from developing sophisticated conversion tools.
The situation is even worse when the system being replaced has little or no support from the original supplier - possibly a reason for the replacement. In this situation there may be no one to do the work on the original system to output records for uploading. Even if the current vendor is still in business, the company has little incentive to do custom work which will primarily serve to make the incoming vendor look better. It is likely that a cottage industry of "conversion specialists" will spring up to meet this critical need.
Conversion of results databases is difficult but critical. In very few cases, however, is it recommended that procedure files and other system specific tables be converted. New systems have so many additional capabilities that the limited data entry saved by a conversion is not worth the effort of developing the translation routines.
Sometimes a system selection is made using a structured evaluation process. The steps are planned in advanced; appropriate resources are assigned and a realistic schedule is prepared. Unfortunately many laboratories used a "seat-of-the-pants" approach the first time around and the installation and early period of operation suffered as a consequence.
Whatever the original process, it is often assumed that "we did it once so we
can do it right this time." When questioned about the first installation, however,
many will respond that it was a "nightmare". It is unlikely that such experience
would translate into competency today. Expertise in system evaluation like any other
complex process is developed through study and practice. It does not happen by doing
a poor or mediocre job once - particularly when that occasion was more than ten years
ago.
In the "good old days" when systems were simple, staffing was plentiful and money was not a problem, errors in the selection methodology or configuration of the chosen system were not serious. If there was a problem, staff could be added or more equipment could be purchased to compensate. In some cases serious blunders resulted in entire systems were replaced after only a short period of use. Today, healthcare facilities do not have the luxury of such misfortune. They must do it right the first time.
While there is no perfect methodology, it is critical that a plan be developed and
that all parties agree the approach is sound. The plan should include time for study
about how the industry has evolved. When the initial system was selected, the team
became experts on the state-of-the-art at that time. Few participants, however, have
the time or inclination to maintain that expertise and current thinking may be years
behind the technology curve.
There is an ongoing debate about the necessity of preparing a Request for Proposals (RFP). Preparing such a document involves a great deal of effort for all parties and some would argue it is not worth it. All the talk about RFP's is misleading. The debate should really center around how the organization is going to obtain detailed information from several vendors in a format that allows apples-to-apples comparison and results in material from the selected vendor that can be incorporated into a contract.
It is obvious that the classic "specification" format for an RFP does not do the job. Telling vendors what you "want" their systems to do makes no sense when the systems are already developed. It is more appropriate to ask what the systems do and compare the answers. The material sent to vendors is then in the form of a questionnaire which you may or may not choose to call an RFP.
Another classic RFP format that produces unsatisfactory results is the "check-list". A series of features is provided and the vendor is asked to check whether the feature is standard, whether they will develop it at no charge, whether they will develop it for a charge or whether they will not provide it at all. While this looks superficially like a good structure, the results are generally disappointing - another reason to question the validity of the RFP approach. The problem with this format is that the lack of standards in LIS terminology means most vendors can claim they have most features - after all that's the sales departments interpretation of the question. "They all said yes to everything" is the most common complaint from reviewers of proposals prepared in this format.
While it is outside the scope of this article to describe the selection process in detail, suffice it to say that good RFP questions provide useful information for comparison purposes. They can also provide detailed documentation of what the vendor claims the system will do and this material should be added to the contract.
"It seems like a good system but they sure don't use some important features". That's what you often hear when a selection team visits a current user. The users explains this underutilization in two different ways: 1) The features really aren't as valuable as the vendor leads you to believe and 2) We don't have the resources to implement the features and train the staff. If the first situation was uncovered after the system was purchased, the selection process was faulty since the department did not know enough about the capabilities to judge their value.
The second problem is more critical since it will get worse as systems become more
complicated and resources are reduced. With computer technology, it is easy to assume
that more is better. Features are piled on features till even operation of a word
processor is more like rocket science than typing. Before selecting a "full-featured"
LIS as a replacement, the laboratory is well-advised to assess the utilization of
the current system. If major elements are not used because resources are not available,
how much worse will it be when the capabilities are increased significantly? The
selected system should not only meet the users' needs; it should match the available
resources as well.
Many factors complicate the LIS repalcement process - not the least of which is the growing complexity of the modern healthcare system. This combined with the fact that there is little room for error in major system installations means that laboratories must excersise great caution in such undertakings. A well-designed evaluation methodology, continuous involvement of all concerned players and an understanding of the pitfalls of the system replacement are critical to the success of the project.