I’m upvoting this in hopes that someone with more knowledge than me can explain why the EMRs are all terrible.
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.
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.
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’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.
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
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.
[1]: https://www.epic.cumc.columbia.edu/timeline/implementation-p...
I'm a big fan of Sherpaa though, from when I had it through a previous employer.
I'd love to hear more about this.
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.
https://code.osehra.org/gitweb/?p=VistA-M.git;a=blob;f=Packa...
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}}
...
}It's a lot like PHP, in that everything is performed by string concatenation, except that unlike PHP the language was EOLed in 2003.
https://thedailywtf.com/articles/isn-t-there-a-vaccine-for-m...
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. :)
Indeed. We joke in our emergency department that patient’s die during Epic downtime. We aren’t really joking.
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).