My latest complaint is that the authors of our EMR, who I know to be legions of fresh out of college young twenty somethings (hardly anyone lasts long enough to be a senior engineer at this vendor, I am told), have not used any sort of helpful SDK for text input boxes, but instead have written their own, having inconsistent and wrong behavior with respect to keyboard based text selection, Ctl+backspace behavior and a variety of other well standardized functionalities.
...and they have written multiple different wrong implementations, as the text boxes behave differently in different parts of the EMR. Even the inconsistencies are inconsistent, like atrial fibrillation.
Individuals don't have much power to change an organizational culture riddled with NIH syndrome (the goddamn ticketing system, timekeeping system, and at some point in the dark past, the email system used internally were ALL written on top of the core EMR codebase) and cargo cult development (the people that /do/ stick around have a healthy share of people that couldn't easily get hired elsewhere on their merits, but do thrive in an environment where accumulating and regurgitating questionable tribal knowledge is crucial).
The system is a testament to the inertia of enterprise software: you can muddle along with a product end users hate while making a damn good profit because the system does deliver on its promises to its actual customers, the hospital admins that are primarily charged with reducing costs and increasing revenue.
The US medical system is so flush with cash and has such high barriers to entry that it doesn't really matter if software isn't great in some (important, but not important in a way that matters to decision makers) ways. The money keeps flowing, and continues concentrating power in the hands of major players. Something like the HITECH act /was/ needed, but lol if you think the people that bought a seat at the table to design it (but totally didn't--that would be corruption, and we don't have that in America!) didn't have a vested interest in pushing certain provisions. Save money by putting an EMR in place sooner, and accelerating vendor lock-in with the existing players? Sure, why not, everyone (for certain values of everyone) wins!
https://www.motherjones.com/politics/2015/10/epic-systems-ju...
Nice. It's a feature of crappy teams that I hadn't been able to put my finger on.
The back story (for Denmark) is that we have been building our very own system since the 1990's at massive cost without getting very far, so by now the biggest commercial offering probably looks like a safe heaven.
Reasons the "in-house" systems never got far are a good story. First, there is the normal insanity of hiring consultancies on cost-plus contracts to design and build a system that is "spec'd" by collecting wish lists from everywhere. Despite this, things might have worked: A lot of my friends from uni started work at these consultancies and the story is that there was not much naked greed and cynicism, and that people really tried to come up with good systems. The real killer was that Denmark, despite being a completely homogeneous country of 5m people with state-funded healthcare, did not opt to build a single system!? Healthcare is provided by the "regions", and the regions could not agree on buying a single system. Since Danes expect their medical records available across regions, the ministry of health then had to step in and provide a data interchange standard. Picture an insane XML-schema for every conceivable piece of medical information, coupled with granular access controls and origin metadata. And then mapping this schema faithfully to 5 different alternative representations...
From what I've read it seems that most of the users are very unhappy about it (https://www.dr.dk/nyheder/regionale/sjaelland/ud-af-tre-laeg...) and crucial integrations to outside systems (like Medicine Card) still don't work properly after 4 years (https://www.dr.dk/nyheder/regionale/hovedstadsomraadet/ny-br...)
Most medical records don't capture enough information about a person longitudinally over time. I worked in a bank that had fantastic customer relationship management software that captured every interaction between the bank and customer and acted as a integration layer ontop of all services the bank provided. It was a stack based model where recent interactions went ontop and nothing could be deleted. You could find old scans of documents, letters the bank had sent and replies. The interaction between bank and customer over internet banking were all captured. I saw my own records from when I got my own account as a child and could see everything from then till now.
I've had a bunch of touch points with medical professionals relating to an eye injury in the last few years. From Emergency to Surgeons and specialists. A lot of information had to be repeated by my wife along the way whilst I a sat there blind.
I don't think special form support or really even business process support would be that useful. I just think having a single pile of client information that's in chronological order would really help doctors be able to stay on top of the issues at hand and then creating a culture of active documentation of actions by all staff so that patient records such as whats on the chart at the end of my bed get's onto my medical record by the end of shift or earlier each day.
This seems like a good place for an ISO standard.
Microsoft Health Vault was supposed to do something like this. The promotional materials said it was going to be a system that you and your medical professional could securely access, and be a central repository of your medical records, so you wouldn't have EMR vendor lock-in. It did OK for tracking immunizations (but I have a yellow WHO booklet for that..)
Tell me more! I've had issues for decades with tracking my immunizations.
Edit: rogue capitalisation
But as you saw (pun intended), it hasn’t gone far. Every time I see my doctor I have to fill out the same forms and repeat the same information. Too bad my work didn’t go far.
No one really wants to do EMR software. Or medical software in general. They do it until they can do something else.
That and you have to work with doctors. And sorry to say, that is not exactly fun. You have people who think because they did a lot of school, that that makes them an expert in everything. And that their bikeshedding is the "real" important issue.
When I last worked with it, databases were the hot new thing. And I don't mean databases were new tech. I mean medical software was just catching on to storing data in databases.
I think one company was pushing a solution that was essentially a collection of Word templates. As if they had hit upon something not only novel, but that no one in history had thought to do.
If you're a software developer, eventually you get tired of pissing up rope and get a better job.
Desire2Learn appears to be the big competitor now (the university i worked at was completing the migration from Blackboard to D2L when i started. and the Uni System of Georgia followed suit.
That said, during my student years I felt like Canvas was steadily converging on being as unusable as Blackboard, which maybe hints at some underlying pressures in that industry. I was involved peripherally in the decision-making process on a small university purchasing a new LMS, and the decision was amazingly political and driven by niche needs from vocal users, and I say this as someone who was pretty used to university politics at the time.
It seems like the way to get an LMS contract is to throw every feature you can possibly think of into the bucket, usability and quality isn't something that really gets evaluated very well. This probably could be changed but I'm not sure how. For example, the university I was with performed student surveys related to the food service vendor and incorporated the results of those surveys as a performance standard in the contract. Nothing like this was done for the LMS purchasing, no student input was collected at either the purchasing or performance stages, and a combination of purchasing methods and institutional politics meant that faculty input was extremely limited (the vendor was basically chosen before the faculty were invited to provide feedback). I don't think higher-ed IT departments often have a user-focused culture but instead a cost-focused one.
Compared to Pearson's crummy web learning platform and the mess of perl that constituted my college's homegrown infrastructure, Canvas was the bright spot where when things went wrong you could get ahold of someone technically competent and helpful at 11pm the night before your test on Saturday.
I wish I had the time to make my own software... At this point I'd be most happy with just a text area where I can write anything I want. I'd love IDE-style features such as autocompletion for medications and tests. An inference engine for simple calculations would also be great. For example, if I write the patient's height and weight, the software should notice that it has enough information to derive the BMI and just do it.
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.
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.
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.
This is probably my single largest source of frustration with building/implementing any enterprise product.
They're of the opinion that everything needs to be "as few clicks" as possible. As if "number of clicks" was the only worthwhile message.
Nobody would read a book where the keyboard was pressed as few times as possible. Sometimes, complex actions require complex input.
We should be shooting for discoverability, not "number of clicks".
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!
I once got in trouble for using autohotkey for something like this. Like, wow were they upset with me.
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.
If my software takes 10-15 clicks to do something any of the users does 100s of times a day, I’d consider that a failure on my part.
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?
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.
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.
I don’t think discoverable and efficient are mutually exclusive.
Something can be discoverable and still usable in 5 clicks or less (example: most menu bars).
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.
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]"
I guarantee that Facebook has more computing power dedicated to showing you Bolivian dogs than any hospital has to showing you patient data.
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.
Regardless, best of luck!
"least bad" is not saying much, they're all pretty bad.
EHRs in the USA, Germany and other countries with numerous health insurance providers are primarily there to ensure every service and tools used is billed fully (or overbilled).
GNU Health’s support for the whole set of pre-authorization, billing, payment, and related transactions seems to be...generating manual invoices.
Because people stand to lose profit if GNU Health is used.
"Speed" (latency of response) has always been the number one user interface problem of all interactive software and it still is.
I have never used an electronic medical record that I would willingly inflict on another person.
The reasons vary, and almost all of them have at least a couple of things that they do very well. But the bottom line is that this exactly the kind of "enterprise software" that is sold to people who will never have to actually use it. They are overwhelmingly sold as ways to increase reimbursement for services provided, as a part of the arms race of insurance companies refusing payment, and hospitals billing more and more.
Even in public sector settings that aren't billing, the only viable options available are built with this problem in mind.