Interfacing Departmental Systems
To the HIS

a look at the big picture

Everyone knows what is desired from an interface between a departmental computer — e.g. a laboratory or radiology system — and the hospital or clinic information system (HIS/CIS):

• The department wants to reduce phone calls
  
  
• Physicians want faster access to results
  
  
• Administration wants a more efficient/productive operation
  
  
• Nursing wants current and past results available for the medical staff
  
  
• Finance wants a faster, more accurate charging system
  
  
• Information Systems wants a total interface to existing data processing systems
  
  
• Everyone wants to get rid of all that paper

While the above goals for a departmental computer are frequently stated and certainly appear to be reasonable, there are many problems that surface when implementation of a new system is actually undertaken. This does not mean the system is not worthwhile. It does mean that unless these expectations are discussed thoroughly at the outset, there is a potential for major disappointment with a new system since many of the goals, as stated, may not be met. Certainly, they will not be met without very careful planning. They don’t just happen.

If they did, why would many users complain that phone calls did not decrease when a computer was installed; that they have more paper now than they did before; that turn-around time is no better than with the manual system and sometimes worse; and, the bane of administration, that staffing has actually increased!

This article will address the particularly troublesome area of interfacing -— not in terms of computer technology but in terms of functionality users expect such interfaces to provide. Since interfacing is thought of as a "computer problem", it is often turned over to the Information Systems staff. Without an initial and thorough consideration of desired functionality, however, a system runs the risk of being declared operational by programmers and a total failure by users.

While interfacing generally involves several functions including billing, demographic data, order entry and results reporting, this discussion will focus primarily on the last item. It is in the area of reporting to nursing personal and the medical staff where serious problems emerge. Issues we will address include phone call reduction, elimination of paper, interface specifications and the choice between integrated and best-of-breed systems.

TELEPHONE CALLS

Phone calls, no one likes them but they continue even when a computer has been installed which should drastically reduce the need for them. Several factors come into play. First, even though they are a nuisance, phone calls are old and comfortable. "It’s the way we’ve always done it." Computer reports, no matter how well-designed and prompt may be new and foreign to the medical staff and nursing personnel. It is always easier to continue with the old rather than to change to the new. There must be strong motivation to change.

Of course many users are past the stage of considering computer reports as "new" or "novel". But even organizations with many years of experience may not have learned their lessons well and run the risk of serious problems with a second or third generation system. The comments here are intended to help organizations installing a new system but also to help current users better utilize existing system by understanding what some of the problems are.

More subtle, but more important than breaking the barriers of habit, is the fact that phone calls are more productive than they were before a computer was installed since the person answering the phone can find out about any procedure in the department, complete or incomplete, in less than a minute. Now phone calls yield a better outcome for the caller, more information more quickly, and they are not nearly the nuisance for the department called, Transferring the caller to a different location is not necessary and the data can be called up quickly on a terminal. The bad news is that phone calls may not be reduced because they are more productive for the caller but the good news is they are much easier to accommodate on the part of the department.

Is it likely under this scenario, that phone calls will decrease. Probably not if they are more productive for the caller and less of a problem for the recipient. Under these circumstances, the system may not meet the expectation of reduced phone calls, but would meet the more important expectation of less time wasted on phone calls — for parties on both ends of the line. To go farther than this, to actually reduce the number of calls requires an understanding by nursing and the medical staff of the reasons to call — primarily in emergencies when results are not yet available in printed reports or through inquiry screens. It also requires a good understanding of how to use the paper and computer inquiry reporting systems so they become as "natural" as the telephone.

A related issue concerns the number and location of remote inquiry devices, either HIS or departmental terminals. If a certain service generates a number of phone calls to the department, and these are a nuisance because of the time they require, it is easy to assume that the service in question needs an inquiry terminal. Before such a decision is reached, the amount of time to answer an inquiry, with a departmental system in place, should be calculated so the cost benefit determination for the terminal will be performed in light of the new environment, not the old. This is a classic problem associated with major system changes whether it involves the first installation of a computer system or replacement or significant upgrade of an existing system.

A great deal of time and money is invested to solve problems that will not exist in the new environment. One of the best know examples of this is the requirement for computers to generate department or workstation "logs". Logs were used in manual systems so that information about tests in progress could be retrieved at a variety of different locations. A computer provides precisely that capability so logs can be eliminated. Selecting a new system, then, becomes more than just buying a good computer from a reliable supplier. Users must develop a vision of how the modernized department will function so needs can be assessed in terms of the new environment.

PAPER REDUCTION

