Hacker News Reader

Comment by samstave | Hacker News Reader

They did. VA pioneered emr...

OpenVista by medsphere is based on Vista, the gov emr...

All emr companies are walled gardens.

In 2009 I built the first mobile HL7 compliant client for the iPhone which was emr agnostic and could work with any emr -across an esb... But all emr companies shunned us because they wanted to protect their walled gardens. At the time hospitals shunned us because they didn't believe the iPhone was a good enough device (big enough screen) to be usable...

We built integrations into a number of systems... But couldn't get traction at that early stage. So we open sourced it through medsphere...

Dr chrono came along and took different tack which was to make an actual emr...

After working with so many hospitals and these systems I basically gave up... The system is pretty broken and the artificial barriers to entry are pretty lame.

View on HN

> HL7 compliant client... which was emr agnostic

In my experience, there's no such thing. HL7 is a spec in only the loosest sense of the word. Half the time you had an 80-character console output dumped into the "freetext" fields. Then there's all the codes used for different drugs, tests, admission/discharge (plus differentiating when they're standardized or user-entered with appropriate typos).

Point is, all the costs were really in the integration. Getting access to the HL7 streams wasn't bad once you got far enough in the sales cycle. Once you had it, it was a one-off project to parse the specifics of the messages. And that was just for a read-only analytics system... trying to generate compatible messages to feed back to the EHR is a whole other beast.

That's the challenge getting into this space if you're a web or cloud engineer... you come in with the mindset that "oh, HL7 is a messaging standard, I'll just read the spec and use it." In practice, there's an infinite amount of variability. You really need to treat each hospital as it's own one-off integration, plus all the politics needed to get access to the messages in the first place.

That's exactly why I'd want to tie a nationwide EHR/EMR system to Medicare reimbursements. In this case, not only must you drag the horse to water, you must force it to drink.

Obligatory xkcd: https://xkcd.com/927/

Touché.

Having used the VA's system as a physician a few years ago, I must say it's probably my favorite. Epic, Sorian, etc add a lot of worthless gloss with minimal increases in functionality, in my experience (probably doesn't have good billing modules but those could be added). I've always thought it was a shame that this wasn't govt mandated EMR ... Im usually for competition, but in this case, we've spent millions (billions?) to reinvent the wheel. It's not at all uncommon for me to print labs off of a screen, then fax them to a different facility, where the values are then input by hand back into a (different) EMR. Completely insane, like something out of Terry Gilliam's Brazil.

I also must say that I've seen hospitals make absolutely terrible decisions when it comes to EMRs. Choice of EMR should be treated as if the hospital is constructing a new building, as its costs and lasting impact can be that massive.

Exactly. Vista has pretty lousy UX, but it's implementation across most of the VA it a central part of the VA's much greater efficiency that other systems with similar populations.

Of course, being written in MUMPS (just like some of the other biggies) doesn't help, but the failure of Vista to be implemented commercially has to do with market and human reasons that could have been engineered around. Missed opportunity for the US, really.

Yup. We need data at rest standards tied to Medicare reimbursement.

If you can't win with the carrot, switch to the stick.

Reply on news.ycombinator.com