Bad software destroyed my doctor's memory
theregister.com
theregister.com
I wrote my graduate thesis on digital medical record systems in family practice over a decade ago, user experience was a huge issue then as well. Having training sessions alone isn't enough.
The problem isn't going to be solved because doctors are not the primary customer for these systems, the procurement department is. They will care more about HIPAA compliance than whether the end-user can effectively replace their workflow with this new tool.
Agreed!
> the procurement department is.
But I disagree here.
From what I’ve seen in ambulatory EHRs, they are finely tuned for billing workflows. The key outcome is that a patient encounter is tied cleanly to an ICD. Actually tracking patient information in a useful way seems to be an afterthought.
[0] https://www.statnews.com/2020/02/27/physician-practice-conso...
In fact, I do not see a single argument that supports the “bad software” claim. Instead, I see something else: part of the information was not in the files that were digitized, but instead in the doctors head. This information is no longer applicable.
When you decide to go digital, the workflow changes, period. There’s no easy solution, it may take quite some time to let go of the old ways and embrace the new system.
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.
Given time to adjust? Sure. This type of thing is a time limited problem.
You cannot mechanically return to the same level of productivity with that tool degradation, so I don't think so.
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.
Put more simply: Doctors these days likely cannot choose to avoid going digital.
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.
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 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.
It might even have been suggested and rejected because that UI is against someone's "no scrollbars" or such dogma...
What is bad in this article is not the software. It is a software.
No its not just Big Pharma/Insurance, its every member of the medical cartel. From Physicians to Hospitals, to everyone in pharma, to BCBS.
The whole system is designed to stay exactly the same, with 5% Medicare raises every year(despite CPI being 2%/yr).
We own a practice and the billing practices make me sick. We blame insurance companies, but its really us, we could bill less, instead we bill the moon and let them 'adjust'. The licensure system is so bad, terrible students get through because every school wants a 99.9% graduation rate. Do not let anyone pretend that doctors in the US are better than elsewhere, we have terrible terrible doctors who did unethical things with full blown licenses. Everything in pharma is amazing to watch, there are so many unnecessary layers. Everyone makes crazy money in medical, anyone who complains about debt is just pretending they are wealthy to be more in-touch with the common person.
That’s because, as I understand it, EHRs are made primarily for insurance companies, not medical staff. This is a huge problem. IT staff should not be blamed.
If you're flicking through paper, it might be easier to e.g. scroll through records for a specific patient and to have some kind of contextual search. But I think the obvious issue is really that they haven't validated and iterated on the design with actual users or even had somebody on the team responsible for caring about this stuff.
I want to know what they're teaching these designers in design school because theyre fucking everything up. Or is it management making design decisions for them and they just go along with it for the paycheck? Are people in these companies deliberately sabotaging products? I don't know what it is but I'm sick of it.
I'll give you an example. When Android came out, one of the first, most important sets of requirements was that it do everything a normal cell phone could do the way a normal cell phone would do it. If you turn the volume all the way down, it must stay all the way down, period. And it worked like that, perfectly, for years. But recently, every so often, you want to play a video silently, and a chirp happens at the very beginning. Someone at some point changed the code where the volume control doesnt control the volume, it saves a variable that's read by the audio decoding software asynchronously and sometimes you get a race condition where audio starts before it is read. Why was this changed? Why is ensuring this functionality no longer a top priority?
That's just a tiny little example. With android, side scrolling menus, pages in the recent apps that take up the whole screen, little race conditions here and there. And that's just android, probably the least offensive software UX wise that there is. Hamburger menus, border less flat elements, nests upon nests, you see UX crumbling everywhere you look. I don't know what to make of it.
Want to buy some audiobooks for a long drive? You'll need to sign up for their subscription service!
Want to buy individual books? Well, for that, you'll OBVIOUSLY need to open Amazon.com _in desktop mode_ and click through a submenu to purchase them individually!
[0] https://www.amazon.com/Recoding-America-Government-Failing-D... — it was recommended on another HN thread.
However, there is large amount of variance in how users access and work with medical records, from person to person, role to role, specialty to specialty, hospital type to hospital type, org to org and it gets even worse when users are transitioning from paper. Skeuomorphism might be attractive to non-technical users in transition, but in my experience (this approach isn’t novel) it falls apart very quickly because a) as I previously suggested, there isn’t one model to replicate and skeuomorphic approaches tend to be rigid, and b) users usually very quickly grow out of analog processes as they adapt to software. It’s important to allow practices to customize views for roles and allow users to override so they can put the most important information at their fingertips, and make it quick and easy to jump into the rest of the full details of their record. It’s an information dense problem area, so your fluffy, padded, pretty commerce-focused user patterns are often an anti-pattern. Automation, driven by rules specified by practice and doctors, to help error check their records or point out patient issues (“patient has disease x but we don’t have record that they’ve done y and z preventative measures”, etc.) can help reduce cognitive load and simple mistakes. Dynamic, annotated notation systems driven by templates selected based on the appointment reason and patient history where they do more simply tapping/clicking checkboxes and less typing let doctors focus on interacting with the patient during encounters. Automatically pull in data collected by sensors (weight, blood pressure, whatever) speeds things up, especially for overworked supporting staff. Speed, stability, and consistency over everything.
Skeuomorphism really doesn’t help any of that. It was mostly a sales tool like 10-15 years ago.
I just finished listening to The Pragmatic Programmer (EXCELLENT as an audiobook), and the authors talk about this pretty explicitly:
> As soon as you have an executable user interface or prototype, you need to answer an all-important question: the users told you what they wanted, but is it what they need?
> Does it meet the functional requirements of the system? This, too, needs to be tested. A bug-free system that answers the wrong ques tion isn't very useful.
So it looks like some programmers need to read this book for homework!
As far as I can tell, the number one rule of being a UX or UI specialist is that one must never, under any circumstances, actually talk with a U, nor consult the team whose job it is to assist U's with the X the designers and developers swear up and down is so intuitive it should never require explanation.
Most applications are still horrible and unintuitive to the people expected to use them, especially when they're built for niche users. This is the normal experience of using software as a non-developer.
Almost every company has customer support people who are beating their heads against their desks trying desperately to surface this feedback in a way that anyone in the company will care about, but support agents "aren't technical," so the developers don't think they could possibly have anything useful to say about their work.
It's a vicious circle. It doesn't have to be this way. But I'm all put of ideas about how to change it.
"We notice you're all still using the old UI and talking about how bad the new UI is when it's actually great! You don't need those features that aren't accessible from the new UI anyway. We're going to default everyone to the new UI now and you'll have to manually change the setting back if you want to."
"Ok you're all still using the old UI, even though the new UI is obviously better, so we're going to turn off the old UI at the end of the month"
"Oooooops! A bunch of people said they'd stop paying us if we turned off the old UI so we will now keep the old UI on until the end of the year"
"The Old UI is gone now. Where did all our customers go?"
Instead of stand-ups let developers spend 15 minutes each day in a call with a customer who has a problem or feature request.
Extreme Programming got that part covered much better.
My experience in startups has been that improvements or bug fixes are often ignored in favor of projects that have some long-shot possibility of increasing revenue, even if the existing customers threaten to and do leave over the bugs and hate the new features.
Probably the solution is to have the developers get as deep an insight as possible into the problem area they are trying to solve, and work very closely with users at every stage.
Some even expect magical abilities from software to turn bad user data in correct data without any work by U. Address data comes to my mind.
Or I want to see all data at once but why does it take so long and doesn't fit on one page and is incomprehensible?
In my personal experience, this only happens after the development. We have found no way to obtain useful feedback during the design phase.
Exactly as I said, it's already too late. For it to be most effective, such advice must arrive before I start coding.
At least occasionally look at how actual users are using software?
In case of paying for software system I would require it as part of a contract.
If I would be decision maker on software project I would also demand it.
Ever used any Microsoft product recently ? Or the new xsnow which has a config screen when it starts ? Or Google with warning messages occupying half the screen ?
This is the trend since about 15 years.
Literally more windows 7 would be an upgrade over windows 11.
Whatever stuff they have going on in the background is not worth the anti-user crap.
The system in question is electronic health records (EHR). These are vast systems, really the comparison is "SAP for medical records" as they typically handle scheduling, billing, coding, store reports, notes, results (blood tests, as the tip of the ice berg). The tie ins to other systems are complex. And all of it is critical, as in patient injury or death if sole things go wrong. And much of it can fall under various federal laws, HIPAA is just the start.
These are long lived systems, upgraded over time. Replacing one can be a multi year effort for even a small organization. So replacing one isn't done because a new shiny one exists. New entries face a long battle into the industry, and the needs of a family physician are very different from a hospital or large group of hospitals.
If you want an idea of the scale and scope, the NYC Health and Hospitals project for their Epic EHR ran $1 billion over budget. Might have been more that that.
Journal systems "is a thing" with lots of hairy issues such as integrations between different hospitals and primary care givers, privacy issues etc.
These are not really solved yet, (even on a regional basis) and on top of this comes the probably most important thing, UX for the actual users such as doctors and nurses.
The people selling this software and buying this software are ultimately not the people that use it. In developers minds and according to their spec sheets, the sofware might actually be amazing and flawless.
And also there is no a single software thing except of maybe Common Lisp which scripts can overcome tens of years with keeping backward compatibility as a primary goal, I mean try to run any scripts from '10s '00s '90s in any other language except of CL. Software industry produces too shortliving things being promoted with bold and click-bait statements and when it breaks, typically because of becoming a legacy, they say you that you just need more software because your one is too old!