Hacker News new | ask | show | jobs
by hyponatremia121 870 days ago
"Operations (not surgery) are so incredibly bad / incompetent in most healthcare settings that software frequently gets the blame for much deeper problems."

"In my experience doctors are a tremendous barrier to resolving problems in healthcare operations,"

I'm a hospital-based physician that works in a system with great operations and results. The physicians, nurses and other staff work amicably together. Management is reasonable/nice. The EMR, though is universally despised. No one likes it. It is a major factor in burnout. The UI/UX is inconsistent. There are slowdowns and outages daily. There is a well known lag in the appearance of text in text boxes after typing that seems to be variable. I've caught the EMR cancelling orders I placed on critically ill patients in the ICU more times than I can count. We have to actively protect the patients from the EMR. Healthcare workers aren't perfect but they are trying to do their best for very ill people in a high-risk setting and the EMR is well-known blocker. I long for the days of paper records because this is worse. Paper charts didn't go offline, have slowdowns, didn't lose orders, were easily located, and easy to enter data into.

10 comments

As someone who worked at a fortune 500 company making such EMR software:

There's no incentive to make the UI or workflows better. They don't pay the bills. Software is sold to the suits during dinners and baseball games, not doctors or nurses.

Besides, a great portion of the development is outsourced chasing lower costs. The code reviews were so bad that a coworker used to joke that "we'd get more stuff done if we just fired the overseas team".

The biggest and most well funded dev team was the one that worked on Revenue Cycle.

I quit a few years ago and haven't looked back.

I worked on EMRs for 20 years. I recently quit that sector completely, and I wish I would have done it sooner.

Almost all of the features/fixes customers are actually begging for (the most popular categories being speed, reliability, reduced cognitive load and UI/UX streamlining) get dumped into the bottom of the backlog to languish. All the board and leadership care about is RCM, stupid ancillary services that patients do not give a shit about but look good in a sales brochure and have a high margin, chasing incentives from insurance and pharmaceuticals, cost cutting, and last minute, bare minimum regulatory/interop work necessary to not lose our ONC certification or violate HIPAA. Patient care and staff happiness just don’t rate that high. EMRs and the people who buy them are purely profit motivated.

It was humiliating watching how angry our customers rightfully have been and knowing there was nothing I could do about it. Now that almost all of our founders, product owners, and SMEs are gone and they just fired all but 7 engineers so they could offshore development to a company we haven’t worked with before and who has no experience with healthcare, our customers are going to be in absolute hell. The sad part is we don’t seem to be an exceptionally incompetent outlier but fairly typical of the industry.

I agree. I also worked on EHR software and what people don’t realize is that the “customer” isn’t the doctor. Not to be disparaging, but the doctor is “just” an employee.

The purchaser of the software is the administrator. And because of harsh regulations and legal liabilities in their industry, they need software that is compliant with regulations and limits legal liability on the institution. Full stop. If they can get that with a good UI/UX, then great! But in the end, this is just another case of “No one ever got fired for buying IBM”. It is all about incentives.

Companies like Epic could make their UX better, but that costs money. And what drives sales is being regulations compliant, and that is hard. It takes a ton of time. There is little time left over to make something work well considering no other software is challenging them on that front. It really is a situation of regulatory capture.

I think the tides have been shifting for years but the medical industry is rare in that a substantial portion of “employees” are interest owners.
100% this.

EHRs almost universally suffer from usability problems. people actually love having their medical records available. They hate the UX they have to go through to see them.

The source of the problem is that the people deciding which EHR to use are almost never the people using it. it’s ultimately the CFO or CEO who’s ultimately going to make the call, and they do it based on metrics like price tag or how many accreditation checkboxes it fills, not on user satisfaction scores. Until those user satisfaction numbers make it into CMS guidelines for reimbursement, the situation’s never going to change.

"The source of the problem is that the people deciding which EHR to use are almost never the people using it. "

