Hospital information systems form a cornerstone of modern hospital care. Developers of such mission-critical systems place special emphasis on maintaining the reliability of the system, as well on as avoiding misinformation that could result in patient harm and on avoiding ergonomic design flaws that make the system difficult or even dangerous to use.
It is the latter aspects of clinical information system design about which I write. Specifically, I would like to share with this journal’s readership some observations about user interface design based on my experiences as a user of clinical information systems and computer-based medical devices over the last decade.

PREVENTING BAD DATA ENTRY

The main clinical information system at the hospital where I work, a system sometimes cynically described as “the best of 1970’s mainframe technology,” allows the user to enter entirely unreasonable patient parameters, such as a height of five inches with a weight of 200 kilograms, or even a heart rate of zero. When I complained to the appropriate hospital authorities about this, I was told that it was the user’s responsibility to ensure that the data was entered correctly, as the software could not easily be modified to put range checks on all entered data.

A related problem is that the computer expects that entered patient weight be entered in kilograms, but frequently the patients tell the nurse their weight in pounds (they are not actually weighed in many cases), and this numeric value is then sometimes entered in the weight field without the necessary “LB” modifier. I suggested that a “weight-to-height” ratio might be used as a simple indicator of how reasonable the entered data was (with a user warning for strange ratios), but this suggestion was dismissed as being impractical given the awkward, outdated software technology that the programmers were forced to use, and given the many other demands made on their time as hospital budgets are cut to the bone.

Perhaps this attitude would change if a 100 pound patient died from an 2.2 times overdose of a toxic drug based on an assumed weight of 100 kilograms. Could it happen? Of course, especially if one were busy and did not actually cast eyes on the patient to note the obvious discrepancy between the weight entered in the patient’s chart and one’s visual impression.

Indeed, several years ago (at another hospital) a patient died when a miscalculation resulted in the administration of a lethal dose of a toxic anti-cancer drug. The newspaper account noted that the software involved had been subsequently modified to disallow any dosages above a particular ceiling.

SELECTION MENU DESIGN ISSUES

One complaint voiced to me by my colleagues was that the system user menu presented to them varied depending on what part of the hospital they were working in. For example, the menu selection presented when they log onto the system is not the same in the Intensive Care Unit as it is in the Recovery Room. The intent is apparently to have a menu optimized for the clinical needs of each area, but, of course, this necessitates that the clinician to be familiar with more than one user interface, obviously not ideal from an ergonomic viewpoint.

A better concept might be for each clinician to have a single interface tuned (optimized) to that clinician’s particular practice, thereby standardizing the excursion route through a complex menu structure.

EXAMPLE: ORDERING X-RAYS

Although one of the alleged advantages of a computer-based physician order system is to reduce physician workload, it soon became apparent with our system that this is not always the case. For example, after heart surgery, patients are admitted to our Intensive Care Unit (ICU), where the clinical routine often requires a daily chest X-ray for three successive days. For years, getting this done was as simple as writing the following order on the patient’s ICU order sheet: “Portable CXR daily x 3”.

When we first switched to the computer-based order system this simple order for a while required the physician to enter something akin to following FOR EACH X-ray required:

• select “laboratory tests menu”

• select “radiological investigations menu”

• select “portable chest X-ray”

• schedule event

From this perspective it should come as no surprise that at one Canadian teaching hospital the resident physicians (who write most of the patient care orders) threatened to go on strike when they realized how much time was required to enter routine patient orders in comparison to the old method of writing orders by hand.

REQUESTING SELECTED FONT CHANGES

In another dealing with our hospital computing authorities, I requested that the patient synopsis paper printout provide a bold font for the allergy field, so that clinicians could more readily determine if there were any medications that should be avoided. I was told that the hospital’s policy was to de-emphasize the paper record in favor of the use of computer video displays, and as such my request could not be given priority status (translation: the paper record is not important enough!) This, of course, is completely at variance with the way many clinicians prefer to operate (including computer literate physicians such as myself), but apparently such practical issues are not worthy of their attention. (Perhaps the root problem was that no one actually knew the necessary escape code sequences to change the printer fonts!) A likely factor in all this, I am told, is the fact that any such system changes involve a complex series of work orders, and approval steps (some made outside of the country!) that makes even the most trivial code changes represent a potentially formidable task.

EXAMPLE: LIVER TRANSPLANT CASE

Once I was setting up to administer an anesthetic to a very sick patient admitted for an emergency liver transplant. When it was clear that the donor liver was surgically acceptable, the patient was transferred over via tunnel from the Intensive Care Unit of her hospital directly to our Operating Room.

The anaesthetic induction went well, but the degree of surgical bleeding soon demanded that I transfuse blood. When I called our hospital blood bank for the blood, I was told that because the patient had been transferred directly to the Operating Room, she had not yet been registered in the hospital computer, and without that step being completed, it was essentially impossible to issue any blood, as the process was more or less fully automated. We avoided catastrophe only when one of the doctors from the original hospital remembered that a number of blood units were available in the other hospital’s blood bank, and immediately ran over personally to fetch them. (Fortunately, she was still registered as a patient at the first hospital or a similar problem might have been encountered at the other end!)

DEATH BY DEFAULT

Although poor interface design is usually more of an inconvenience than a hazard, there are, regrettably, numerous cases where deaths have been attributed to exactly that. In 1997, the ECRI problem reporting system documented 3 deaths that occurred while patients were connected to the Lifecare 4100 Patient Controlled Analgesia machine. In at least 2 of the cases, the alleged reasons for the deaths were the same. When nurses program the drug concentration, the Lifecare 4100 display shows a particular concentration value (e.g., 0.1 mg/mL). Nurses can either accept this initially displayed value or they can modify it using the arrow controls that are available. The safety-critical flaw in the design is that the Lifecare 4100 offers the minimum drug concentration as the initial choice in some software releases of their machine. If nurses mistakenly accept the initially displayed (or default) minimum value (e.g., 0.1 mg/mL) instead of changing it to the correct (and higher) value (e.g., 1.0 mg/mL), then the machine will “think” that the drug is less concentrated than it really is. As a result, it will pump more liquid, and thus more narcotic, into the patient than is desired. [Visit http://canmed.net/Lifecarefor a detailed account of this problem.]

CONCLUSION

I bring these issues to the attention of the hospital administration community to emphasize clinical computer system vulnerabilities from a user’s perspective. Fortunately, some of the problems I have identified have been partially remedied. Nevertheless, I encourage hospitals and clinics in the planning stages of acquiring a clinical information system to ask both information technology experts, as well as ordinary users at other sites, about the strengths and limitations of the proposed system to avoid the unfortunate problems I describe.

This editorial is not meant to blame the hospital information service workers, who often have merely inherited an unmanageable system. My experience is that they are knowledgeable and hardworking people trying to make the best of an unfortunate situation. Nevertheless, I think that most readers will agree with me that some existing systems may have undesirable limitations that could even adversely affect patient care.