Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Secondary to the question, but I live right by the Epic campus and use the Epic MyChart platform to communicate with the University of Wisconsin health system. It is phenomenal as a patient; I can handle all billing, message any doctor I've seen, view test results as soon as they're uploaded, etc. Recently I saw the results of some bloodwork in the ER before the nurses had time to come and tell me about it. (The UI/UX is awful, though.)

I look at the screens of the medical staff when I'm in the office and I can see why they don't like Epic; bad UI/UX and they definitely reorder and rearrange common menus when there's a big update. For overworked medical staff it's got to be a nightmare.

There must be a middle ground. I never want to go back to a healthcare system where I don't have something like Epic, but also it would be nice to have a platform with a more stable, simple design philosophy.



Disclaimer: My Epic experience is around a decade old.

I never saw a riot, but I definitely saw providers who hated Epic when it was installed. As in people literally screaming at the top of their lungs at IT nerds. I saw a few contributing factors:

1. Epic supports making all the technically-mandatory-but-not-mandatory-if-you're-in-a-hurry data actually mandatory, so providers have more typing and less ability to just get stuff done when needed (which minimizes agency).

2. Related to above, Epic will make the updates for any new regulation, which increases the amount of data providers need to collect.

3. The customizability of the Epic UI and workflows for each type of visit was completely insane; many permutations of steps in a visit had to be supported which meant a huge maintenance surface with ok coverage rather than an opinionated workflow for each visit that could be optimized and improved over time.


> The customizability of the Epic UI and workflows for each type of visit was completely insane

Ah, Lotus Notes Syndrome.


Interesting, because I think enforcing an opinionated workflow would be a similar mistake to enforcing mandatory requirements.

There should be some flexibility in both.


>technically-mandatory-but-not-mandatory-if-you're-in-a-hurry

:/


In my experience, the software development profession could spend a long, long time doing some self-reflection about this one. It's eloquently stated, and something a lot of developers could learn. Too many times, I've seen overly restrictive inputs cause users to hate and distrust the software. Ironically, overly restrictive inputs cause users to think that the software doesn't properly understand the domain, which is the root of mistrust.

We should be very liberal with accepted inputs. I call them "Fuck It Buttons." There are lots of cases where you want a "Fuck It" button to just go around all the data entry and get an answer or move on with minimum info. Warn that the data isn't complete and we're using defaults, and don't just make output look the same as a complete workflow, but let them go through, nonetheless. Health care is just one example, but "Fuck It" comes up in every industry.

This is the UI/UX equivalent of knowing which hills to die on.


I highly doubt the developers have anything to do with this in this case. The people requiring the inputs are managers who are responding to regulators and insurers. They're not going to buy software that has a Fuck It Button that allows workers to skip data entry that could cost them money, time, or lawsuits.


At Epic there aren't really product managers. The devs mostly set the projects, design, scope with input from clinicals/sales (a very small group).

So it is interesting to me because most of the design choices - both good and bad - are made by the devs themselves with input from area experts in the aforementioned group, QA, and customer implementation/support.

Some might argue there would be better results with someone who is not the dev managing the product more. But there are pros as well as cons.


> Ironically, overly restrictive inputs cause users to think that the software doesn't properly understand the domain, which is the root of mistrust.

Well, they're quite likely right! I freely admit that as a developer, I don't understand the domain remotely as well as the people working in it (construction workers in my case). The reason there's still a decent market for custom software and that the likes of Epic haven't gobbled up everything, is that every so often a construction worker, dentist, nurse or whatever picks up enough programming to actually make something that suits them, and they manage to bypass the administrators addicted to sales dazzle.


At our company we came to the same conclusion. We have a DSL that is essentially a programmable schema to describe the shape of the data (more specifically a contract) you want to capture as well as how answers and decisions are derived from it. The only hard validation we have are types, eg. you can't put letters in a box that captures a number type. Other than types the rest is soft-validation which means that you can input anything, even if it is partial or not quite correct, and the system will do its best with what it has. In tandem, at any point in time you can ask the system to tell you what is missing and/or incorrect. All this then affects the lifecycle of the information, ie. you can't move past certain checkpoints in the workflow if the information is not in the required shape. In the context of a medical software imagine you can fill in just the things that will get you back meaningful answers to help you treat someone and you can deal with the rest after to make the case complete.


I agree! But what would you put in the database? A NULL? A special fuck-it value?


Like with most things, it depends! Maybe it's a default value; maybe it's a null; maybe it's a special value that triggers a workflow on insert. I'm an evangelist for RDBMSes, and they can do so much, so let them help you!

Maybe you have a state column that's derived that you cannot move to another step in the workflow until all nulls are filled in, but you've let the UI save what data it knows about and move on. It totally depends on what the user is doing and why we're skipping steps/data.


A trigger on a timer that notifies the fuck-it-provider (email, calendar entry, text message, whatever) that they need to go back and enter a value.


