By Atul Gawande for The New Yorker
On a sunny afternoon in May, 2015, I joined a dozen other surgeons at a downtown Boston office building to begin sixteen hours of mandatory computer training. We sat in three rows, each of us parked behind a desktop computer. In one month, our daily routines would come to depend upon mastery of Epic, the new medical software system on the screens in front of us. The upgrade from our home-built software would cost the hospital system where we worked, Partners HealthCare, a staggering $1.6 billion, but it aimed to keep us technologically up to date.
More than ninety per cent of American hospitals have been computerized during the past decade, and more than half of Americans have their health information in the Epic system. Seventy thousand employees of Partners HealthCare—spread across twelve hospitals and hundreds of clinics in New England—were going to have to adopt the new software. I was in the first wave of implementation, along with eighteen thousand other doctors, nurses, pharmacists, lab techs, administrators, and the like.
The surgeons at the training session ranged in age from thirty to seventy, I estimated—about sixty per cent male, and one hundred per cent irritated at having to be there instead of seeing patients. Our trainer looked younger than any of us, maybe a few years out of college, with an early-Justin Bieber wave cut, a blue button-down shirt, and chinos. Gazing out at his sullen audience, he seemed unperturbed. I learned during the next few sessions that each instructor had developed his or her own way of dealing with the hostile rabble. One was encouraging and parental, another unsmiling and efficient. Justin Bieber took the driver’s-ed approach: You don’t want to be here; I don’t want to be here; let’s just make the best of it.
I did fine with the initial exercises, like looking up patients’ names and emergency contacts. When it came to viewing test results, though, things got complicated. There was a column of thirteen tabs on the left side of my screen, crowded with nearly identical terms: “chart review,” “results review,” “review flowsheet.” We hadn’t even started learning how to enter information, and the fields revealed by each tab came with their own tools and nuances.
But I wasn’t worried. I’d spent my life absorbing changes in computer technology, and I knew that if I pushed through the learning curve I’d eventually be doing some pretty cool things. In 1978, when I was an eighth grader in Ohio, I built my own one-kilobyte computer from a mail-order kit, learned to program in BASIC, and was soon playing the arcade game Pong on our black-and-white television set. The next year, I got a Commodore 64 from RadioShack and became the first kid in my school to turn in a computer-printed essay (and, shortly thereafter, the first to ask for an extension “because the computer ate my homework”). As my Epic training began, I expected my patience to be rewarded in the same way.
My hospital had, over the years, computerized many records and processes, but the new system would give us one platform for doing almost everything health professionals needed—recording and communicating our medical observations, sending prescriptions to a patient’s pharmacy, ordering tests and scans, viewing results, scheduling surgery, sending insurance bills. With Epic, paper lab-order slips, vital-signs charts, and hospital-ward records would disappear. We’d be greener, faster, better.
But three years later I’ve come to feel that a system that promised to increase my mastery over my work has, instead, increased my work’s mastery over me. I’m not the only one. A 2016 study found that physicians spent about two hours doing computer work for every hour spent face to face with a patient—whatever the brand of medical software. In the examination room, physicians devoted half of their patient time facing the screen to do electronic tasks. And these tasks were spilling over after hours. The University of Wisconsin found that the average workday for its family physicians had grown to eleven and a half hours. The result has been epidemic levels of burnout among clinicians. Forty per cent screen positive for depression, and seven per cent report suicidal thinking—almost double the rate of the general working population.
Something’s gone terribly wrong. Doctors are among the most technology-avid people in society; computerization has simplified tasks in many industries. Yet somehow we’ve reached a point where people in the medical profession actively, viscerally, volubly hate their computers.
On May 30, 2015, the Phase One Go-Live began. My hospital and clinics reduced the number of admissions and appointment slots for two weeks while the staff navigated the new system. For another two weeks, my department doubled the time allocated for appointments and procedures in order to accommodate our learning curve. This, I discovered, was the real reason the upgrade cost $1.6 billion. The software costs were under a hundred million dollars. The bulk of the expenses came from lost patient revenues and all the tech-support personnel and other people needed during the implementation phase.
In the first five weeks, the I.T. folks logged twenty-seven thousand help-desk tickets—three for every two users. Most were basic how-to questions; a few involved major technical glitches. Printing problems abounded. Many patient medications and instructions hadn’t transferred accurately from our old system. My hospital had to hire hundreds of moonlighting residents and pharmacists todouble-check the medication list for every patient while technicians worked to fix the data-transfer problem.
Many of the angriest complaints, however, were due to problems rooted in what Sumit Rana, a senior vice-president at Epic, called “the Revenge of the Ancillaries.” In building a given function—say, an order form for a brain MRI—the design choices were more political than technical: administrative staff and doctors had different views about what should be included. The doctors were used to having all the votes. But Epic had arranged meetings to try to adjudicate these differences. Now the staff had a say (and sometimes the doctors didn’t even show), and they added questions that made their jobs easier but other jobs more time-consuming. Questions that doctors had routinely skipped now stopped them short, with “field required” alerts. A simple request might now involve filling out a detailed form that took away precious minutes of time with patients.
Rana said that these growing pains were predictable. The Epic people always build in a period for “optimization”—reconfiguring various functions according to feedback from users. “The first week,” he told me, “people say, ‘How am I going to get through this?’ At a year, they say, ‘I wish you could do this and that.’ ”
I saw what he meant. After six months, I’d become fairly proficient with the new software. I’d bring my laptop with me to each appointment, open but at my side. “How can I help?” I’d ask a patient. My laptop was available for checking information and tapping in occasional notes; after the consultation, I completed my office report. Some things were slower than they were with our old system, and some things had improved. From my computer, I could now remotely check the vital signs of my patients recovering from surgery in the hospital. With two clicks, I could look up patient results from outside institutions that use Epic, as many now do. For the most part, my clinical routine did not change very much.
As a surgeon, though, I spend most of my clinical time in the operating room. I wondered how my more office-bound colleagues were faring. I sought out Susan Sadoughi, whom an internist friend described to me as one of the busiest and most efficient doctors in his group. Sadoughi is a fifty-year-old primary-care physician, originally from Iran, who has worked at our hospital for twenty-four years. She’s married to a retired Boston police lieutenant and has three kids. Making time in her work and family schedule to talk to me was revealingly difficult. The only window we found was in the early morning, when we talked by phone during her commute.
Sadoughi told me that she has four patient slots per hour. If she’s seeing a new patient, or doing an annual physical, she’ll use two slots. Early on, she recognized that technology could contribute to streamlining care. She joined a committee overseeing updates of a home-built electronic-medical-record system we used to rely on, helping to customize it for the needs of her fellow primary-care physicians. When she got word of the new system, she was optimistic. Not any longer. She feels that it has made things worse for her and her patients. Before, Sadoughi almost never had to bring tasks home to finish. Now she routinely spends an hour or more on the computer after her children have gone to bed.
She gave me an example. Each patient has a “problem list” with his or her active medical issues, such as difficult-to-control diabetes, early signs of dementia, a chronic heart-valve problem. The list is intended to tell clinicians at a glance what they have to consider when seeing a patient. Sadoughi used to keep the list carefully updated—deleting problems that were no longer relevant, adding details about ones that were. But now everyone across the organization can modify the list, and, she said, “it has become utterly useless.” Three people will list the same diagnosis three different ways. Or an orthopedist will list the same generic symptom for every patient (“pain in leg”), which is sufficient for billing purposes but not useful to colleagues who need to know the specific diagnosis (e.g., “osteoarthritis in the right knee”). Or someone will add “anemia” to the problem list but not have the expertise to record the relevant details; Sadoughi needs to know that it’s “anemia due to iron deficiency, last colonoscopy 2017.” The problem lists have become a hoarder’s stash.
“They’re long, they’re deficient, they’re redundant,” she said. “Now I come to look at a patient, I pull up the problem list, and it means nothing. I have to go read through their past notes, especially if I’m doing urgent care,” where she’s usually meeting someone for the first time. And piecing together what’s important about the patient’s history is at times actually harder than when she had to leaf through a sheaf of paper records. Doctors’ handwritten notes were brief and to the point. With computers, however, the shortcut is to paste in whole blocks of information—an entire two-page imaging report, say—rather than selecting the relevant details. The next doctor must hunt through several pages to find what really matters. Multiply that by twenty-some patients a day, and you can see Sadoughi’s problem.
The software “has created this massive monster of incomprehensibility,” she said, her voice rising. Before she even sets eyes upon a patient, she is already squeezed for time. And at each step along the way the complexity mounts.
“Ordering a mammogram used to be one click,” she said. “Now I spend three extra clicks to put in a diagnosis. When I do a Pap smear, I have eleven clicks. It’s ‘Oh, who did it?’ Why not, by default, think that I did it?” She was almost shouting now. “I’m the one putting the order in. Why is it asking me what date, if the patient is in the office today? When do you think this actually happened? It is incredible!” The Revenge of the Ancillaries, I thought.
She continued rattling off examples like these. “Most days, I will have done only around thirty to sixty per cent of my notes by the end of the day,” she said. The rest came after hours. Spending the extra time didn’t anger her. The pointlessness of it did.
Difficulties with computers in the workplace are not unique to medicine. Matt Spencer is a British anthropologist who studies scientists instead of civilizations. After spending eighteen months embedded with a group of researchers studying fluid dynamics at Imperial College London, he made a set of observations about the painful evolution of humans’ relationship with software in a 2015 paper entitled “Brittleness and Bureaucracy.”
Years before, a graduate student had written a program, called Fluidity, that allowed the research group to run computer simulations of small-scale fluid dynamics—specifically, ones related to the challenge of safely transporting radioactive materials for nuclear reactors. The program was elegant and powerful, and other researchers were soon applying it to a wide range of other problems. They regularly added new features to it, and, over time, the program expanded to more than a million lines of code, in multiple computer languages. Every small change produced unforeseen bugs. As the software grew more complex, the code became more brittle—more apt to malfunction or to crash.
The I.B.M. software engineer Frederick Brooks, in his classic 1975 book, “The Mythical Man-Month,” called this final state the Tar Pit. There is, he said, a predictable progression from a cool program (built, say, by a few nerds for a few of their nerd friends) to a bigger, less cool program product (to deliver the same function to more people, with different computer systems and different levels of ability) to an even bigger, very uncool program system (for even more people, with many different needs in many kinds of work).
Spencer plotted the human reaction that accompanied this progression. People initially embraced new programs and new capabilities with joy, then came to depend on them, then found themselves subject to a system that controlled their lives. At that point, they could either submit or rebel. The scientists in London rebelled. “They were sick of results that they had gotten one week no longer being reproducible a week later,” Spencer wrote. They insisted that the group spend a year rewriting the code from scratch. And yet, after the rewrite, the bureaucratic shackles remained.
As a program adapts and serves more people and more functions, it naturally requires tighter regulation. Software systems govern how we interact as groups, and that makes them unavoidably bureaucratic in nature. There will always be those who want to maintain the system and those who want to push the system’s boundaries. Conservatives and liberals emerge.
Scientists now talked of “old Fluidity,” the smaller program with fewer collaborators which left scientists free to develop their own idiosyncratic styles of research, and “new Fluidity,” which had many more users and was, accordingly, more rule-bound. Changes required committees, negotiations, unsatisfactory split-the-difference solutions. Many scientists complained to Spencer in the way that doctors do—they were spending so much time on the requirements of the software that they were losing time for actual research. “I just want to do science!” one scientist lamented.
Yet none could point to a better way. “While interviewees would make their resistance known to me,” Spencer wrote, “none of them went so far as to claim that Fluidity could be better run in a different manner.” New Fluidity had capabilities that no small, personalized system could ever provide and that the scientists couldn’t replace.