12 ms·

I don’t think productivity was ever the goal of this software. It was to have a record that is standard, digital, transferable, etc. Doctors fought it as long a

• FunnyBadger 4y ago
• yamtaddle 4y ago
  They also fought it because they didn't go to medical school and survive residency to fill out forms all damn day—and they didn't used to have to, they had staff for that. 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.
  • t-writescode 4y ago
    Sounds like modern startup devops-without-devops culture
    • throwaway5959 4y ago
      Shift left amirite? Same with DBAs.
      • lamontcg 4y ago
        Don't need DBAs if you're hiring 10x full stack developers.
  • nradov 4y ago
    Some healthcare provider organizations now employ medical scribes who follow physicians around and do all their EHR data entry. This is expensive, but can be cost effective because then the physicians have more time to perform billable procedures.
    • yamtaddle 4y ago
      If so, that's hilarious, because that's precisely one of the jobs all these expensive, painful-to-use computer systems were supposed to replace. You'd take a year or two course at junior college, to learn shorthand and drill some medical terminology so you'd be less likely to make a bunch of simple transcription mistakes, then go to work.
      • nradov 4y ago
        There's still a fairly large job market for medical transcriptionists, but that's a different job than being a medical scribe. Transcriptionists don't use shorthand any more, they mostly work from digital voice recordings. And they're typically not transcribing from scratch; now usually a voice recognition system does the first pass and then the human edits it to fix the ~2% errors. Transcriptionists don't usually work directly in EHRs, but their documents are fed into EHRs.
        • robertlagrant 4y ago
          Microsoft recently bought Nuance for this very reason.
      • TeMPOraL 4y ago
        It's doubly hilarious when you realize it's the inverse of what the office productivity software did to everyone. 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?
    • warbler73 4y ago
      The least capable doctor's time is worth $300/hr. The scribe is paid what, $25/hr? 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.
  • ameister14 4y ago
    That and the staff actually doubled over the same period
  • Scoundreller 4y ago
    Seems an artefact of doctors not being employees. 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).
    • onlyrealcuzzo 4y ago
      You can reduce 90% of the work - but if the remaining 10% is shifted to someone that gets paid 50x as much, it's still a loss.
      • Dylan16807 4y ago
        I, yes, that was their point. You're just saying the same thing with different numbers.
    • mattkrause 4y ago
      Laughs from academia....
      • Scoundreller 4y ago
        Trick is to be hourly!
  • hinkley 4y ago
    > they cut the human time needed low enough that full-time workers weren't needed 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.
  • StillBored 4y ago
    But the doctors almost always were taking notes anyway. My step father (A doctor) fought a losing battle against electronic records because he had _decades_ of paper records stored in the "records" room of his office. That was largely the responsibility of the front desk to pull the patients records and have them ready for him to read/check before seeing the patient. Then clean them up and refile them. Long term patients had pages and pages of hand written notes, prescription histories, etc. 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).
    • covidiot5 4y ago
      They’re taking notes with cheap pencils and paper! We should sell them an complex, messy to build, fleet of machines! It’s like cutting off a head when stitching a cut on the leg was the problem.
    • toss1 4y ago
      Sounds about right 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).
      • bombcar 4y ago
        Dictating while the patient is there is brilliant, because it double-checks both the doctor and the patient's understanding of what happened.
  • TeMPOraL 4y ago
    > 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. 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.
    • chiefalchemist 4y ago
      Great point(s). There's no longer the barrier to entry. No longer a belief that just because you can doesn't mean you should. That behaviour gets reinforced because doing X or Y is easy, that lack of friction builds a bias that the end product / output is 10x better than it really is. You're not the only one with that bait and switch feeling.
• givemeethekeys 4y ago
  We can use an all HTML, Javascript-free interface that people can still memorize and quickly Tab through.
  • conductr 4y ago
    But that's not what anyone was selling at the time. I'm sure complexity has only increased since then. 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
