It's among the least bad, but nobody would ever mistake it for software sold to general consumers in this century. I know it's complex and specialized, but so are IDEs, and those are (in my limited use and understanding of them) worlds better in their engineering.
That said, I'm not crazy about how actively Epic appears have tried to keep medical records created in Epic locked in to Epic.
The spirit, if not the letter, of the legislation requiring a move to electronic records was due to record portability. From where I stand, they have actively prevented that (or at a very minimum sandbagged) to expand their market share.
Another unintended consequence of this is that it makes it extremely difficult for doctors and nurses to pull data to do basic research or look at patient outcomes.
For example, if you wanted to see what the outcomes of giving a specific drug at a specific dose to a specific group of patients at your hospital was, you're in for a real fun time manually copy-and-pasting thousands of entries from the EMR to a spreadsheet.
Now more than ever it is important to look at data relating to patient outcomes with various COVID treatments that haven't been thoroughly vetted yet. But, guess why your local hospital isn't doing anything like that? Because what should be a simple 3-hour exploratory data analysis that can be breezed through IRB now has to involve a budget component of hiring a professional copy-paste person. Can't even use med students to do it anymore because they aren't allowed to hang around the hospital due to COVID, and you can't access those records remote due to HIPAA.
That’s just completely untrue. First of all, Epic has a built in tool called Slicer Dicer for clinicians to perform pretty complex population data analysis without having to do any database queries. Second, every healthcare organization extracts much of their patient data to a data warehouse where you can perform direct SQL calls on it.
MD here too. I encourage you to stop and think about your defensive reaction to a tool you know well that's designed for exactly the purpose the client is looking for. OP, who I wager uses Epic every weekday for 5+ hours, has no idea about this tool and probably wishes existed (I'm guessing). It's probably not included in their software contract, or there are unnecessary HIPAA issues, or the IT person is not competent. Just some of the many issues.
On the radiology side, I know there are extensions and tools for PACS that the vendors can't be bothered to come explain/train, even though the company sold it to the hospital. It's like pulling teeth.
Valid point. My defensiveness was less directed towards OP's specific scenario but rather to the blanket statement that EHRs are broken in this way, when there are specific and high-quality tools designed specifically for data analysis. A lot of people, including myself, tend to put a lot of faith in HN comments about industries that we are not personally familiar with, and someone reading OP's comment would likely get the wrong impression about the state of the medical records industry.
There are certainly a million reasons why a doctor may not have access to or be able to use tools like Slicer Dicer, but most of those come down mainly to hospital policy. Amount and quality of training is certainly the biggest differentiation between clinician who are satisfied with Epic and those that hate it.
You are correct, I made a blanket statement based on what was apparently incorrect information. But, I'm glad I made it on HN, because I went from having an incorrect assumption to having a solution!
Thank you very much for sharing that. I'll look into it more. The clinicians (head of trauma Evidence-Based Medicine as well as the head of the trauma department overall) I have talked to at my non-academic Level II trauma center do not have any clue this exists. They are currently exporting thousands of records by hand.
Edit: Do you know offhand of a good guide to SlicerDicer I can share with them? I will google around, but if you had something you personally liked?
There's still likely some good reason to do that work manually. The quality of data entry into EMRs is often poor, especially when it comes to event or time data that's not just numeric bloodwork. Imagine that at a random physicals date your patient was suddenly was 155kg and 65cm tall. Or for another example, having someone be inaccurately be diagnosed as having new onset diabetes after transplant, despite them having DM for several years prior. People switch up entry fields, inaccurately assess or diagnose patients all the time--generally because of the sheer variety of ways in which data can be screwed up, only a person can notice those oddities (or write a little script to fix them).
At population levels I could concede that these errors may well be inconsequential though.
I work at Epic, so the resources I have are all internal training/document. That being said, the best way to learn it is probably to have someone who’s an expert in it, ideally another doctor, walk them through it. If you want, I can see if I can find some specific customer-facing documents/training to link them to.
Lack of public documentation has to be my #1 pain point with proprietary software over the years.
Especially in the EMR space, putting up barriers to access basic documentation is quite unreasonable.
Public documentation is not going to suddenly allow your competition to gain an advantage, while your own firm benefits from users being able to easily google and get authoritative answers from your own official documentation.
> and you can't access those records remote due to HIPAA.
The person who told you that is misinformed. I have personally worked on products that allow physicians and staff to access patient records remotely in a safe and fully HIPAA compliant manner. It's incredibly common.
I think EHR vendors sometimes get unfairly blamed. The fault often lies with provider organizations who simply haven't turned on the available functionality.
Ha, exactly. UI/UX is precisely the area where Epic fails the most. I am not an expert in this area, but in my every day use, I can only describe the Epic style of UX as "vomit all information onto the screen at once."
Looking at the website right now, I see three different horizontal arrangements of links.
Of these links, there are four duplicate pairs, at least. Two of these sets of pairs lead to indistinctly named pages (/Home/InteroperabilityGuide and /Home/Interoperate)
I would start by having all of these links be at the top, and adding some descriptive text to each of the fields in the main body, as opposed to meaningless graphics/marketing numbers.
Addendum: Also, I wouldn't want to do the split in thirds thing that occupies the majority of the page. Each of those can get a description of at least a paragraph, and go one after the other. If there's not enough info to fill a paragraph, then they probably need to be merged.
This one isn't entirely their fault--it's legitimately a customer demand they've acquiesced to, and while they bear some blame for doing so, they're not the root of the issue there, users are.
There's a legitimate case for high-density, specialized interfaces that aren't focused on usability in the sense that you might find in more consumer-targeted software: the end users of these systems don't necessarily need something that's easy to learn or that presents only important info up front. Arguably they need the opposite: something that packs a lot of complex functionality and dense information into a small space is _good_ when your users are highly-specialized and frequently run through similar complex workflows. It's akin to a phone camera interface and a camera designed for professional photographers: the former eschews having ALL THE THINGS for accessibility, whereas the latter eschews accessibility for high info density and rapid access to tools because its users are okay putting in the time to learn something complex when getting over the learning curve will afford them a high degree of control and quick feedback.
Where things break down is customizability: expert tools, and especially expert software tools, suffer from "the user knows best, they can design their own UX" syndrome: this is true to a degree, but in the case of shared tools oft turns into one user (team lead X, who's been doing this shit for years! they know their shit!) designing something that works for them, or that replicates an existing workflow from elsewhere (just make it EXACTLY like the old paper charts! why would you do anything else? what do you mean the design considerations for a paper system might not perfectly transfer to a computer system?) in total ignorance of things they fail to do well. Computer systems, I think as an artifact of their relative novelty, lead users to believe they're experts in UX design by virtue of having (a) experience in the field the system serves and (b) having used a computer interface at some point in the past (and, in America, (c), broader cultural hubris about individual competency across disciplines based on competency in some unrelated highly-skilled field). Designing a truly good interface requires a dialog between user and designer, but we too often tend towards a "skilled user must be right, they're good at SOMETHING and therefore good at EVERYTHING" mindset. Enterprise software design provides customizability to a fault--we hear users want it, don't have enough time to actually sit down and try workflows with them, and they say they're skilled enough to do it themselves independently, so let em have at it.
I sometimes wonder what it'd be like in a world where "cars" were sold to ENTERPRISE DRIVING CABALS, full of VERY SKILLED DRIVERS, where the "car" in question ended up being a pile of sheet metal and control surfaces, a collection of engine and power train components, a big tub of asphalt, and a rough map of places people need to go, entrusted to a multitude of very experienced horse carriage drivers who each sought out to build their own bespoke personal vehicles and interstate highway system as they saw fit based on their own intuition and cunning, with nary a notion of needing to design something that worked for anyone else or wanting to take advantage of the new tech's more novel features. I doubt it would be a good one, but it would probably be hilarious to look at having driven on a somewhat saner system in a more thoughtfully designed vehicle.
Certainly that's an issue, but again you can't really blame the vendors if providers make extensive customizations to EHRs and then refuse to commit IT resources toward rolling out version upgrades.
Good luck actually using that, most deployments have the open-operability stuff specifically disabled, and it required many layers of bureaucracy to get it enabled and have keys issued.
Thankfully, TEFCA was implemented anyway, and is still on schedule.
We'll see what it works out to in practice. But data sharing is definitely still possible, today, even with Epic (they are quite good actually). You are limited to certain reasons but they are pretty broad.
Full disclosure: I work on this full time. It is a strange world, that works on its own standards and practices for good and bad reasons.
I know a whole bunch of nurses who won't shut up about how much they hate Epic. I watched my doctor try to use it once when I was in for a visit and he didn't seem to be enjoying the experience much either based on his grumbling. It seemed like there was a LOT of UI cluttering going on so I can understand how it might not be very easy to use.
Just a little personal anecdote but - A while back I had a week long stay in the hospital, after some small talk with one of my nurses she learned I write software. She told me a bunch of things they hated about Epic and gave me a quick tour of the interface they have to use. The main complaint seemed to be that things they need to do hundreds of times a day require way too many input actions. And it did indeed look incredibly cluttered.
I love getting little tours of software I'll likely never use even though I'm not in a position to fix any of the problems. It's just interesting.
Epic just unveiled a new user interface for nurses trying to address this exact issue. The problem, and another commenter pointed out, becomes everybody has a different idea of what they need quickest access to, and many hospitals want to customize to fit their existing workflows, even when that’s not ideal for speed of use.
Sure. Discoverability is great for new users to software. After the initial learning period I care far more about ease of performing repetitive actions. Discoverability is useless to me when I've already established a workflow and just want to perform known actions.
I was specifically talking about things they do hundreds of times a day (at least) like dispensing medication, requesting medication, inputting vitals, taking notes, etc. Those things shouldn't require 10-15 clicks and 4 different modals/menus each time. They're extremely common use cases that a nurse will likely be performing a number of times in every single room they enter.
And why shouldn't they have an opinion on what is important? They're the ones using the software all day!
> After the initial learning period I care far more about ease of performing repetitive actions. Discoverability is useless to me when I've already established a workflow and just want to perform known actions.
I once got in trouble for using autohotkey for something like this. Like, wow were they upset with me.
In a clinic or hospital setting, there's always going to be someone on an initial learning period. So while discoverability may be "useless" to you, it's not useless to everyone.
The issue is also what's important for one use is not important for another. The person dispensing medication may not be the same person taking vitals, etc.
And it might be the common use case for that nurse, but another nurse may have a different workflow. What works for cardiovascular doesn't work for ophthalmology.
And all these people think they're equally important. They all want the same priority.
Not to mention, most people are bad at UX design. So while they should have opinions, they should not be the only consideration.
1, 2, 15, 100, the number of clicks doesn't really matter.
It's like measuring code quality by line count.
It's Spinal Tap. "But it's one less click, innit?" If it takes you 10 seconds to find the one place to click or requires such heavy front-loading that it slows down the system on every click, you've already failed. Doing more of the thing that caused you to fail is a hole with no bottom.
Second, the engineers and UX designers aren't the people really driving the design process. That's a problem. The people driving the design process don't know what they're doing. Because everyone things UX design is easy. It's not. It's hard. People think they know what they want, but the don't really. What they know is what they want to do. But they get it wrapped up in their mind that what and how are interchangeable. So "I want to prescribe medicine easy." becomes "Prescriptions need to be one click".
Maybe they don't really. Maybe to make them easier to do, they need to be in a context menu or something else. I don't know either. I'm not a UX designer by trade. Because I know it's hard.
I don't think it is, at all. And counting clicks isn't a fools game - it's a direct metric for how buried simple tasks are. Do you need 15 clicks to restart the process you're debugging? No, it's one click on the debug window. This is no different.
>"But it's one less click, innit?" If it takes you 10 seconds to find the one place to click or requires such heavy front-loading that it slows down the system on every click, you've already failed. Doing more of the thing that caused you to fail is a hole with no bottom.
Why would it take the nurse 10 seconds to find a button or place to click for an action they've performed thousands of times?
We've already established that new nurses have a training program to get familiar with the system. You don't think they are just hired and then thrown into 'go take care of this hallway by yourself' do you? And whats better - front loading so they can select a patient as they enter the room and let it all load up while getting ready to treat (confirm name, start gathering data, etc), or waiting 5 seconds every single time they click anything? Oops, clicked the wrong thing there - thats 10 seconds to let it load, back out, then select the right thing.
You can argue discoverability all you want - but go stay a week in a hospital and observe the people actually using the software. Watch how 3/4 of the time they're in your room they're fighting with the computer to perform simple tasks. Tasks they know how to do, but take way too long because of the clutter and poor design of the system. Watch them click 15 times through 4 different windows to dispense a medication - which they'll do 8 times a day just for you. Multiply by that by all the patients they're responsible for. Do you see the problem yet?
It feels like I'm saying 'make it easier to use for the people who use it' and you're saying 'no make it shinier so anyone off the street can use it' lol. Maybe we're actually saying similar things - just not aligning thoughts well?
> We've already established that new nurses have a training program to get familiar with the system
You've made the claim. But really, that's just washing your hands of the problem. I've been part of that training. I'd call it a joke, but there's nothing funny about it. You aren't going to get familiar with these systems in an afternoon seminar with the vendor's representatives.
You say this:
> You can argue discoverability all you want -
Then just make my argument for me.
> because of the clutter and poor design of the system
Reducing clutter would make things more discoverable. Making things discoverable is part of good desing.
I'm not saying "make it shinier". That's a poor inference on your part.
I'm saying the metrics by which we are using to design these systems are just flat out wrong. They are confusing the what with the how. And I'm not even getting into how sometimes you actually want things to be complex or hard to reach because you want the action to be deliberate.
Counting clicks is wrong. And anyone who advocates for it is also wrong. Discoverablity makes things easier to use. For the people who use it. You have this platonic ideal of a user who always knows the software in and out. That user does not exist. Any given user will only really use about 20% of the software, but every user will use a different 20%. So that other 80% needs to be discoverable. You shouldn't need to memorize or hunt down on a screen of options for it.
And since that 80% is different for all users, it logically follows that the entire system needs to be discoverable.
And that's not to say you can't implement shortcuts and hotkeys and what not. But really, any software shouldn't be making people think to much about how they're doing something so they can focus on what they're doing.
Your whole argument basically boils down to 'I somehow know better than the people who use the software for hours nearly every day and will disregard their usability complaints'. I think that is pretty arrogant and dismissive towards the users. I don't see us making any ground in this conversation so I'm going to leave it.
Not myself. But someone. Some people make it their job to figure this stuff out. UX design is a skill. A skill you have to train and study.
The idea that users themselves know how to make something usable is just as misguided as what you're accusing me of. It's like assuming that most people are good chefs because they have a lot of experience eating.
They can tell us whether something is bad or not, but they can't tell us how to make it good. Don't confuse the former for the latter.
They aren't exclusive. Something that is easily discovered gives you an efficiency of thought.
But "number of clicks" isn't a measure of efficiency.
What's the time from thought to action? That should be our main concern. If that takes one click, five clicks, ten thousand click, it doesn't matter. Thought to action.
At the end of the day, it's a simple record of the patient, not an IDE. Nurses need to see stuff, MDs need to see stuff.
FWIW, my goddamn opinion: Epic is probably the best EMR I've used, but I can still see some random dude's dog in Bolivia on FB faster than I can pull up a patient's critical lab values during a procedure. Not too worried about missing out on "Now your EMR comes with customizable colors! [dismiss]"
Batch loads are usually faster. Regardless, no it's not a different problem. It's THE problem. Clinicians need to go fast, and EMRs slow them down. If everything is a single click away from the landing page, they'll go much faster and in their eyes it's the only thing that matters even if it goes against any kind of common sense.
At my hospital the nursing UI of Epic is absolutely horrid. It's cluttered and confusing with multiple places to document everything.
Epic is completely customizable, but the people who make the decisions in nursing management aren't always the same people using the software. That and funding to make the changes.
If you want to see really bad software take a look at Meditech it defaults 800x600 (!), and doesn't resize well at all.
Ah yes, I am still forced to use Meditech's telnet interface today. I asked our IT guy if we can please change the font to a smoothed, non-raster font. I think it took all his willpower to not burst out laughing lol
MD here. Epic is terrible, as are all other EMRs that I have used (with the exception of VA's older software). I use Epic every day and I am ready to jump ship from medicine altogether to help build an EMR that could actually work well for both health care providers and patients. There is no excuse for such poorly executed software, especially the UI/UX.
All EHRs are bad, some are just worse than others. With the right build, Epic is one of the least bad. But the wrong build can really be soul-destroying.