Honestly this sort of deferred validation exists as a standard feature of certain modes of data intake that are often criticized for same, for example paper forms (the "required" fields can be left blank), or creating support tickets via email (required fields stay null until an agent updates the ticket via web UI). At some point additional round trips may occur to pay back this debt, but debt is a powerful tool for that person in the field who needs to move onto other things until the dust settles and they can pay it back.


Paper forms can be filled in by different people with different roles at different times. Customers can fill in their personal data and possibly leave blank something they don't understand. A clerk can review the form, ask the right question and fill in the missing field plus the remaining ones.

"Fill in what you know and leave the rest to us" is a simple and cheap to implement GUI compared to a full fledged workflow. It could bootstrap a process quickly at the cost of some extra labor in the customer facing department. Maybe they have that extra bandwidth and the sw developers don't.


Yes. Oh Lord yes.


Right? When aren't medical professionals "in a hurry"? They've always got a ton of things to do and not enough time for all of it.


It happens in hospitals. Treat the human first, treat the chart once they're stable. Speedbumps in the process are fine, because we shouldn't be bypassing protocol all the time, but flat-out roadblocks aren't, because sometimes we really don't have time to worry about all that.


I agree that my healthcare interactions have been improved by Epic. But Epic has no motivation to keep improving, because they control most [1] of the US medical records, and once a hospital is a client, its practically impossible for the hospital to also try a competitor's record management system (medical records are not unique in the enormous cost of switching between systems). So even while we can be glad for mychart we will suffer the increasing downsides of Epic's practical monopoly, without even knowing how much better it could be.

[1] https://www.forbes.com/sites/katiejennings/2021/04/08/billio...


Now proceed to imagine that software being shoehorned into a healthcare system where many aspects of the US healthcare system are impossible to fill out at the care provider side, because they don't exist in the society model. (Let's be honest, you guys have opted for a model which have several very distinctive features in an international comparison).

And I'd be surprised if the Norwegians didn't already have the positive aspect on the patient side in whatever this is now supposed to replace.


yes, the patient side already exist here as far as I know. Helseplatform use their endpoints. The integration is mostly for the hospital, pre-ER and city health services. The pre-ER or LegeVakt (Scandinavian system you call/go if you need assistance but is not life threatning) has been using it for a few months and service level is now so bad that they have apologised in the newspapers. The city that has been sold this system had a wishful thought that all the doctors practices (and all Norway) was also going to use it. This is simply not going to happen now. However the "city" used so much money on this that they refuse to hear the health personel and insist on going further with the project without improving the system. Apparently Epic selling points was something like "It is not going to happen what happened in Denmark" Maybe some Danish people can iluminate on what happened there.


There are a couple of use cases that the new platform is solving, that were not straight-forward in the old system. Primarily the fact that your GP/family doctor and the hospital system did not have access to a common set of health records, they had to send specific requests for copies back and forth. As an example, when you're pregnant you get this special paper booklet where all your information gets recorded by GP/ultrasound/midwife/etc., and when you go to give birth you have to bring this booklet and give it to the midwife so they can see your pregnancy-related health records.

But we have had for a long time a website called "Helsenorge" where you can log in and access most of your health records. For example during covid this was used to give you PCR test results and that worked flawlessly, you get an SMS notification when you have updates to see.

So a big part of the "why on earth are they using this Epic software" sentiment is the feeling that we would be much better off by extending the Helsenorge system to do what we need. Especially since it's only a small part of the country going with the Epic system, and other parts will run other systems - a legacy of the previous privatisation-trigger-happy government.

There are also a lot of obviously broken things on the end-user side in Epic Mycharts. For one, you cannot change the language in the app, it is tied to your phone system language. So if you're Norwegian but prefer to use Android/iOS in English, you're stuck with poor translations to English that you have to guess-translate back again to Norwegian.

The app needs a new login after 10 minutes of inactivity, and this login is using a semi-complicated Norway-specific MFA called BankID that is run by the banking sector, so the login flow takes about a minute to complete. This means you can't actually get push notifications from the app, since it's never logged in while running in the background. So you get SMS and/or email notifications instead.

There is a lot of cruft related to insurance and billing stuff you have to scroll through in the menus that will never be useful to anyone in this country, and nobody understands why they can't just hide those buttons.

There are three different types of messages you can send - Letter, Question and Message - nobody knows what is the difference and one of them redirects you to the other when you start to compose something.

When you go to view your health records summary, there is a big text box at the top which says "Take care, the results here might be displayed in a mixture of Norwegian and American formats" - they have obviously not learned the lessons of the Mars Climate Orbiter failure. For instance it says "Marital status: Gift" on my summary.

To access my children's health records I had to send Proxy Data Requests for each one, which went through a rather complicated login flow every time. Then after three weeks I got a message from some random person saying I have access, apparently there are some poor souls sitting somewhere and manually verifying that yes, this person is the child of that person, even though that information is already in the Helsenorge database.

All in all it seems that either the Epic system is such a horrible pile of fragile spaghetti code that nobody dares to touch it and adapt it to our use case, or we are simply such a small customer that they can't be arsed to fix our woes.