• ip26 4y ago
  I don’t think productivity was ever the goal of this software. It was to have a record that is standard, digital, transferable, etc. 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".
  • sokoloff 4y ago
    This is amusing as, 10 years ago, my wife (a decade-plus under 60, even now) showed up to a consultation with a doctor who remarked that she looked very good for someone over 60 and who suffered from a series of conditions that she did not have but showed up in "her" medical records.
    • conductr 4y ago
      My wife is in 30s but has had a lot of women's health stuff going on the last decade. We stay completely within the same "healthcare network" of hospitals precisely because they actually use the same system and all doctors can access it (obviously we like the providers as well!) But even for basic procedures we could save a little on like lab work or imaging by going out of this network we've learned it doesn't really work as promised. It's still hard to get your records to stay together unless they're in the same company's database is what we've learned.
      • lotsofpulp 4y ago
        We do the same. My wife sees tons of suboptimal healthcare delivery due to lack of doctors having the necessary information. In our current area, it is easy to find doctors they use mychart and interface with local hospital, so if we were to end up in the hospital, our medical history is immediately available.
      • robertlagrant 4y ago
        Yes. All the systems are set up this way. 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.
• Underqualified 4y ago
  The GUI apps have the benefit of being easier for onboarding. We've redesigned the workplace to deal with constant employee turnover. I guess they also make more sense to management since it looks like something they could do themselves, or at least understand.
  • tremon 4y ago
    This is a good observation. Constant employee turnover also reduces worker productivity, as it means most current employees are juniors in their role (regardless of what their title says).
  • Scoundreller 4y ago
    Problem is the GUI could have shortcuts for everything, but usually won’t. 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).
  • mike_hearn 4y ago
    You can have both. GUIs were a breakthrough because they enabled much better discoverability, allowed images in the UI and so on. But they were also designed to be fully keyboardable and low latency. 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.
    • tomcam 4y ago
• mbesto 4y ago
  > It was to have a record that is standard, digital, transferable, etc. 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).
  • marginalia_nu 4y ago
    Right, but it's the records that are standard, digital and transferrable; not the work. So what you end up optimizing for is producing paperwork.
    • mbesto 4y ago
      huh? if the records are "standard, digital and transferrable", it means all of the work associated with those records is sped up. - 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.
      • marginalia_nu 4y ago
        That will only be a speed-up if the time saved from easier information retrieval is smaller than the time spent in increased paperwork, which it may or may not be, but is an assertion that needs justification. 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).
        • 4y ago
• covidiot5 4y ago
• VBprogrammer 4y ago
  At Uni as a summer job I worked processing Corporate Actions for a large custodial bank. We used exactly the same kind of system where every action was 4 characters. I can still remember some of them despite it being 10 years since I did that job. Even more importantly, the screens were trivially scriptable so lots of the grunt work could be handled by writing export scripts, pulling a bunch of data into excel, processing it and occasionally posting the results back the same way. 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).
  • P_I_Staker 4y ago
    You could provide a terminal UI from within the GUI (it's not unheard of and can work quite well)
    • VBprogrammer 4y ago
      Alas, most modern software doesn't come with the option of a GUI. It's a HTML document pressed into service as a GUI with a greater or lesser degree of success.
      • P_I_Staker 4y ago
        I see. Well... piss.
        • VBprogrammer 4y ago
          Lol!
• StillBored 4y ago
  IMHO, this is because the people writting GUI's these days are mostly incompetent, or hamstrung by "web" technologies. 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..
  • conductr 4y ago
    It's also because it's enterprise software. Which actually isn't software, it's more of a platform. You have to do so much implementation detail that the GUI is just the result of some form-builder type module. Everything I've ever encountered that was enterprise software, felt like it's GUI was not made by humans at all. I don't actually know how they get built but they're almost never optimized for humans or the usage they're meant to benefit.
    • badpun 4y ago
      Nobody wants to pay for better GUIs in enterprise software, so no vendor puts any attention into them. An Enterprise Architect explicitly explained to me (when I was raising a point of choosing a software package that had much better UI) that good UX is a small factor and company (a bank in that case) would rather buy cheaper software and just have its workers suffer more, because it's deemed more cost-effective.
• QuercusMax 4y ago
  "Fun" fact: the Therac-25 tragedy was in part caused by this type of usage - folks who know it so well they just blast through the screens from memory. But the software in question wasn't resilient to this use-case, and apparently resulted in an inconsistent state.
  • gridspy 4y ago
    Good example. --- 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] https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25
