> I do not see a single argument that supports the “bad software” claim.

What is bad in this article is not the software. It is a software.

>>There’s no easy solution

No? The doctor's frustration seems pretty simple - just let them go left/right for newer/older notes on the patient's health. Seems simple enough to me.

I would be tremendously surprised if this were not possible. I have seen many programs at various doctors’ offices and all of them could do this.

I suspect that instead the doctor was not properly taught how to operate the software. Of course this could also mean the UX is bad, yes. I’m not convinced yet however.

The fact the doctor struggles is literally the definition of a bad UX. I don't understand how you can suggest anything else. It might be the doctor can learn a new workflow which is as good as or better than previously, but you can't just impose that on someone.

I can easily imagine how it is both possible and bad solution. You only see one piece of information at a time, out of context. Here it's painfully obvious to me how nobody bothered with formatting the whole patient record as a document that can be read at once without mad clicking. No skeuomorphy is necessary at all, just a scrollable document-like output with all the information visible and sanely formatted.

It might even have been suggested and rejected because that UI is against someone's "no scrollbars" or such dogma...

When the purpose of the software is to support the existing practice, if the users don't see the benefit then the software has failed. If this is the end result of going digital, the correct solution is to not go digital.

Skeuomorphism may or may not be the right answer -- I suspect not, but anything's possible. What the doctor appears to miss, though, is the time-based context of a document. It might be significantly easier to find a single record (especially if you don't know when something was recorded) but whoever specified the software missed the utility of a time-based context.

Or possibly failed to train the doctor on how to do with the software what they were used to doing with a physical file, but that would still count as a failure of the digitisation effort.

Most doctors practice in clinics where software is mandated by the administration, which in turn has pressures from insurance companies that the software was likely chosen to satisfy.

Put more simply: Doctors these days likely cannot choose to avoid going digital.

There's a key point missing from most of the discussion: "In the USA".

Also, whether or not it's the choice of the doctors is only tangentially relevant to whether or not it's a failure of the system. Even if money is the only consideration, I'd question whether the system as described is the most effective. Ultimately, a US-based medical administration bills on being able to show that they've done things that they can justify having done. Hobbling the doctors' capacity to actually carry out work impedes that process, regardless of any questions around medical effectiveness.

And of course, "going digital" doesn't strictly imply moving to a broken system either.

Take your workflow, whatever it is. Probably it works for you. Now, artificially limit the things you used to do. For example, if you have 2 monitors, drop to one smaller screen. If you used emacs, uninstall it and restrict yourself to notepad++.

Will you reach the same level of comfort and productivity?

Programmers tend to have rather personalized setups that they've developed over the years but software companies tend to produce one-size-fits-all solutions. A new doctor might be used to working within the confines of Epic, but an older doctor is used to being able to have the pieces of paper in front of them, tactile, movable, etc. Going to a system with a screen for problem list, a separate screen for visit, a third screen for prescriptions, a fourth screen for labs, means that doctor is no longer allowed to organize their thoughts the same way.

> Will you reach the same level of comfort and productivity?

Given time to adjust? Sure. This type of thing is a time limited problem.

> Given time to adjust? Sure.

You cannot mechanically return to the same level of productivity with that tool degradation, so I don't think so.