Live data from Hacker News

OpenEMR v5.0.1

openhealthnews.com

31–39 of 39 posts

Re: OpenEMR v5.0.1

#31

Earlier quoted context omitted.

The other issue with Epic is that it's designed for hospitals. The parent comment sounds like a doc in a smaller practice. There are certainly EMRs out there better suited to that environment (disclaimer: I work for one that I think does an especially good job at that)

Yes, I primarily work in a small clinic setting, though I've also used Epic in a hospital setting and have been similarly unimpressed! ;) In general, I think that EMRs try to cram as much information onto the screen as possible, without enough thought toward what pieces of information are useful at particular times. It's like the opposite of the experience that I have on a well-designed website. Most of my complaints…

>In general, I think that EMRs try to cram as much information onto the screen as possible, without enough thought toward what pieces of information are useful at particular times.

The thing is, healthcare has so many variables it's hard to know what is relevant and useful at any one time. It's not a static website where the designer knows the exact content. The best solution has been to make sure it's all available to the physicians and nurses that can then decide what is relevant. It becomes a trade off of what to hide behind more mouse clicks or to cram into a small window. Now that data analytics are advancing, the system can be designed to show the most relevant stuff, but obviously it takes work to write that system and ensure it's trustworthy for being used for healthcare.

Re: OpenEMR v5.0.1

#32
I'm late to the game but wanted to provide some context for the discussion. The dominant EMR in hospitals is Epic - can't find a cite but the ballpark is that more than 80% of academic medical centers have adopted (ie, paid through the nose for) Epic.

As a clinician, I find Epic to be horribly clunky - it definitely detracts from time with patients and impairs collaboration among clinicians by 'hiding' important details in multiple sections/submenus. It's like a Frankenstein's monster of Windows 3.1 and Atari 2600 Basic.

As a researcher, the very restrictive agreements that Epic insists upon have a profound impact on our ability to a) make good use of health records data for research and b) develop extensions to Epic, for things like decision support and risk stratification. (In the latter case, they essentially 'own' anything that touches their code.)

BUT - like the old saying goes, no one ever got fired for buying IBM.

Moral of the story: Hooray for OpenEMR, VistA, and all the open platforms! This round was lost to Epic, but hopefully the next round we can do better.

(edit: - academic medical centers in the US. Rest of world, you can do better!)

Re: OpenEMR v5.0.1

#33
I'm a volunteer that has been contributing to OpenEMR for more than a decade and the last year, which is well represented by this 5.0.1 release, has been by far the funnest and most exciting yet. It's a great community that is open to volunteers of all types; come check us out.

Re: OpenEMR v5.0.1

#34
really good people are involved with this software project and they make it easy and fun to contribute; there's still a ton of work to do so get involved if you're able

Re: OpenEMR v5.0.1

#35
post #23

Earlier quoted context omitted.

Yes, I primarily work in a small clinic setting, though I've also used Epic in a hospital setting and have been similarly unimpressed! ;) In general, I think that EMRs try to cram as much information onto the screen as possible, without enough thought toward what pieces of information are useful at particular times. It's like the opposite of the experience that I have on a well-designed website. Most of my complaints…

Hank, I'm the one who's been handling OpenEMR's cloud deployment packages -- I've been working on a range of targets from a single-instance low-resource non-HIPAA (education or international) target (OpenEMR Express), to a HIPAA-eligible solution that meets encryption and auditing requirements (OpenEMR Standard), and at the lavish end, I built an enterprise-grade deployment (OpenEMR Full Stack) that leverages AWS Ava…

I would be happy to help out. Feel free to connect on keybase (see profile) or let me know how to reach you. Thanks.

Re: OpenEMR v5.0.1

#36
post #29

I started contributing to OpenEMR 1-2 years ago. Great community! If this is your first foray into open-source I'd highly recommend getting in touch with the admin and getting involved in the many exciting projects happening. We are currently working on integrating OpenEMR with PACS so if you are interested feel free to reach out to me or OP!

Thanks :)

We are better off for you!!!

Re: OpenEMR v5.0.1

#37

Earlier quoted context omitted.

The other issue with Epic is that it's designed for hospitals. The parent comment sounds like a doc in a smaller practice. There are certainly EMRs out there better suited to that environment (disclaimer: I work for one that I think does an especially good job at that)

Yes, I primarily work in a small clinic setting, though I've also used Epic in a hospital setting and have been similarly unimpressed! ;) In general, I think that EMRs try to cram as much information onto the screen as possible, without enough thought toward what pieces of information are useful at particular times. It's like the opposite of the experience that I have on a well-designed website. Most of my complaints…

The amount of data on the screen, depending on where you experienced it, is also configurable by the IT department. One of the tasks that I have at my job is to make the data on the screen as concise as possible.

I am not sure when you last interacted with Epic but it has come a very long way in the last 8 years in the realm of personalization, macros, mobile access, and alerting (you can subscribe to results and be notified on your phone or watch when it returns as one example).

My goal with the providers I work with is to provide minimum scrolling, limited clicks, and easy ordering, all while being as workflow agnostic as possible through personalization of the user experience.

As to the need for faxing and scanning, the VA benefits from being completely uniform and, frankly, socialized in its data. The non governmental hospital system consists of millions of data sinks (data centers, file rooms, etc) and all of them are owned and controlled by different entities. The fact that even the level of data that can be requested and accessed instantly between health care providers exists as it does today is impressive.

Re: OpenEMR v5.0.1

#38

Earlier quoted context omitted.

Yes, I primarily work in a small clinic setting, though I've also used Epic in a hospital setting and have been similarly unimpressed! ;) In general, I think that EMRs try to cram as much information onto the screen as possible, without enough thought toward what pieces of information are useful at particular times. It's like the opposite of the experience that I have on a well-designed website. Most of my complaints…

The amount of data on the screen, depending on where you experienced it, is also configurable by the IT department. One of the tasks that I have at my job is to make the data on the screen as concise as possible. I am not sure when you last interacted with Epic but it has come a very long way in the last 8 years in the realm of personalization, macros, mobile access, and alerting (you can subscribe to results and be…

To be fair, we've only just implemented it. Sounds like we need to hire you to help us make it a better experience!

Re: OpenEMR v5.0.1

#39
post #25

Earlier quoted context omitted.

It's kind of a shame about VistA, the VA system. It's the most widely used well liked hospital system >The VistA system is highly rated by physicians, receiving the highest overall score in Medscape surveys of over 15,000 physicians in 2014 and again in 2016, receiving particularly high marks for connectivity and utility as a clinical tool. https://en.wikipedia.org/wiki/VistA and available free open source http://wor…

It's also written in an obsolete, obscure programming language https://en.wikipedia.org/wiki/MUMPS .

I wouldn't call it obsolete (since it's still actively being used/developed in) or obscure (since there's a large and active user base). But it is a unique programming language.
Post reply on HN