Then the computerized systems "replaced" that staff but all that really means is they cut the human time needed low enough that full-time workers weren't needed, but didn't eliminate it, so now that's another thing doctors have to do themselves.
AFAI can tell, the effect of tech overall is to cut some jobs while making the remaining ones harder and more stressful, while increasing so-called context switching.
No, that's not it at all. What GP is saying is that they cut the human expertise low enough that full-time workers weren't needed. The manpower savings never materialized because an app built for experts is faster than one built for casual users, and also because those experts, even with the high training cost, were ultimately cheaper per hour than the highly compensated people who now have to do the job because we 'made it easy'. First you devalue those experts by making their job harder, then you get rid of the job and make it someone else's, split between entry level staff and your most expensive employees.
> AFAI can tell, the effect of tech overall is to cut some jobs while making the remaining ones harder and more stressful, while increasing so-called context switching.
You still got there in the end.
If their employment status was the same as everyone else’s, there wouldn’t be any effort to replace admin staff with someone getting paid 10x as much unless there was actually a 90% reduction in work (doubtful).
Remind me again why do I have to manage my own meetings and prepare so many powerpoints and fill in so many forms as a... well, my position doesn't matter, because everyone is doing the same, no matter their role?
This is so much like hearing of engineers that will not hire a $20/hr maid due to egalitarian reasons so they squat in filth or waste all their free hours cleaning, all while capable and willing cleaners starve. Insane.
Also there are plenty of costs to employing others besides the hourly cost. Large organizations have huge fixed costs to cover them. Consider:
- liability
- maintaining of knowledge and training to hire help
- skill to source and hire people
So a part of the job has always been the record keeping, OTOH, as one of the other users mentioned, I've seen enough Dr's using their computer records systems to know that software is mostly garbage. The Dr's spend 2-4x the time dealing with the shitty UI as actually typing in the notes now.
(In the end he basically retired instead of convert to electronic records).
For those that seemed to transfer successfully, I noted that at Mayo Clinic, the doctors use live dictation software and dictate at least some of their notes into the system while the patient is present near the end. This immediate review sometimes brings up a few new questions (from either Dr or patient), and a bit more notetaking. So, it looks like a very efficient system. They also have no apparent shortage of staff organizing things.
That said, I doubt every medical organization and office has the same quality setup as a top world-class institution. At some level of degradation, the system becomes more of a hindrance than a help, and that point is likely fairly near the top levels (so most of it is a hindrance).
What form would give validation error or warning that a note the Dr is making either raises a new question by the patient or is in conflict with something the patient knows?
(& yes, from what I could see, there were also fields for patient data, date, etc, that are presumably validation-checked)
What I've noticed is that EMR has greatly reduced the amounts of screw-ups or delays caused by not having the right information at hand, or having to repeat tests. Also, since there's now a terminal in every examining room, I can see what amount of effort is required to use the EMR tool (Epic in the case of my provider), and it doesn't seem all that onerous. I can guesstimate the additional amount of time that they spend outside of clinic hours, completing their records for the day, and again, it doesn't seem onerous.
For a few years I had to fill out a lengthy medical history form, every time I visited a clinic, but that's pretty much gone today. My primary care doctor just retired, and her replacement took up the baton without skipping a beat. She can also easily delegate to her physician's assistant or nurse practitioner, so they can all work as a team, with instant access to the same information.
Now I have noticed something interesting. The urgent and primary care clinics all have a terminal in every examining room, and the clinicians perform their examinations while seated at the terminal, except when they actually have to poke around. That's where it seems quite efficient.
In the hospital wards, they still don't have a terminal in each room, meaning that each clinician has to look things up at centralized terminals, remember them (or not), and has no access to information. If they need some information, they will come back with it, next time their make their rounds, which might be the next day. And they screw up. My dad had an episode that took him through an ER, to a regular hospital bed for a few days, then to a rehab ward. I had all of his records at my fingertips thanks to MyChart on my laptop. The doctors and nurses were lost, they completely overlooked the documented diagnosis that was at the root of is condition, and didn't believe me about it.
Some of the nurses in the hospitals now have a terminal on a wheeled cart, that they bring on their rounds.
What I'm guessing is that in the days of handwritten records, the doctors were mostly winging it.
100% agree.
The Office suite is, in some ways, the worst thing that happened to corporations. Thanks to computers, everyone can now easily write a report, fill in a spreadsheet, or manage their meetings. Which means that everyone now has to write reports, fill in spreadsheets and manage their calendars. This used to be a separate job. You had people specializing in those tasks, and they were focused and efficient at it. Now, everyone does it on their own, and not only we suck at this, it's also distracting us from the "main" job we're supposed to be doing.
The older I get, the more I feel computer revolution was in big part a bait-and-switch.
You're not the only one with that bait and switch feeling.
It was pre-AJAX and pre-"Javascript being useful", I think even pre-Firefox and was IE6 only. So it was loading java applets and stuff to just get some basic functionality
Going a little further, this was appealing in part to avoid simple medical errors & oversights. Losing the record, mixing up records, incomplete history, and so on. Eliminating medical error is incredibly valuable but doesn't show up as "productivity".
The problem is: how do you allow departments to retain their fiefdoms in a world of centralised data? The answer is to spend a fortune on management consulting.
https://en.m.wikipedia.org/wiki/VistA
It's actually public domain and open-source. Unfortunately the VA is in an ongoing project to replace it with Cerner Millennium.
The big issue from my EHR-adjacent vantage point is that all the money is in making giant, entrenched EHRs, whereas the future should be in lighter-weight services that conform to standards, and competition is between those services. That way you could gradually slice off VA functionality piece by piece, and have a successful, more efficient, gradual migration.
I guess they also make more sense to management since it looks like something they could do themselves, or at least understand.
It doesn’t help that the evaluators for a new system will also approach from the perspective of a new user, even though none of them will be a new user in some months.
I’ve so wanted to create auto-hot-keys for many tasks, but end up having to use (x,y) clicks where I get boned every design touch-up (deliberate or side-effect of another change).
Web tech broke all that:
- UI was/still is very high latency. Keystrokes input whilst the browser is waiting do not buffer, unlike in classical mainframe/terminal designs. They're just lost or worse might randomly interrupt your current transaction.
- HTML has no concept of keyboard shortcuts, accelerator keys, menus, context menus, command lines and other power user features that allow regular users to go fast.
We adopted web tech even for productivity/crud apps, because browsers solved distribution at a time when Microsoft was badly dropping the ball on it. That solved problems for developers and allowed more rapid iteration, but ended up yielding lower productivity than older generations of apps for people who became highly skilled.
HTML has had a limited concept of accelerator keys for years, but it's not pretty:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
All of these (except logging on to the same data from all my devices, which is nice) benefit the developer at the expense of the user.
Glad you pointed that out. And, in the most prevalent application of Conway's law[0], those changes enabled and are entrenched by the "agile" practices in software development. Incremental work, continuous deployment, endless bugfixing and webapps fit each other like a glove (the latex kind that's used for deep examination of users' behavior).
It also enables data siloes and prevents any app from becoming a commodity - making software one of the strongest supplier-driven markets out there, which is why the frequent dismissal of legitimate complaints, "vote with your feet/wallet", does not work.
----
- Very high latency
- No support for online updates
- Impossible to easily administer
Cross platform was much less of a big deal when web apps started to get big. Windows just dominated in that time. Not many people cared about macOS Classic back then and desktop UNIX didn't matter at all. Browsers were nonetheless way easier to deal with than Windows itself.
Agree that killing piracy was a really big part of it. Of course, you can implement core logic and shared databases with non-web apps too, and the web has a semi-equivalent problem in the form of ad blockers.
Which translates into productivity. If something is standard, digital and transferable it means you can increase the rate of output in relation to its input (which is the definition of productivity).
- Need to retrieve past doctor visits about a patient? person at front desk no longer needs to walk to the folder closet, then scan the whole thing to find your name and then read through all of the documents to find the relevant visits. just click a button.
- How about getting the prescriptions provided to you from a previous doctor? Reduction in time to phone / fax the previous doctor. just click a button.
- Want to check if your insurance covers your procedure? Receptionist calls the carrier, sits on a 6.5 minute customer service wait queue, then gets the info versus 1-click.
- and, and...
It was always about productivity.
And back in the paper days, the staff would pull up the records for the days appointments. ER visits would have less data but normal medical care would be fine.
None those are related to use or lack of use of technology. Those are purely bureaucratic rules setup by insurance carriers.
> And back in the paper days, the staff would pull up the records for the days appointments.
And sometimes those papers would get lost, or maybe they're still sitting in the folder on a door because someone forget to clean them up, or they were in the wrong order so it took the person longer to find the person's name, appointments would shift, etc. etc.
I can't believe I'm having to explain to someone the productivity advantages of a system of record to a technology focused crowd...
They are very much related to use of technology, because they are enabled by technology. The degree of bullshit paperwork every white-collar worker has to deal with nowadays is a direct consequence of computers making it possible to make us do that work, and for the recipients to process it.
The benefits of those processes are whatever they are designed to be, but this creates a false image of net productivity, because the costs are now hidden, smeared across everyone's workload, adding to a vague sense of dissatisfaction and low productivity. In contrast, if you tried the same processes few decades ago, it would mean hiring dedicated people on both ends, and the costs - as measured by their salaries - would be clearly visible.
> I can't believe I'm having to explain to someone the productivity advantages of a system of record to a technology focused crowd...
You don't have to. But you're missing the disadvantages of the situation when maintenance of that system of records becomes a job distributed across everyone. It's not the digital recording per se that's the problem, but the fact that everyone is now also their own secretary.
These are bold claims backed up by little to no data other than your anecdotal observations. Productivity has generally been on a steady upward trend in the US since it was first measured in 1947. My own professional service business, which does require a decent amount of "bullshit paperwork" would not have been possible at the scale it achieved without technology.
> In contrast, if you tried the same processes few decades ago, it would mean hiring dedicated people on both ends, and the costs - as measured by their salaries - would be clearly visible.
Ever seen Mad Men? There was literally a full floor full of human beings typing out bullshit letters on typewriters because computers didn't exist in the era.
That's my point: those people received salaries for typing out those letters, making the cost of it clearly visible to the business.
Explain that one to me.
$68 Billion in medical fraud in the US
> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6139931/
Part of the opioid crisis caused by basically bribing doctors
Yes I’m well aware that when drug abuse was happening in the “inner cities” where the government looked the other way because it was more concerned with propping up countries during the Cold War, the same people who want to treat drug addiction like a “disease” when it’s happening in “rural America”, it blamed “single mothers” and “lack of morals”.
In general, I'll note producing documentation is fairly slow and tedious. It takes something like an order of magnitude longer to write a sentence than to read it. So this optimization is only going to be a productivity boost if this paperwork is accessed repeatedly, dozens of times in the course of treatment (the productive thing).
What paperwork creation increased as a result of digital record use?
I'm beginning to think y'all are conflating the increase of documentation with the use of digitalization. The two aren't mutually exclusive.
I think what we're talking about is a clear (if non-typical) example of the Jevons paradox[0]. Digitalization makes creating and processing paperwork more efficient, allowing the overall organization as a system to support/afford more of it. As a result, amount of documentation and form filling increases.
----
According to the Ford Motor Company, its fuel economy ranged between thirteen and twenty-one miles per gallon. There are vehicles on the road today that do worse than that; have we really made so little progress in more than a hundred years? But focussing on miles per gallon is the wrong way to assess the environmental impact of cars. Far more revealing is to consider the productivity of driving. Today, in contrast to the early nineteen-hundreds, any American with a license can cheaply travel almost anywhere, in almost any weather, in extraordinary comfort; can drive for thousands of miles with no maintenance other than refuelling; can easily find gas, food, lodging, and just about anything else within a short distance of almost any road; and can order and eat meals without undoing a seat belt or turning off the ceiling-mounted DVD player.
A modern driver, in other words, gets vastly more benefit from a gallon of gasoline—makes far more economical use of fuel—than any Model T owner ever did. Yet motorists’ energy consumption has grown by mind-boggling amounts, and, as the productivity of driving has increased and the cost of getting around has fallen, the global market for cars has surged. (Two of the biggest road-building efforts in the history of the world are currently under way in India and China.) And developing small, inexpensive vehicles that get a hundred miles to the gallon would only exacerbate that trend. The problem with efficiency gains is that we inevitably reinvest them in additional consumption.[0]
In other words, you're too narrowly focusing on "miles per gallon", not the fact that "any American with a license can cheaply travel almost anywhere, in almost any weather, in extraordinary comfort; can drive for thousands of miles with no maintenance other than refuelling; can easily find gas, food, lodging, and just about anything else within a short distance of almost any road; and can order and eat meals without undoing a seat belt or turning off the ceiling-mounted DVD player."
For example, in the show Mad Men, you'd see a whole floor full of human beings who's sole job was to type out letters on typewriters. Now, those jobs are obsolete and the white collar worker is responsible for them. Still bullshit paperwork, but the white collar worker now has to do them.
The overall trend for productivity since it was tracked in 1947 has been on an upward trend with its sharpest 1H downward trend ever this past year. Are you seriously suggesting white collar workers magically got more bullshit paperwork just these past 2 quarters?
[0] - https://www.newyorker.com/magazine/2010/12/20/the-efficiency...
Is there a "standard" medical record, or does each system implement its own proprietary format? Are the records transferrable? If so, why am I asked to fill out a complete medical history form on paper every time I visit the a doctor, as if I'm a new patient, when all the doctors I see are in the same network and presumably use the same EHR system.
Absolutely no way a modern system could be half as efficient, short of completely automating the whole job (which involved a lot of communication with other parties and basically freeform restrictions).
Early GUI's didn't have the problem you describe because they were designed as discovery mechanisms to the underlying function. AKA, the idea was that after clicking File->Save a dozen times you would remember the keyboard accelerators displayed on the right hand side of the menu. Or if nothing else, Remember that the F in File was underlined along with the "S" in Save (or whatever). Which would lead people to just press ctrl-s, or Alt-F, S. Then part of testing was making sure that that the tab key moved appropriately from field to field,etc.
I remember in the 1990's spending a fair amount of time doing keyboard optimization in a "reporting" application I wrote (which also had an early touchscreen) for use by people who's main job wasn't using a computer. Then we would have "training" classes and watch how they learned to use it.
So, much of this has been lost with modern "GUI's", even the OS vendors which should have been keeping their human interface guidelines updated, did stupid things like _HIDE_ the accelerator keys in windows if the user wasn't pressing the Alt key. Which destroys discoverability, because now users don't have the shortcut in their face. Nevermind the recent crazy nonsense where links and buttons are basically the same thing, sometimes triggering crazy behaviors like context menus and the like. Or just designing UI's where its impossible to know if something is actually a button because the link text is the same color as the rest of the text on the screen..
In the EHR space, all the CMO (chief medical officer) cares about is it helps keeps them in compliance. Why should they care if it’s hard for their office staff to use?
So there were two sides, the engine optimizations to assure things like tab orders on a form, and the was the actually writing the form descriptions. In the first couple organizations that adopted it I wrote the forms and the engine in parallel adding feature flags/controls as needed to support the desired UI outcomes. Later after I quit, the lady who wrote much of the RFP responses started writing the actual form descriptions because it was just as easy as drawing them out in the (visio?) plugin she was using with MS word and doing screen captures for the RFP. Then I guess because she knew how to do it, was doing the "tuning" as well.
The latter is definitely not the problem. Even the Twitter re-design from a couple years back still supports all the old hotkeys.
All it takes to at least support a tab-based workflow is using the "tabindex" property if your form isn't logically laid out already, and the rest can be done by capturing hotkeys.
Even multimedia content can be operated using hotkeys. Youtube is a good example. There's no excuse but laziness and incompetence IMO.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
If you watch people use the sabre command line interface (the one from the 1970s?), you can see some of what i'm talking about when people are just filling out the forms with the submission line, its less using the GUI and more just knowing some sequence of keystrokes that results in an action being taken.
AKA its possible to do both, without having the user wear out the tab key, or grabbing the mouse all the time.
A sign up form that a given user will only use once in their lifetime is another matter. It needs to be simple lest the user abandons the process. Most users in that case are not willing to learn keyboard shortcuts, tabbing over optional fields probably makes more sense here.
I'm constantly writing UI for sports teams who do not at all like to waste time with these kind of fiddly UI elements and flows. Most of them would likely stick to Excel if our solutions are more cumbersome (which is a high bar to meet/beat, but rightfully so). They need to be able to easily get to data and relevant, connected pieces of data, quickly enter data into relatively complex forms, and have it all be clear, reliable, and fault-tolerant. This means making some tradeoffs, particularly around what is considered modern UI aesthetics, and doing things most UI developers don't need to do such as automating little things, adding hotkeys, etc.
Kind of a hard core position in my opinion considering it's ignoring the sometimes advantages / use cases for client side code (like complicated SPAs where the user is explicitly buying into the idea of running lots of code in their browser, figma comes to mind) but I still like to think about it here and there.
99% of web applications are not Figma and probably do not need any client side JavaScript. The amount of JavaScript that's actually just wrong is incredible.
1. I don't care what your client side validation thinks. That is my email address.
2. Why are you serving people all of the news story if you are going to then hide it? We can block the JavaScript and read the news.
So I don't disagree on merit alone, but it seems if we wanna do a good capitalism, we need to make sure people are actually giving us real emails apparently
In fact, it makes the experience generally worse.
Tying this back to the top-level comment: at some point I've realized that so many SaaS would be better off as an Excel sheet, because they're fundamentally just a slower, buggier, much less productive and uglier version of one. But the point isn't efficiency and empowerment. The point is control: the SaaS forces the user to a specific workflow. One that makes it easier for developers to develop (by constraining the problem space), or for company to monetize, or for corporate to retain legibility - but rarely to actually help the end-user.
As an end user from a generation that was taught Excel and MS Access at school, I'd go as far as saying that 50+% of web applications I use would be an order of magnitude more useful if the UX was that of Excel or Access.
I preach this all the time. Anyone who has to enter data really wants excel and not the fancy wizardized stepped workflow that seems to be the norm nowadays
I suspect an overwhelming majority of use cases is for this reason alone.
As you say the web is a culprit but so is attempting to shoehorn mobile designs into desktop.
With some OS's you can't even have fine grained control over those defaults anymore. Dark modes have brought some of it back, so its better now than 5 years ago, but still worse than 20 years ago. But people pretend that having a dark/light switch is the same thing as being able to customize the color of just about every layer of the UI and have the vast majority of the applications honor it.
Where we partially lost that is when UX started to get async. It's not fundamentally incompatible with well-ordered input messages, but in practice, people who write async code all too often forget that it's async all the way (and not just for their favorite scenario). And so you get travesties such as textboxes that let you type text into them, and then erase all that when the app or the page is "fully loaded".
I was at the post office here in Australia a few years ago and saw the screen. It was one of those DOS-era full screen red and blue text interfaces. She was flying through hotkeys and getting things done. People can learn, so much software treats them as infants.
And you know there's definitely someone looking at replacing that software with a modern GUI.
You should see the customized JBHIFI terminal + keyboard.
Bloomberg terminals also have a custom keyboard and are essentially a terminal program.
It was supposed to be read:
A [ncurses or gum] workflow.
Gum being an alternative method of making a Bash UI.
At the time I had no idea why. In hindsight, it's hilarious. I'm guessing it was the result of a clash between someone that wanted to use modern tech for the sake of it and someone representing the users that told them to get fucked, probably went through 15 meetings before eventually getting palmed off on the intern so it didn't pick up too much steam (probably the only good decision that was made in the whole process).
So learning an interface is frowned upon. Every interface must be designed as if the user has never seen it before.
Which is ok, as long as there’s also an alternative path which may take time and effort to learn but leads to increased efficiency and productivity.
Unfortunately, that alternate path takes a lot of effort. And worse, it leads to very few extra sales. The company which puts in the effort to build a complex but efficient workflow in addition to the initial easy workflow will get beat in the market by competitors who only focus on the easy workflow that looks great in demos leading to the C-suiters to buy it.
The best example is the pioneer of both these trends. Apple. It used to be that Apple insisted on a single button mouse so the primary interface was extremely easy to use. Yet, it spent a lot of effort including keyboard shortcuts, which were prominently displayed, everywhere. Unlike Windows, which basically only had Ctrl/Alt modifier keys, Apple has had the Ctrl/CMD/Opt modifier keys as integral parts for a very long time, encouraging those shortcuts. Apple also put s lot of effort to make their, and 3rd party applications easily scriptable (the choice of AppleScript however always held this back). The most MS did was VBA for Office.
But once Apple entered the iEra, it realized it didn’t need any of this to sell products anymore. The massive lag in supporting basic keyboard shortcuts on the iPad when using a keyboard is one of the strongest evidence for this.
Completely agree with all of this.
Adding that it's not even web technologies that can't be used. My work Mac had an issue with a Bluetooth mouse, removing and adding a Bluetooth device with the keyboard is basically impossible using tab as nothing gets highlighted to show you switched to it and some of the crucial parts don't get toggled through.
Modern GUIs are absolutely not fit for purpose.
No one knows what they really want till the software starts getting written and someone finds out they can't do their job, then come change requests (made a lot of money off of them). You kind of just get numb to it all.
---
The system distinguished between errors that halted the machine, requiring a restart, and errors which merely paused the machine (which allowed operators to continue with the same settings using a keypress). However, some errors which endangered the patient merely paused the machine, and the frequent occurrence of minor errors caused operators to become accustomed to habitually unpausing the machine.
One failure occurred when a particular sequence of keystrokes was entered on the VT-100 terminal which controlled the PDP-11 computer: if the operator were to press "X" to (erroneously) select 25 MeV photon mode, then use "cursor up" to edit the input to "E" to (correctly) select 25 MeV Electron mode, then "Enter", all within eight seconds of the first keypress, well within the capability of an experienced user of the machine. These edits weren't noticed as it would take 8 seconds for startup, so it would go with the default setup.[3]
---
... which allowed the electron beam to be set for X-ray mode without the X-ray target being in place. A second fault allowed the electron beam to activate during field-light mode, during which no beam scanner was active or target was in place.
Previous models had hardware interlocks to prevent such faults, but the Therac-25 had removed them, depending instead on software checks for safety.
The high-current electron beam struck the patients with approximately 100 times the intended dose of radiation, and over a narrower area, delivering a potentially lethal dose of beta radiation. The feeling was described by patient Ray Cox as "an intense electric shock", causing him to scream and run out of the treatment room.[4] Several days later, radiation burns appeared, and the patients showed the symptoms of radiation poisoning; in three cases, the injured patients later died as a result of the overdose.[5]
---
In response to incidents like those associated with Therac-25, the IEC 62304 standard was created, which introduces development life cycle standards for medical device software and specific guidance on using software of unknown pedigree.[7]
You also have a hardware lock on the power - this can be as simple as a hardware timer (a RC circuit siffices) which limits how long the emitter can be on within in a given window to be safe.
Never trust the software. If you must trust some software, create a minimal set you CAN trust which isolates the rest of the software from the hardware.
You are correct, the discussion about how to exercise this bug (fast UI, blah blah) is interesting to hear but totally irrelevant to the lesson (don't trust software).
Not in medicine (run a small e-commerce business selling mostly used video games), but definitely noticed the same thing for us.
We have some terminal-based Python scripts I wrote to automate a lot of the data entry tasks like listing and shipping (entering tracking numbers, printing labels).
Everyone that uses the scripts is initially apprehensive, but then after maybe a day of getting used to the terminal turns into a powerful data entry God and they love it. Even had an employee gush about our shipping tool to a random supplier.
The greenscreen data entry was highly optimised to not even require tabbing to different fields, but just run the values together in a large single field and the software would split them into fields and validate them.
I assume it was very fast and efficient for the experienced operators.
I can imagine this being true. It seems that almost the whole software industry has failed to grasp the distinction between an appliance and a tool. An appliance you expect almost anyone to be able to use without training. A tool, well you are expected to learn how to use it, and after that, you are much more productive than before. And most software seems to be moving towards appliance.
Well, EHR is a glorified billing platform.
Thing to remember finance/economists/rentiers have a different definition of efficiency and productivity than you do. In this case the productivity has to do with billing not the uninteresting things that doctors do. By reducing the cost of billing and forcing doctors to document more things to be billed more money can be extracted.
Productivity is indeed a selling point.
I will also tell you that EHR software is universally hated by doctors. Does not matter who makes it. The company that cracks that will make billions.
One interesting idea was a voice assistant wired up to take inputs as doctors did their work. I don't think it went anywhere (yet).
Considering how often I have to fill out the same goddamn forms (sometimes literally down the hall in the same building as another doctor), I think that goal failed miserably.
While in the hospital, the phlebotomists came after me for routine lab work at hospital prices. I declined and then I had a conversation with the nurse about releasing my labs from June to them. On script, she said "Mmm, 4 months is kinda old! We'd rather do our own!" so I filled out the ROI anyway, and curiously nobody offered to draw my blood again.
This comports with my most recent experience using SAP in 2018. I know, I know, SAP has GUIs and such now. This well known and profitable corporation under the Blackstone umbrella, though? Nope. It was exactly as you describe.
Those who had the time-in-service or the mentality to accept it excelled at their job, but uniformly skewed older (late 40s and up) or younger (under 25). At the time, almost everyone aged in between was entirely befuddled by it all.
Context: supply chain, procurement, purchasing, logistics, maintenance, work orders, inventory
First, yes, productivity was one of the goals of the forced move to electronic health records systems. The federal government passed the HITECH Act in 2009 creating economic incentives for doctors to switch to EHRs because it would be better for public health, Medicare billing, and also because it would supposedly unlock doctors to spend more time with patients and be more productive, via the use of technology.
The reason that third thing has failed, to my mind, is largely because the government, in the same act, required a HUGE list of requirements be met by the software designers making the EHRs. This list, by law, needs to be prioritized in scrums over customer requests and design thinking. Sometimes it makes good UX impossible.
Ironically, the government, hearing this feedback, actually added a new requirement to the list: "Safety-Enhanced Design" [0].
Go read that regulatory requirement and see if it makes any sense to you. That's why design sucks in EHRs.
[0] https://www.healthit.gov/test-method/safety-enhanced-design
I will say that small, private clinics who only accept private insurance don't necessarily need to use a federally certified EHR. They are legally allowed to build their own system. One example is OneMedical. When you ask the doctors/PAs/nurses at OneMedical about their EHR, they actually love it.
I think the first step would be validating my anecdotal experience here by polling doctors using non-certified EHRs to see if they like them more. If they do by an overwhelming amount, I'd first take that evidence to the Office of the National Coordinator (the government agency created by the aforementioned HITECH Act who makes the certification criteria). I'd tell them that if they vastly simplify the criteria and add more flexibility, they'd make doctors happier.
I guess the problem is that happy doctors, unfortunately, isn't necessarily aligned with the existing federal laws. Probably you'd need to pass a new statute at Congress, this time around with the benefit of talking to a lot of people with experience making EHRs.
I considered targeting standardization in health tech for a while and uncovered a similar layer of red tape as you describe. We can't continue to let our medical system continue to lag behind the rest of the world's and good EHRs are a part of that.
I'm not entirely sure about this. During the early digitization era productivity was a big driver. Modern word processors are a godsend if you've ever tried to typewrite a document for publication (forget anything with complex formulae) or dealt with actual physical spreadsheets? Office itself and it's now many clones is a fantastic set of tools for productivity.
My opinion is that we've created a world in technology now that drives technology for the sake of tech and financial drivers. I regularly deal with people who think it would be a great idea to build a system to automate some aspect of business that's already well optimized or generalize something they thing is general but is really quite niche.
There are certainly cases where it makes sense to develop a system around something but you need to consider the full cost/benefit tradeoffs, not just benefits which industry tends to do.
As the company customized more and more of the code base, upgrades to the system became more and more difficult. Every upgrade required a manual comparison of custom code to be merged with the baseline code. This led to skipped upgrades, and eventually a cessation of upgrades. Of course, after no upgrades over a long period of time it was eventually decided to move to a new ERP system.
I am still appalled at the things sacrificed to prevent disruption of a small group of peoples work flow.