I recently went to see my physician for my annual physical. I have never seen him for a physical as I had switched physicians for other reasons about six months ago. But I had seen him a few times for acute care; sinus infections and what not. Overall I was pleased with my visit, and it went as well as could be expected. He came into the room with a small notebook computer, verified the information the nurse had entered into my electronic chart, and then began the examination, chatting away with me the entire time. After he took my BP, he stopped the exam to enter it into the computer. After he examined by ears/nose/throat he did the same. After he listened to my breathing and heart, he did the same. It did not bother me that he stopped to do this. Maybe because I am a member of the generation that is very comfortable with technology, and maybe because I recognize that one can enter things into a digital device and still be listening to what is going on around them. However, when my physician turned the screen to me to go over lab results, I have to admit I was both shocked and a bit worried with what I saw. The GUI (Graphical User Interface) was very confusing, the screen loaded with fields for entry. It took the physician several clicks to access the data he was looking for, and even though he did it quickly (because he was obviously familiar with the system), to me the data seemed to be “buried”. While the software education specialist side of my brain marveled over what a nightmare a system like that would be to teach to a new and unfamiliar user, the HITECH side of my brain mentally cataloged the usability of the system, its design and the capacity for errors related to its design. I have to admit the score was not a good one; it was definitely not the most user friendly system and I could see the changes in workflow from just my few visits in the last few years.
My mother, on the other hand, is a charge nurse and shift lead at a Critical Access Hospital (CAH) back home in Michigan. They recently switched over to an EMR system in time to meet Meaningful Use Stage I criteria. At the time of the change, our phone calls were often spent with her complaining about how the system worked or didn’t work, how the training was not the best, how the one IT employee was running himself ragged preparing for the change with almost no help from the vendor, etc. I heard the same fear from her that I often hear from new customers my company brings on before and during a conversion. I counseled patience, saying that transitions are generally bumpy and stressful, but that after a while they generally work out for the best.
Now that my mother’s hospital has been on and EMR system for some time, her complaints have changed. She now readily admits that the technology has made certain parts of her job easier, but she laments that it has complicated others. These complaints relate to the usability of their current system. “For example,” she said during one conversation, “Our program lists five different methods for taking a person’s temperature. When we enter the temperature in the field, we have to use a drop-down to indicate how the temperature was taken. At our facility we only use three methods…we don’t even have the equipment to use one of them! But we cannot remove these other two methods from the drop-down, and it has caused us headaches when someone accidentally chooses one of them or takes us additional time to select the method. Why can’t we remove the options we don’t use?” I understand her concern, and told her that there should be a parameter level settings somewhere where they could remove those methods, or they could ask their vendor to customize the field to remove them, but since I wasn’t familiar with either her EMR or her Vendor I wouldn’t be able to know for sure. There should be a way for this simple task to be accomplished, but depending on the Vendor and the specific program I would not be surprised if it were not possible.
These are examples of a newly emerging concept in Health IT Design…usability. Usability roughly can be defined as the ease with which a technology can be used, and the study of how different technology designs can either contribute to or prevent errors. In healthcare, this is a big deal because errors can have very serious negative consequences for the patient. While the idea that the GUI of a CDSS (Clinical Decision Support System) or a CPOE (Clinical Physician Order Entry) system may be a factor in medical errors is relatively new, it seems fairly common sense. If you design a system that is complex to its human users, you increase the likelihood of error.
An Op-Ed piece from The New York Times by Robert Wachter illustrates this point, and explains how poor usability in software systems has not only stifled progress towards improving patient care, but it has even had the affect of forcing some physicians (admittedly the “Sky is Falling!” bunch) to want to ditch using technology altogether and run back into the safety of using binders, paper and physical files. Why Health Care Tech Is Still So Bad catalogs things from alarm fatigue leading to AHE (Adverse Health Events) in patients when hospital staff become numb to the incessant alerts which often turn out to be false alarms to negative effects on workflow and on patient satisfaction as their doctors stumble their way from office visit to office visit with their eyes glued to a computer.
All of these problems are real, and since I work in the software field I see examples of these what I like to call usability fails on a regular basis. I have seen the frustration that it causes the end users of the system, who invariably find “work arounds” so that they can interact with the system as little as possible. I have seen the fear as users contemplate moving to a new system, because while they may hate their current system, at least they know its quirks; to borrow an old adage “Better the enemy you know than the enemy you don’t.” I have seen the massive workflow disruption that occurs when technology becomes more of a hindrance than a help due to poor design. In all of these cases, efficiency will not be gained. and your mission will not be improved.
I also have a theory on some of the cause behind these poorly-designed systems from the end-user perspective. The end-users are not the ones designing the system. The system is designed primarily by programmers, who have a very different point of view. Because they working with enormous databases and tables and any manner of things that would make a normal person’s head swim in order to create a software system that functions, they are making logical connections between what they need to connect so that the program will execute quickly and correctly. In other words, they are thinking like a computer. Now don’t get me wrong, I have enormous respect and admiration for programmers. Without them our world couldn’t function! But because they are coming from this different point of view, it makes it very hard on end-users, who are not programmers and don’t think like a computer. The inevitable result is frustration, disrupted workflows and poor use the system which can result in errors, or in the case of CDSS or CPOE’s, can even result in death for patients who are the victims of these errors.
Dr. Wachter points out that usability needs to be improved for these systems so that health care technology can truly deliver on its promises of increased efficiencies and better patient care. After all, he says, the airline industry does it; cockpit computer system are designed and then go through hundreds of hours of testing with actual pilots to make sure that the design of the system will not increase errors…errors which could have catastrophic consequences. He likens it to a car whose wheels are spinning, but finally find traction to get going. Many vendors are also starting to realize that there is more to designing a system than making sure it functions…it needs to function in a way that end users will be able to use easily and safely. In the mean time, it is up to users to band together to make their voices heard, and to vendors to listen to those calls for change from the users and the academic community. Trainers and workflow specialists can do what we can to help improve the system as it currently exists, but efforts need to be made on both sides to allow our wheels to finally find the traction to get going.