By David Do, MD
In Shirie Leng’s excellent post, “The Email I Want to Send To Our Tech Guys But Keep Deleting“, Dr. Leng lists a series of problem areas which plague software development in healthcare. Making things better requires taking a closer look at the specs we use. The new-age consumer-focused software companies can build products with outstanding usability because they start and end with the specs.
I have spent time at several academic medical institutions, and their software solutions are very much the same. At one, I was given this five-page table of portals and documentation systems with instructions on how to log in.
The punchline: I'm asked to have a different username and password for each of them.
I give much credit to the physicians who navigate these software applications, including the one that compiled the list I showed above. But physicians have allowed poor design of their technological solutions for too long, and have neglected to demand interoperability from software vendors.
The number of required training hours is a good indicator of usability. (And many of the items on the list come with long training hours.) While physicians have accepted these courses as part of their jobs for years, why should formal training be necessary to operate an EMR? Most of the tasks of ordering and documentation are no more complicated than paying your credit card bill or shopping online.
I'll only scratch the surface of this usability problem by highlighting several notably poor implementations. I won't even get into the inefficiencies in ordering and documentation.
My first example is an EMR system that is used to order medications and communicate data with nurses [below]. At a glance, there are no fewer than seven distinct menus on the screen at the same time. In my experience using this EMR, I've clicked ten percent of these buttons (and I would estimate that 90% of the work occurs in 5% of the buttons). The poor organization of information leads to lengthy searches for the right information, and often, the unawareness of critical information that is hiding under a nondescript label.
Lesson: Menus should have clear hierarchy.
My second example is a shift-scheduling application [below]. Here is an example of of how applications can invent interfaces rather than using the ones familiar to us. The primary menu is on the left-hand side. Upon clicking on one of these options, the secondary menu is displayed right below the header. The tertiary menu, however, goes back to the left-hand side. The issue here is a lack of consistency and predictability.
Lesson: The user's next step should be salient contain a reasonable number of options (between two and five).
In today's hospitals, with so many concurrent information systems, some have devoted resources to "hacking" the systems to mine data and present it in one, coherent, application. Initially, I applauded these efforts, for building a tool around user needs, despite the difficulties of lack of interoperability and APIs in the systems they have paid millions for.
These homegrown solutions, however, can fail without good guidance from clinicians. The third example involves one such homegrown aggregator of content. After selecting a patient using the application, the user arrives at a menu that organizes data by department [below].
Where would I find a full-body CT, or echocardiogram, or rheumatology consult? I can think of a handful of categorizations that make more sense, including organ system or type of encounter. The issue here is that there is no way to gain a comprehensive understanding of a patient without clicking on thirteen categories and reading all the information, when in reality, a physician-to-physician handoff requires that information to be conveyed in less than five minutes.
Lesson: Organization of information needs to be built to facilitate the fastest understanding of the patient possible, not by departmental boundaries or other historical or political distinctions.
Luckily, the click of an "info" button clarifies everything [below], as my patient waits for me in the next room.
I have only touched on some of the organizational problems of these systems. There are separate portals for medical education videos, procedure logging, evaluation, and incident reporting that have their own issues. These are some of the technological barriers that make work in the hospital far from frictionless.
Information technology within the confines of medicine remains in the dark ages. Hospital information officers boasting 20 years of experience are, in effect, dinosaurs. That's because the past ten years has seen tremendous innovations in usability, design, and security. Medicine needs the agile developers, the designers, and user testers.
Before the software revolution can hit medicine, we providers need to speak the language of the software developers in order to be good consumers of technology.
Physicians, repeat after me: Menus should have a clear hierarchy, the interface should be predictable, data should be organized how I think about the patient, and I do not need a training certificate to use a software program.
David Do, MD is a graduate of The Johns Hopkins University School of Medicine and a resident physician at the Hospital of the University of Pennsylvania. He is an agile software developer and Chief Technology Officer at Symcat.com.
No comments:
Post a Comment