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.

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.

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.

You sound like the Gnome developers!

Indeed. I wish more developers were willing to take such a principled stance. (Though given the vitriol they endure I understand why most don't.)

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.

> 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.