I was startled back in 2015 when a world renowned oncologist got chatting with me about github and tinkering with code. I think it depends on one’s appetite for technology.
TL;DR: Doctors don't hate computers. They hate medical software, because it's done badly. It gets in their way with pointless (to the doctors) bureaucratic trivia that the doctors shouldn't have to care about.
And, in the case of the software being discussed, eliminated or nearly eliminated the ability of office staff to handle those sorts of details. Additionally, it apparently failed to have reasonable defaults (active user isn't defaulted into the physician providing care; current date isn't defaulted into the date field for a note).
I'm going to take some guesses here but I'd love to hear a discussion about this from people with experience in medical software.
Medical software seems like it is rife with mandated requirements, likely written by people with no regard to real-world usage implications. By this I mean decisions that are akin to attempting to increase security by password complexity and expiry requirements -- when the reality is that decreases security by making users write down and/or cycle through easily-predictable passwords.
I would also guess the purchase cycle is very disconnected from its users. The people actually making the buying decisions never actually touch the software. This is probably also like a lot of enterprise software: very expensive, long contract/license lengths, high switching costs.
A relatively minor point but there's also no dogfooding: The developers building the software are not medical professionals and thus never use it themselves. They don't get to see the daily pain.
The result of all this would be very little incentive to build anything beyond "working" software -- spending time on UX or UI design just eats into profits. The type of developers/PMs/etc that excel at and advocate for this type of work are likely not going to stick around (or even work there in the first place), making improvements even less likely.
Have spent decade more or less as health tech security and privacy consultant, checking in.
Requirements come from the institutions that fund the solutions ("solutions," not products) and not the users themselves, so engagement with end users is limited. It's very waterfall, no product managers, just "business analysts," whose only leverage is their perceived relationship with "the client," who may or may not be represented by an actual user.
I've thought a lot about how to disrupt healthcare, and the only viable way I can think of doing it is selling new products into emerging markets that don't yet have ensconced bureaucracies running health. The most successful grassroots medical product I am aware of is "Figure 1," but any product going into western world healthcare is going to be %95 enterprise solution and %5 health related.
An "Uber for stitches" product would be illegal in most countries, but that's the only kind of innovation I can see driving change for most people.
Kids who go to med school tend to be the ones who excel in math, chemistry, and similar ”logical thinking” subjects. They usually do reasonably well with computers.
In my experience, the contrast is stark to another high-paid professional group: lawyers.
Oh my god, agreed. I have known many lawyers, my father being one, and the amount of hubris and tech-derision is insane. You could give lawyers a computer that prints money and they would shrug and tell you to get it out of their office.
>I remember WordPerfect being very popular in law offices, but also dictation machines, so who knows?
There was a period during which PCs (as well as other word processors) were coming in when computers were seen as being increasingly important (in law and elsewhere) but the management at many companies weren't sold on it being a good ROI for professionals, especially those billing by the hour, to use them directly.
There was definitely a period of time in many places where there were computers but it was secretaries/paralegals/etc. who actually typed on them. And, remember, a lot of young professionals in the late 1980s had never really learned to type, even hunt and peck.
Do tech support for a hospital and this attitude will very quickly dissipate.
>In my experience, the contrast is stark to another high-paid professional group: lawyers.
Database systems like WestLaw & word processing systems in the 80s and 90s were killer apps for law offices, so if lawyers are tech illiterate it's a recent phenomenon.
Anecdotally, I disagree with this, for both lawyers and doctors.
I know several doctors my age and younger that cannot stand using any computer or laptop, while my best friend’s father, a surgeon, had one of the first HP color flatbed scanners (SCSI) and the only person I knew to have an ISDN line.
My cousin is about a decade older than me, and I remember spending the night at his house with his TRS-80 and Apple II computers. He is an attorney.
Is there any one-platform-to-rule-them-all solution, that will support 70K users across hundreds of sites, that doesn't look and work like a clunky piece of junk?
Maybe the one-solution model isn't the best option.
This is an extremely long article and admittedly I started skimming halfway through, but this statement:
>But we think of this as a system for us and it’s not,” he said. “It is for the patients.”
Is wrong. It's a misnomer to call them medical record systems. They are primarily billing systems. Sure, improving patient care or reducing paper records are nice. But the #1 thing is to document the care to allow them to bill insurance or the government.
I don't think that's entirely accurate. It's true that billing is a core part of most EMRs, but out of the hundreds/thousands of features in a big platform like DrChrono or EPIC, a large portion of them are not billing related.
There's tons of operational utilities like e-prescription, lab ordering, patient problem tracking, vital sign tracking, imaging and diagnostics tooling, etc. You could argue that all of those are somehow related to billing because they help doctors see more patients per day, but billing would still be possible without them, and they largely exist because doctors need them to work effectively and treat patients more efficiently, not because they directly serve the billing pipeline.
Good luck using a piece of paper to e-prescribe a medication such that it's shipped to the patient's pharmacy before the patient even shows up. Ditto for lab orders, imaging analytical tools, custom vital tracking with automatic flagging, diagnostic hardware integration, etc. there is lots of stuff in modern doctors offices that would be significantly more difficult on paper.
Not to mention all the issues of paper management and physical security once you have thousands of patient documents scattered around in filing cabinets.
It's a more generic problem than that. It's that the purchase requirements of the system are not controlled by the users. There are billing requirements, sure, but also regulatory requirements and hospital administrator requirements etc.
The result is that the number of companies offering a system that meets all the bureaucratic requirements is small, because doing so is arduous and expensive and disheartening. So the few that exist don't have a lot of competition and people still use their product even if it's miserable. People not using their product would have been their incentive to make it better to use, and the disincentive that making it better costs money is still there, so they don't.
Having worked for a company producing software like this, the EHR and Practice Management/Billing components were essentially separate products. Analytics was separate as well. Those were the three big tentpoles, and they would all talk to or depend on each other, but shared very little code and were of course doing completely different things.
You're kind of right though in that it never felt like we did anything because it's what patients or providers wanted. We didn't do things if we were afraid providers wouldn't like it, but a lot of work seemed to be mostly driven by regulatory requirements (meaningful use, icd10, etc.).
I'm an MD, and most medical software is objectively terrible. I've worked in private hospitals, campus student health clinics, jails, juvenile detentions, VAs, group homes, state hospitals (in the US) - and in clinics and hospitals in New Zealand.
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.
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.
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?
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.
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.
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!
> 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.
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 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.
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.
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
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.
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.
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 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]"
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.
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.
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.
This reminds me of Blackboard and its competitor (I forget the name of it) in higher education: students hate it. Professors hate it. It's brutally hard to use. Professors can't easily adopt an alternative (as they can with by choosing Google Docs or Dropbox).
Instructure Canvas is probably the more popular alternative right now, Moodle having always struggled with usability and manageability issues (and taking a long time to get a "modern" looking UI).
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.
Canvas is free software, Instructure's main value add is a 24/7 support desk, operational expertise (not needed for small scale users) and custom software development.
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.
It's interesting, I've used four or five LMS' over my time as a student (Canvas, Blackboard, some k-12 ones, touched Moodle once). Canvas has been the only one I really liked. It works amazingly well at managing coursework, isn't slow, doesn't have a weird paradigm around groups vs courses vs sections. It's not confusing to use either, and they leave a graphiql client there on the hosted version if you want to pull your data yourself (and the API is great). I don't understand why people use Blackboard anymore if they can help it (although maybe it's better now?).
Moodle is more or less fine, we use it quite successfully at the University of Geneva. It helped us a lot to organize remote classes during the pandemic. There were some quirks, but nothing on “enterprise-grade horror worthy of TheDailyWTF page” scale.
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.
It seems like they never watched an end user use their product. Like, who re-invents the 'Page Next' function? Just put a blue underlined "Next Page" button at the bottom of the list like we've done for decades.
A good text user interface, keyboards that can record and play back keystrokes for getting around the menus, customizable per user, and responsiveness.
"Speed" (latency of response) has always been the number one user interface problem of all interactive software and it still is.
It's one of those sectors where the people who are interested aren't good enough and the people who are good enough aren't interested.
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.
Also an MD, also hate our EMR because it is hot garbage, and I love your username.
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.
To be fair to Epic engineers, I don't think many of them want the system to be that way either--they may not be super-experienced, but that shit's more a product of ossification from decades of refusing to change much of anything (the company seriously considered forking VB6 to avoid going to .NET).
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!
Thanks for posting this -- I didn't know this was the system we bought (am Danish).
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...
We have the regions in Sweden too, and they too do their own thing. I think it might be better in 5 to 10 years, because the national parliament decided to integrate the software.
By any chance have you used GNU Health[0] at all? I'm guessing no since it's uncommon in the US/NZ, but figured I'd ask just in case. Curious what your impression of it would be as an MD.
Does anyone in high-income countries use something like that? It is worth nothing that the software product itself is only a tiny part of implementing most enterprise software projects.
Maybe not, but if the EHR systems used in high-income countries are as universally awful as I've heard from doctors, and if GNU Health is at all better... I'd ask why not then!
Billing and marketing is likely the reason. There is no one responding to RFPs advocating for GNU Health, and it likely is not up to scratch for medical billing/automated overbilling of insurance providers.
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).
Because the EHR system is not itself an independent system, but part of a broader complex that also includes handling of financial transactions, and financial transactions are what moves money.
GNU Health’s support for the whole set of pre-authorization, billing, payment, and related transactions seems to be...generating manual invoices.
Lets not talk about the craven insurance industry or security or American healthcare for a moment. Lets let ourselves dream.
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.
25 years ago when I was an intern, I worked for a healthcare software company on the interface team. Our job was to get records out of a hospital’s system and into a home care provider’s system. We were an early proponent of the HL7 standard and our customers were thrilled with not having to repeat information like you experienced.
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.
Your doctor shouldn't be having you fill out the exact same information. Review of systems (like if you have a cough, etc) is fine, but all of your past history? It should just be what has changed or been added to your problem list since the last time they saw you.
It's like that in some places. Typically, the consequence is that you'll get a phonebook-sized file in no time, with so much cruft accumulated from prior encounters that the file will be next to useless.
This is a great point. As someone who receives a lot of medical records from various exports, I can just say that hundreds of pages for a healthy 11 YO only makes it easier to miss the important parts.
This just seems like lazy doctoring compounded by busy schedules. If you can't summarize what's going on succinctly, what was the point of all that training? God forbid you spend a little more time on patients.
I now keep a copy of the photos of my retina on a USB stick. It never fails - either I move and get a new ophthalmologist or they change systems and my old photos are lost/inaccessible. Having a history can be a big help to them in tracking my age-related vision issues, and so far every system is able to export a PNG/TIFF/JPG image.
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..)
It’s the Carte Jaune (Yellow Card) which has a function of being a record of immunisations that is sometimes useful when travelling to or from regions with specific disease outbreaks (yellow fever, measles, polio etc). The US Government printing office may still print a version of this. https://en.m.wikipedia.org/wiki/Carte_Jaune
I told a doctor I'd received a few vaccinations but forgotten to bring the card, and they just added them with no other questions. I'm pretty sure that was true, but it's definitely not a very bulletproof set of credentials.
There have been several attempts at creating a personal health record system like Microsoft Health Vault. All have failed because providers have no incentive to cooperate. However it appears the Apple Health app is getting some traction and they have built interfaces to quite a few providers.
I remember one system whose idea of a backup was to make a copy of the MySQL database directory to another location on the same machine. Another system would transmit everything I wrote to the backend via HTTP with zero encryption. Lawyers tell me to record everything that happens yet all systems I've used don't let me add any information after the consult is finished, exposing me to legal liability.
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.
Having spoken to a lot of doctors during medical school, it really does feel like a generational thing. Physicians who were trained in the pre-EMR times have a really hard time transitioning. This is partially a UX design failure on the part of EMR companies.
The newer crop of physicians have a much better time using EMRs. Don't get me wrong, they are acutely aware of the ridiculousness that is modern billing-centric medical records. But having been trained in that atmosphere, it definitely appears less painful to their day-to-day.
Perhaps. The older generation has a lot of trouble with computerized systems in general. The younger generation of doctors (including me!) can handle them just fine but find them still to be an overwhelming waste of time.
I'd love it if we just had a great API that workflows could be build upon. And I'd kill for a command line EHR!
I'm older, and maybe this speaks to my age, but I also daily dream of a TUI EMR. Orders done using awk for text field processing, grepping for results, editing notes in vim with medical syntax highlighting and completion...
Alas, I spend my days cursing as Cerner re-draws the unnecessary html and the focus refuses to follow the mouse, and that no one along any of multiple points took the time to write an interaction checker that didn't result in getting three popups to acknowledge that epi boluses given at separate times during a code (and now the patient is dead) don't interact.
Partly generational, partly how ingrained habits/preferences are.
I had to switch from my primary care about a year ago. (He was getting out of doing primary care work because, he said, he had a small practice and just couldn't deal with the paperwork.) From the beginning, he really resisted the computerized systems and probably complained about them pretty much every time I was in for a physical.
My new primary care, in the same hospital system, and not that much younger at least gives the appearance of encouraging things like tele-medicine, using the medical portal, and so forth.
On the contrary. Young docs hate EMRs with unrivaled passion. I am personally convinced that EMRs are a frequent indirect cause of suicide among young docs.
The big part of this issue is how lawyers and politicians make everything more complicated than it needs to be. Doctors can't access the data they need, require multiple forms and signatures for simple things (like transferring records), and are stuck in old school tech / jurisprudence (can I email a scan? Oh, it has to be fax).
Don't even get me started on the format of VAERS data...
Of all the failings of our medical system I don’t think I would cite having safeguards for patient privacy that require explicit unambiguous consent in the form of a paper signature and mandates for secure communication channels. Yes it’s kinda silly that faxing is still allowed and grandfathered in but a lot of times the lowest common denominator since everybody can get a phone line.
You actually can email that scan, your email provider just has to be part of DirectTrust.
I think it's the cost of the bureaucracy and systems that are a major failing, not privacy itself. The litigation involved is also expensive. I'm trying to get my kid's record transferred to primary care from two hospitals and it's a nightmare. I feel like most of the frustration could have been avoided if the personnel involved were properly trained. The costs of visits and treatments include this overhead.
It doesn't matter if the signature is on paper since the files are digitized and thus exposed to attacks. Not to mention that fax isn't really more secure than email. I have yet to see a provider near me who will accept a scanned document through email, but maybe that's different in other areas. Medical files go for a high price on the black market, but they are still fairly prevalent.
I’m not saying that having them on paper makes them more secure or anything, just that signing hard copies is the best way to make sure the signer actually understands what they’re doing and the gravity of it. For you I realize this is not such a great feature but for a system that has to work for absolutely everyone pen and paper works really well. But yeah I’m sorry you had such a painful experience with it. It’s supposed to be one request, you fill out the sheet with the doctor’s info and it shows up at their office.
My bad, of course you can’t email documents to your doctors. The issue is that Gmail isn’t set up to process your medical data. Doctors can email other doctors though with that system. I agree that faxing isn’t exactly the panacea of information-theoretic security but it’s pretty good in terms of policy-security. You’re not going to accidentally have your faxes processed for marketing data and anyone who tries risks big-time jail. Plus faxing these days is all digital and encrypted beyond the last mile. Not super dissimilar to the evolution of email having to bolt on security features after years and years. Unless you’re using a literal physical fax machine it’s very likely that your fax was encrypted the whole way.
I’m surprised your office doesn’t have a patient portal of some sort with an document uploader.
The primary doesn't have a portal. The hospital does, but apparently I had to sign up while there (no one told me). Portals cost money, which raises prices and increases attack surface - not something I particularly like.
I swear we signed a release at the primary that they can request the record from anywhere, but so far it seems to be a big fiasco. I strongly question the training and professionalism that our doctors recieved. My kid suffered an SVT 48 hours after recieving 4 vaccines. While I acknowledge vaccines as generally safe and a great modern accomplishment, the staff seems to be brainwashed into thinking they are infallible. Everyone said it can't possibly be associated. Show me the VAERS and PubMed data then? Looks like I have to submit to VAERS and do the data analysis myself. Who knows, maybe I will be published in a journal if I find some strong correlation. No one else will try.
My first "real" job out of college was database reporting at my local hospital that used Epic. I was young and starry-eyed, but I remember sitting at these Epic trainings and using the software. I knew something must have gotten lost in translation during development, because the software was absolutely a mess of confusing menus and screens. After all, I was a budding software developer with absolute computer literacy, if I didn't get it, who would?!
I remember thinking that there was no way self respecting developers would allow this to happen, but I was so naive!
HCIT is a sh*tshow. It’s mind boggling how nearly 7 years of billions in “investments” have yield minimal improvements. Tax dollars down the drain. And I‘ve seen enough to know that it’s all by design. The entire HC industry does everything within its power to keep the system as opaque as possible.
I used to work for an EHR vendor. Users don't drive features, hospital administrators and CMIOs[1] do. In general, we give hospitals the ability to get better reimbursement from insurance companies by embedding more detailed billing information in the patient's chart and documents. We also help shield hospitals from liability by helping add more details demanded by their lawyers. Information about the patient from healthcare providers for other healthcare providers runs a distant third.
If your old paper chart didn't get misfiled or fall behind the cabinet, almost everything in it was relevant to your care, because there wasn't enough hours in the day to record anything else. Now, it's a sea of compliance bullshit and autocompleted lies -- the unscrupulous practitioners insert multipage reports on tests that were never performed with just a few clicks. (I think the EHR vendors now also sell tools to detect that sort of fraud.) For users who ultimately want to provide care, dealing with electronic medical records is a nightmarish situation and it's leading to burnout at record rates.
1. Chief medical information officer --usually a doctor who became an expert EHR user and now decides what will work for doctors and what won't.
So, HN doctors here, how ‘computer literate’ are
your colleagues?
I have worked with doctors of varying age groups, including family, and it really just depends. Age is not a factor, it seems some people are averse, and others passionate.
This was a long time ago, but a relative of mine was hiking in Wales, and got injured. She made it to the next town and found a clinic, where she was treated. Then she asked how she should pay. They were like, pay? You don't pay for medical care.
She told them that she wasn't from the UK and therefore wasn't covered by their system. But they said that they had no way of figuring out a price or generating a bill for her. So she went on her merry way.
The short version is that primary care services like consulting with a GP, visiting a walk-in centre, or emergency treatment in a hospital accident and emergency department are generally free to all, as are various other specific types of care.
Most secondary care services such as other hospital treatment are only free to people ordinarily resident in the UK, which roughly means anyone who is an EEA citizen or who has the immigration status of indefinite leave to remain, again with lots of other special cases.
Some services, such as dental work and buying prescribed medication, are generally chargeable by default for everyone, though even then the NHS may set standard prices and there are various provisions to help those of limited means or in certain vulnerable groups.
But yes, if you have a nasty accident and need to go to hospital as a result, no-one is going to be asking for your credit card number here before sending the ambulance, and if you only need treatment in A&E and don't need to be admitted as an in-patient, you probably would get most or all of your treatment for free even though the equivalent in certain other places would cost a fortune if you didn't have insurance to cover it. There are a lot of reasons we are proud of our NHS here, and this is one of them.
Just in case anyone reads this later, let me add a final note that if you're coming here, please check the details for exactly where you're planning to visit. A lot of health policy is devolved, meaning policies can be different in England from in Wales, for example.
I'm sure it depends on the country. Denmark currently have five different systems for hospital records, which communicates poorly or not at all. So records from on region has to be manually send to hospitals in other regions. I the future I believe we'll be down to two or three systems, one of which is Epic and the other is developed by a Danish company.
As for pay, pretty much as in the US, each visit to a doctor as a value, but the bill is handled by the local region. Denmark has five Regions, each responsible for the healthcare in that geographic area. The regions are given a sum of money by the state each year, to cover the cost of operating the healthcare system and pay for doctors, hospitals, ambulances and so on.
It's a little complicated, but for instant: I need to see my doctor tomorrow, he'll be paid a fixed amount for that consultation. A consultation is defined as 12 minutes. That's 12 minutes to say "Hi", diagnose, write a prescription (if needed), talk to me about treatment and document everything.
Epic was a medical records system built up since the 1970's in Verona Wisconsin, first developed to turn paper based medical records into a database computer system. A good 8 minute YouTube video from January this year on the sole female founder and the quirky company culture is at:
Epic does do UI/UX studies. It's got a lot of legacy code to plow through, combined with regulatory and customization demands that lead to best UX practices having to be bypassed sometimes. Striking a balance between too much information and having a clinician miss critical information because it was hidden behind a click or hover bubble is always a concern.
Regarding the campus, the theming is actually quite cheap. The bigger expenses come from employee QOL stuff like roomy underground parking to keep cars out of the snow.
Epic's founder, Judy Faulkner, is the fourth richest self made woman in the US. She's the CEO of one of the largest companies in the health tech industry, and almost no one has heard of her.
The author, Dr. Atul Gawande, is more than a bit of a rock star. He's a Rhodes Scholar and MacArthur Fellow "genius grant" recipient. He wrote, among other things, The Checklist Manifesto, having headed up (IIRC) a World Health Organization project to implement short, bang-for-the-buck preincision checklists for surgeries, which apparently improved outcomes dramatically.
This article is what led me to read The Checklist Manifesto. What I loved about that book is that it works through all the traps around how these checklists can be implemented.
An example - Administrators typically want _everything_ on a list, because everything is important, right? However these lists need to be concise enough to be useful otherwise people just ignore them.
I hate my dentist's computer. She's looking at my xrays on the computer, touching the mouse then my mouth.
Should I freak out? What are the odds she autoclaves the mouse between patients.
I hate watching the nurses typing on the keyboards that they wheel around from room to room, and touching patients after touching the keyboards. Especially considering that those keyboards are not easy to clean, and just standard dell keyboards. It's absolutely disgusting.
tldr; information overload, reduced actual time with patients and increased time entering bunch of information into computers, summary from https://autosummarizer.com/ :
My hospital had, over the years, computerized many records and processes, but the new system would give us one platform for doing almost everything health professionals needed—recording and communicating our medical observations, sending prescriptions to a patient’s pharmacy, ordering tests and scans, viewing results, scheduling surgery, sending insurance bills.
But three years later I’ve come to feel that a system that promised to increase my mastery over my work has, instead, increased my work’s mastery over me.
A 2016 study found that physicians spent about two hours doing computer work for every hour spent face to face with a patient—whatever the brand of medical software.
My hospital had to hire hundreds of moonlighting residents and pharmacists to double-check the medication list for every patient while technicians worked to fix the data-transfer problem.
“Now I come to look at a patient, I pull up the problem list, and it means nothing. I have to go read through their past notes, especially if I’m doing urgent care,” where she’s usually meeting someone for the first time.
Many scientists complained to Spencer in the way that doctors do—they were spending so much time on the requirements of the software that they were losing time for actual research.
In 2014, fifty-four per cent of physicians reported at least one of the three symptoms of burnout, compared with forty-six per cent in 2011. Only a third agreed that their work schedule “leaves me enough time for my personal/family life,” compared with almost two-thirds of other workers.
There are messages from patients, messages containing lab and radiology results, messages from colleagues, messages from administrators, automated messages about not responding to previous messages.
Previously, she sorted the patient records before clinic, drafted letters to patients, prepped routine prescriptions—all tasks that lightened the doctors’ load.
She called it “a ‘stay in your lane’ thing.” She couldn’t even help the doctors navigate and streamline their computer systems: office assistants have different screens and are not trained or authorized to use the ones doctors have.
Doctors hate their computers because the software they are forced to use sucks.
And it sucks for the same reason that most enterprise software sucks: because the people who budget for it, choose it, and pay for it are not the people who use it.
For more on this, see this now-classic Twitter thread by Princeton CS Prof Arvind Narayanan:
To be fair, the people who use enterprise software typically only understand a single-digit percentage of what the software needs to do, at best. If you asked them to design it, you wouldn't get a better result.
To properly architect enterprise software, you need to capture the competing needs and goals of hundreds of different roles in different departments. You will uncover underlying political and organizational issues that you will need leadership to sort out before you can ever start to determine the business-logic. To be successful, you have to be an expert at playing politics, business analysis, and mediating conflict.
I wouldn't say "enterprise software sucks"... more like, the lack of cooperation in many organizations sucks, and enterprise software puts a big spotlight on it.
> To be fair, the people who use enterprise software typically only understand a single-digit percentage of what the software needs to do, at best. If you asked them to design it, you wouldn't get a better result.
Sure, users don't know what a system needs to do to meet their needs, but if you had modestly competent business analysts work with them to specify the system, you'd have good results.
The role of systems analyst (nowadays confusingly called business analyst) seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs.
Turns out neither of those beliefs was true, and systems analysts are needed. With the passage of time the role has largely been forgotten.
> The role of systems analyst (nowadays confusingly called business analyst)
Classical systems analysts were, as I understand it, usually the more experienced programmers on a project, and had a role that combined the more recent technical architect and business analyst roles, so they aren't interchangeable with BAs, who often are nonprogrammers, and in any case are viewed as less technical than developers.
> seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs.
In theory, the kind of requirement that is the role of a system or business analyst in other development methodologies seems to be largely shoveled into the responsibilities of the omnicompetent development team in Agile methodologies, though some of it also seems to fall into the product owner bucket in methodologies with that role.
I do think that that the requirements elicitation and analysis skills that go with that role have become undervalued because there is an idea that incremental iteration means you never need to look at requirements in a structured way. I don't think this is even approximately correct, but it seems to be the thinking.
That'll get you part way there -- but for a truly enterprise-wide deployment you also need analysts with deep cross-divisional understanding and some degree of cross-divisional political capital.
Often, organizations that try to do this internally have their business analysts inherently shackled to a specific department or division by nature of the org chart. It is the interdepartmental conflicts that are the hardest to mitigate.
This is one of the lesser-spoken reasons that higher-ups call in consultants -- they have a better ability to short-circuit the org chart and haven't been around long enough to piss off that one director, Karen.
To expand on that EMRs, much like SAP and other enterprise offerings aren't so much fixed pieces of software as ridiculously flexible frameworks for making software. And the people deciding how to configure Epic, and deciding how the doctors and nurses need to use it aren't practitioners, they are administrators who are making decisions for bureaucrats reasons, CYA being high on the list. Anytime an accident occurs, rather than understanding why it occurs, the solution is always to add more administrative controls, to record more details in the chart, more busy work to do that makes each step of the process take longer.
As a result, the number of things that practitioners need to enter into EMRs keeps growing, and every year they spend more and more time charting. This in turn decreases the signal-to-noise ratio of the information in the charts, resulting in the practitioners getting less information out of them despite the fact that more information keeps getting put in. Which results in more accidents rather than less.
Most people don't know that always writing tickets, even if they get refused and ignored, will have an impact. Your goal is not to convince level1 support to be your friend, but to turn the statistics into a way that forces administration to consider your concern. So always write tickets and encourage your colleagues to do the same. And if they get ignored make a screenshot and send it with the headline "lol, got refused again" to the watercooler mailing list and laugh about it together.
Also the devs who write the software never actually need to use it. Developer tools such as editors and compilers are of high quality (relatively, of course) because developers use these tools while working on said tools. Many developers doing enterprise software don't even have a rudimentary idea of the work flow around the app that they're developing. Consequently, they are unable to design an effective and efficient app.
That's not really true. There are open-sourced EHMR's, consumer-facing emrs and in-house built EMRs. They all suck, and there are many reasons for it which are not this one.
Yes and no. People can force software on your office computer but not on your private laptop, tablet and raspis. And even on windows computers you will find ways to install software without admin rights (e.g. Putty doesn't need any admin rights). Therefore I would argue the main thing missing is a desire to conquer the computer as a tool, a tool that might save hours of work time, that might help analyse problems more efficiently than a human brain can, that can help outperform one's colleagues.
With a desire to conquer the computer, open source, and exchanging knowledge online, actually many private enthusiasts who can't afford medical care or won't get the right one can already help themselves. And they have not studied as long or hard as most medical people do. I.e. a doctor with the right spirit should be able to achieve a lot more than such hobby enthusiasts.
And with that passion and knowledge the medical community as a whole would slowly also force better software into their work environments. They know how to hold conferences and argue with facts.
It's hard to blame others if you belong to one of the smartest tribes on the planet.
For the medical professionals here who hate their EHR systems: send the CEO, CTO, President, VP, etc of the company some mail describing your problems, how many people hate it, how much time it drains, one or two ideas on how to make it better, and ask them to forward your mail to the product owners. One of them will hopefully forward it down the chain and in a year maybe one of those things will be less painful.
Also, a bunch of the people reading HN work for different vendors, so light up the comments about specific problems with specific products and we can take them directly to the people who can fix it.
I wonder how often people are pissed at the software companies, when the real villain in this story is their hospital. They're actually upset at customizations the hospital insisted on.
At my last job I tried to get some fields in our bug tracking system made optional. You could run reports showing they were garbage most of the time. Naturally, I failed, and those fields are still required to this day. I started putting "supercalifragilisticexpialidocious" as a value in some of them. No one ever commented on it.
333 comments
[ 4.1 ms ] story [ 291 ms ] threadCommittees composed of doctors know nothing about software design, so their advice to developers is not very useful.
IMHO you need developers, who are also doctors or other providers actually doing the clinical work, to make decent medical software.
(I say this as a paramedic/developer who works for a "clinical first" EHR)
Medical software seems like it is rife with mandated requirements, likely written by people with no regard to real-world usage implications. By this I mean decisions that are akin to attempting to increase security by password complexity and expiry requirements -- when the reality is that decreases security by making users write down and/or cycle through easily-predictable passwords.
I would also guess the purchase cycle is very disconnected from its users. The people actually making the buying decisions never actually touch the software. This is probably also like a lot of enterprise software: very expensive, long contract/license lengths, high switching costs.
A relatively minor point but there's also no dogfooding: The developers building the software are not medical professionals and thus never use it themselves. They don't get to see the daily pain.
The result of all this would be very little incentive to build anything beyond "working" software -- spending time on UX or UI design just eats into profits. The type of developers/PMs/etc that excel at and advocate for this type of work are likely not going to stick around (or even work there in the first place), making improvements even less likely.
Requirements come from the institutions that fund the solutions ("solutions," not products) and not the users themselves, so engagement with end users is limited. It's very waterfall, no product managers, just "business analysts," whose only leverage is their perceived relationship with "the client," who may or may not be represented by an actual user.
I've thought a lot about how to disrupt healthcare, and the only viable way I can think of doing it is selling new products into emerging markets that don't yet have ensconced bureaucracies running health. The most successful grassroots medical product I am aware of is "Figure 1," but any product going into western world healthcare is going to be %95 enterprise solution and %5 health related.
An "Uber for stitches" product would be illegal in most countries, but that's the only kind of innovation I can see driving change for most people.
In my experience, the contrast is stark to another high-paid professional group: lawyers.
I remember WordPerfect being very popular in law offices, but also dictation machines, so who knows?
There was a period during which PCs (as well as other word processors) were coming in when computers were seen as being increasingly important (in law and elsewhere) but the management at many companies weren't sold on it being a good ROI for professionals, especially those billing by the hour, to use them directly.
There was definitely a period of time in many places where there were computers but it was secretaries/paralegals/etc. who actually typed on them. And, remember, a lot of young professionals in the late 1980s had never really learned to type, even hunt and peck.
>In my experience, the contrast is stark to another high-paid professional group: lawyers.
Database systems like WestLaw & word processing systems in the 80s and 90s were killer apps for law offices, so if lawyers are tech illiterate it's a recent phenomenon.
I know several doctors my age and younger that cannot stand using any computer or laptop, while my best friend’s father, a surgeon, had one of the first HP color flatbed scanners (SCSI) and the only person I knew to have an ISDN line.
My cousin is about a decade older than me, and I remember spending the night at his house with his TRS-80 and Apple II computers. He is an attorney.
Maybe the one-solution model isn't the best option.
>But we think of this as a system for us and it’s not,” he said. “It is for the patients.”
Is wrong. It's a misnomer to call them medical record systems. They are primarily billing systems. Sure, improving patient care or reducing paper records are nice. But the #1 thing is to document the care to allow them to bill insurance or the government.
There's tons of operational utilities like e-prescription, lab ordering, patient problem tracking, vital sign tracking, imaging and diagnostics tooling, etc. You could argue that all of those are somehow related to billing because they help doctors see more patients per day, but billing would still be possible without them, and they largely exist because doctors need them to work effectively and treat patients more efficiently, not because they directly serve the billing pipeline.
Not to mention all the issues of paper management and physical security once you have thousands of patient documents scattered around in filing cabinets.
The result is that the number of companies offering a system that meets all the bureaucratic requirements is small, because doing so is arduous and expensive and disheartening. So the few that exist don't have a lot of competition and people still use their product even if it's miserable. People not using their product would have been their incentive to make it better to use, and the disincentive that making it better costs money is still there, so they don't.
You're kind of right though in that it never felt like we did anything because it's what patients or providers wanted. We didn't do things if we were afraid providers wouldn't like it, but a lot of work seemed to be mostly driven by regulatory requirements (meaningful use, icd10, etc.).
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.
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.
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?
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.
At population levels I could concede that these errors may well be inconsequential though.
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!
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.
https://hapifhir.io/
Then use the search operation to find the resources you need.
http://www.hl7.org/fhir/search.html
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.
https://open.epic.com/
I think EHR vendors sometimes get unfairly blamed. The fault often lies with provider organizations who simply haven't turned on the available functionality.
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.
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.
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.
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.
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.
This is probably my single largest source of frustration with building/implementing any enterprise product.
Regardless, best of luck!
"least bad" is not saying much, they're all pretty bad.
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.
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.
"Speed" (latency of response) has always been the number one user interface problem of all interactive software and it still is.
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.
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...)
[0] https://en.wikibooks.org/wiki/GNU_Health
Because people stand to lose profit if GNU Health is used.
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.
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.
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.
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
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.
The newer crop of physicians have a much better time using EMRs. Don't get me wrong, they are acutely aware of the ridiculousness that is modern billing-centric medical records. But having been trained in that atmosphere, it definitely appears less painful to their day-to-day.
I'd love it if we just had a great API that workflows could be build upon. And I'd kill for a command line EHR!
I would kill for a command line EHR, especially if I could edit notes in vim!
Alas, I spend my days cursing as Cerner re-draws the unnecessary html and the focus refuses to follow the mouse, and that no one along any of multiple points took the time to write an interaction checker that didn't result in getting three popups to acknowledge that epi boluses given at separate times during a code (and now the patient is dead) don't interact.
I had to switch from my primary care about a year ago. (He was getting out of doing primary care work because, he said, he had a small practice and just couldn't deal with the paperwork.) From the beginning, he really resisted the computerized systems and probably complained about them pretty much every time I was in for a physical.
My new primary care, in the same hospital system, and not that much younger at least gives the appearance of encouraging things like tele-medicine, using the medical portal, and so forth.
Don't even get me started on the format of VAERS data...
You actually can email that scan, your email provider just has to be part of DirectTrust.
It doesn't matter if the signature is on paper since the files are digitized and thus exposed to attacks. Not to mention that fax isn't really more secure than email. I have yet to see a provider near me who will accept a scanned document through email, but maybe that's different in other areas. Medical files go for a high price on the black market, but they are still fairly prevalent.
This is different than a hospital, but quite cheaper than a normal primary care visit ($200ish). https://www.bloomberg.com/news/articles/2019-12-13/pittsburg...
Anyways, there are tons of problems and costs in the system.
I’m not saying that having them on paper makes them more secure or anything, just that signing hard copies is the best way to make sure the signer actually understands what they’re doing and the gravity of it. For you I realize this is not such a great feature but for a system that has to work for absolutely everyone pen and paper works really well. But yeah I’m sorry you had such a painful experience with it. It’s supposed to be one request, you fill out the sheet with the doctor’s info and it shows up at their office.
My bad, of course you can’t email documents to your doctors. The issue is that Gmail isn’t set up to process your medical data. Doctors can email other doctors though with that system. I agree that faxing isn’t exactly the panacea of information-theoretic security but it’s pretty good in terms of policy-security. You’re not going to accidentally have your faxes processed for marketing data and anyone who tries risks big-time jail. Plus faxing these days is all digital and encrypted beyond the last mile. Not super dissimilar to the evolution of email having to bolt on security features after years and years. Unless you’re using a literal physical fax machine it’s very likely that your fax was encrypted the whole way.
I’m surprised your office doesn’t have a patient portal of some sort with an document uploader.
I swear we signed a release at the primary that they can request the record from anywhere, but so far it seems to be a big fiasco. I strongly question the training and professionalism that our doctors recieved. My kid suffered an SVT 48 hours after recieving 4 vaccines. While I acknowledge vaccines as generally safe and a great modern accomplishment, the staff seems to be brainwashed into thinking they are infallible. Everyone said it can't possibly be associated. Show me the VAERS and PubMed data then? Looks like I have to submit to VAERS and do the data analysis myself. Who knows, maybe I will be published in a journal if I find some strong correlation. No one else will try.
I remember thinking that there was no way self respecting developers would allow this to happen, but I was so naive!
It has nothing to do with why pilots are/aren't epicures, and a more to do with their bosses deciding to serve them crappy food.
Another comment mentions that Epic is amazingly customisable. But that is not in the control of the people who use it.
If your old paper chart didn't get misfiled or fall behind the cabinet, almost everything in it was relevant to your care, because there wasn't enough hours in the day to record anything else. Now, it's a sea of compliance bullshit and autocompleted lies -- the unscrupulous practitioners insert multipage reports on tests that were never performed with just a few clicks. (I think the EHR vendors now also sell tools to detect that sort of fraud.) For users who ultimately want to provide care, dealing with electronic medical records is a nightmarish situation and it's leading to burnout at record rates.
1. Chief medical information officer --usually a doctor who became an expert EHR user and now decides what will work for doctors and what won't.
I have worked with doctors of varying age groups, including family, and it really just depends. Age is not a factor, it seems some people are averse, and others passionate.
She told them that she wasn't from the UK and therefore wasn't covered by their system. But they said that they had no way of figuring out a price or generating a bill for her. So she went on her merry way.
https://www.gov.uk/guidance/nhs-entitlements-migrant-health-...
The short version is that primary care services like consulting with a GP, visiting a walk-in centre, or emergency treatment in a hospital accident and emergency department are generally free to all, as are various other specific types of care.
Most secondary care services such as other hospital treatment are only free to people ordinarily resident in the UK, which roughly means anyone who is an EEA citizen or who has the immigration status of indefinite leave to remain, again with lots of other special cases.
Some services, such as dental work and buying prescribed medication, are generally chargeable by default for everyone, though even then the NHS may set standard prices and there are various provisions to help those of limited means or in certain vulnerable groups.
But yes, if you have a nasty accident and need to go to hospital as a result, no-one is going to be asking for your credit card number here before sending the ambulance, and if you only need treatment in A&E and don't need to be admitted as an in-patient, you probably would get most or all of your treatment for free even though the equivalent in certain other places would cost a fortune if you didn't have insurance to cover it. There are a lot of reasons we are proud of our NHS here, and this is one of them.
Just in case anyone reads this later, let me add a final note that if you're coming here, please check the details for exactly where you're planning to visit. A lot of health policy is devolved, meaning policies can be different in England from in Wales, for example.
As for pay, pretty much as in the US, each visit to a doctor as a value, but the bill is handled by the local region. Denmark has five Regions, each responsible for the healthcare in that geographic area. The regions are given a sum of money by the state each year, to cover the cost of operating the healthcare system and pay for doctors, hospitals, ambulances and so on.
It's a little complicated, but for instant: I need to see my doctor tomorrow, he'll be paid a fixed amount for that consultation. A consultation is defined as 12 minutes. That's 12 minutes to say "Hi", diagnose, write a prescription (if needed), talk to me about treatment and document everything.
https://www.youtube.com/watch?v=8lPMYk09nUg
Regarding the campus, the theming is actually quite cheap. The bigger expenses come from employee QOL stuff like roomy underground parking to keep cars out of the snow.
https://en.wikipedia.org/wiki/Judith_Faulkner
https://www.forbes.com/self-made-women/#68196cf36d96
https://en.wikipedia.org/wiki/Atul_Gawande
An example - Administrators typically want _everything_ on a list, because everything is important, right? However these lists need to be concise enough to be useful otherwise people just ignore them.
My hospital had, over the years, computerized many records and processes, but the new system would give us one platform for doing almost everything health professionals needed—recording and communicating our medical observations, sending prescriptions to a patient’s pharmacy, ordering tests and scans, viewing results, scheduling surgery, sending insurance bills.
But three years later I’ve come to feel that a system that promised to increase my mastery over my work has, instead, increased my work’s mastery over me.
A 2016 study found that physicians spent about two hours doing computer work for every hour spent face to face with a patient—whatever the brand of medical software.
My hospital had to hire hundreds of moonlighting residents and pharmacists to double-check the medication list for every patient while technicians worked to fix the data-transfer problem.
“Now I come to look at a patient, I pull up the problem list, and it means nothing. I have to go read through their past notes, especially if I’m doing urgent care,” where she’s usually meeting someone for the first time.
Many scientists complained to Spencer in the way that doctors do—they were spending so much time on the requirements of the software that they were losing time for actual research.
In 2014, fifty-four per cent of physicians reported at least one of the three symptoms of burnout, compared with forty-six per cent in 2011. Only a third agreed that their work schedule “leaves me enough time for my personal/family life,” compared with almost two-thirds of other workers.
There are messages from patients, messages containing lab and radiology results, messages from colleagues, messages from administrators, automated messages about not responding to previous messages.
Previously, she sorted the patient records before clinic, drafted letters to patients, prepped routine prescriptions—all tasks that lightened the doctors’ load.
She called it “a ‘stay in your lane’ thing.” She couldn’t even help the doctors navigate and streamline their computer systems: office assistants have different screens and are not trained or authorized to use the ones doctors have.
And it sucks for the same reason that most enterprise software sucks: because the people who budget for it, choose it, and pay for it are not the people who use it.
For more on this, see this now-classic Twitter thread by Princeton CS Prof Arvind Narayanan:
"Why Enterprise Software Sucks"
https://twitter.com/random_walker/status/1182635589604171776
To properly architect enterprise software, you need to capture the competing needs and goals of hundreds of different roles in different departments. You will uncover underlying political and organizational issues that you will need leadership to sort out before you can ever start to determine the business-logic. To be successful, you have to be an expert at playing politics, business analysis, and mediating conflict.
I wouldn't say "enterprise software sucks"... more like, the lack of cooperation in many organizations sucks, and enterprise software puts a big spotlight on it.
Sure, users don't know what a system needs to do to meet their needs, but if you had modestly competent business analysts work with them to specify the system, you'd have good results.
The role of systems analyst (nowadays confusingly called business analyst) seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs.
Turns out neither of those beliefs was true, and systems analysts are needed. With the passage of time the role has largely been forgotten.
Classical systems analysts were, as I understand it, usually the more experienced programmers on a project, and had a role that combined the more recent technical architect and business analyst roles, so they aren't interchangeable with BAs, who often are nonprogrammers, and in any case are viewed as less technical than developers.
> seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs.
In theory, the kind of requirement that is the role of a system or business analyst in other development methodologies seems to be largely shoveled into the responsibilities of the omnicompetent development team in Agile methodologies, though some of it also seems to fall into the product owner bucket in methodologies with that role.
I do think that that the requirements elicitation and analysis skills that go with that role have become undervalued because there is an idea that incremental iteration means you never need to look at requirements in a structured way. I don't think this is even approximately correct, but it seems to be the thinking.
Often, organizations that try to do this internally have their business analysts inherently shackled to a specific department or division by nature of the org chart. It is the interdepartmental conflicts that are the hardest to mitigate.
This is one of the lesser-spoken reasons that higher-ups call in consultants -- they have a better ability to short-circuit the org chart and haven't been around long enough to piss off that one director, Karen.
As a result, the number of things that practitioners need to enter into EMRs keeps growing, and every year they spend more and more time charting. This in turn decreases the signal-to-noise ratio of the information in the charts, resulting in the practitioners getting less information out of them despite the fact that more information keeps getting put in. Which results in more accidents rather than less.
With a desire to conquer the computer, open source, and exchanging knowledge online, actually many private enthusiasts who can't afford medical care or won't get the right one can already help themselves. And they have not studied as long or hard as most medical people do. I.e. a doctor with the right spirit should be able to achieve a lot more than such hobby enthusiasts.
And with that passion and knowledge the medical community as a whole would slowly also force better software into their work environments. They know how to hold conferences and argue with facts.
It's hard to blame others if you belong to one of the smartest tribes on the planet.
Also, a bunch of the people reading HN work for different vendors, so light up the comments about specific problems with specific products and we can take them directly to the people who can fix it.
At my last job I tried to get some fields in our bug tracking system made optional. You could run reports showing they were garbage most of the time. Naturally, I failed, and those fields are still required to this day. I started putting "supercalifragilisticexpialidocious" as a value in some of them. No one ever commented on it.