Friday, April 15, 2005

Computerized Physician Order Entry Systems

Computerized Physician Order Entry (CPOE) systems are going to be increasingly common in hospitals. The average health consumer will generally be completely insulated from the issues these systems raise. I thought however that a brief discussion of some of them might be interesting.

Click here for complete post.
Computerized Physician Order Entry (CPOE) systems are going to be increasingly common in hospitals. The average health consumer will generally be completely insulated from the issues these systems raise. I thought however that a brief discussion of some of them might be interesting.

In most hospitals, physician orders are written on carbon copy sheets in the patient's chart. Such orders are then handled in different ways depending on the type of order. For example, an order for a laboratory blood draw will be entered directly into a computer by the unit secretary.

To do this, the secretary accesses a series of computer screens that enable him to enter the exact lab type, the desired time for the blood to be drawn and the urgency of the blood draw i.e. routine or stat (short for the latin word statim, immediately). The information is then transferred to the lab where a phlebotomist is assigned the job of drawing the blood at the right time and insuring that it is drawn into the right type of tube (depending on the particular study ordered).

This system generally works quite well if I'm ordering common tests such as a complete blood count (CBC) or a set of electrolytes (Chem 7). The secretary usually has no problem locating the proper code in the computer for these common studies.

But what happens if I'm ordering a less common test and the secretary can't find it on the computer list in front of him? For example, I might order what I call an ANA and the computer doesn't list such a study. The secretary might not know to look for something called an Anti-Nuclear Antibody. There might be many different names for the same test but only a few are listed in the computer. Or perhaps, the secretary can't read my handwriting clearly. What does the secretary do?

He has several choices. He can call the physician which might be time-consuming and difficult. Or he can ask whoever else might be working in the nursing station at that instant and get a group consensus of what the physician meant. Or he can simply guess. You may not think these last two possibilities would happen very much but you'd be surprised! Obviously, there are many opportunities for errors to occur.

The same type of procedure is generally used to order an imaging study such as an x-ray or an MRI. The problem of finding the correct name for the procedure can occur. In addition, it is also common practice to include the reason or indication for the study in the order . When a radiologist interprets the actual study, he'll benefit from some clinical information about why the study was ordered. Such information helps the radiologist provide the most informed evaluation.

For example, if I note in my order for a chest x-ray that I'm concerned about the pain my patient experiences when I push on the left side of the chest wall, the radiologist will look particularly closely in that region for any disease of the bones there. On the other hand, if I indicate that the patient has diminished breath sounds in the right, lower chest when I listen with my stethoscope, he'll look specifically for lung disease in that area.

Obviously he's responsible for reporting any abnormalities that he might find but interpreting imaging studies can be a very difficult business. Such clinical information can be invaluable in optimizing the final reading. Again, the secretary is charged with inputting this information with the order. When he doesn't interpret what the doctor wrote correctly, erroneous or misleading data is entered. Incorrect study interpretations are more likely.

If the physician is ordering a medication, a registered nurse is generally responsible for taking the order off the chart and either inputting it into the computer or FAXing it to the pharmacy. Clearly, many of the same errors of interpretation discussed above can occur and occasionally the consequences of such medication errors can be catastrophic.

Experts have examined the flow of information in such systems as outlined above and subjected these processes to what is commonly referred to as failure analysis. They look at each step of the process and identify those with the highest probability of failure. The idea is that maximal efficiency (and in the setting of patient care, safety) will be achieved by improving those high risk steps. As can be seen from the above discussion, the data entry step is one such high risk node in the process tree for labs, imaging studies and medication orders.

One possible intervention is direct physician order entry. Hospitals are increasingly looking to CPOE systems to increase efficiency and reduce errors thus improving patient care and particularly safety. The idea is that since physicians know exactly what it is they want to order, the likelihood of a "signal drop-off" is lower if they enter the order themselves. Information flow would be more efficient and medical errors less likely. Many different proprietary systems have been developed for this purpose.

Unfortunately, developing such an application is much more difficult than one might anticipate.

Ignoring issues of patient privacy, system security, errors introduced by hardware and software bugs and other problems (which can be daunting) creating an easy, highly usable system is extraordinarily difficult. Ask anyone who's ever yelled at or hit their computer because it didn't respond as anticipated.

If a secretary is entering labs and studies continuously throughout the day, usability issues, though important, are less so. They gradually, through experience, learn tricks for getting around computer program inefficiencies and learn its idiosycracies through constant use. Likewise nurses who are entering many medication orders into the computer throughout their shifts get particularly good at navigating such systems.


Physicians however would be expected to enter orders far less frequently than a dedicated unit secretary or a nurse entering computer orders for many patients throughout the day. Because of this, it would be rare for physicians to develop comparable facility with the same system. For this reason, a CPOE system has to be far more intuitive and usable to be acceptable.

Secondly, such a system would have to be very fast. Having physicians do data entry normally performed by secretaries and nurses constitutes a shift of labor to the physician. Such a demand on one's time is not reimbursable and therefore would be expected to lead to significant resistance unless it’s very quick.

CPOE systems rarely live up to their expectations however. Cedars-Sinai Medical Center in Los Angeles switched to a CPOE system and essentially had a revolt with doctors refusing to use it because it was so unwieldy. Such problems might have been avoided had the hospital's administration involved the doctors at an earlier stage in the transition but even then, the system was perceived as being very detrimental to patient care.

There is some evidence that errors may in fact go down with CPOE systems (in some studies as low as 81% fewer). What is surprising is that there is very little data to demonstrate that such systems actually improve patient outcomes. JAMA actually published a recent article suggesting that certain types of errors may be increased with CPOE systems.

Such errors seem to arise from poor usability issues i.e. separation of functions that facilitate multiple dosing of the same drug, inflexible ordering formats, etc.

Given that, according to many surveys, everybody seems to want greater use of automation and computers in medicine (administrators, nursing, office managers, insurers, hospital credentialing organizations and the lay public) it is obvious that this is a trend that will be exploding. It has even become a government mandate with the president specifically supporting it.

I think that eventually, the reality will begin to approach the promise. I don't think we're there though. The software still has a long way to go in my opinion.

0 Comments:

Post a Comment

<< Home