Yes, this. We are a Cerner (now Oracle, yaaaaa) site, not Epic. The Cerner folks I've met in smallish meetings are nice/great on the front lines. However, the deal that our CEO/CFO/COO/CMIO made with Cerner was years ago and, per rumor, involved large financial penalties for early cancellation. Subsequent people in those roles have chosen to uphold the contract. The local management and healthcare teams in my particular facility are great but I take a dim view of our c-suite as do the majority of the work force. Things are reasonable locally for most people, I think, except for the EHR.

So, I would plead with leadership teams of EMRs, EHRs, healthcare systems, and shareholders of these entities to do the right thing and give healthcare workers working in high-risk settings the proper tools they need. You are currently failing us. No one wants unreliable, difficult software installed in critical settings such as ICUs.

I've submitted tickets, emailed leadership and had conversations with the CMIO. If there is improvement it is so slow that I cannot discern it.

In anecdotal conversations over the years I've observed that the vast majority of healthcare workers hate all EMRs but give Epic the nod because it is the least worst, and for some, reasonable. I have met a few Epic users that are enthusiastic about the software but that is after they arrived at our Cerner site and were in shock.

@duffpkg - my original comment was under yours and I wasn't intending to malign your project. I'm not familiar with it but do like that it is open source.

Respect to the developers that work on EHRs. I recognize you are held down by management.

I'm perplexed by UX/UI problems in EMRs. This must cost more to fix than I suspect. It seems to be the easiest of the issues from my layperson/healthcareworker/tech-enthusiast viewpoint.

One more thing to add: an effect of bad EHR is healthcare worker burnout. Bad EHR is a known contributor. Burned out healthcare workers are at increased risk to make medical errors. Bad EHR -> burnout -> errors -> adverse outcomes. This is a well known flow to us in the clinical setting that we attempt to mitigate. The executive teams of orgs that produce or purchase EHRs are never held accountable for bad outcomes even though, to my view, they share responsibility.

Edit: government regulators (CMS, etc) also share in the blame for bad EHR and outcomes.

This is a much easier fix in Cerner. I would guess based on the limited information at hand there is something wrong in the setup of the order release rules. IT should hire a Cerner specialist and the problem should be able to be resolved in days/weeks.
You one of their phone sales people?
Usability wasn't on the feature list.

That's $10M extra.

As someone with a similar working background, I agree, in fact, I wanted to share this same exact sentiment. The software is shit, and everyone knows it how it's shit, and the reason is that the incentive is not there to make it not-shit. The main users, and the people who they record, are not the main concern in these systems. That is why everyone feels bad while using the software. It's not about them, it's not for them. It's not even against them - it just doesn't care. And this really radiates from the UX.
This is the sad tale of enterprise software.
This is so broken and depressing. I had a tour of the EMR system being used in my jurisdiction and it was shocking how bad the UI/UX was. The scenario you describe is exactly what I imagined.

As a software developer I feel so motivated to fix it, I know a small team could do a better job. But I don't even know where to begin to try to enter that industry.

You don’t. It’s a regulated industry that regulated competition out
It's not just EMR, it's just capitalism in general. Everything is about squeezing the most value out of the least budget.

If there was a way to factor in costs due to downtime, poor usability, anything like that, might be able to push back and bake some of that in to begin with... but even that is a can they'd kick.

I totally disagree except to the degree the provider is broke, close to broke in which case capitalism can yet help. When you're worried about money one may manage for money the exclusion of all else. It's a distortion only not a counter argument for capitalism.

The issue, ultimately, is crappy management. The need for, the good outcomes that could be achieved profitably, are insane in possibilities. Many country's demographics now include a lot of retiring people.

I continue to think basic TQM (which has gone out of vouge unfortunately) would help a lot.

Look at psychology in the US: a lot of providers will not even get involved in the insurance side of the equation. Patients pay cash. The patient is stuck with the insurance and re-imbursement, if they can figure it out.

The supplier side --- medicine and insurance and to some degree politicians --- made the paperwork system extremely bad. Simplification and elimination have got to be on the table.

Part of the problem is the patient is dis-intermediated The supplier deals with insurance directly --- hospitals in the main:

* the supplier can bill the patient's insurance wrong, for the wrong procedure, for stupid high amounts, and so on. The patient is not empowered to push back on that because the patient doesn't hold the checkbook