It kinda feels like when you are using any product from Google or Microsoft, only in this case you're paying Microsoft a couple hundred million to adapt the software to your organization and still have that feeling.


>message any doctor I've seen

Doctors especially hate this part, since they don't get reimbursed for fielding these messages and (unlike scheduled appointments) there's no limit to how many there can be or how quickly they can come.


In every case that I've messaged a doctor through Epic, a nurse replies. I doubt that the doctors are being interrupted at random moments to field these inquiries.


I feel like that's something that should really be accommodated for in the billing/insurance model. It kinda is with HMOs and primary doctors, AFAIK they get paid whether you see them or not. Just not in the PPO model.

(I warn, I know nothing about how it actually works!)


Yeah. These messaging services essentially place doctors on call at zero extra compensation.


“On call” has a precise, intuitive, definition that “receives messages and can respond to them at-will” does not fit.


Can respond at will? Yeah, about that. I have no doubt the patients using the doctor messaging feature will expect a prompt if not immediate answer. The system is definitely imposing an unpredictable work schedule on doctors with no compensation. If you're expected to respond to patient messages, you can't go do something else with your life.


I'm sure there are folks who don't read disclaimers but that's on them. Before I can send any messages I get the disclaimer

> Please use this for non-urgent medical questions. Replies may take 2-3 business days. If you need immediate assistance, you will need to contact the practice.

> If this is a medical emergency, call 911.

> Please note, this is not a text message and should be used to ask questions directly related to your medical care. Some requests for medical advice may require an office visit.

I've only used it to send 2 messages but I think they were fair. One was telling my doctor that I had gotten a lab appointment for an exam they referred me for on a certain date. The second messages was today, I got some scan results back, my cardiologist commented things looked good, so I sent a message asking if I could start jogging again. I don't mind if he takes 5 days to respond or even says "we're not sure", but Id rather not wait for my next appointment in 3 months to ask that.


Yeah, UCSF here also uses MyChart, and I agree that it's great from the perspective of the power and flexibility it offers me, even if the UX isn't fantastic (frankly, I think it's fine, though could be better).

But, like you, I've also observed medical staff inputting my data during a visit, and it looks terrible, and I've also noticed significant UI changes on occasion. (I've gone in once a month for the past two years for an allergy immunotherapy injection, so I get to see it regularly, and over time.) I've only heard the nurses complain once or twice, but I can kinda tell how they occasionally stumble with the UI, and it all just seems completely unavoidably bad. A little user research would go a long way, but I imagine the cost of switching to another system (if there even are that many good options) is so high that a hospital might ignore staff complaints anyway, so the company is not incentivized to spend time and money to make things better.


Medical staff don't like Epic because it's the kind of software that's sold to administrators, but used by providers. Guess who has the most sway in things like what features are included and how much effort gets invested into making the UX good?


Bingo, Epic has probably the most in depth sales team, they know everything about your organization and YOU before even starting the call.

They will smooch, take to dinner, do whatever it takes to bribe the head of office staff. Then once they're in the door they convince you to hire 5-10 of their 'Epic Engineers' and charge you $500+ an hour for the honor.

Soon you discover that you can never really get rid of those engineers and need to hire your own on staff team... Which you probably could have done with literally any other EMR if you wanted to customize it.

2 years in the medical staff hate life and the front of house staff have costed their business 50-100M in fees.

Alberta found this out the hard way after spending 5 years and 450M+ on Epic. Roughly $100 per person in the province was required to get Epic 'running'. (I am not sure if its been rolled out to all of Alberta?)


I don’t think Epic’s install costs are secret or a “gotcha”. Any administrator interested in Epic can look at 20 years of installs and see that an Epic implementation is routinely a multi year, $100 million+ project for large organizations.

I’m also not sure what these “Epic Engineers” you’re referring to are, but I know that IT staffing is a conversation that happens early on in the sales process and it is not a surprise to anyone who’s looked around at existing Epic sites.

Whatever Epic’s flaws may be, I don’t think “public boondoggle” is a fair portrayal of how they do business.


I have some doctors in my family and they told me that when their system switched to Epic, Epic sent a consultant to sit in their office for months and answer questions because every new user complains about UX.


Totally agree. Even better is doctors from different providers can likely see your records from each other. It isn’t fool proof but it’s getting pretty good. If a provider doesn’t use Epic then I’ll be looking for a different provider at this point.


I don’t mean this to sound passive aggressive; I’m genuinely unsure: are you using “UI/UX” correctly here? if you’re getting exactly what you want from it, is that not good UX?


Its definitely possible for something to work and still suck to use. Just because you can get there eventually doesn't mean the experience of clicking through a dozen menus to find where a button has been moved with this update is a good one.


Maybe? I think that the system is poorly designed, but I can still do everything I want to do with a medium level of difficulty in achieving it. MyChart is way better than nothing, but it's not as good as "a good version of MyChart".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: