Hacker News Reader

Comment by christophilus | Hacker News Reader

This is refreshing to see. I was just at the doctor today, and they mentioned how a recent system update (they use a system called Epic) made their receipt printing go from an abysmal 30 seconds to a full minute.

It seems that programs get bloated and slower with each passing day. I'd love to see a Renaissance of small, focused, efficient applications.

View on HN

From what I've heard, Epic is the best out of all the EMR (electronic medical record) software platforms!

Quite the back handed compliment! They are one of the better ones but the bar is extremely low.

I wonder why this field hasn't been disrupted yet. It seems ripe for it. Established players. Arcane systems. Poor performance. From what I've heard from employees at Epic their software is something of a nightmare.

Is it just something waiting to happen? Is there a company that is already doing this? It could probably be done one independent hospital at a time. Eventually you could get a small network, etc. I understand there is quite a bit of complexity involved, but isn't that what technology excels at?

Edit: Did I forget to mention expensive? These systems are not cheap, and usually involve engineers spending weeks or months onsite setting it up. That means there should be a significant of margin to cut out for competition, and/or healthy revenue for a startup, at least further down the road.

I worked at Epic a long time ago. They're a bad employer -- churn that would make the worst valley sweatshop blush -- and even when I worked there had 10s of millions of lines of vb6 and the same in mumps/cache, the world's worst programming language. I'd imagine their systems have broken 100m lines of code by now.

You're essentially using software to automate how hospitals and outpatient clinics work. Each one of those has established workflows/procedures; each of those workflows have started or evolved to be (at bare minimum) subtly different than everywhere else. Each and every procedure has to be build into the software or adapted to it. Installs are comparable to installing ERP systems into fortune 500 or fortune 100 companies, with at least comparable risks. Imagine how risk adverse you would be if inaccessible, incorrect, or incomplete health records could quite reasonably contribute to severe medical problems for humans.

If you were ever in a hospital for something serious pre EMRs, you would be unsurprised to have a file that is several hundred sheets of paper. Every single scrap of paper in a hospital has to make it's way into Epic's EMR.

Oh, and hospitals / clinics often buy these systems piecemeal, starting eg with labs. Your code has to talk to their code.

Lots of these got started before web clients worked well, so they're deployed clients. You can't upgrade 10k seats simultaneously, so both the clients and the servers have to be compatible up and down protocol versions. Ponder just how much fun that would be.

Or ponder just how convoluted the logic would be to ask if a person who does X in clinic A is allowed to see record B for patient C. In, for example, a hospital chain that may employ 25k+ people in the hospital and various outpatient clinics.

And follow up with questioning the idea (and expense!) of retraining every nurse, doctor, aide, tech, etc in a hospital on a new system.

TDWTF had an article about MUMPS that stands out in my memory [1]

When I see COBOL fixed width data at my workplace, I just think about that article and thank my lucky stars.

[1] http://thedailywtf.com/articles/A_Case_of_the_MUMPS

MUMPS really isn't a bad programming language. It has certain characteristics like allowing incredibly terse code, with abbreviations for all the commands and single letter variable names, but the trade-off of a NoSQL hierarchical datastore acting as variables to the programs with string values and string subscripts on arrays, hiearchical inter-process locking, high level variable management and garbage collection, run time code and variable evaluation, and other advantages. Modern MUMPS systems have high level database management systems as well.

If I'm not mistaken that is about Epic, but they didn't write the name to prevent lawsuits.

Please tag this as NSFL.

I work in an industry you wouldn't think is similar (telecom). It's hard to establish trust, it's more complex than you think, it's more regulated than you think, more rules than you think, closing deals takes longer than you think (6 months is long? Try multi-year sales cycles!), big companies will ruthlessly undercut you to destroy you at their own expense...

You can't just slap together a single page javascript app and close a deal. You need credibility, capital, time, solid engineers... and most strong engineers will avoid EMR software like the plague given the riches they can make in other areas in 1/10 the time.

I wish everyone the best of luck, it needs to happen, but it will be hard.

There are companies that are trying. Athena was doing a good job in a lot of respects but then decided they wanted the hospital market and that hasn't gone well. The issue is that switching EMRs has a huge switching cost. You are looking at years just to get the sale. Then there is the time and cost to switch which can easily be 6-24 months depending on size. The biggest problem is that all the health care workers have to relearn a whole new flow and these things are not trivial. Add in that most health care workers are not as tech savvy as you would think.

Additionally, as was mentioned, the health care systems depend on the EMR for all government and compliance reporting. The EMRs also do NOT play nice together so even if you get customers, it is hard to get data out and shared with other systems. It is possible to disrupt this space but you better start with a war chest, start with a very focused niche (say Urologists) and be prepared to slog it out for a decade.

Thank you. It looks like Athena is trying to do just what I described. They even have an incubator for new health related startups[1]. Of course, it is difficult to know from the outside how well they are doing and their trajectory, but I am (foolishly?) optimistic.

[1] https://www.athenahealth.com/more-disruption-please/labs

The incubator program is fine but it is a little bit dependent on their cash flow. They sunk too much money into the hospital space and their free cash flow is down and so is their stock price. Johnathan Bush is a free spirit and willing to be disruptive which is their greatest strength. If I lived in Boston still, I would be working there.

(not an expert in this field obviously) I believe that it might have to do with HIPAA compliance and the red tape overhead that scares away potential disruption. But I imagine if someone were willing and able to disrupt it, they'd make money hand over fist.

Weeks or months... Try 2 years.

The quality of programmers working for companies like this is terrible. I'm talking about programmers who claim to "know" C++ because they used it once during a computer science project and just managed to avoid getting segfaults too often after lots of trial and error. Writing a small, effective program has been a sign of competence forever because we know that you can't "fake" it. You really have to know what you're doing.

Bloat wouldn't even account for a delay this long. This seems to be the realm of bad design or overly cautious developers. My guess is that 'printing the receipt' really means process the transaction hitting a bunch of different record stores and APIs along the way and that the system waits for all of that to complete before sending the print job.

This is why i have the habit of never updating anything unless it's linux.

Reply on news.ycombinator.com