* hospitals and outpatient stuff like MRIs etc. don't publish a price list for the patient. Granted this is changing slowly. But why has that taken so long? Because the patient doesn't have the checkbook so why bother? Payment is done out of sight between the supplier and insurance company. It doesn't matter what the customer thinks.

The stuff where capitalism works better is when the customer knows the price, the supplier has no choice but to be upfront about it, and the customer will fire the supplier, refuse payment, or dispute payment for crappy supplier quality. The supplier can't get payment no matter what if the customer isn't going to provide it. Conversely, the supplier can refuse service for bad customers. This way both parties are encouraged to act smartly.

If I could wave my magic want I'd like to see a scenario in which,

* Customers pay insurance premiums to insurance companies in return for a bounded amount of access to a cash account.

* The customer must deal with out-of-pocket and co-insurance to eschew abusing the insurance company, fraud, and feckless spending. There must be bounded access to cash so the customer prioritizes what needs work and what doesn't.

* The supplier presents the customer with an itemized bill

* The customer --- and only the customer --- pays the bill electronically to the supplier through the insurance company's B2B payment system.

* Patients must get involved in, and start owning up the fact they can't refuse to take a zero on the dollars and cents of the care they're getting.

See also the current HR story on Intel [1].

>biggest and most well funded dev team was the one that worked on Revenue Cycle

> no incentive to...

I am working hard to not build and fuel a fully loaded Boeing 787 into high-earth orbit and crash land it on the not-my-problem, told'ya, it's all corrupt-all-the-time, MONEY! money-is-the-measurement-of-all-things, it's bad-here-so-I-left city center fecklessness of it all.

Toyota at its peek performance (say late 1980s) was making king-kong sized money top and bottom line. No manager would ever say their only incentive or even primary care is cash. "Our only incentive is walk around with cash. Cash in the hand, cash in the brief-case, cash in the pocket, cash on the boss' desk. Show me the cash." has never spoken in companies knowing about TQM.

Instead there were aware of the numerous cross-cutting factors that, in net, determine what kind the money the company can make

Maybe medicine cares about cash so much, because it's broke or close to broke all the time. Hmmmm.

There are ton's of great incentives for the docs, the nurses, the customers, and the company's top/bottom-line to name just a few.

Somehow, someway, one day, one time management will have to get sick and tired of the on-going mediocracy. And until then I guess medicine doesn't suck hard enough. Eventually, like in Voltaire's Candide, they'll have to get into lockup, when the lady in the other cell says (paraphrasing): "You think that's bad? Big deal. I only have one ass-cheek" and goes on to tell a serious tale of woe. We're not sure yet if medicine is the one-cheeked lady, our Candide and his charges in the other cell. Only time will tell!

My extended family:

* runs several hospitals in the US

* owned a radiology business w/ multiple branches for a while

* worked at major city trauma care university hospitals that eventually went bust and had to stop operating

A few things I can tell you about them when we spoke about how the US does 16% of GDP on medicine with its high costs, and sometimes poor outcomes in what should be routine stuff,

- On the people: doctors, and nurses love to help and can be counted on same. Wonderful people.

- They did not tolerate quitters

- Good incentives (carrots) and incentives for dumb (sticks) are not per-se key, but rank in the top 10 with several other things to right the ship.

- Crummy hospitals run by crummy people (esp admin, senior staff, and management) that can't even break even can't help patients, because the unit has to close. There was serious contempt for anything contributing to that eventuality

- They tried in some cases to focus on process improvement, and process simplification instead of more automation for crummy processes.

- They were at times despondent about the sectionalism and the fact that software is too compartmentalized by discipline because the IT stuff often came from vendors that could have some integration but certainly not enterprise integration.

[1] https://stratechery.com/2024/intels-humbling/

One of the biggest scandals in Norwegian health care at the moment is a botched transition to Epic in one of the biggest university hospitals. Doctor dissatisfaction has gone to the roof at the point where 50% of the doctors are considering quitting.

https://www.nrk.no/trondelag/70-leger-soker-aktivt-ny-jobb-v...

