Return to Braley Consulting Services, Inc. Home Page
In the modern fast-paced world where sound bites replace detailed discussion, time
is measured in nanoseconds and "the simpler the better" is a common standard,
pitfalls are often encountered due to oversimplification of complex tasks. The selection
and implementation of medical information systems is no exception. This article will
review often heard statements that contain a grain of truth but are often misleading
in their simplicity.
A good contract is an important part of any system procurement. However, with the current emphasis on legal problems and protecting the user, contracts are often emphasized to the determent of other important issues. A good contract is not the primary point in selecting a system. A contract should be the culmination of a series of steps which produce a good understanding of the agreement between the buyer and the seller. If the user has carefully evaluated available products and understands what the selected system will and will not do, and if the vendor has a thorough knowledge of the buyers needs and technical requirements, a contract serves primarily to formalize these understandings.
The major mistake in this regard is to assume that a good contract can compensate for misunderstandings and lack of knowledge on the part of both parties. Contract items that are carefully spelled out are seldom the subject of controversy. Disputes most often arise about what "we thought they meant". Since a contract is usually negotiated by attorneys, vice presidents, information systems managers and consultants, negotiation is a poor time to develop the detailed understanding of the technical issues that can only be handled by the end users.
While protection in case something goes wrong is a worthwhile objective of performance and penalty clauses, most of the emphasis in the contract should be on making things go right. Too often this is not the case.
The end result of any system is some type of output for the users. It might be a cumulative report of patient results or statistical documents summarizing the operation of a department. Concentrating primarily on outputs, however, has resulted in many installations where data collection and day-to-day operations of a department have been severely compromised because the only objective was to generate a report for physicians or administrators. While the ultimate goal is a final report, the only way to meet that goal effectively is to run an efficient department which is capable of producing accurate, timely reports. Operating a paper system and entering all information at the last minute for the purpose of producing a readable report generally slows the reporting cycle and increases both the effort involved and the possibility of error.
A variation of this statement is true - COMPUTER PROJECTS ARE GENERALLY NOT COMPLETED ON SCHEDULE. They can, however, be accomplished on time but only if the projected schedule is realistic. The administration of one hospital demanded that the selection and implementation of a major system be completed in four months. Such an effort could never be completed in such a short time frame. So, of course, that computer project will miss its scheduled implementation. The problem, however, was with an unrealistic schedule based on what someone wanted to happen.
Scheduling should be done by describing the activities that need to be accomplished, estimating the time and resources required and allowing for contingencies that may arise. As logical as this approach may sound it is often executed poorly for two reasons - buyers are not aware of a structured methodology for decision making so thorough planning is impossible and no one likes to think a project will take one to two years to complete.
No schedule should be based on everything going right. It never does. How anyone - vendor or user - can use the Christmas holidays as an excuse for being late is a mystery. Were they really surprised by the fact that Christmas occurred on December 25th? Why weren't the problems of this very predictable event planned into the schedule?
While most hospitals have some long range planning activity and often hire consultants or produce reports to formalize this work, the results are frequently disappointing. The end product is severely constrained by lack of understanding about the real information system needs of the institution and by inadequate resources to do the planning. A corollary to this myth is that the Information Systems Steering Committee doesn't really have much to do and can meet on a rather casual basis. Many IS Committee members can not summarize the long range plans for the institution although they may remember that a detailed report was prepared in the last year or so. Most IS Committees do not have a structured agenda with specific assignments and a strong connection with individual projects that are undertaken. Is it any wonder that confusion about the benefits of individual systems is common and the relationship among the various components causes unending controversy.
The truth is technology by itself rarely solves problems and implementation of the latest technology invariably takes years longer than most people predict. Barcodes, voice and handwriting recognition, optical disk storage, bedside information systems - these are all examples of the next revolution in computer systems. While barcodes are prominent in selected applications, well-developed integrated systems are only now becoming a reality. This, in spite of the fact that a prototype bar code system was installed in a community hospital 15 years ago with the capability to eliminate all paper work from the collection of laboratory specimens through the testing and reporting of results - and barcoding is a relatively simple technology compared to voice or handwriting recognition. Technology forecasts serve one purpose - they indicate what may be possible in the future. The major drawback is that they do not consider the problems individuals and institutions have in converting to new systems. The barriers to change are enormous. Existence of older systems, limited budgets, psychological resistance and numerous other factors constrain the pace of change. Realistic planning can only be accomplished when the human factors and other aspects of the institution are combined with technical considerations.
As with most myths, there is kernel of truth to this assertion. High level involvement is critical but the decision on a major information system should be a joint effort involving a team of users, managers and executives who reach a consensus on the best system for the institution. With most paper systems and some departmental computers, such a consensus is never reached. Statements such as "it's a great laboratory system but the nurses hate the reports" provide insight into the problem. The definition of the "best" system was made by only one unit in the organization - in this case the laboratory - when, in fact, the system would affect individuals throughout the facility who should have been part of the selection team. At the heart of the evaluation process, is the need to define what is "best" for the institution considering all components that will participate in the change over to the new system.
It is true that a Request for Proposals, per se, is not required. However, a good understanding of the needs of the institution and capabilities of proposed systems is mandatory. A well-written RFP can be the basis for such an understanding. An RFP supplies information to the vendors about the client and requests information from the vendors in a structured form for evaluation and later inclusion into the contract.
A Request for Proposals often gets confused with the concept of a "system specification" which served an entirely different purpose for many years. A specification generally provides elaborate details about how a system should be designed. Such a document is an absolute necessity when new software is written. Since large numbers of medical systems are now marketed as turn-key products - where the software is already developed - a great deal of effort spent describing what the user would like a system to do is a waste of time. A more constructive format for the RFP is a questionnaire where the user can ask questions about existing capabilities. If a system has certain features, the user needs to find out what those features are - not waste time describing capabilities that the vendor does not offer. The idea that a user, with minimal experience and precious little time to devote to the effort, can describe an ideal computer system is unrealistic.
System selection is becoming more difficult as the complexity of software and hardware
increases and the penalties for failure grow larger. A user with limited experience
and time pressures on all sides must resist the temptation to seek simple solutions.
The benefit of new systems is being demonstrated in hospitals across the country.
Caution, however, is still the key word and thorough evaluations based on reasonable
expectations will yield the only consistently good results.