Absolutely it's about the administrative end and not patient care. We've got a situation in our regional health authority (Vancouver Island, BC, Canada) where they're trying to roll out a significant update/expansion to their EMR (Cerner-based) in the hospital in Nanaimo. Despite immense pressure, some docs have been now suspended for refusing to use it and switching back to paper, despite the massive increase in time it takes to provide the same patient care, and also because of notable examples where the EMR has endangered patient safety. (Google 'ihealth nanaimo' if you're curious for details, then rinse and repeat for the same story in so many other places)
This is a pretty shocking opinion to see expressed. Like, you may as well have said "A bunch of developers at <place> decided to go back to C89 because writing code in Rust was too slow, plus did you see the bugs in its borrow checker?" . Do you really believe that paper is a safer alternative?
Can't chime in on safety issues, but on usability: I know a physician who transitioned to using EMR roughly five years ago. It doubled the amount of time they need to take notes, to this day. They can't see nearly the same amount of patients they used to because so much of their day is spent going into and out of full screen surprise submenus in the EMR software and flipping through different tabs and re-entering information into multiple forms and scrolling through dropdowns with multiple hundreds of options. GP's post is 100% believable for me. It's nothing like Rust vs C89. It's more coding with punch cards vs an IDE, except the EMRs are the punch cards.
Doing things via pen and paper can be safer than doing things by a complex, poorly designed computer system that doesn't take into account actual work practices, patterns of collaboration that involve artifacts like paper as an essential part of communication and work flow that isn't captured by these computer systems. You need some serious perspective if you think just computerizing something is necessarily making it better, and that it can't turn out to be a disaster.
A better analogy would be ticketing in Jira versus ticketing with Post-It Notes. The main job of the professional (medicine/programming) is not what's at stake here. We're talking about documentation. Jira is a heavyweight ticketing system that is okay, but a lot of people are really slowed down by it, and if there are problems with the network, no-one gets much effective work done. Post-its are less visible to all stakeholders, but they let the worker get on with their primary job with less interference.
Keep in mind that medical software isn't written with the latest and greatest frameworks and UX designers.
The Jira analogy falls a little bit flat, because the information entered into an EMR is often the actual product, not just documentation. Orders entered into the EMR directly affect the outcome of the patient, and errors can be fatal. Having a free-text hand-written system for something like that just seems pretty crazy. It'd be like going to a dev shop where no one used linters or wrote tests and the check for deploying to prod with no rollback option was one (admittedly extremely skilled) guy in the basement signing off after a quick code review.
Two bad things that can happen... one, the order entry procedure on the computer (besides being more time consuming) has usability problems that make it easy to enter the wrong thing accidentally. And an incorrect order looks as official as a correct order. In the old scribble system, where everyone deals with the same physical chart, things that may be a bit more ambiguous/indecipherable are more apparent. Plus, equally importantly, there's more communication between different professionals around the chart. The EMR takes a lot of the ad hoc communication out of the equation. For an example of this in another domain, air traffic controllers used paper "flight strips" to represent current state; initial attempts at computerizing these completely missed that the strips were not only information but also a vehicle for ad hoc communication, and that latter part, critical to work actually being done, was missed in the computer systems.