• prlyons 4y ago
  Another reason is to satisfy insurers increasing demands for documentation to backup billing.
• AussieWog93 4y ago
  >This is when I formed my “never replace a terminal based app, with a GUI based app and expect productivity gains” theory. 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.
  • Smoosh 4y ago
    Back in the late '80s the government department I worked at had a dedicated data entry team with their own system (hardware and all). 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.
• beefield 4y ago
  > never replace a terminal based app, with a GUI based app and expect productivity gains 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.
  • conductr 4y ago
    I like this dichotomy. I'd want to add a third, the product. The product has ego, it needs to look nice, it needs to demo well, it is marketing. This is what the auto industry has become since the model T and it's what software has become since it was a tool. The problem is with software, things like productivity typically take a hit as it moves further from tool to product. More so when the domain is something like EHR or ERP or E anything.
• kakoni 4y ago
  > I don’t think productivity was ever the goal of this software. Well, EHR is a glorified billing platform.
• Gibbon1 4y ago
  > I don’t think productivity was ever the goal of this software. 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.
• RajT88 4y ago
  I used to work in Healthcare software (Not Epic). 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).
  • darkmarmot 4y ago
    I work in it too. And the US govt is not approving or even looking to approve new EHRs. The bureaucratic hurdles (and regulatory capture) are such that it is no longer feasible in this country. I would write one in a heartbeat if it wasn't a doomed venture.
    • adunsulag 4y ago
      There are lots of new EHRs being approved. Just go look on CHPL and you can see that there are a 100 new EHRs that have made it through the 2015 Cures Update certification. Its hard and expensive but it can be done as I can attest to getting our product certified just this year.
• vidanay 4y ago
  > It was to have a record that is standard, digital, transferable, etc. 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.
  • Eleison23 4y ago
    No practice or healthcare system accepts anyone else's records. There is supposedly a way for the patient to release records and have them sent around, but none of the doctors I've asked will accept that sort of nonsense. It's "NIH" for healthcare - if they didn't generate the record, they don't want it. 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.
• peteradio 4y ago
  Mouse moves are crack for ml algorithms if the interface is maintained somehow.
• drited 4y ago
  Sounds like Bloomberg.
• jimmygrapes 4y ago
  > [...] they type in some random 3 letter code and a screen would pop up. Then they would memorize how many tabs each field was apart from each other. Without a mouse, people could just hum along imputing data a blazing speed once some muscle memory was in place. Everyone had little cheat sheets printed out for the less frequently used commands/codes. 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
• johndhi 4y ago
  As someone who worked in the electronic health records industry, closely with design teams, and has thought more deeply about certain aspects of this problem than anyone else in history (not exaggerating), I think you're missing major factors. 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 https://www.healthit.gov/test-method/safety-enhanced-design
  • soulofmischief 4y ago
    What do you see as the way out of this mess?
    • johndhi 4y ago
      Hmm. There are many layers of problems in the healthcare system, EHRs with bad design only one. 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.
• Frost1x 4y ago
  >I don’t think productivity was ever the goal of this software. 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.
• SapporoChris 4y ago
  This memorization and strict adherence to past ways of doing things killed me as a developer. I was tasked with maintaining and customizing an Enterprise Resource Planning system. It was a terminal based app. Sometimes system upgrades would add a field to a screen. For example, perhaps country code was added, split from the phone number in the customer screen. I would frequently be requested to suppress the upgrade, or move the new fields so they didn't 'ruin' peoples memorized routines. 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.
  • Aperocky 4y ago
    But CLI apps should be extensible in the same way that .bashrc is. If it can't be upgraded, it's not because of its a terminal app, it's because it's poorly designed.
• troupe 4y ago
  Was your hospital by any chance using Meditech as the terminal based application?