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.

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.

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'll have to start by finding the FHIR web service endpoint URL for your EHR instance, as well as appropriate authentication credentials.

Client applications can be written using the HAPI FHIR library.

https://hapifhir.io/

Then use the search operation to find the resources you need.

http://www.hl7.org/fhir/search.html

Given a choice, clinicians would usually rather have maximum information density to avoid clicking around for what they need.

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.

I don't understand. How can colors be stressful?

This sounds like it's way less configurable than vim

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

That's a different problem. That's not solved through just putting all the functions of the application one click away.

I see you use JIRA too!

This could also be a factor of how much hardware is thrown at the problem.

I guarantee that Facebook has more computing power dedicated to showing you Bolivian dogs than any hospital has to showing you patient data.