I used to work at Epic as a software developer. My take on it is that the key explanation for why medical software is so bad is that it is so hard to even attempt to compete with established EMR's.
I could go on at length about this but I'll try to keep it short. Basically, imagine that you're a startup and you want to compete with Epic in providing a comprehensive IT solution to health systems. You will _at least_ need to:
1. Write software for every major medical specialty that is comprehensive enough to satisfy the specialists' expectations of domain-specific tailoring
2. Also ensure that these modules are flexible to accommodate intra-specialty variation (for example, oncologists vary a lot in how they divide stages of cancer)
3. Ensure that your software will comply with and help your customers perform well financially with federal, state, local, and program-specific (Medicaid, Medicare...) regulations
4. Go into a room full of health executives who are deeply weary and suspicious of health IT people (for better and worse reasons) and convince them they're better off risking a multi-year, extremely expensive transition project on your startup, which might not be around in a few years, instead of going to an EMR vendor that's almost-not-even-mediocre but stable like Cerner or Epic. (The "nobody gets fired for buying IBM" effect here is real.)
Clearly all of this requires a lot of work, and would require millions of dollars in funding and the poaching of some top talent in healthcare IT who know the lay of the regulatory land. As a result, most HIT startups (that I know of, at least) target something less ambitious than an enterprise EMR. Some target only a specific specialty (like home health or care management), others target small family practices (which are becoming increasingly rare as they are bought out by major health systems).
This is in a way bad for everyone except the software vendors, though, because without a competitive threat, there is little incentive for companies like Epic to undertake the risky, major rewrites which are vital for the company's long-term technical health. Epic still uses a typeless, (almost) data structure-less language called MUMPS for its server and DB code, and on the client side, all of it is still either in VB6 (yes, 6, not .NET) or a quite spartan home-grown JavaScript framework. The result is that bad code never gets totally thrown out, and Epic's developers are not able to benefit from the productivity-multiply amenities of modern languages, which include type systems and abstractions more powerful than subroutines and goto statements. Development then takes an order of magnitude longer than it might have, and the feedback cycle continues.
Healthcare tech is notoriously bad, but over the past 5 ish years there has been a wave of healthcare tech companies who focus on making their products consumer-friendly (ZocDoc, DrChrono, Oscar, PillPack, Capsule etc). NYC in particular has a large healthcare tech industry.
So why are EMRs so bad in the US?
1) Most EMRs are on-premise software with that being the preference due to regulatory/compliance/security risk. Because the EMR companies don't have the ability to deploy changes or updates on their schedule, the rate of change is much slower and updates made for one client aren't made for all clients.
1a)Many of these EMRs are heavily customized per client (think Epic in particular). These customizations aren't often being brought back into the core product but are one-offs. Think of it like starting from scratch with each client.
1b) Unlike the Googles/Facebooks of the world which are built on web software, there's no easy way to deploy. This means that where tech first companies are probably deploying multiple times an hour, Epic/Cerner installs are probably being updated once a month or less. Some hospital systems are running on software that's 10+ years old.
2) Large initial barrier to entry. The sales cycle for most healthcare software is close to a year minimum. For EHRs, which affect how the entire hospital runs, it's almost certainly a multi-year effort. Most EHRs are signing 5 year contracts, so providers can only switch every 5 years. And for the large providers it can take 5+ years to implement a switchover from one EHR to another [1]. This means that any new entrant needs a lot of startup cash and the ability to sell to provider systems.
3) You're building regulated software, which means that most of your third-party components have to be secure and HIPAA-compliant. Also your developers probably don't have access to production data or error reporting, so fixing issues can take a long time.
4) You're building enterprise systems. Whatever you build has to support EVERY department in a provider from the ER, to the pharmacy, to billing. What makes sense for one department won't make sense to another so you end up with products built by committee.
PS You may be interested in looking into some of the modern EMRs that have come out. They seem to focus on either small practices or specialties. DrChrono is one, Flatiron Health is another.
I own a company that is attempting to modernize electronic medical records, and there are plenty of legitimate reasons why medical software is bad. The decision makers at large hospitals are even more conservative than other large enterprises. Nobody is willing to risk their career/hosptial by writing an eight or nine figure cheque to an unproven enterprise to run their critical infrastructure. So the market is dominated by companies that were earliest to market (Meditech, Epic, Cerner, Allscripts) or have big enough pockets to compete (GE's Centricity, McKesson). Nobody ever got fired for choosing IBM.
Hospitals were some of the earliest adopters of computers and the systems that were developed have been in place for decades. Most of these systems carry a lot of baggage from their development history and are too risky or brittle to modify without good reason. It's the same story that most big banks find themselves in. Everything is clunky, confusing, and old but the job gets done and that is good enough.
The people making purchasing decisions do not care about the usability of the product, as they are not going to be the ones using it. They mostly care about billing, compliance, data integrity, security, and managing costs. Electronic medical records primarily exist for billing an insurance company or the government. Every other reason given for their existence is secondary to that need. If you don't believe me, check how many staff members are dedicated to billing at your hospital. For reference, the average staff ratio is 2.7 billing professionals for each physician across the industry.
Medicine is both an art and a science. Even physicians in the same discipline vary greatly in the way that they practice their craft. There is no way to turn a hospital visit into an assembly line. Nothing is standard, everything is specialized. This is at odds with the ideal software project, where everything is defined up front and can be turned into an efficient repeatable process. If it were easier I think you would have greater competition which would lead to better products.
Can we do better? Absolutely. The limiting factor is not software development talent. You need to understand how the industry operates to be able to find a foothold. Attacking the incumbents directly will end in certain doom. If you want to learn more about how we're approaching the problem my email is in my profile. We built a product to run our own clinic and are almost ready for wide release.
I could go on at length about this but I'll try to keep it short. Basically, imagine that you're a startup and you want to compete with Epic in providing a comprehensive IT solution to health systems. You will _at least_ need to:
1. Write software for every major medical specialty that is comprehensive enough to satisfy the specialists' expectations of domain-specific tailoring
2. Also ensure that these modules are flexible to accommodate intra-specialty variation (for example, oncologists vary a lot in how they divide stages of cancer)
3. Ensure that your software will comply with and help your customers perform well financially with federal, state, local, and program-specific (Medicaid, Medicare...) regulations
4. Go into a room full of health executives who are deeply weary and suspicious of health IT people (for better and worse reasons) and convince them they're better off risking a multi-year, extremely expensive transition project on your startup, which might not be around in a few years, instead of going to an EMR vendor that's almost-not-even-mediocre but stable like Cerner or Epic. (The "nobody gets fired for buying IBM" effect here is real.)
Clearly all of this requires a lot of work, and would require millions of dollars in funding and the poaching of some top talent in healthcare IT who know the lay of the regulatory land. As a result, most HIT startups (that I know of, at least) target something less ambitious than an enterprise EMR. Some target only a specific specialty (like home health or care management), others target small family practices (which are becoming increasingly rare as they are bought out by major health systems).
This is in a way bad for everyone except the software vendors, though, because without a competitive threat, there is little incentive for companies like Epic to undertake the risky, major rewrites which are vital for the company's long-term technical health. Epic still uses a typeless, (almost) data structure-less language called MUMPS for its server and DB code, and on the client side, all of it is still either in VB6 (yes, 6, not .NET) or a quite spartan home-grown JavaScript framework. The result is that bad code never gets totally thrown out, and Epic's developers are not able to benefit from the productivity-multiply amenities of modern languages, which include type systems and abstractions more powerful than subroutines and goto statements. Development then takes an order of magnitude longer than it might have, and the feedback cycle continues.