EPIC is flashy, has a gorgous campus in Madison, WI, and has lots of marketing. but at its core, it runs on MUMPS as both a language and database.

I know many people that have worked on their integration teams, and could not imagine having to deal with what they do.

https://en.wikipedia.org/wiki/MUMPS

my team is about to start working on an epic integration and i can safely say we’ve all thought briefly about staging a revolt…

i just keep telling myself “at least it’s not meditech…”

Maybe they are different versions, or I'm an outlier, but I love epic - I used a relatively new build of the software last year for a new months, just the ability to message other staff in the context of a patient's chart saved huge amounts of time and interruptions. They also had this super low friction way of addending to the chart, so you could, say, review a (paper) ECG and start recording your interpretation straight into the correct chart within a second or two, and be done in around 10 seconds (with dicatation software which is usually from a different company but integrated)
Your link is broken. I believe you wanted to link the Apotti wiki page

https://fi.m.wikipedia.org/wiki/Apotti_(potilastietoj%C3%A4r...

Denmark transitioned to Epic some years ago. It was a major frustration on many levels.

https://www.sciencedirect.com/science/article/abs/pii/S13865...

So you and your colleagues are protecting the patient (thank you).

Who's been protecting this EMR?

(Who likes using it?, who doesn't lose their job by continuing to choose that vendor?, who gets kickbacks from that vendor?)

I'm assuming the hospitals in Norway & Finland used some form of a public tender where the cheapest solution wins. I don't think you need malice or corruption to explain it, just good intentions.
There's malice on the sell side. If they can't integrate a trial period then its not worth attempting. Its dumb terminal work not like its actually expensive just very very lucrative because its run like a mafia.
Exactly, when selling a big software system like this to the government, the contractor will very deliberately ensure that it follows the requirements exactly (because requirements are never specific enough) so that the government will then have to go back to them for fixes and upgrades forever. If they see a poorly worded requirement that they can implement as-is knowing it will cause a problem, they celebrate because its a future revenue source.

The only way I can see to avoid this is for a government to have its own dedicated software developers who make these types of applications and maintain them. Preferably open-source so that other governments can use them as well. The incentives change and they'd probably save a ton of money.

The reality is much more mundane.

If they don’t implement that poorly worded requirement, they are entering a world of pain of having to justify the deviation through 10 layers of project managers and qa, all from different organisations (either customer or other contractors). And at the end they’ll be the troublemakers who delayed the milestone

So why bother?

This is also true I don't doubt, but I've heard directly from contractors that they look for requirement holes so they can monetize them to the maximum extent possible.

Having a dedicated developer team who work directly for government whose sole job it is to make and maintain software like this for the long term, still seems like the most cost-effective and durable solution.

See Foundation for Public Code: https://publiccode.net/
Given the nature of EHR systems, it's just not realistic to have trial periods, because everything in a hospital is interdependent. Even the relatively small system I worked on did everything from billing, accounting, insurance, HR, inventory management, scheduling, integrations with medical equipment & third parties (e.g. national health systems) with per-speciality workflows and other automation. Most of it isn't even strictly health-related.

Migrating one way is already a multi-year process, making it potentially two-way with low-latency data consistency for the duration of the trial sounds impossible.

In an ideal world, the system would be modular and you could evaluate it piecemeal, but none of the big players are incentivized to make it possible. The standards that do exist are also very lax and legacy systems don't even support those. Something like a goverment intervention is probably required to break this stalemate.

> none of the big players are incentivized to make it possible

Yea this is the problem. When well meaning startups attempt to make change they get acquired by a piece of shit sales behemoth. If somehow one could resist the acquisition and just eat everybodies lunch we'd all be better off.

The only way change will come is if some actually independent hospital develops open-source in-house software (under the strongest possible non-cooption license available, likely GPL3) over literal decades until it becomes a standard.

It’ll be fought every step by the entire healthcare industry.

> just good intentions

And yet the system is aimed at getting the cheapest possible bid? Perhaps the intentions are good, but the execution is horrible. So maybe not malice or corruption, but incompetence.

In Finland the tender was between Cerner and Epic. Because our largest hospital district wanted to buy American eletronic medical record system. I guess the biggest influencer was Kaiser Permanante (=they are world class and are using Epic, so it has to be best system in the world)
I know that devs that work on EMRs might read this thread. I'm pleading with you to take the EMR to the next level when it comes to UI/UX and reliability.
I've managed large enterprise health organizations across multiple sites that use Epic. We built an adjunct system that is still used by some of them that papered over serious problems that doctors using them never knew wasn't only Epic. We defined, documented and tested real world workflows before we subjected patients to them. There are a lot of other ways to address those issues operationally. You have management, IT and operations problems, not software EMR vendor problems. No software is perfect, Epic less perfect than most. Your facility chose that system and decided how it was implemented in a way that is dangerous or potentially dangerous to patients. No software vendor can fix that. That's really the heart of my rants in response to this article.

I built that EMR, it was/is called ClearHealth/WebVista/HealthCloud. Your facility would never have bought it because incompetent management will only buy Epic. We solved the problem by buying organizations and replacing the incompetent management.

Are you still involved in that EMR? It looks like the company was acquired a decade+ ago.
Webvista and HealthCloud are still utilized by some facilities and maintained as an internal system. EMR as a standalone line was <10% of ClearHealth's business when it was acquired in 2017, I remained involved in some capacity until 2019. ClearHealth's main business was as medical/hospital management company.
I am such dev. It’s not up to us. It’s up to our management. We would love to engineer good quality EMR, but upper management wouldn’t let us.
That, my friend, sounds a lot like The Cat Ate My Source Code [The Pragmatic Programmer]

Price, lead time, quality, (and scope) — pick any two. When the stakes are high, don't rely on your manager to pick quality — that is your responsibility.

And if you can't convince your "boss" to give you enough time to deliver something that meets your bar, quit.

> if you can't convince your "boss" to give you enough time to deliver something that meets your bar, quit.

I did this and while it solved my moral dilemma it made things worse for our users.

Many years ago I started my career working for a startup that got bought by a big government contractor. The most incredible people I've ever worked with tried harder than you can imagine to deliver reliable, usable software for the American taxpayer that met the very high bar we set for ourselves.

Because the incentives weren't aligned, most of the good people eventually quit to work at places where they could deliver something that met their bar and were replaced with junior devs and senior clock-watchers.

Every good person who left made that problem slightly harder for those of us who stayed because there was one less person fighting for quality and usability, but the contracts were as big as ever and the new people were less likely to rock the boat so management didn't care that product quality was dropping off a cliff.

In the end it was primarily our users who suffered.

> [--------] didn't care that product quality was dropping off a cliff.

fill in the blanks! it's not management, it's the customer. if the customer doesn't care management doesn't care.

it's a tragedy, but it's what it is. citizens as users need to demand better. it's just politics. in the end revealed preferences show that users don't care that much. they learn the shitty system to do their thing, and then they go home to their family/dog/MMORPG/life.

and users don't care on the meta level either, to have better procurement processes.

You're right, management was simply the messenger relaying customer priorities.

I will point out that enough consumers are willing to pay for a quality products that many niche companies exist to serve them. Many citizens choose to move to countries/states with better services even if they have to pay higher taxes. There are employees who reject higher-paying jobs that require interacting with poor-quality software or processes. (I work for a niche company that makes and uses high-quality products in a high-tax / high service state so I know many people like this!)

> citizens as users need to demand better.

I get what you mean, but as you point out many people's revealed preferences show that they don't actually want quality in which case they already do "demand better" -- it's just that for them "better" means cheap, fast, and convenient.

> [..] were replaced with junior devs and senior clock-watchers.

That is a sad story indeed.

I guess the silver lining is that you didn't waste your talent contributing to a mismanaged project. Hopefully, given a free market, the service will eventually be replaced by something better.

I don't regret the decision but I do feel a little guilt for what I left behind.

I have friends who moved out of struggling towns and states who describe similar feelings about being part of the "brain drain" death spiral that is hollowing out the place they grew up.

> Hopefully, given a free market, the service will eventually be replaced by something better.

I too believed that something like that would happen eventually but their business is still booming. In the decades since I've learned that the "fitness function" of companies that serve governments or large enterprises do not reward product quality (at least not commensurate with the cost of quality) so companies or teams that insist on wasting effort making quality products do not survive. It's not malice or incompetence, it's just a survival response to misaligned incentives.

We don't live in an ideal world where we can all find perfect jobs that give us the agency to deliver the quality we want.

I'll happily compromise on quality if it means I can comfortably afford medical care for chronic conditions that limit my employability.

This is a fair point. If the only agency you have is the choice between following marching orders without questions, or unemployment — don't quit.

But I would be surprised if this is the way all EMR software is built. Software development being a creative process, there should always be a feedback loop where managers ask open questions. There lies the agency to recommend spending more time and money, reduce scope in order to guarantee a level you feel comfortable with. You may not get what you bargain for, but it's up to you to decide if it's enough.

Taking the money in return for doing the work is a way of telling your boss you're on the same page. Given your medical context, that may not mean you fully agree, but it evidently means you accepted it.

And then we have about 90% of working sw devs quit tomorrow - it sounds great but people are not going to leave when they know the next place is basically the exact same.
I beg to disagree. Although I've only worked for European and US companies, my experience is that even bossy bosses appreciate quality design and understand that lack of time, pressure and exploitation cause products to degrade. But pressure can only exist if there is an equally opposing force — you, me, us.

If my recommendation to bluntly quit sounded harsh, I'm happy to tone that down. There is value in compromise, but just make sure your voice is heard, say no if you cannot / will not do it in such little time to the extent that you feel is required. Fighting for the time to do our job well is our struggle. Sometimes it's easy, more frequently it's hard, but when it's simply impossible — have your boss find someone else.

Quality — at least internal quality — is primarily the responsibility of the software developer, not her/his boss or some QA department.

I don't think it sounds harsh, and I have worked with dozens of tech companies and directly for a dozen or so - the only one that wasn't obsessed with cheating out on quality to make a buck was bilking his customers so much that he didn't care.

At every phase of the conversation is management saying they have this hard deadline and

I have been fired multiple times for being too vocal about the failures of process or technology, though mostly I just get ghosted for pushing back when things are unreasonable, at this point I exclusively go for visualizations, gantt charts, etc - to communicate that the timelines are not possible with the current investment in the team/tech/whatever.

I just got laid off for (as far as I can tell) being the person who kept asking the question about why we were doing a thing that provided no technical or business value for a year, and in most of these cases some exec thinks they know best because they read some magazine equivalent that tells them this is the new hype revolution.

Basically if you can find some highly skilled or highly profitable company that's concerned about losing their edge you might be able to do this, but your next boss might change the entire equation.

If you quit, they'll just hire someone who's willing to do the crappy stuff. As a bonus, they'll probably pay less for that person. Or they'll spread the burden over the remaining staff. Or they'll outsource the whole team to some remote hell. Quality is not a bottom-up thing, everybody has to be in on it.

Most management will exchange quality for quick gain whenever they can because they're there to make money and don't plan for long term. Because they can also leave the ship when the sum of their mistakes starts to sink it.

> Quality is not a bottom-up thing, everybody has to be in on it.

I like it. But I've seen at least one place (a start up) where (to some extent) quality was a bottom up thing. Eventually it became a share value, but it was rooted in developers saying: No, we need more time.

On the other hand, I don't know of examples where quality was forced top-down — places where a senior developer would say: I'm done/I don't care/this is good enough and their manager telling them to spend more time on a feature or teaching them about software design.

Ah yes, rogue quality enforcement, I've done it too. It's all fun and games until some nosey manager questions the overeager developer who naively lets them in on the scheme and thus exposes the whole team for the bunch of non productive rebels that they are and then it's back to square zero.

Quality conscious management doesn't impose strict rules themselves but rather maintain a climate of mutual trust between business and technical where constraints and problems can be surfaced, discussed and addressed openly. Respect for technology is sorely missing from the business class curriculum, yet so much depends on it.

> And if you can't convince your "boss" to give you enough time to deliver something that meets your bar, quit.

Ok, all the programmers with a sense of ethics have quit. Now what, boss?

If the new EMR (or any other IT system) doesn’t look exactly like the old one, everyone will drag their feet switching to it
This is the underlying issue for anything where software isn’t the primary goal. Nobody wants to change their workflow that they’ve trained over years, no matter how absolutely broken and absurd it might be.
This sounds a lot like Epic. Respectfully I don't understand how your facility can face those issues with a system like that and also be considered to have great operations and results. With Epic it is possible to workaround a lot of notorious problems but management has to understand and have in place the operational capacity to do it. If a system is allowed to persist in an organization that may have or actually did result in patient deaths in the ICU and it was up to me I would see the facility shuttered until that got sorted out.

I also want to be clear that doctors are not by any means the only obstacle to resolving workflow problems. You being put in a position to protect patients from a business process of the facility that may accidentally result in their death is the literal definition of incredibly bad / incompetent operations. That software didn't magically appear and become responsible for ICU ordering magically on it's own. In this instance whatever insane people have been given responsibility for that implementation are responsible.

After consideration, this comment from a doctor, in a nutshell encapsulates so much of what is wrong. A doctor on the front lines alluding to staff burnout, thinking that people almost or actually dieing because orders are being cancelled inappropriately in the ICU is somehow "a software problem", while simulatenously praising the management, operations and results of their institution. Welcome to healthcare.

Are you saying that the cancelled orders are due to a management decision/policy, and not a software bug? Or that EMR wasn't intended for managing orders and the decision to use it in such a way was wrong? Asking as someone who's mostly unfamiliar with this.

Edit - I'm trying to make sense of this thread, and it seems like this might be a reasonable summary: There's good and bad software (epic). The fact that management chooses epic instead of good software makes it a management problem.

@hyponatremia121 says that EMR software (epic) is terrible, which doesn't contradict the above. @hyponatremia121 pleading for EMR devs to focus on UX might be misplaced since their only experience is epic and not better EMR software.

@duffpkg saying that epic shouldn't be blamed here seems overreaching. If epic were good/hard to misuse this conversation wouldn't happen in the first place. But there's always well marketed terrible software, and I agree organizations that aren't able to avoid this do have organizational problems.

I am lacking all the information as to whether we are even talking about Epic but Epic is a lousy tool. It is still just a tool though. For the unititiated Epic is not some tiny little software program to manage an ICU, it's a city scale platform to run most of a hospital city. You can do a lot of good things with it and a lot of stupid things with it. If in fact orders are being randomly cancelled in the ICU that's a problem that should have never reached a live rollout to an ICU without some sort of consideration for how to resolve it, that isn't a software vendor problem, that's a management problem. This is nicking an artery and blaming the scalpel. Maybe if it happens once but if it happens consistently the problem isn't the scalpel. The problem is with how the scalpel is being used. Epic dates some of it's underlying pieces to the 1980's at least, it has some well known problems and bugs. Better managed facilities develop workflows that successfully route around those problems.

In-N-Out does not as I understand it develop it's own Point of Sale system, they work with a vendor. What do you think would happen if In-N-Out had a location that was consistently failing to ring up orders or lose them randomly? Would the cashier blame the POS vendor and store management stand by and do nothing while the problem persisted? Would the system be rolled out without definition and documentation of workflow, reliability testing and proper training of the cashiers? Can we not operate our hospitals at least as well as we operate a burger stand?

In a lot of ways not legally.

In and out can fire their vendor and walk away, this is nearly impossible for an public institution to do once the procurement contract is awarded, so those systems end up "too big to fail" no matter how bad or unfixable the situation is.

It just takes management with a spine. I work in the public sector, it absolutely can be done.

My guess, it's partially the softwares fault and partially the organization for trying to force a particularly bad workflow on bad software. It's probably fixable without throwing the baby out with the bathwater, but it takes someone willing to go dig in and figure it out. Those people can be hard to find in any organization, and doubly so in public sector organizations.

> this is nearly impossible for an public institution to do once the procurement contract is awarded

I think a big part of why these big projects fail is that a procurement contract is absolutely the worst way to decide which vendor to go with. Especially since most of the time, price is a big factor in who wins, and actual price is by far the hardest to pin down for projects of any non-trivial size.

Another big reason is that a lot of people at the top of the organizations on the customer side have little to no actual IT experience, and are too far removed from actual operations.

The best outcomes I've seen in large projects that we have been involved in has been when the customer didn't care too much about the sticker price, had decent IT knowledge up top or knew when to defer, and included people close to operations early on and throughout.

I have tried a lot of tools. Epic is terrible. capital T terrible. And its still better than just about every other thing out there.

Epic suffers from "it has to be all things for all people". so it is nothing for anyone. It is bloated, big, overly customizable, yet doesn't fit. Steep learning curve, bad UI/UX, expensive, just all around terrible.

And yet it is still better than everything else i have ever seen, except native single-hospital EMRs like Beth Isreal hospital, Boston, EMR.

Part of the problem is that every provider organization wants to have their own unique forms and workflow; there is a lot of "not invented here" syndrome and everyone falsely believes that their institution is special. This forces a lot of customization in the EHRs and actually makes the UX worse. If providers nationwide could get together and agree on standardized forms and workflow (at least within practice specialties) then it would become a lot easier to build good EHR software.
I've started joining design meetings for a new streamlined way for nurses to do their tasks in the EHR. Multiple times now we've got stuck in a little back and forth about how to do something, and someone suggests a setting to allow either option. And each time I try to interject "no settings!". It's a pain for support and code maintenance, increases potential bugs, and means that some organizations could get left behind on new features that aren't compatible with niche settings that they refuse to change.
I am a patient at UTSW in Dallas for over a decade. They seem to have implemented Epic successfully? I even like their mobile app. I can contact all my doctors in UTSW (over a dozen), see my lab results, and ask for refills through the app. Billing is still a bit of a mystery but I believe that is due to balance billing.
Yep I’m happy as a patient. My doctor is very in tune and uses it for everything effectively so prescriptions are easily handled, she comments on lab results, answers messages etc. it’s amazing for someone like me.
> Are you saying that the cancelled orders are due to a management decision/policy, and not a software bug?

The first time the order gets cancelled unintentionally, it's a software bug. Shit happens. When a bug happens, management makes a choice how to respond to that.

When the bug is permitted to persist and result in cancelled orders again and again and again, that's no longer a software bug, that's a management decision to continue to let broken software run rampant and affect their operations.

Think of it as the software equivalent of fool me once, shame on you; fool me twice, shame on me.

Clearly it’s both mismanagement and a software issue. I can’t believe the people here trying to ensure the software platform and provider never looks like the bad guy by defining “bad” in the most convenient way. (Again, management is bad. I’m not denying that. But two things can be bad.)
It is a management issue indeed. Good management holds the software company feet to fire.
When management insists to continue using software that:

> the EMR [is] cancelling orders I placed on critically ill patients in the ICU more times than I can count

then I suppose the management is a problem?

Maybe more competent managers would have given the software a test run smaller scale first?

And had a plan for returning to paper and pencils again, if the new software didn't work?

Competent management would atcept the report of this and scream about it. That means lawyers taking whoever is at fault to court. That means invoking the contract line to to pay (which they would have put there). That means of course a way to report things like this that any busy doctor can figure out.
The classical "the executives bought software because it ticked checkboxes, and they'll never be the boots on the ground using it"
Are you running Epic? As a patient it has been amazing to use and have everything available. My doctor uses it effectively and it’s quite cool she can do all prescription management etc through it. Now even virtual meetings.
HypoNa --

I think you made a throwaway account for this reply, but I would really appreciate continuing this conversation with you. My email is available under my profile.

I'm not seeing substantial investment back in the EHR, wherever the money is going it's not being spent on improving the product. Epic remains a thick desktop app served over Citrix sessions, their web-based workflows still haven't materialized.
This aligns with everything I've heard from multiple nurses and doctors in my circle who work with the EMR here.