[HN Gopher] EHRs: The hidden distraction in your doctor's office
___________________________________________________________________
EHRs: The hidden distraction in your doctor's office
Author : pseudolus
Score : 51 points
Date : 2025-08-03 10:07 UTC (12 hours ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| localghost3000 wrote:
| I worked in health care tech for about 5 years. AI driven before
| it was cool. Took processes that normally took years down to a
| couple hours. Cutting edge stuff.
|
| What struck me over the years was the open hostility we faced
| from the staff. The admins would buy our product, then have us
| come do trainings. The clinicians seemed to resent every second
| of it and would just never use the tool.
|
| Towards the end of my tenure there, a PM said to me "the last
| thing these people want is to have to learn yet another
| workflow". Which is when the penny dropped for me that our tool
| was just one of a bazillion being force fed to these poor people.
| They want to spend their time with patients not a screen.
|
| Despite it being the most mission driven I have ever felt about a
| product (we were literally trying to help cure cancer lol). I'll
| never work in health care again. Like education, it's a quagmire.
| Taikonerd wrote:
| > _I'll never work in health care again. Like education, it's a
| quagmire._
|
| Remember: there's a lot of "health care" out there. Even if
| doctors resent EHRs, there's also drug discovery software,
| telehealth software, embedded software in medical devices, etc!
| leovander wrote:
| > we were literally trying to help cure cancer lol
|
| Project Ronin?
| zaptheimpaler wrote:
| Yeah doctors hate them because it's just shit software. It's
| something like Workday trash - software that's made to be
| extendable to every possible use case and save costs for the
| developer while being complete garbage to use. Even if it did
| work, it's then tailored to the priorities of legal and
| management rather than doctors.
| II2II wrote:
| > Towards the end of my tenure there, a PM said to me "the last
| thing these people want is to have to learn yet another
| workflow".
|
| I suspect that people entering medicine do so to address human
| needs, and have very little interest in dealing with technology
| (or handling traditional paperwork for that matter). Couple
| that with a perception that pretty much anything digital being
| obsolete before it reaches market, and even more so when it can
| take upwards of a decade for the product to reach them, and you
| are left with a group of people who have nothing but dread
| about being stuck on a never ending treadmill that is outside
| their scope of interest and expertise.
|
| Take that opinion with a grain of salt though. My background is
| in that other quagmire: education. I have seen some amazing
| tools developed over the years that were abandoned, so everyone
| had to move on. Worse yet, no replacement was created for most
| of those tools so everyone is back where they were before the
| revolution happened. (I'm thinking specifically of software
| used by teachers and administrative staff, but something
| similar can be said for software used to deliver the
| curriculum.)
| Scoundreller wrote:
| University of Toronto used to basically run on a homegrown
| curriculum management system called CCNet up until ~2006.
| Basically run by one professor on a CPU under their desk.
| Course notes, grades, that kinda thing.
|
| I guess for future-proofing, the university moved to
| Blackboard. For a while, some courses were on Blackboard,
| others on CCNet.
|
| We had a professor poll the class and ask which they
| preferred, and all 240 of us in unison said "CCNET!"
|
| I still remember a quiz on Blackboard where the answer was
| something like "2" and it responded, sorry, the correct
| answer is 1.9999999999.
| 3eb7988a1663 wrote:
| I have been looking for the term to describe this kind of
| enterprise software. It has glossy dashboards that are sold
| to VPs with the flash, "Monitor the entire company from one
| screen!" The actual rank and file users hate the product
| because little attention is ever given to the day-to-day
| workflows. Things barely work, super convoluted, etc.
|
| An accountant friend was just migrated to Workday(?) for
| their backend. Apparently whatever labyrinth configuration
| they have can only export 12,000 rows at a time. The
| official workaround they were given was to run reports in
| one week batches when a month of data is required. Previous
| solution could seemingly export unlimited amounts of data
| and time windows. A complete technical failure for which
| everyone should be ashamed.
| dcminter wrote:
| I've just left somewhere that was using Workday. It was
| terrifically bad in an already outstanding field of
| ghastly Enterprise abominations.
| fragmede wrote:
| We have the Internet, which was supposed to fix things.
| Why can't we talk to the developers at workday and make
| that export issue an issue? How would we force it such
| that the renewal contract doesn't get signed unless it
| gets fixed?
| 3eb7988a1663 wrote:
| I am not invested in this particular issue, but the
| recurring root cause: the organization is completely
| disconnected from actual users. No accountant would think
| 12k rows for a corporate level system was acceptable. How
| do you handle monthly, quarterly, annual reporting? A
| single POS terminal at Target could process 12 thousands
| transactions in a month.
|
| Yet, the entire Workday chain of developers, PMs,
| management - all slapped their seal of approval on the
| product and pushed it out the door. Compiles? Good
| Enough.
| Loughla wrote:
| All LMS's are trash. Blackboard, moodle, canvas, whatever
| other bullshit.
|
| They're all actively user hostile and add features admin
| think look nice but provide no real value for classes.
| lvl155 wrote:
| It's more than that actually. Where is actual interop? It's
| been promised literally 10 years ago. It's not that hard.
| People in Healthcare IT are just that bad.
|
| The only time I've experience interop in healthcare is due to
| actual organizations merging. That's it. This entire space is
| filled with incompetence. Maybe providers will actually use the
| tools if they work consistently. Food for thought.
| SoftTalker wrote:
| It's also strange to me that every time I go to the doctor I
| have to sit and fill out forms like I'm a new patient. All my
| insurance info, again. My entire medical history, again.
| Consent agreements, again. This experience hasn't changed in
| decades, and I don't understand why.
|
| I've asked, why do you need all this again and the answer is
| usually "oh we have a new system" or "we need to know if
| anything changed" (but that's not what the forms ask).
| dboreham wrote:
| Quick guess: 1. lawyers and 2. principal/agent problem (the
| providers don't give a crap about your wasted time and the
| bad data they're collecting).
| fn-mote wrote:
| My observation has been that after filling out the form,
| the office skims it and enters nothing in the computer. I
| guess that's the "nothing changed" situation.
|
| Patient time is worth 0 to the medical system.
| candiddevmike wrote:
| FHIR was supposed to be the interopt but the end results look
| more like schemaless blobs of contained fields. But hey, at
| least I can find all the data related to a patient ID, I
| guess.
| Scoundreller wrote:
| Most of my experience is on the pharmacy side, and tech
| basically saved pharmacy, from recordkeeping, insurance claims,
| accounting to inventory.
|
| But it was voluntary (for the organizations, not so much the
| staff). There was no need for government to shower pharmacies
| with money to adopt it because it paid for itself.
|
| I'm sure a lot of the staff initially met it with the same
| hostility. Even in 2010 when I was more in the field, we still
| had staff where their only computer experience/use was at work
| and otherwise lived an offline life.
|
| Can't say I saw a pharmacy that didn't have a computer since
| the early 90s in Canada (and my memory doesn't go before that).
| And before that, at least they used typewriters. Meanwhile my
| GP was all-paper well into the 2000s except for some billing
| stuff. God help anyone that had to read his notes. But
| sometimes you're reimbursed sufficiently that there is no
| driver to change workflows even if it would be economic.
|
| Ontario Canada.
| tbs_ wrote:
| That resistance to change is just human nature. I work on much
| lower stakes line of business apps and the new thing can be
| _objectively_ better in every way and there will still be
| significant pushback from a large percentage of the userbase.
| mitchbob wrote:
| Obligatory mention of Atul Gawande's piece in the New Yorker,
| still a classic:
|
| https://www.newyorker.com/magazine/2018/11/12/why-doctors-ha...
|
| https://web.archive.org/web/20250104014248/https://www.newyo...
|
| The fun part is about 4/5 of the way in and starts with
|
| > Some people are pushing back. Neil R. Malhotra is a boyish,
| energetic, forty-three-year-old neurosurgeon who has made his
| mark at the University of Pennsylvania as something of a
| tinkerer. He has a knack for tackling difficult medical problems.
| In the past year alone, he has published papers on rebuilding
| spinal disks using tissue engineering, on a better way to teach
| residents how to repair cerebral aneurysms, and on which spinal-
| surgery techniques have the lowest level of blood loss. When his
| hospital's new electronic-medical-record system arrived, he
| immediately decided to see if he could hack the system.
| ChrisMarshallNY wrote:
| This is where user-friendliness is a _requirement_ , not a
| luxury.
|
| Anyone who has ever looked at an EHR/EPIC screen, can tell you
| that the 1990s Web called, and wants its tables and frames back.
|
| In fact, one doctor I went to, still ran Windows 95 (in 2009),
| because they didn't want to deal with new interfaces.
|
| Engineers are notoriously unsympathetic to usability and simple
| GUIs, but I have found them to be an absolute gold mine, if you
| want people to actually use your product. Apple and Google are
| trillion-dollar companies, now, mainly because of their simple,
| usable UX.
| mulmen wrote:
| I can't quite tell if you are saying the tables and frames are
| a better UX than Apple and Google. Personally I find frames and
| tables far more user friendly than the constantly shifting and
| indecipherable UX that Apple forces on us with updates.
| ChrisMarshallNY wrote:
| Well, it doesn't matter what you or I think of it. It _does_
| matter, however, what a _doctor_ thinks of it.
|
| As the other comment pointed out, it's a balance. Simple is
| not the same as user-friendly, but they live on the same
| street.
|
| Doctors routinely deal with concepts that would confound me,
| but they are often _quite_ technophobic, when it comes to
| computers. I have a friend that 's a really skilled
| anesthesiologist, and is constantly asking me the most basic
| questions about his iPhone.
|
| Complex interfaces can be trained, but the magic is to have
| an interface that can be _explored_. If you train someone on
| rote, then they go to pieces, when anything changes.
|
| However, if you give them an interface that doesn't penalize
| them for exploring, and has clear, unambiguous affordances,
| they can easily adapt to things like updates, and they won't
| force you to have to maintain an ancient UX.
|
| But designing that kind of UX is quite difficult, which is
| why so few people do it.
| dogmatism wrote:
| nah
|
| I maintain my emacs config
|
| the problem is if someone changes something, that
| immediately impacts my efficiency which slows me down, then
| the patient's are pissed, and the administrators are too
| (which is ironic since _they 're_ the ones who signed off
| on the change)
|
| It _has_ to be rote, no time for _exploring_
| ChrisMarshallNY wrote:
| Eh. Whatevs. We look at things differently.
|
| No big deal.
| rscho wrote:
| TBH, yes it's a big deal. You correctly identified that
| docs are especially good at rote memorization. I always
| thought that this calls for a drastic revamp of accepted
| UI principles. You would usually design to group things
| logically, conform to an assumed user story and design
| around it. Well, docs have exactly one single UI
| priority: speed. They'll adapt easily to having a
| thousand infos on the same screen, given time to learn
| the location of each of those. They'll never adapt to
| deep menus requiring 10 clicks to reach a form.
| ChrisMarshallNY wrote:
| I was just saying I won't argue about it. I haven't done
| UI for medical records software (but some for imaging).
|
| Not really my wheelhouse.
| mulmen wrote:
| How do you know I'm not a doctor?
|
| HTML forms are a metaphor for literal paper forms. They
| don't have to be complex. One of the forms in the EHR
| system I am familiar with uses a stick figure layout. So if
| you are making notes on the left leg you just type it in
| next to the left leg. I don't see how this is difficult.
|
| Meanwhile I can't figure out how to get my iPhone to show
| me what photos I took in the park by my house and every
| setting change involves consulting a web search or LLM.
| martin-t wrote:
| Simplicity and usability are not the same thing.
|
| On one hand you have massive GUIs spanning the whole screen
| containing hundreds of controls. On the other you have airy
| GUIs with more empty space than actual content and every time
| you want something you have to open 3 layers of menus to find
| it.
|
| Both are wrong. The correct thing is to find a balance. The
| balance depends on the usecase as well as the users.
|
| This is what makes it hard. You can't just code up an app and
| throw is over the fence. You have to actually engage with the
| users, watch them perform their work, even try it yourself. You
| have to understand what is important and what is a distraction.
| You have to understand when these things chance. And you have
| to understand that beginner users evolve into experts all the
| while you have new beginner users coming in.
| yesco wrote:
| The problem is a bit more complex than just UX from my
| experience. It's not as if the people designing these portals
| are going out for their way to make it user unfriendly, it's
| that the underlying data model all these hospitals use for
| their EHR is usually completely insane.
|
| Hospitals were among the first to get "computers", I'm talking
| the big mainframes and such that used to be popular in big
| institutions & universities. On these systems many hospitals
| each individually hired programmers to construct custom
| databases for their record keeping. While most have by now have
| transitioned into a more standardized structure, like HL7, the
| original sin has carried forward enormously bizarre data
| structures that make you wonder if the designers were
| deliberately trying to sabotage the possibility of good
| software in the industry. I can't think of a better example of
| why you should never design by committee.
|
| Yet in parallel to all this, capturing medical data is already
| hard. Doctors are most comfortable just writing notes freehand,
| recording the patients current state, notable observations,
| treatments and so on. When modeling this it becomes very tricky
| because you basically need a proper medical background _and_ be
| a good at data modeling / programming. This kind of person is
| basically a unicorn in the industry everyone wants but can
| never get.
|
| Consider, just for a moment, all the complexities that come
| with dealing with the thousands of different units and their
| conversions within the industry. Some doctors don't even use
| the same units for certain measurements, entirely out of
| personal preference. Then remember that measurements are the
| easiest part of the system to model, even what should be the
| simplest part of the entire thing is hard. Also yes, you will
| have to re-write all this from scratch, there is no special
| library or open source software to help. Everytime someone
| makes tools for this they keep it proprietary.
|
| But that's just the tip of the iceberg, to really get an idea
| of what I mean, just look at HL7. It's basically a data format
| that is like a cursed csv with about 5 layers of deliminators
| for nested entries, since all hospitals like to be super
| special, the specification tries to be "flexible", so what
| exactly these characters are is not actually standardized! It
| wasn't enough for HL7 to just be a data model, they needed to
| violate a few OSI layers and interlace it with the transport
| protocol too!
|
| So in essence you must establish a bizarre handshake on top of
| tcp to learn what the hospitals super special configuration of
| the standard is, the very syntax itself! Worse, 90% of it is
| the same for all hospitals but the 10% that isn't is entirely
| unpredictable!
|
| Then you have the actual data model itself, like demographics,
| lab records and so on. They change the specification every few
| years! You need to support it all since this committee of
| monsters don't seem to care much about the migration path! All
| the changes they make seem pretty arbitrary to me but what do I
| know?
|
| I'm still only scraping the surface here but my exposure has
| been limited to what I do, which was processing all this from
| the perspective of a medical device that only needed to deal
| with a subset. When I imagine the struggle one would have with
| actually dealing with the entire thing holistically I feel
| empathy and a desire to never have their job.
|
| It's like building a house on top of an active volcano. Any
| illusion I had that my medical records could be used for
| anything other than basic notes for another doctor to read have
| long since shattered, because clearly that's how all of this
| mess is actually being used in practice.
|
| Oh and don't forget HIPPA! Even when you roll up your sleeves
| and try to fix the problem, you learn you aren't even allowed
| to thanks to the governments overbearing regulations against
| using medical data for things that could help society. Wish
| they just made it a crime for insurance companies to use
| instead of whatever this is.
|
| The fact any of this works at all is a fucking miracle
| honestly.
| ChrisMarshallNY wrote:
| Like I said, it's not easy. I've made some _big_ screwups in
| "easy" UX. I have the scars to prove it.
|
| Interoperability is also one of those "holy grail" things
| that is really hard.
| classichasclass wrote:
| I have a rule I don't do charting in front of patients. Maybe I'm
| old-fashioned, but I think it's rude. I might take a couple notes
| for later, but I do my charts in my office. I have never logged
| into an EHR in the exam room.
| dogmatism wrote:
| you must print out old notes and test then and carry them into
| the room like you're pretending it's still in the paper chart
| days
|
| which is fine until something comes up that you didn't
| anticipate and print out. Then you can a) fake it, end the
| visit and follow up with pt later after you've looked it up or
| b) log in and get the info
|
| How do you have the pt's current med list? Does staff print it
| out after they've roomed the pt?
|
| Also, how are you ordering test/procedure? Writing it down for
| staff to do later? Violates most org's "CPOE" policies.
| Otherwise pt leaves and your staff has to call to schedule
| later, including labs that maybe they could do before they
| leave.
|
| You must have re-created a paper chart workflow in an EHR era
| which is only possible if your staff/org enables this for you
|
| Most of us are just employed widgets in the health care
| factory, and don't have the pull to get staff to work with this
| kind of workflow
| classichasclass wrote:
| I read the chart before I come in and get it fresh in my
| mind, and I do my orders immediately after I've seen them.
| This is Epic, so that tends to merge with the workflow, since
| it really wants you to do your documentation after you've
| done everything anyway.
|
| At least for the health maintenance stuff, I already know
| what needs to be done on that score before I even enter the
| room. If I have to grab something out of the record, like a
| result I wasn't expecting, I can quickly run back to the
| office (it's just around the corner) and come back.
|
| So, no, no paper.
| dogmatism wrote:
| I guess you're smarter than I am
|
| I can't remember all the details to a sufficient level that
| I feel comfortable that I'm not forgetting something
|
| and how do you know the current vitals and medication list?
| When the pt tells you they saw Dr X for Y (that you didn't
| know about) do you not want to look at that in case it
| impacts your plan? I guess you go out and come back? If you
| rx a med that needs lab monitoring, did you memorize that
| too? What about trends in labs?
|
| IDK, I need info _while_ I 'm seeing the pt
| classichasclass wrote:
| If the vitals were fine, as far as I'm concerned I don't
| need to remember the exact number (even though if pressed
| I probably could), and the same for labs. If a patient
| wants the exact values we'll make a copy for them.
|
| For the med list, I do know what they're taking, but my
| usual folks bring in their pill bottles anyway just so we
| can make sure they all match up. This is also useful
| because if I want them to discontinue something or change
| it, I'll write it on the bottle, and make the change in
| the MAR when we're done. We're not usually making massive
| med changes on any one visit.
|
| If they saw someone in the interim, I'll have already
| seen it in the chart before I see them, and if it's not
| there, I'd have to order the record anyway so it doesn't
| matter. Most of the offices here are on Epic, so Care
| Everywhere will usually get their notes.
|
| I think we just have different practice styles here.
| rscho wrote:
| Honestly, the real mystery is how can GP handle the
| workload with this completely sequential workflow. I'd
| just die of karoshi and sleep at work every night if I
| did that. GP must be ultra efficient.
| UltraSane wrote:
| That seems silly. I would WANT my doctor to be looking at Epic
| while seeing me to have the best data.
| rscho wrote:
| You maybe. Most other people indeed take it as a sign of
| failure or lack of manners. Healthcare is social first, logic
| second (or third, or maybe fourth...)
| brown wrote:
| It's true that many providers need a custom solution for their
| unique workflows, and the one-size-fits-all EHR is often a myth.
| The problem is that many EHRs try to solve this with
| customizations, which can be expensive and still feel like a
| compromise.
|
| On the other hand, when a team tries to build their own tools,
| they quickly realize they have to build a ton of compliance and
| interop code they never wanted to touch in the first place.
| That's why open source platforms that handle the core
| infrastructure, like Medplum, HAPI, or OpenEMR, can be such a
| good starting point. They get the team 90% of the way there, so
| they can focus on what really matters: building a great UI/UX for
| their users.
|
| I don't think providers truly want to go back to pen and paper,
| but they are looking for a better way. They can see the promise
| of what the solution could be, but they just haven't experienced
| it yet.
|
| Disclaimer: I work for Medplum.
| Taikonerd wrote:
| I had this thought recently: "different hospitals have
| different workflows, and they want to see different stuff in
| the UI. But obviously they all want domain objects like "a
| patient," "an appointment," etc. Some company should offer a
| standard backend, and a starting template for a frontend that
| each hospital can customize however they want."
|
| It turns out that concept is called "Headless EHR," and it's
| pretty new.[0] Medplum (that the parent comment mentions) is
| one of the companies in this space.
|
| [0]: https://healthapiguy.substack.com/p/to-ehr-or-not-to-ehr
| analog31 wrote:
| The custom workflows are because each clinic system is trying
| to figure out the best way to make money, not the best way to
| treat patients or serve clinicians.
|
| Disclaimer: I know a number of people who work for Epic. ;-)
| osmano807 wrote:
| Through the years I've worked with several EHR, be helping their
| development be using it in my practice, and each had it's
| idiosyncrasies. In my country there was proposals by the
| government of integration, but as all things that need
| coordination, we're nowhere close to sharing information between
| care centers.
|
| On a city we have several places controlled by the same entity,
| and they use an integrated EHR, so that a doctor who sees a
| patient at the emergency department has access to it's full
| history from the tertiary center, but at the same time the major
| tertiary/quaternary hospital isn't managed by that same entity
| and doesn't use the same EHR system, so we can't share
| information digitally. To make things worse, one system is made
| in Flash and all computers need to have an outdated Chrome
| version with the Flash plugin to run it. The other system is made
| in Java and some form of custom frontend framework, which works
| ok until it doesn't.
|
| Expanding on this other system made in Java, it's a federal
| hospital, and we have other internal systems which doesn't
| communicate with this main EHR, so for example emitting radiology
| requests need us to copy paste information from two systems (like
| address, contact numbers), and on top of that those systems
| aren't connected to the national patient registry, and daily I
| have residents redoing requests to merge the information,
| otherwise the requests are made invalid.
|
| I haven't touched on payments, imagine that each health insurance
| plan have different billings and we need to adapt the reality of
| what we did to what code better pays and input that in the
| system, so in practice the records are tailor fitted for each
| payment system, the actual procedure descriptions change, and we
| need to remember all that when billing and when treating the
| patient.
|
| Add on top of that system outage and unreliability, and I haven't
| even touched much on the UI, which sometimes loses input text
| data or sometimes we have to input in certain fields order or
| else the system crashes, or the fact that the tabindex isn't set
| on all fields and we need to click with the mouse to go to a
| field.
|
| Personally I've made a simple system for my private practice,
| while it doesn't have all the functionality, at least I'm the one
| to blame for it's particularities. I'm still exploring how to
| better input the clinical data, and I'm starting to think that
| general systems doesn't work. Each specialty has specific
| routines which need to be accommodated in the system, be it
| structured forms, be it clinical image input with annotations and
| commentary. The field is huge, and we're looking at how to design
| UX for immediate input and for later review, which sometimes are
| at odds (for example, a single textarea is easy to input, but how
| do we parse that data and present a timeline of clinical signs
| for example?).
|
| I guess we need a Linux of the EHR, something which we can
| iterate on. I've looked into open source projects, but I don't
| know if the field is entrenched in inherent complexity or we're
| all trying to model too generic abstractions on top so that a
| small team of developers can't comprehend the system.
|
| I should publish some code instead of rambling, but as the field
| is covered in regulations, I fear not even a code license can
| disclaim legal obligations.
| dogmatism wrote:
| Y'all have no idea
|
| I'd elaborate but it wouldn't be good for my mental health
|
| edit: I'll give one example: my org can't even implement single-
| sign-on even though it's essentially all MS
| UltraSane wrote:
| What is the alternative to EHR software? Thousands of pages of
| paper records that is impossible to rapidly search? Just being
| able to index and search health records is enough to justify the
| existence of EHR software.
| wswope wrote:
| My C/2 as someone who works in the space: EHRs are currently
| mandatory for compliance, reporting, and billing reasons -- but
| completely unnecessary for the practice of medicine.
|
| The first big step towards untangling the gordian knot in my
| book is pivoting the industry to a capitated payment model, so
| compensation doesn't require tying everything back to CPT & ICD
| codes, or tracking super-anal quality metrics for CMS. Once you
| make that jump, it's pretty easy to imagine a lightweight note-
| taking + file-hosting platform that lets providers document
| summary data on a patient profile wiki-style, and attach notes
| to the profile in any arbitrary format using customizable
| templates. (I'm basically picturing a mashup of Google Drive +
| Wiki.js + Obsidian features.)
|
| Handling meds, orders, and referrals in a cross-platform way is
| starting to become a solved problem with FHIR. Tack on modular
| plugins for each of the above to the patient profile page, and
| you've reinvented the functionality of an EMR in a way that
| sucks far less and lets users get shit done.
| computegabe wrote:
| The biggest problem is security. I have yet to see a single EHR
| provider take security seriously despite HIPPA. It's only a
| matter of time before our medical records get leaked. My medical
| records have already been leaked twice, once through an EHR, and
| then again through my insurance provider.
___________________________________________________________________
(page generated 2025-08-03 23:01 UTC)