Why doctors hate their computers
newyorker.com
newyorker.com
The actual people who do the day to day work have no real say in which software systems they use. Only management has any real say, so sales people tailor their pitch towards management. Unfortunately, managers only have a high-level overview of what the people below them actually do, and no understanding of software, so they have no idea what they need their software to do.
And situations like this are where sales people shine brightest. Sure, the new "cloud-based, totally-super-secure, widget producer 9000" won't actual be useful at anything, but it sure looks cool to management.
Look at companies like Oracle, and Microsoft for good examples: Their actual products are awful, but that doesn't matter. What matters is that their sales team can sell a shit product.
All enterprise software sucks, because it's sold to administrators, not to users.
The managers see the purpose of software as improving their own workflow (tracking, data gathering, compliance) as well as controlling the users, not (gasp) empowering them.
Compounding the problem of enterprise software is customization. A person who works at an EHR vendor told me that every clinic system wants to develop their own bespoke workflow, in search of slightly higher efficiency, and so the thing that the user actually sees is not a well engineered system, but a hodgepodge of screens and forms that were designed at the last minute. My friend said that the user experience is a lot better at sites where the customer uses the off-the-shelf implementation with little or no customization.
The best workflows were those were the custom fields were used and just had a nice label (e.g. "Old Customer Id") and not the workflows where some consultant had created an additional UI that didn't even use the underlying fields and did something like write the data to some unrelated storage mechanism and then building reports that are trying to awkwardly mix and match these data sources.
And on top of this, the software used to customize the base software was esoteric and required extensive training just to change the resource strings. This was before i18n, of course, but I have no reason whatsoever to believe that made anything better.
The whole thing was--and probably still is--held together by huge gobs of money. If Epic were in any industry other than US healthcare, it would have been bankrupt a long, long time ago. My experience has led me to believe that if software developers had any significant union membership in the 80s and 90s, able to enforce minimum standards for development practices, health care costs today could have been 3/4 of what they actually are now. We are now paying for jobs that could have been completely automated by 2000, and its because Epic and Cerner and GE and all their competitors have been shoving technical debt--in the form of bullshit customizations--into every deployment for decades, at the behest of administrators who were understandably reluctant to authorize the purchase of any product that would automate them out of their own jobs.
And it just gets worse when you add billing integration, because then Medicare and the private insurers get involved...
Got out, didn't look back. Don't work in medical software if you love programming and don't want to spoil that.
That's kind of the same-but-opposite of my experience.
When software tries to control how it's going to be used, it fails spectacularly more often than not, ime. The best software that I've used always leans into the problem: They let me access it via a dump. Then I can manipulate it as I need, then upload it back in.
But when those that don't understand the workflow try to tell developers how to design software, it usually ends up in a big mess of workarounds just to get the basic use-case to work correctly.
Imagine that's not a consultant anymore but a doctor, and he or she is not entering hours worked but medical stats. Sleep well tonight.
I also read about a similar project, ostensibly designed using latest principles and understanding of hospital work, which unsurprisingly turned out to have a zillion papercuts and completely impractical design decisions. So, yeah.
Though change can be difficult.
The very article posted that new functions in the EHR increased deaths by 0.11% per function in the first year, but then decreased by 0.21% per year.
I have made a few practical suggestions to the facility people in the past always gut shrugged off.
I think the bigger issue is that an EHR is not one piece of software, it's 100+ applications are bundled together under a single name. It's a registration system, a billing system, a coding system, a data warehouse, a surgical system, a physician's office system, a scheduling system . . . It's inevitable that some of these applications will be better than others, but that's the sacrifice you make for the cost savings, consistent support, and guaranteed interoperability that comes with going with a single vendor.
Not to mention that with a medical staff of hundreds to thousands of highly opinionated, highly intelligent providers, you're never going to make everyone happy.
A lot could be said about it, but in any case, it's certainly not a management layer responsible for the degradation of the system.
Edit: forgot to include the link. [0] - https://www.mitpressjournals.org/doi/abs/10.1162/POSC_a_0018...
In my experience, a lot of the problems that medical software and devices have stem from a lack of understanding on the "other" side of the fence. Committees of people who don't really do much medicine anymore meet committees of people who don't write much software anymore and come up with specifications that are almost, but not quite, entirely unlike what the doctors really need.
And then the implementation is outsourced to a team comprised of people who have to churn out software with minimal understanding about how it will be used. These folks will try to understand it at first, but there are so many project managers and customer satisfaction managers and NDAs between them and the people who need the system (and, of course, there's no documentation because that's the first thing that gets slashed out of the itemized billing when the customers see the price) that it takes weeks to get a straightforward answer to even the most trivial question.
Not that it's easy to do things differently. When I was working on devices for the medical industry, I had not looked through an anatomy textbook since my teenage years; understanding the jargon alone was hard, let alone make meaningful design decisions.
I was super fortunate to work for a company that had long learned these lessons and did things correctly. But doing things correctly and profitably takes a long time; most companies don't have that kind of patience so they don't really bother with it. People who possess substantial knowledge of both programming and medicine are extraordinarily rare and not too easy to keep on payroll, so these companies rarely manage to develop the kind of technical leadership required to successfully mentor new people and drive projects over a long time.
"Previously, she sorted the patient records before clinic, drafted letters to patients, prepped routine prescriptions—all tasks that lightened the doctors’ load. None of this was possible anymore. The doctors had to do it all themselves."
This is a huge fail and is not just a problem in medical - though the consequences are more serious and will result in patient deaths because doctors are spending more time on paperwork than diagnosing and treating patients.
There was a recent article posted to HN on research going back decades highlighting this issue.
Welcome to rigid software not built for adaptability.
It's not the software it's the organization who cuts admin positions for short term gain. Instead of assistants who help you with that work you have a ton of VPs for diversity and whatever where nobody knows what they are actually doing.
In my company we used to have somebody who made all travel arrangements but now we have to do it ourselves which is a major pain and takes a lot of time if you use the system only once a year.
As we develop systems that take software developers out of the loop because it seemed a cool idea to work on, we'll only have ourselves to blame.
So for them it's quite likely hard to imagine that other people might have assistants to do things for them.
Unfortunately the problem isn't as simple as getting more competent EHR designers and developers (although that certainly wouldn't hurt), but rather a deeper look into each aspect of increased work for physicians and analysis of why it is in the workflow (5 whys application would be great). At that point, organizations and physicians will better understand the reason work is on the physicians' plate and have a chance to weigh the pros and cons of either removing that work or shifting it to another person.
The other side of this that most don't see is that EHR vendors are also being held back by these same billing and compliance pressures. Here's a secret - EHR vendors actually want to help physicians be as efficient as possible and would love to automate work off of their plate. Unfortunately the environment created by compliance departments who are afraid of being sued and hospitals who would like to get paid has handcuffed the more innovative development from EHR vendors. If a system reviews incoming medication refill requests from patients, evaluates protocols, and determines that a refill should be approved who does is listed as the authorizing provider for the purpose of the pharmacy and the patient's insurance?
If this system has really done all this work that presumably would have otherwise been done by a provider, what's the harm in presenting the recommendation to a doctor or pharmacist for final approval?
I'd think that it's important to get a trained professional to apply their experience to the final decision, which is perhaps why there is an "authorizing provider" field in the first place.
My favorite was how this one doctor would call IT almost daily. He would complain that his computer was slow, so this IT guy would walk up to his office and do something random. Like unplug his Ethernet cord or mouse and plug it back in, or turn his screen off and back on. The doctor would evaluate if it was better, and always said "thanks, that fixed it".
The IT team realized that they just had to do something to make him happy when in reality they did nothing at all.
I would say that this is true of people in general. Sadly, a lot of the people working in this industry seem to be completely ok with, if not outright love the bullshit computers put us through. Just look around man, everything is ridiculously slow and unresponsive considering the hardware behind it, there are so many hoops we have to jump through for no good reason, software seems to be just as (if not more) fragile as ever, it's awful.
https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and...
If anything, the online version is worse. They essentially preserved the same layout and organization of the paper, just converted to online forms. There is duplicate entry everywhere. I entered my address on at least three different forms, my phone number on four or five. And everything had to be repeated from scratch for each kid. And it was all presented in a weird iframe container that didn't quite fit the content, so you had to scroll around to see different areas of the page. If a phone had been my only way to access these, it would have been even worse.
It was so much like what would have been done in 1995, I could not believe they found this in any way acceptable in 2018.
Offtopic: That reminds me of a change I submitted for an in-house time tracker which was for a button that did "Same as last week but with some plausible minor random differences".
I was deeply disappointed that this was rejected.
It isn't just doctors. And it isn't just computers. Whenever an employee is forced to use a particular system, they will grow to hate that system. When there is only one cafeteria, the food is "horrible". When there is only one ferry, it is always late. When you have to use a particular set of software tools, they are always too slow. It is basic psychology: give people even a modicum of choice and they will feel better about the system. Deny that choice and all you will get is criticism.
The doctor would evaluate if it was better, and always said "thanks, that fixed it".
IT users vs IT support is an interesting line of conflict full of mutual misunderstandings and wrong attributions.
> Last fall, the night before daylight-saving time ended, an all-user e-mail alert went out. The system did not have a way to record information when the hour from 1 a.m. to 1:59 a.m. repeated in the night. This was, for the system, a surprise event. The only solution was to shut down the lab systems during the repeated hour.
Any system like this that fails to store all times as UTC is broken.
No one should make this mistake more than once. I made it once, and boy was it painful. And boy did I feel stupid to realize I had forgotten about daylight savings time. I just can't see how it was possible for the designers of this huge system to miss this.
I could easily see a case where the timestamp is stored as a string to interoperate across various computer SYSTEMS.
Doing a wide scale fix for this problem is probably cost-prohibitive - assuming it is even possible.
Most lab data is communicated to other systems using HL7 V2.x messages. The standard does allow for including a time zone offset in all date/time fields. However, many older implementations fail to include the offset and just use local time. Obviously that's not a good idea.
It depends on the needs of the system. For example, a patient comes in, and has a test or takes a medication at 8am local time (12 noon UTC). Now the patient moves one timezone east, and their new Dr. looks at that test/medication record. How do you display the time of that test? 8am (when the test was taken local time), or 9am (the wall clock time in the new timezone). If you care about waiting 24 hours before the next test, the latter is what you want. If you want to know how early in the patient's morning the test was taken, you prefer the former.
It's broken, but it's been broken in this way for decades and hasn't stopped it being very successfully sold.
Say you see on the chart that a patient received medication at 1:30. It's now 2:30, and the patient is supposed to receive medication every 2 hours. Do you give them another dose? Did they get their does at the first 1:30 or the 2nd 1:30? Expand that by the literal thousands of super (almost frustratingly) customizable workflows, custom charts, etc., and the problem gets pretty big.
Considering most (maybe all?) Epic upgrades require brief downtimes, a lot of hospitals chose to take their downtime to install updates during the DST changeover time and rely on their doctors/nurses/etc. to be extra careful on paper during the doubled hour. Is it a great system? Not really. But it kind of works I guess.
Every moment I touch Jira feels like time I won't ever get back, and it is miles better than any medical software I've seen. Imagine if your whole work life was in a system like that. Misery.
On the other hand, I used to work on EHR software. Eff that.
When programming, something that makes you think "yup, I'll do that as soon as there's time" is much better (for planning/PM) and more routine than "hmm, not sure, I'll try", right? I think the same applies to personal medicine - routine and boring forms are better than puzzled investigations.
On the other hand, healthcare administrators who demand doctors spend no more than 15 minutes per patient AND fill pages and pages with summaries of visits really do not care about your daughters even a tiny bit.
I can certainly attest to this, from my own experiences growing up (in the 90's). My father is a doctor, and I distinctly remember him spending most of his evenings in his home office doing paperwork. I asked him why he didn't do it at the office, and he said that many of his colleagues did... But as a result, they didn't get home from work until much later. (and he was already getting home just barely in time for dinner)
I guess software is inherently monopolistic (or oligopolistic) market especially in highly regulated markets (healthcare, finance etc.).
So going back to earlier question -- why can't someone start an open source alternative? And may be sell it something along the lines of Redhat business model. It looks like support (training, maintenance) costs are way more in healthcare. Why can't be Epic disrupted?
P.S. One of my physicians uses Epic, and he is pretty old guy. And once he showed me the interface, my first reaction, "oh god, that software is designed by committee". I really sympathize with doctors who have to work several hours everyday to work on Epic.
This allows IT teams at hospitals to have say and power over best practices but also requires massive investments in custom software and consulting and training.
Add in they've been doing it with patchwork for so many years and it's difficult and there's little incentive to build a new system. When consulting revenue for implementation outpaces licensing... You're going to have a bad time.
Also, this isn't wi-fi based juicer machines or Uber for llama rentals nonsense that SV is so good at disrupting. This is a very complex business that often makes no sense (American medical billing is insane to put it mildly) and usually requires heavy customization for every client, and have pretty heavy switching costs.
It would be an interesting project to disrupt them, but it's nowhere near as easy as it seems, and it is doubtful that you'd get any of the big clients EPIC, Cerner, or GE Healthcare care about.
This is a really sad truth. Not only for physicians but also for other workers who have to work with an ERP system. At least here in Greece I have not seen until now any EHR/ERP that has good UI/UX.
Most of the time we was just building copies of physical forms or simply expose most of the fields of a huge entity in openEHR. Without automating anything.
I think that a big factor thats data entry process takes longer is because instead of hand writing something, now they have to type it or search for a check box to check. At least here in Greece I don't know any physician who can type as fast as he/she writes by hand.
I'm a physician primarily working in an administrative capacity for a large local government (though I also have a background in enterprise computing and did that for several years both full-time and as a consultant). I'd lived through the horrors of the EHR transition at the large HMO I used to work for and was determined not to have that happen again.
We were selecting an EHR product and had it narrowed down to three main products which I won't name here but they're all major players and are still in the market.
I was representing the clinicians, so I selected the product "A" I felt had the best clinical support, the best clinical workflow and the easiest UI slope. So did the nurses who were selecting for nursing staff (we didn't coordinate our choices; we each legitimately felt this was the best product for our respective scopes of practice).
The billers selected the product "B" that had the best reporting and financials.
So, we on the clinical side were asked, can you live with "B"? Well, yeah, sure, I guess? We can make it work, but it's clearly less flexible, the workflow is clunkier, the decision support is less comprehensive and we felt would be more difficult for the physicians. The billers said adamantly that "A" was too much work to deal with the reporting and they wanted something out of the box. They were not willing to compromise despite our concerns on the clinical side, even though we'd have more facetime with the product than they would, and there would be less to bill if the physicians couldn't figure out how.
So the clinicians got overruled by the billers and "B" was selected.
I understand that the billers must have a say, but the billers are dealing with a small portion of the product. The billers managed to convince administration that their concerns were more valuable because their work translated into dollars. As if the clinicians' work didn't? How does that work? And yet I see this occur again and again in other clinical systems.
As a postscript, the local government's rollout of "B" went aground and we ended up with a cheap vanilla install of "D", which wasn't part of the original three and ended up pleasing no one, and is ironically the same EHR I still have PTSD from all those years ago.
The “best” EHR vendors know they are, and charge accordingly. The underdogs know that they can win on price if they can’t on usability
I see this on a regular basis when using visual studio team services so much so that our team spends a large amount of our time dealing with the VSTS interface instead of making use of the system to do our planning quickly and efficiently. I deal with a computer all day every day and I don't find VSTS the least bit intuitive or helpful. The problem described in the article is not one that just doctors have to face.
Anyone told to stick around for 4 more hours after 8 hours of work to update records and answer emails would hate it too.
On the other hang, as with travel agents, it might be that the old mainframe-based legacy system is better than the Windows/Web-based replacement, UI-wise.
And never mind the software, against the ever-changing requirements of the state and insurance companies, the IT gods themselves struggle in vain.
Much of the workforce is older and adoption of new technology is avoided by many.
Large organizations move slowly and health care workers don't tend to be among early adopters of technology.
While working individually, face-to-face with a patient, pen and paper can actually be the best option.
A younger workforce, more understanding patient population and new environments centered around technology first will occur eventually.
While there are other factors at play, the main one is that electronic medical record software is really, really bad.
I think it will take a new generation of professionals like yourself involved in building not only the software systems, but also the hardware used, the clinic environment and entire patient experience. As it is, these terrible systems, designed by non-medical professionals, are dropped in the laps of practitioners who are not comfortable with technology in settings not designed around the use of technology.
I bet most medical record systems are built for administrators (who make the purchasing decisions) and not for doctors.
But one thing that stood out is that at least twice when the doctor clicked on a drop-down, tbe computer selected a different option that wasn't even visible in the ~8 item scroll drop-down. The second time it happened the doctor turned around to me with a confused look and I said, "Yup, I totally saw that too, I dunno".
I was unclear if this was just native software (kinda looked like it), or just a really old fashioned website.
Doesn't instill a lot of confidence in me about the safety of my medical data...
These reasons are also why so much defense-industry software is also a completely unusable mess. (that's an industry I used to work in) The software is written to satisfy a requirements checklist, nothing more, nothing less.
You're talking about safety, consistency. Lives - and geopoltical situations are at stake.
Do you know what it means if a guided missile goes wayward and crosses international borders?
Or the rescue helicoptor's GPS is unreliable?
Totally agree it's bogged down in bureaucracy ...
But those requirements are real.
You want complicated: work in 'manned space flight' probably the highest safety tolerances of anything. My god I don't even know how we get someone in space these days.
We use the Russian system because it's old school, probably less complicated and reliable.
What is the actual experience? Error rate? How long did it actually take?
Number of clicks doesn’t matter: that’s the equivalent of buying art by the pound.