
Why doctors hate their computers - greeneggs
https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computers
======
CaptSpify
This isn't isolated to doctors sadly. You see this in any medium to large
organization: schools, cities, companies, etc. The problem, the way I see it,
is that management is the one really being sold to.

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.

~~~
analog31
This was once described to me as the Law of Enterprise Sofware:

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.

~~~
logfromblammo
I worked at Epic, and while I was there, I can confirm that a huge number of
workers were fresh out of college and making crap customizations, for every
single customer we had. If a salesperson ever told a customer "no, that can't
be customized", they might go with another EMR vendor. So every bit of user
choice added by the developers and the staff physicians was eventually taken
away by customizing administrators turning optional into either mandatory or
forbidden. It was completely ludicrous. One part of the company was building
software to be used at theoretically any medical facility, and another part
was busy turning it into many shards of software that could each only be used
in one location for one customer.

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.

------
alxlaz
I used to work on stuff that doctors use (and I miss it a great deal), so I've
seen a lot of this first-hand.

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.

------
dwd
This was the telling statement of the whole article.

"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.

[https://news.ycombinator.com/item?id=18157885](https://news.ycombinator.com/item?id=18157885)

~~~
maxxxxx
That's a bad trend you see everywhere. Admin assistant positions are being
reduced and now the specialists have to do everything themselves.

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.

~~~
short_sells_poo
It's short sighted cost cutting. An assistant/admin position is easy to
justify for the chopping block, it's removal reduces headcount and the
increased load on the specialists is not seen directly on the balance sheet
for a while.

~~~
secabeen
It also reduces organizational liability, which produces the usual
externality. <sarcasm> Why does the assistant have a need to know about
patient X's medical issue? They shouldn't be able to see that data! Only the
Dr. should see it! </sarcasm>

------
jcowdy
The problem with this article is that Dr Gawande is too quick to point the
finger at the EHR vendors for increasing the amount of non-clinical work that
physicians are responsible for today. The EHR has become the face for arcane
and archaic billing, regulatory, and compliance requirements which, when
enforced through the software of the EHR, cause additional work to be shifted
to the physician. Those questions that you get when you place a radiology
order have typically not been added by the EHR vendor. More than likely they
were added at the advice of legal / compliance.

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?

~~~
danans
> 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.

~~~
jcowdy
Yes, definitely an option although eventually the volume of "final approval"
items will stack up. Another option could be to allow items that pass
protocols for non-controlled substances to be approved by nursing staff.
Conversations like this are exactly what need to take place for each item on
the provider's plate.

------
beckler
I used to work for a company that made EHR software. Doctors have very little
patience for computer issues; most don't enjoy using them. My job at the time
would involve me talking to most IT folks at hospitals, and they would have
some crazy stories.

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".

~~~
AnIdiotOnTheNet
> Doctors have very little patience for computer issues; most don't enjoy
> using them.

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.

~~~
ams6110
So true. This year, finally, my kids local school system deployed an online
replacement for the ~20 paper forms they require at the start of each school
year. I have always loathed filling out those forms, especially since there
was no checkbox to the effect of "everything is the same as last year"

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.

~~~
arethuza
"everything is the same as last year"

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.

------
7402
This was the part that absolutely stunned me:

> 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.

~~~
nradov
It's not always necessary or desirable to store all times as UTC. What you
actually need is a time plus _offset_ from UTC. Storing times as UTC is
essentially just a special case of that where the offset is always 0.

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.

~~~
secabeen
>It's not always necessary or desirable to store all times as UTC. What you
actually need is a time plus offset from UTC. Storing times as UTC is
essentially just a special case of that where the offset is always 0.

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.

------
clueless123
For most people, (read spreadsheets, word processors, etc ) computers make
their jobs easier or more productive. It is hard to say the same for medical
software, mainly because it is not designed to help medical providers, but to
help administrators.

~~~
SketchySeaBeast
I wouldn't say that's correct - diagnostic imaging is entirely computerized
these days and that's made life a lot more productive and efficient, but is
also the source of huge frustration when these incredibly expensive machines
have software glitches or network connectivity problems.

~~~
carbocation
As a doctor, I agree with `clueless123. The imaging software is not what makes
us frustrated: it's the EHR that is optimized for billing, not patients or
doctors.

~~~
SketchySeaBeast
I'm just speaking from my experience with Rads and their technologists. I
imagine billing is a nightmare as well.

~~~
carbocation
I actually don't think there is a real dichotomy - the system can be annoying
to different groups for different reasons. The reasons it's annoying to MDs
may be different from the reasons it's annoying to rads techs, etc. But you
started by contradicting the parent post (" _I wouldn 't say that's
correct_"), which is why I felt inclined to chime in.

------
anitil
The system designers are doomed though. \- Legacy Systems \- Complicated
workflows \- Enterprise software \- Difficult compliance issues \- Billing and
coding

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.

~~~
eropple
I'll cape up a little for Jira. You need to have it built and configured by
somebody who actually, really _cares_ about how people already work and has
the Jira-specific knowledge to express it--and that can be hard when doing the
right thing in Jira is as counter-intuitive as it is--but when done right it's
really very powerful and can be made to be effective and user-friendly. (I
volunteered to be the Jira admin at my new company because I do care and I do
understand it well enough to do that stuff--and because I own enough of the
other systems it'll have to hook into eventually, anyway.)

On the other hand, I used to work on EHR software. Eff _that_.

~~~
wink
Can said person make the search return sensible results? I doubt it - it's not
_only_ configuration.

~~~
eropple
Search is, admittedly, the worst part of Jira. ;)

------
jatsign
In the last few years, I've noticed that visiting my kids' pediatricians that
the doctors spend most of the time during the visit poking at their computer.
As a parent, it makes me feel that they're just filling out a form, not caring
for my daughters.

~~~
gbustomtv5
They care about your daughters but they care about their children too. If they
do not fill in electronic records they will have to stay after work. Many
doctors have to work at home until 1-2AM to keep up with recordkeeping.

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.

~~~
octorian
> They care about your daughters but they care about their children too. If
> they do not fill in electronic records they will have to stay after work.
> Many doctors have to work at home until 1-2AM to keep up with recordkeeping.

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)

------
skarras
In the past I was a developer working on a EHR system. I was laughing when I
read "There was a column of thirteen tabs on the left side of my screen".

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.

------
classichasclass
So here's my story about this.

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.

~~~
Scoundreller
Could it be that the “B” product was a lot cheaper?

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

------
voltooid
I am an engineer and I particularly relate to the problem that the doctor has
with having to click multiple times to order medical tests where previously
only one sufficed. Also, the problem of multiple links named with very
similar, thus confusing names - "chart review", "result review" etc.

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.

~~~
Chris2048
Didn't amazon patent one click orders?..

------
gbustomtv5
Doctors hate their computers because of the growing volume of recordkeeping
and patient communication required yet unpaid.

Anyone told to stick around for 4 more hours after 8 hours of work to update
records and answer emails would hate it too.

------
stmw
Great article -- it's a big problem that needs urgent nnovation. BTW, if you
are reading this and are interested in helping build better software for
doctors, drop us a line. We are a stealth startup working to fix the software
doctors use. As the article explains, if you have seen what physicians have to
put up with, it's a bad version of the 90s, and makes medical care worse and
more expensive for everyone. Please email jobs@commure.com and mention
"[whydoctorshatetheircomputers]" in the subject line.

------
naveen99
This is why AI won’t replace doctors. Doctors aren’t even allowed to properly
use computers their user interfaces are handicapped. No API to the medical
record (hospital IT locks it out even if there is one from the vendor). If
they give AI access to the full medical record with an API, they will have to
give doctors access too.

~~~
nradov
AI won't replace doctors, but it's not because of lack of API access to
medical records. Medical records don't contain all of the data that an AI
would need to make an accurate diagnosis and come up with an optimal treatment
plan. In order for an AI to do that it would need to be able to see, touch,
and converse with the patient. We're a long way from that capability.

~~~
Scoundreller
I give it 10 years before I’ll be pleading with the paramedics to take me to
the AMZN or GOOG hospital instead of XYZ Health System.

------
mhd
Medical software still has huge rooms for improvement. Combining complexity
with bureaucracy will just result in issues, never mind that in hospitals the
sheer volume of porting things is a recipe for keeping legacy systems alive
and plenty of technical debt. Good luck getting rid of you MUMPS system. Or
dot matrix printers (AFAIK still required in Germany, as some forms require a
literal carbon copy).

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.

------
shanecleveland
There are many factors at play. I work for a US manufacturer in the medical
industry, and our customers definitely lag behind in technology. Some of the
things I see:

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.

~~~
phren0logy
I'm a (relatively) young and tech-savvy doctor. The electronic medical records
I have used (around 5 or 6) are all truly terrible. As the medical director of
a group of clinics, I explored replacing our terrible system, and every other
system I looked that was a reasonable fit for our needs was, at best,
marginally better.

While there are other factors at play, the main one is that electronic medical
record software is really, really bad.

~~~
shanecleveland
No doubt. I didn't mean to minimize this aspect.

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.

------
noddy1w
Medtech is annoying because of the primary focus being documentation. I spend
much of my day writing stuff that noone cares about for people who will never
read it. Doing this on paper is slow. Doing it on a computer is even slower.
Finding a terminal and filling in structured forms is a pain in the ass when I
want to be seeing patients, doing procedures etc. Using things like google
glass and offsite scribes is a good way to do this.

------
maxxxxx
It's probably the same as me having to deal with our enterprise systems for
documents and requirements. They are a major pain in the a.. and just add more
burden instead of making my work easier. I hate them every second I have to
use them and avoid as much as I can.

I bet most medical record systems are built for administrators (who make the
purchasing decisions) and not for doctors.

------
amelius
To the IT people who are making others click ads: perhaps it's time to fix
some _real_ problems ...

~~~
SmellyGeekBoy
Ads in medical software! I like your thinking.

~~~
hotzenplotz
European doctor here. We have ads in our medical software!

------
dmoy
I went to the doctor for a routine vaccination a couple weeks ago. As I sat in
the room I had a perfect view of the computer that the doctor was using to
fill out the requisite form. It was a pretty bog standard form with a
gazillion fields.

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...

------
throwaway5752
Because Cerner and Epic are awful and the rest are too.

------
Areading314
Sounds like jira

------
sonnyblarney
UX centric design is the future, companies need to understand that.
Particularly buyers who are making decisions of of 'feature checklists'.

~~~
octorian
This is only possible when the customer isn't completely disconnected from the
user, there is real competition, and that competition is based on the product
itself... Not the contract to buy/develop said product.

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.

~~~
sonnyblarney
I worked in defence as well, and the requirements are not just a 'checklist'.

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.

