Return to Braley Consulting Services, Inc. Home Page
Justifying the purchase of an expensive computer system is not an easy task. Simple arguments based on "lost charges" and "improved patient care" don't work any more. On the one hand financial considerations restrict a lab's ability to acquire a system and on the other hand regulatory requirements and the desire to limit staffing are increasing the pressure to become more efficient.
Justification problems faced by dissimilar facilities appear entirely different. A small rural hospital installing its first system does not face the same issues as a major reference laboratory considering an expensive upgrade of an installed system. Although the set of factors incorporated into each organization's justifica tion will vary and the importance of specific items will differ, a common methodology can serve as the starting point for attacking the justification problem at both facilities.
Expenditures for capital equipment are increasingly difficult to justify in the rapidly changing worlds of healthcare and computer technology. While the need may be intuitively obvious, questions about the future of the organization, rapid obsolescence of systems, and how the pieces will all fit together do not lend themselves to simple mathematical analysis. This article will cover many issues that are often overlooked in initial stages of system evaluation and justification that often come back to haunt an organization at the time of purchase or even during installation and subsequent operation. Topics addressed include
The user contemplating a first LIS installation generally frames the question in terms of whether or not they can afford a computer. If the answer is no, an alternative would be to streamline the manual system. In the end though this cannot be a decision about installing computers but a question of how many, when and in what manner. All laboratories are being automated: new word processors in the office, a data collation unit is provided with a chemistry analyzer, a QC package is supplied by a vendor, etc., etc.
A lab that decides they cannot afford a computer might instead install a small PC network so results can be entered and reported. It is a catch-22, that a large number of the improvements that can be made if a lab elects not to install a computer require the installation of a computer - or several computers.
The real question to address then is whether to install a more comprehensive system and do it in a structured fashion. "Doing nothing" could result in a mismatched collection of small computers that do not resemble a "system" at all.
This problem is compounded by the fact that LIS vendors
have generally been very good about updating products.
Medium and large facilities have been through the justification process at least once since most have systems currently installed. The "need" for a system is well established. While systems are expensive, difficult to install and less than perfect, few current users would consider going back to the manual approach.
Even though they have been through a justification process, it may have been in the "good old days" when almost any story would work. There may have been delays and a variety of forms to fill out, but in the end a lab computer was purchased. Now just at the time when financial resources are shrinking there is added complication to the justification process for these users.
The differences between a manual and automated laboratory are relatively easy to explain even considering most decision makers have very little understanding of laboratory operations. The differences between two automated processes - the current computer operation and the replacement computer version - are much more difficult to explain. This problem is compounded by the fact that LIS vendors have generally been very good about updating products. A nine year old system does not have nine year old software.
These vendors realize that laboratories will not tolerate changing systems every five years as businesses have done; the trauma is too great. Consequently, regular - albeit expensive - software upgrades are included in their offerings. It's hard to explain why a system is no longer usable when the vendor has been supplying updates on a regular basis.
It takes a thorough analysis to document the failings of such a system which might include: degrading response time, increasing hardware problems, lack of certain features, poor maintenance, etc.
In two extreme cases though, justifying a replacement is easy. A vendor who abandons a system and discontinues support forces the user into a replacement mode. Also, if the current system is so bad that its problems are known throughout the organization, buying a replacement is not generally difficult. Along the way, the question of "how did we get into this position" must be addressed - particularly if the system is only two or three years old. In some cases key personnel may be replaced along with the system.
There are numerous other issues involving selection and implementation of replacement systems - that differ from first time problems; they are unfortunately beyond the scope of this article.
It is one thing to perform a thorough analysis of costs and benefits; it is quite another to explain the results to individuals with little or no understanding of laboratory operations. A common approach to educating decision makers about the complexities of the modern laboratory is to document through flow charts and reams of written material everything that goes on in the department. While the approach is common it is often ineffective; managers seldom have the time to digest this amount of detail. There are alternatives which work better and involve less work.
If written documentation is necessary, it is possible to describe one common activity - e.g. processing a routine chemistry panel - in detail. After this is presented, it is only necessary to point out that the department has 500 other procedures of equal complexity to get the point across.
Sometimes it is helpful to have board members or other interested parties take a walk through the laboratory. If they have any business experience at all, they will quickly recognize the information overload problems faced by the modern laboratory.
When installing any new system, there is a temptation to think of the outcome in simplistic terms. Generally, we envision the coming changes as being patches or fixes to problems with the current system. It is assumed the department will operate about like it does at the present but the things we don't like will be improved.
This limited view restricts our ability to get the most out of a new system because we don't look outside of our current environment for improvements. It also makes justification more difficult if benefits are not tabulated in a "re engineered" department. More than one laboratory has expressed a desire to install a computer but "not change the way we work". Even when this is not a stated goal, it is often the hidden agenda of those who would try to minimize the disruption to current procedures - after all, nobody likes change.
"We don't have time -
time to set up the files
time to test the system
time to train the users."
Many of the major gains from a new system - which must be exploited if justification is to be meaningful - will not come about without a major overhaul of department procedures.
In a related issue, how many times have you seen a department which does not use an important feature of a system - Q.C. or management reports for example. It's a good bet that some of those features were used as part of the justification and possibly the reason to buy one system instead of another. Often the reason a feature is not used is "we don't have time" - time to set up the files; time to test the system; time to train the users, etc. If this is true, was the amount of time required to operate a complex system - including significant training costs - determined at the beginning and factored into the justification? Often such costs are underestimated and an important capability is unused as a result.
The lesson here is that in an attempt to exaggerate a justification claim by understating labor costs, real benefits may be lost.
It is difficult to calculate long term costs and savings associated with a major investment when many organizations are not even sure what will happen to them six months down the road. In most cases there are potential actions - merger with a neighboring hospital for example - that are the most likely and should be incorporated into the justification. In a "what if" analysis, the utilization of a given system in such a scenario can be predicted and the benefits of the system following the merger can be included or excluded based on the results of this analysis.
Laboratory computers and other departmental systems are often considered in relative isolation. Unfortunately outside issues such as medical staff acceptance and HIS interfacing success or failure may ultimately be more important than pure laboratory functionality. This complicates justification since a benefit predicted by an LIS team - comprised primarily of laboratory personnel - may not materialize if the outside parties have not "bought into" the process.
As a simple case, whether or not a new LIS saves one hour per shift at each nursing station - as calculated in the justification - is in the end totally outside the control of the department. In fact, nursing might describe savings in qualitative terms but be unwilling to commit to specific values or acknowledge that these savings can in fact be "recovered" and "reused".
Many of the benefits
of a laboratory computer
accrue from outside users
Outside influences are also critical when the subject of interfacing comes up. Unfortunately with all the work that's been done in this most troublesome area, there still is no simple solution. Point-to-point interfaces, interface engines and standards such as HL-7 are all part of the mix but they have not produced outstanding results.
At the very least costs from outside vendors such as the HIS supplier must be incorporated into the justification. It is not safe to estimate such costs based on industry averages since actual costs vary widely. This is not so much a technical problem - some vendors charge horrendous fees for interfaces they have already developed - but a marketing decision. An HIS company may intentionally make it expensive to interface to a "foreign" system so the user will be more inclined to purchase their product.
Even companies that describe their systems as "open" may adopt such a strategy. While the systems may be technically "open" the decision makers in the marketing department are definitely not open to the idea of such interfaces. In the end this may be the aspect of "openness" that counts the most.
Many of the benefits of a laboratory computer accrue from outside users - particularly the nursing department. As systems become increasingly complex, training of staff inside and outside the department is a growing burden on all parties. If that burden is not acknowledged during selection and justification, resources to train personnel may not be included in the budget. The result will be systems that are underutilized - you can't use what you don't know about - and predicted benefits will not materialize.
In predicting lifetime costs it is vital that future enhancements and upgrades be considered. While it is impossible to say precisely what these changes will be it is certain they will occur and funding should be included in the cost-benefit calculations. If a $40,000 upgrade is projected in the third year it will not come as a surprise when an upgrade is required even if the amount is not exactly $40,000 and the timing is a little off.
Of course there is an alternative - buy all the equipment needed for the lifetime of the system when it is first installed. In fact many users feel they better "get it while they can" because it will be impossible to obtain additional funds later. Administration can legitimately claim that no additional funds should be necessary since they were not predicted in the lifetime cost analysis. That's precisely the problem; unpredictable costs are omitted rather than estimated.
With computer technology there is a compelling argument to postpone purchase of equipment that will not be needed initially. Hardware prices continue to decrease at incredible rates. In particular disk drive and other storage media increase in capacity and decrease in cost so much over time that the prudent buyer would never purchase such devices several years before they are needed. It is vital, however, that this strategy be understood by all parties at the outset. That way there are no surprises when upgrades are requested in subsequent years.
One other factor comes into play and that is the promise of the vendor to provide regular enhancements to the product. While this is considered essential by most clients, it is not a very well defined commitment. The vendor generally determines - certainly with input from the user group - the nature and timing of such improvements. The troubling issue for the user is that some of these enhancements may require a more powerful processor, increased mass storage capacity or additional input/output devices. Of course hardware and software enhancements will undoubtedly increase support and maintenance costs beyond the usual cost-of-living increases generally factored into lifetime calculations.
The flexibility all users demand in new systems can contribute to the problem as well. Vendors will commit to response time guaranties under some set of "normal" circumstances: normal load, normal transactions, etc. A user who later makes frequent use of advanced tools such as relational database searches and report writing can easily overload a system in ways that are impossible to predict. As technology improves and new vendors come into the market with entirely new systems, the problem is compounded since there is little experience on which to base predictions of performance.
To be on the safe side all cost and savings predictions should be conservative. The product should not be oversold. Expectations should be based on knowledge gained in this field over the last 30 years and not just on a vendor proposal and optimistic estimates of critical parameters.
The difference between mediocre and outstanding system performance depends as much on the user as it does on the system. The average LIS offers literally thousands of capabilities and hardware performance in modern computers is phenomenal so system functionality is not often a major issue. The limiting factor today is how much time and money the client is willing to commit to training, management, set-up and testing of new functions and user-group participation.
If a significant amount of effort is not expended in these areas many benefits will be lost. A cost analysis must take this into consideration by either lowering benefit expectations or raising costs of training, testing and other user controlled factors.
Evaluating the corporate strength of bidders is part of any thorough investigation. While this is understood to be important in determining the ranking of proposals, the relationship of vendor strength to justification is less obvious. There are really two issues to consider; one is the stability of each company; the second is the each company's long term commitment to the market. Over the years countless strong companies have abandoned the LIS market. Financial resources are a necessary but not sufficient condition for success in this difficult field.
After all is said and done, and a leading vendor is assumed to be financial strong and (apparently) committed to the market, one more step is required. A thorough evaluation would consider the possibility that support for the product might be unavailable after it is installed. It is easy to plan for the best case - when the supplier has unwavering enthusiasm for the duration of the contract. When support is no longer forthcoming it makes no difference that it was an unlikely outcome. Management that does not plan for such contingencies is burying its collective head in the sand.
In the simplest case if two vendors are considered equal, the potential problems if each abandons the system or market might be the deciding factor. Any number of issues might be involved including the number of sites - a third party would be more willing to take over a large client base; standardization of the product - an organized user group could find support for a standard system; languages and hardware involved - certain combinations would be easier for a user to support without company backing.
This train of thinking leads naturally to justification since self-support and other costs of an abandoned product are potential expenditures. While it may be difficult to quantify such costs directly, it should be possible to decide that one system is more justified than another based on the above factors which would increase either the likely hood of abandonment or the costs associated with such an action.
The question of when and how to justify a computer system plagues every organization. One cause of this difficulty is that justification is seen as a "one shot" process with a straight forward yes or no answer. Many people simply want to know whether a computer system can be justified and they would like to know the answer before they waste money evaluating systems.
A "preliminary justification"
has the benefit of being honest.
The problem is that much of the information needed to do a thorough justification is not available until a significant portion of the evaluation is complete. This can be seen when the "justification question" is rephrased in a more meaningful fashion.
"Is it in the best interest of the organization to invest this amount of money on this product at this time?"
It is obvious from such a statement that a detailed justification cannot be accomplished before proposals are received; that's when system costs will be known. Justification at the outset of a project should be stated differently
"Based on our limited knowledge of the subject matter does the likelihood we can eventually justify a computer appear high enough to warrant researching the subject matter in depth?"
While it would be nice to completely justify a purchase before doing any work, this is an unrealistic goal. The best an organization can do at the beginning is to justify spending resources on an investigation.
This might appear to be a half-hearted approach since there is no guarantee a system will be purchased even after the research is done. It is, however, no more half-hearted than discovering at the conclusion of the evaluation that the original "justification" was faulty and no system is installed as a consequence.
A "preliminary justification" has the benefit of being honest. Administration and management of an organization should respect the following statement. "We won't know whether or not we will be able to afford a system until we learn more about the capabilities and costs of the available products. We do, however, believe the prospects are good enough that we should investigate the possibilities in more detail."
Once a vendor has been selected, a detailed cost-benefit analysis can be performed. All of the information including exact system costs and complete descriptions of capability are available. In addition, the experience of other users - in terms of installation and operational costs - can be factored in to provide an accurate life cycle projection.
If it is necessary to perform a detailed analysis before all the facts are in, the same model can be used. Unknown items will have to be estimated and comments included about the potential for revised values to impact the final result. Sensitivity analysis is often used to determine whether a variable does or does not materially affect the outcome so the necessity of added effort to "pin down" the value can be assessed.
The stages of justification are shown in Figure 1.
Figure 1. JUSTIFICATION STAGES
The results of a detailed mathematical analysis of costs and benefits sometimes result in a definite finding that a computer would pay for itself in a given number of years. This is often the case when the assumptions tend to favor that result. The amount of time nursing will save and the recovery of those savings are often exaggerated. Costs - particularly those associated with ongoing activities such as training, upgrades, etc. - are frequently understated.
It is important to document
assumptions explicitly.
A good analysis would show a range of outcomes with the understanding that the actual result will be somewhere in the middle and will depend greatly on how the implementation and operation are managed. Just because a favorable outcome is predicted does not guarantee it will come to pass.
The only way to perform such an analysis is to use "What If" functions of a spreadsheet such as Excel or Lotus 1-2-3. While it is beyond the scope of this article to describe such a model in detail, the general structure is as follows.
It is important to document assumptions explicitly so they are not buried in the spreadsheet formulas. The following list might serve as a starting point.
Figure 2. Justification Variables
CURRENT LAB STAFFING
ASSUMED VALUES
IDENTIFIED POTENTIAL SAVINGS
OTHER POTENTIAL SAVINGS
These factors would be estimated or quantified by detailed time studies. They would be recorded in dollars or hours per month. A spreadsheet would be used to extend the results over the estimated lifetime of the system. Since many laboratory computer systems operate for ten years and few are replaced in five, it is safe to use a seven year projection.
A major mistake is made by assuming
that all identified savings will be recovered.
While many of the factors are straightforward, a number of them (indicated by values in parentheses) deserve comment.
(1) Factors such as this "Growth Multiplier" can be used to simplify the analysis and allow a parametric analysis of the effect of growth on the results. If workload is projected go grow by the percentage indicated on the line above this one, how would such growth be reflected in lab staffing with or without the installation of the proposed system. Too often projections assume that critical factors such as staffing will not change in the future if a computer is not installed. This is not realistic for a variety of reasons. It is also not safe to assume that a given percentage increase in workload would be matched by the same percentage increase in staffing - although this is not an unreasonable assumption all other factors remaining constant. This "Growth Multiplier" can be used to indicate that staff growth is a specific fraction of workload growth to project staffing costs.
(2) A major mistake is made by assuming that all identified savings will be recovered. While this may be true for high volume operations where there is a great deal of flexibility in staffing, it is definitely not the case on a night shift, for example, where there is and always will be one employee.
(3) All of these items can be used in the model to selectively include or exclude factors so various combinations can be analyzed. If the results indicate, for example that the project is only justified if Medical Records savings are included, it is vital that such savings be accurately predicted and that a procedure put in place to make sure they are realized.
A model which uses these initial conditions can produce a variety of results. While numeric values will be useful, most are easier to understand in graphical form such they involve a series of numbers. For example, the following shows how costs and savings accumulate over an eight year period (one year for installation and seven years of utilization). Costs are greatest the year of purchase and there are upgrades which can be seen in the third and sixth year.
Figure 3.
It is important that staffing be analyzed carefully. The following chart compares current (manual) staffing with and without improvements that may be required to keep up with increasing regulatory demands with theoretical staffing in a computer environment and predicted savings when a variety of staffing issues are considered. All of these can be contrasted with the current staffing level. While the comparison here is between manual and computerized operations, a similar analysis could be performed with a current computer system compared to a proposed replacement.
Figure 4. 
If the data is well-organized it is possible to drill down to see how the results were obtained. The following chart shows the source of savings in one particular case.
Figure 5. 
Sensitivity analyses are in important part of projections where there are so many variables that are difficult to pin down. How will the project fare if test volume does not grow as predicted? The Net Present Value of savings are shown in the following chart where lab volume growth has been varied around the nominal case of 5%.
Figure 6. 
It is critical that system selection and cost-justification activities be planned carefully. In particular justification is very complex for systems that cost hundreds of thousands of dollars and affect individuals and departments throughout an organization. The consequences of a casual approach include purchasing a product that is not justified as well as not installing an appropriate system due to inadequate justification. Other ramifications include inadequate resources to fully utilize a system based on personnel and upgrade costs that are overlooked and consequently not planned for the lifetime of the system.