What about the paper? "Won’t it be great when we can get rid of it all!" Even the pessimists believe the quantity of paper will be greatly reduced by virtue of installing a new computer system. Why doesn’t this happen? First, people still prefer to read from paper when more than a few numbers or words are involved. A well designed report in the reader’s hand cannot be surpassed with reasonable cost using current computer terminals. In fact the goal of many new display technologies is to produce an image of the data that is as close to the appearance of a piece of paper as possible, e.g. full page screens with black on white lettering.

Of course, the computer shines by making data available in a variety of forms at numerous locations on demand. All computer commercials show the recall of text, numbers and graphics, usually in vivid color, with the touch of a few keystrokes. Why is it then that in hospitals and clinics across the country, most physicians still rely on printed reports even though departments such as the laboratory have been automated and often interfaced to a Hospital Information System for many years. As in the case of the telephone, they are used to the paper and it’s not easy to change unless the reasons are overwhelming.

What is a common complaint with computer reporting systems? The reports are not color coded like the old slips. In other words it’s different and in that one respect it is not as good. The advantages of better formatting of sequential reports, potential for graphic output, ability to reprint pages, simplified charting procedures and computer printed versus hand written results can be negated by the one noticeable disadvantage of the old system — "the one we were used to." It’s amazing how much better any system appears to work, in spite of all the past complaints, at precisely the time a replacement is installed!

physicians will not accept
poor response time

As with continued telephone calls, there are incentives to keep on producing paper. Computer paper is inexpensive, compared to multi-part forms, and reports can be generated at the rate of a thousand lines per minute or more on common high speed printers with the entry of one or two commands. Combine the twin fears that the system will be down when results are required and that data may be lost from the computer memory, with the desire of most users to have something to carry around and the motivation to continue printing is overwhelming.

Before any organization embarks on a new system project believing that direct reporting to the physicians through floor terminals will eliminate lost and delayed paper reports, they should examine carefully just how such a system might work. Without such an examination major flaws can develop which render the entire concept useless. In one hospital physicians were encouraged to use floor terminals to inquire about lab results only to discover that response time was prohibitively slow — due in large part to their frequent use of the system!

In another case, a committee of the medical staff voted to use only terminals for reporting from the new departmental system. They did this with no guarantee from the companies that the reporting system would work and that response times would be acceptable. This was also done without a thorough analysis of the nursing station workflow to determine the availability of terminals for this new use by the medical staff. This group of physicians might have been forward thinking and excited about working out the bugs in this new technology. What about the ninety percent of the medical staff that did not participate in this committee? It is possible they did not participate precisely because they were not as excited about the new technology. It is very likely, had this plan been implemented, that the results would have been similar to the example discussed previously — i.e. response times so slow as to make the system unacceptable to the medical staff as well as the nurses who had been using the system in the past.

Response time in most hospital information systems is, to say the least, underwhelming. Nurses and ward clerks are often forced to accept poor response but physicians will not. Several questions need to be answered before direct reporting through floor terminals is recommended to the medical staff. Do they consider it usable in terms of content, format and keyboard entry required? Are there adequate terminals available at both the time and place desired by the staff? Is reliability of the total system sufficiently high so that complaints about downtime will not counteract the positive aspects of the system?

While not strictly a reporting issue, order entry certainly contributes its share of paper and confusion to the process. The most important question to ask in this regard is whether the order entry process provides real assistance to the physician in selecting the best possible procedure or is it merely a transcription function which could be performed better by the clerical staff? There is a significant difference between the traditional billing oriented order entry function and a sophisticated "physician assistant" approach based on rapid access to patient history and artificial intelligence. The temptation to attempt direct physician ordering — because it just sounds like such a good idea — without a thorough analysis of such factors may lead to rejection of all or parts of the system by those it was intended to serve.

If reducing the number of pages of printed material is considered the final objective, many approaches would work and all of these have been tried: Use smaller print; Use larger paper; Provide less information; Provide information less often; Provide information to fewer people. What all of these meet the stated objective, they are unlikely to win favor with the medical staff.

The goal should be a well-designed reporting system which combines timely, organized, printed forms with terminal inquiry in an optimal system for the specific needs of each service. While the elimination, or indeed significant reduction of paper, may not be feasible, a system can meet the more appropriate expectation of making departmental results available in the most desirable form, paper or otherwise, for a variety of locations in an expedient manner.

INTERFACE SPECIFICATION

