Why doctors hate their computers

7 years ago (newyorker.com)

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.

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

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

    • This is very true. I'd see this in software I worked on integrating ERPs where we'd have support for like 5-10 custom fields.

      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.

    • > Compounding the problem of enterprise software is customization.

      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.

  • This does not match my experience in healthcare. I've gone through the EHR vendor selection process at several community hospital systems and it's always been led by one or more physician leaders who have an incredible amount of influence on the final decision.

    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.

  • Ha, to torture it a bit, I think this can be even more generalized to include more than enterprise software - furniture, office spaces, office design, ALL are sold to the c-levels and their support staff and not the people who work in and with those decisions.

    • Yes!! I recently read about a new hospital wing or medical center or somesuch where they had – gasp – involved actual future users (ie. medical personnel and patients) already in the design phase! This was regarded as something revolutionary and almost unheard of.

      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.

      2 replies →

    • Very true. In my company they are planning another office redesign and the people sitting in that environment had zero involvement. Our role is only to be cheerful once the new plan is revealed.

      I have made a few practical suggestions to the facility people in the past always gut shrugged off.

  • Eh, I don't disagree with everything you said, but the essay links to a fascinating article by an anthropologist who spent 18 months with a group of physicists using and developing a modeling system called Fluidity [0] that presents a different picture. The article is thoughtful and well-balanced on the problems associated with what the author calls the "piecemeal" growth of an application as its user/developers add more and more features with insufficient "bureaucratic" regard for software engineering quality control practices.

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

  • I whole heartedly agree, and if newer computer programmers don't believe that's how the sausage is made they could either start working as a consultant or ask their consultant friends about the inevitably awful software they use to log their hours. The reason it's awful is because at no point has a consultant's work flow ever been considered during development. At no point has a consultant ever been present while the software was sold. The consultant isn't the customer, or even the end user in mind, it's the financial departments who get to turn all those hours logged into nifty charts.

    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 feel that companies selling B2B think of high-level executives as having incentives to deliver "something that wins", but they won't be around years later when it stinks. The company structures themselves accordingly by delivering fast productivity now, but skeleton crew later.

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.

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

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

  • Yeap. A relatively lower paid person should be able to help reduce the workload of the higher paid person. Makes good business sense.

    Welcome to rigid software not built for adaptability.

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

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?

  • EHR vendors and clinicians need to find a way to come together to both design software that will make clinicians lives easier, but also to change any billing/legal/compliance hurdles that are in the way of putting this technology in clinics. If someone can put all of these pieces together we could see some powerful changes. Perhaps Dr Gawande's new venture with Amazon, Berkshire Hathaway and JPMorgan will give him a chance to control both sizes of this puzzle and create a better environment for clinicians and patients.

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

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

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

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

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

      2 replies →

    • Until recently (I just checked and noticed it was gone), the web version of Slack had a several-second scroll delay if you had loaded a few pages of history. The power in our machines, yet we still have trouble scrolling text.

      2 replies →

    • We also tend to have the latest technology, or else we choose models we have a particular affinity for. Try working on a random laptop that’s several years old and a 3-year old phone. Your experience will be completely different.

      1 reply →

  •     The doctor would evaluate if it was better, and always said "thanks, that fixed it". 
    

    The doctor probably also thought: OMG another one of these clueless bastards who think I'm stupid and don't know how to fix the simplest problem. I'll try again tomorrow. Let's hope they'll send me somebody else.

    IT users vs IT support is an interesting line of conflict full of mutual misunderstandings and wrong attributions.

  • Your story makes it sound like he was dumb. He was probably being polite.

    • He was given a placebo and reported an improvement. I can live with that explanation.

    • He called IT with the same complaint multiple times a week.

      The IT team realized that they just had to do something to make him happy when in reality they did nothing at all.

      2 replies →

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

    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.

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.

  • At least a few years ago, when I was at Epic (not on a medical-user-facing team), the issue that caused this wasn't the data storage of the timestamps or whatever. It's figuring out how to display events during that repeated hour in charts that assume 24 hour days in patient-safe way.

    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.

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

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

  • You are making a bad assumption here: "Any system" ... Chances are we are talking about multiple systems created at different times and by different companies.

    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.

    • From experience with an EHR system: these things are so big that interoperating between different pieces of big-ball-of-mud systems is a dicey matter and making any changes requires extensive manual tests, since there are approximately zero automated tests.

  • I have a feeling that lots of stuff that translates between a human's conception of time and a computer timestamp have problems with DST. Have you ever tried editing a crontab entry in the hour leading up to the DST change? It won't run until after 2am (at least on RHEL7). I found this out last weekend during the time change.

  • I contracted at Cerner, which is Epic's largest competitor, for a couple years. I spent a solid three months on the Android implementation of a time function. The time you mention is called the "ambiguous hour" and everyone working on similar problems on my team was well aware of the issue and all unit testing scenarios accounted for the issue. I can't imagine that Epic completely ignored or was unaware of this.

  • From experience, at least one EHR system doesn't use UTC because it has never used UTC and is an amalgamation of code going back to the 80s. This can probably never be fixed because reliance on this format is threaded throughout the entire system, which has approximately no unit tests.

    It's broken, but it's been broken in this way for decades and hasn't stopped it being very successfully sold.

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.

  • I was part of an implementation team for an EHR at a very large ambulatory unit (i.e., private practices of one of the largest hospitals in the US). Complaints for EHR by medical staff were as follows: 1) "I am spending time looking at the computer instead of making eye contact with the patient. Therefore, patient experience deteriorates." 2) "Pen and paper are much faster inputs than having to click around tabs and typing values" (especially for older doctors). This slows them down, which means they can see less patients (direct impact on revenue). 3) While there were government incentives to encourage practices to implement EHRs, doctors from more lucrative specialties (who are not involved in research) did not see value in having the data computerized. Imagine an ophthalmologist who can perform another Lasek procedure instead of record a patient's drinking status, and other things that may not affect the procedure.

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

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

      2 replies →

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.

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

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.

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

    • > 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)

  • I suppose this is dependent on how much you trust the doctor(s) in question, but, in general, a specialist I trust 'filling out a form' is somewhat reassuring; there's nothing sufficiently bad that they're breaking routine.

    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.

More tangential q. I always wonder - why Epic is not disrupted yet? In same vein similar Q can be asked, why Bloomberg is not disrupted yet?

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.

  • I worked with Epic's main competitor. The main fact is that this type of software is sold alongside consulting and training solutions with custom options.

    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.

  • What Artistri121 said (I also worked for a major competitor of Epic).

    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.

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.

  • Cerner millenium (a common and widespread EMR) looks like a 90s visual basic application.

    Hell, it probably IS a 90s VB application under the hood.

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.

  • 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

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.

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.

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.

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.

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

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

  • Problem is education. There is prolly literally little to none courses about computers in medical school in most part of the world.

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.

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.

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

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

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.

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.

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

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

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

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

  • Ethnographic analysis is becoming more common. E.g. throw a user in front of 5 different systems and do the same task.

    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.

This is an absurd complaint by a millionaire who is too important to document his work. Boo hoo.