Epic is a steaming pile of shit. I hate the medical software industry so bad. I don’t understand why the current EMRs are so bad. I’m in medical school now but I hope to make a better EMR some day.
I’m upvoting this in hopes that someone with more knowledge than me can explain why the EMRs are all terrible.
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.
Spot on. Epic isn’t designed for patients or clinicians. It’s designed for up-coding patient encounters, that is, to maximize the amount of money a hospital bills insurance or Medicare.
When a hospital switches to Epic, they do so because they know it will result in more money billed per patient. This justifies the outrageous price.
> I’m upvoting this in hopes that someone with more knowledge than me can explain why the EMRs are all terrible.
As another poster said: EMRs are billing and compliance tools, paid for by administrators that are intending to buy billing and compliance tools. They support that function very well.
The people using it clinically (a) aren't the ones paying for it, and (b) tend to be inconvenienced by the very same billing and compliance elements that make it worth paying for.
EMRs don't suck for clinicians because it's impossible to have a nice clinical interface. They suck because they're a non-clinical tool being shoe-horned into a clinical setting and forcing clinicians to do the data entry work.
I went into medical school with the same goal. Intended to do an informatics fellowship after residency. After witnessing the Epic rollout at my hospital, I want no part in EMR development. The beuracracy is disheartening.
I’ve found other places in medicine to make software and have an impact.
That said, I truly hope you succeed. We need more hackers in medicine.
i tried for 3 years to create an emr. we had some success (its being used in the real world) but not enough to be sustainable against the monoliths like epic
my 0.02 on why they arw so bad:
1. the number one goal of emr software is not quality of care. its not user experience. its suppprt and integration for billing. ie, they are accounting systems
2. this partly follows from the fact that emrs are not purchased and implemented by the same people who actually use them. a government mandate and high level health execs make the decision and their priority is the bottom line, in terms of $$$.
3. its not an encouraging field to get into. there is lot of regulation and standards to deal with and not much money to go around to pay for it
Enterprise sales into a heavily regulated industry are really, really hard. On top of that, the primary purpose of an EMR in the US is to provide accurate billing information. So the usability of the system really only matters to the degree that it affects the efficacy of billing.
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.
Does ZocDoc work well for anyone? My experience with it has been that none of the appointment availability is accurate and administrators don't even know about it when you call them up to make sure the appointment has been made.
I'm a big fan of Sherpaa though, from when I had it through a previous employer.
It tends to be hit and miss. Some places have it work well and sometimes it just hasn't gone through. I'll have to take a look at Sherpaa, I hadn't heard of it before.
The database contains 18,000 tables. The same underlying data might be represented in multiple different ways in each of these tables. I say "might" because there is really no way to know - imagine how hard it is to search that vast schema space to find the data you are looking for. The problem results in proliferation of new types whenever a new person shows up.
But most of the useful data is in "patient notes" anyway. These are mostly unstructured, because constructing good medical ontologies is hard, and medical professionals hate using them because the interfaces are bad and the ontologies limit their ability to describe what they need to for patient care. This effectively means it is impossible to search. There is a half-hearted attempt to work around this with "structured notes" which allow you to enter some parseable fields into the note, you can imagine what a mess that is.
It's not written in anything you've ever heard of - it uses a custom database language called MUMPS invented in the 60s. The database is not relational - although every night, the data is ported from the actual Epic database into a relational DB ironically named Clarity. You can get access to Clarity by attending a 5-day training session at Epic headquarters.
Finally, it's a huge monolith - one company runs the systems for hospitals all over the country. You can imagine how responsive they are to requests for change.
Part of the reason why change requests are so hard at Epic is because most of the system doesn't have automated regression testing at all, so any change that isn't a totally new feature requires laborious manual testing just to convince yourself that you haven't broken anything.
To be fair MUMPS isn’t the problem; it’s actually a very interesting programming language, but it’s so far removed from modern programming languages and syntax that is is a pretty big pain to work with.
MUMPS is definitely part of the problem. Easy access to B+ tree globals don't make up for dynamic scoping, loose typing, no namespaces, no 3rd party libraries (and an embarrassingly small standard library,) a terrible console-only debugger, a godawful error handling system, etc.
and lines like this (from VistA) which is, I believe, doing some sort of string parsing.
S PSRT=$S($P($P(BPSORT,U,1),":")="N":PATNAME,$P($P(BPSORT,U,1),":")="P":PINS,$P($P(BPSORT,U,1),":")="S":$S('BPCRON:-DOS,1:DOS),1:BPDIV(BPDIV))
I remember stumbling across code for implementing SHA1. Of course, MUMPS has no builtin code for bitwise operations so there was some code built for it that looked like
switch(operation, operandA, operandB) {
case 1: //AND
{{AND A and B}}
case 2: // OR
{{OR A and B}}
...
}
which manually implemented bitwise operations using integer arithmetic
At least MUMPS gets the "noSQL" thing better than any noSQL tool invented by people who weren't even born when MUMPS came out. But coding anything sufficiently complicated in MUMPS is not the most pleasant task.
Epic has coded around most of these issues internally. So it'll be a problem for anyone trying to pick up MUMPS out of the box, but not really for Epic.
Well, the other language you can work in at Epic is Visual Basic 6, which powers the backend of the patient portal. Newer features are in C#, but anything developed before a few years ago (which are the core features) is all in VB6. Not VB.NET (unless it's changed since I worked there), actual honest to god VB6 plugged into IIS.
It's a lot like PHP, in that everything is performed by string concatenation, except that unlike PHP the language was EOLed in 2003.
MyChart is VB.NET. The main client is still VB6, which is why there has been a big push to a web based client. A few more years and VB6 can be fully retired.
Now on to your question. A lot of the EHR systems have grown organically and in the end they are made by people with software experience but not per se medical experience.
Disclaimer first: I work on a competitor for Epic (Well, they only run in 3-4 hospitals in my country and we run in 30, so they're not really a threat). And I'm not saying we are doing it better than Epic, but these are a few of my thoughts (loosely collected).
1) Most of us don't have medical training. Our campus is shared by a university / hospital, so we do have access to a lot of doctors and when they work with us, their sides of the program tend to run quite well. But, not all doctors want to spend time on this (understandable) so one system might be well tailored for doctor A, but not to Doctor B.
2) The systems are _old_. They grow organically, but Epic is a few decades old and our system started in 1992, so it's by no means 'young' either. The Medical field evolves and so does the software field - we are playing catchup on both most of the time.
3) We can't afford downtime. We can't just decide "upgrade tonight and go offline for a bit". So we have to engineer around this. We release a new system of our software every week (one week testing by a dedicated team with medical knowledge, then production). But since we can't do a bulk update and force people to restart, we need to deal with different versions which impacts the code quality.
4) We run on multiple hospitals. Hospitals have their own way of working, but to tailor to each hospital directly becomes impossible at some point. In the end you get a system that doctor Y from hospital A really likes, but doctor B from hospital A doesn't. Here, sadly, money will factor in. If you want the software more tailored you will have to pay more. And this is not just to the doctors to decide.
5) These systems are _huge_. (SVN reports a linecount of just over 37 million at the moment). Because they do a lot, to give an idea:
* Patient scheduling (find optimal time for a patient to get X therapies)
* Decision support for doctors (suggested medication, ..)
* AI System to monitor patients in the hospital
* Scheduling for the devices (MRI, CT, ..)
* Communication system between specialists (GDPR compliant nowadays, yay)
* Import/Export to share with all other hospitals
* Billing system
* Social insurance integration
* Government integration
* Medication system
* ER System
* ....
This is a pretty loose collection of some things that come to mind. :)
> We can't just decide "upgrade tonight and go offline for a bit". So we have to engineer around this... But since we can't do a bulk update and force people to restart, we need to deal with different versions which impacts the code quality.
This is pretty typical of almost any customer-facing software written these days. Every mobile app has this problem. Web apps have this problem to a lesser extent.
Because the primary contribution to a patient's health is factors beyond the healthcare provider's control, like the patient's wealth, education and genes, followed by a mix of real and placebo effects in evidence-based medicine.
Generously, if IT is number three, it's just not going to work as much per dollar as say, transferring money directly to the patient (in the form of free healthcare) or R&D funding (in institutions like the NIH).
I know of this industry, in the hardware side, that if someone "has a way" to get a device certified to selling in a country, that someone is sitting on a lot of money. It's ridiculous. The laws made to protect user's from low quality products became a corruption-bureacracy user's money exploiting shady horrible industry. Not to mention the ethics on the Patents related side of the medical tech.
I’m upvoting this in hopes that someone with more knowledge than me can explain why the EMRs are all terrible.