"We definitely need a complete interface." Many people will make that statement, and go so far as to include it in the contract for a new system, without being able to describe what the phrase means. If there is no precise understanding of what is meant by "complete interface" or "partial interface" or any other form of interface, what sense does it make to say that a certain supplier has four interfaces to a given hospital information system. It’s not appropriate to make definite statements about indefinite subjects. An individual hospital will say that their interface is complete if it does everything they want it to do which may include on-line order entry and reporting or may be limited to a billing tape hand carried to the mainframe once a day.

The single biggest problem with interfacing is a lack of understanding on the part of the users about what they will and will not get in the resulting product. Although there are attempts being made to standardize in this area, those standards are a long way from being generally accepted and implemented. The HL-7 standard, which is gaining wide spread acceptance, provides guidance in record content and field description for interface transactions. It does not tell the hospital staff how a system will be used. It is, therefore, only the beginning of a solution to the problem. If such a standard is agreed upon by the user and vendors involved, there is still a lot of work to do.

A major source of difficulty is the lack of involvement and input in early stages of interface development on the part of end users. They often see themselves as being incapable of understanding a subject when words such as ASCII code, baud rate, modem and protocol are the common terms of the trade. The key is to separate the user functional specification from the programming detailed technical specification. The users should be able to describe how they want the system to operate without using computer terms — least of all obscure ones such as ASCII and baud rate — and then present that specification to the development team. The major complaint of programming organizations is that "the users did not tell us what they wanted". Therefore, the implication is, the developers had to guess. They did not intentionally do it wrong. They did the best they could with limited input from the users.

HL-7 is the beginning
of a solution

The difficulty in developing a good functional specification is that someone with both a knowledge of the departmental application and computer technology must direct the effort. They must understand the application so they can relate to the end user and they must understand the technology so they can document the needs in a form that is acceptable to a programming staff. It is not easy to find someone with such capabilities.

BEST OF BREED VERSUS INTEGRATED SYSTEMS

The ongoing debate concerning the choice users face between the so-called "best of breed systems" selected from a variety of vendors and "integrated solutions" purchased from a single vendor is flawed from the outset. The argument is stated in terms that limits users to only two possible choices and in doing so leaves out the most logical and frequently implemented approach. As with most debates that focus on only the most extreme positions, this approach obscures more practical solutions. Users are lead to believe they must choose between a fragmented collection of difficult to interface systems and a one vendor solution with the possibility of at best uneven departmental capabilities.


A viable practical middle ground is readily apparent if the term ‘best of breed" is expanded to "best of breed for the institution". This slight change in wording opens up the possibility of selecting a laboratory system, for example, from a vendor other than the HIS supplier where the latter company has a system users inside or outside the lab find unacceptable.



This approach is difficult to execute in cases where decision making is carried out in an isolated department-by-department scenario. It is precisely this flawed selection methodology that forces organizations to think the lab can make a decision in the best interests of the lab or the I.S. department can make a decision based on total facility considerations but the groups cannot work together to balance those interests and select a laboratory system from a third party that can be interfaced in an acceptable manner.

The problem is compounded by vendor pressure on the department to buy the system most capable of meeting their needs and corresponding pressure from H.I.S. companies to sell total solutions to "the interfacing problem" — particularly where their clinical systems are weak. Few parties inside or outside the typical healthcare facility have an overall view of information systems including needs of users and problems of the I.S. Department. Unless these conflicting requirements are balanced through structured strategic planning and system selection efforts, there will always be "winners and losers" and the conflict the disappointments resulting from such an outcome.

CONCLUSION

In the case of both the telephone and the paper issues, the focus is too narrow, i.e. on changing one particular aspect of the current system, which appears to the user to be critical, when in fact the problem is much more broad and an overall analysis of reporting systems is in order.

In general, the best reporting system is not one approach but a combination of the best aspects of several different approaches combined in the most efficient fashion. The question is not "How should our computers communicate?" but rather "How should our organizations communicate?" A computer interface may turn out to be one important part of the answer — but only one part.

Good communication concerning information technology should start with system selection. If detailed meetings involving users and I.S. personnel only start after a system is installed, the organization is stuck with a system and can only try to solve problems with a great deal of finger pointing to explain "how we got here in the first place".

It follows then that a description of how interfaces should work, i.e. a functional specification, should start with documentation prepared by users entirely in user terms concerning the data that must be communicated between the organizations. The requirements for those data elements which will be handled by a direct connection between computer systems can then be translated into technical specifications by the programming personnel that are involved.

As has been proven over and over in many areas of our society, technology is not by itself the answer. However, the carefully controlled design, implementation and utilization of technology can go a long way toward meeting the needs of the modern health care facility.

THE END