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.
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.
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.
So, thank you!
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?
At population levels I could concede that these errors may well be inconsequential though.
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.
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.
Do you know of a good way to leverage this API in a way that can be directly used by clinicians to pull and work with data?
Client applications can be written using the HAPI FHIR library.
Then use the search operation to find the resources you need.
I think EHR vendors sometimes get unfairly blamed. The fault often lies with provider organizations who simply haven't turned on the available functionality.
Conventions which would help:
- add vertical padding between elements
- simplify illustrations or using icons
- use a consistent color palette
- use color sparingly
- at least one of black text and white background should be off-black or off-white respectively
- cookie request background should be a neutral color rather than yellow
- cookie request should be at the bottom of the screen rather than the top
- choose one hover event: animate the illustration or underline the text
- the footer should be at least 3 times the height
- replace "over the last year as of date" with "each year" then restore standard font weight
Fixing all of the above should take about an hour.
Edit: Not a doctor/in health care. Just basing this on the link above.
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.
Edit: ambiguously -> indistinctly
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.
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.
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.