Hacker News new | past | comments | ask | show | jobs | submit login
OpenEMR v5.0.1 (openhealthnews.com)
123 points by exception_e on April 28, 2018 | hide | past | favorite | 37 comments



I am looking for some strong server side programmer volunteers (and volunteers of _all_ types)! Email is in my profile.

Be a force for good in the developing world !

https://open-emr.org/welcome/

-Matthew (OpenEMR Admin)


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!)


From what I understand the software for EMRs isn't very complicated (message queue + message parsing + encryption). What is an issue is integration with other provides who....

    1. Have the data you need
    2. Charge a huge premium for integration
    3. Don't like giving up their data
    4. Always have their slight twist on message format
This is a huge step forward still. This kind of software is not easy to get right. Soooo many variables and sooooo much demanded customization as well as almost mandatory adherence to incumbent UI designs


Actually, you'd be surprised. There are not many good EHRs out there. It's all about the features and the ability to make the system work with your workflows and use cases.

Of course, your points are valid though! That is the state of the "behind the scenes" side of things :).

EDIT: Just saw your edit and your correct assessment of the need for a great UI (we have gaps, but a good team working on it).


Having used many EMRs over the past 10 years, I totally agree—there are not many (any?) good EMRs out there. Most are clunky UI/UX nightmares that end up interrupting the visit and leave me frustrated and staring at a screen far more than I should be.

I stumbled across OpenEMR a few months ago (as I was cursing Epic and praying for a better open source option) and must say that I’m impressed with the speed of progress. I’m certainly not a developer but I am a physician—if you need any more volunteers from medical personnel, I would be more than happy to help.


90% of Epic's issue is how a Hospital implements it. It is so configurable that compliance and leadership will lean on it way more than they should to drive policy leading to BPAs, poorly created OrderSets, and way too many documentation points that contain low value....Then there is the case of not implementing the features that Epic releases that will make life better for the users because the IT department is underfunded or the leadership does not want to change....and then the fact that many users do not like to be trained on how to improve their use of the system.


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 are around that phenomenon, as well as all of the unnecessary clicking / scrolling required due to poor design. I also think that the cost of implementing / migrating these systems is insane, especially when that just adds to our already overpriced health care system. It's hard not to think that companies that build EMRs prefer to be as closed and proprietary as possible, to prevent an easy switch to a competitor.

A few things that I do like in Epic and think are generally good features in EMRs: -lots of shortcut keys -saved phrases (I think they're called "smart phrases" or some nonsense like that) -single click connectivity into clinical resource websites and some hospital portals -modern browser support (I seriously used to use an EMR that could only be accessed on an old version of Internet Explorer -- "just make sure you don't let the computer update the browser") -eprescribing

My favorite EMR of the 10 or so that I've used was at the VA. (I've heard, though not verified, that that EMR was licensable for almost no cost outside of the VA, but was ignored in favor of "nicer" systems.) I don't know if it is the same now, but it was extremely simple in appearance with some basic fields for writing notes, an image viewer, a quick way to order and review labs, etc. Looked almost like a terminal. Copy/paste functionality. Most importantly, because it was used at every VA in the country, I was able to easily review records/labs/images from, for example, a 65 yr old veteran who had just moved from across the country. No faxes, no scanning. It is this sort of uniform system for data access that we are missing right now in medicine in the US and it is wasting time, costing us a lot of money, and damaging patient care.


>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.


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://worldvista.org/AboutVistA/copy2_of_index_html

but hospitals instead spend hundreds of millions on Epic and Cerner who I presume have fancy sales teams to push those to hospital managers.


OpenMRS-based systems are widely used in the developing world in hospitals, not sure what the barriers are to first-world adoption.


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


Mumps is also used by Epic, the market leader and various banks. It or a variant is being developed by InterSystems who claim their system is the world’s fastest object database. So it struggles on. It actually sounds quite interesting tech.


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.


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.


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


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 Availability Zones to keep the whole application running even if Amazon loses a data center.

I'd love for you to take a look at what we've got going on -- the day might come when we're a good fit for somebody's clinic.


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


I am working in this area and would love to pick your brain. (My brother and I run a clinic in SC, which I've made the software for) We've made some cool stuff and are close to releasing it to the general public. My email is in my profile if you want to reach out.


There is an ambulatory module that is designed for clinics. The cost of implementing Epic certainly is not within the realm of an independent practice so it is only reasonable for hospital systems to deploy for their clinics and affiliates.

I would not expect the commenter to have had an experience outside a hospital affiliated clinic if they work as an AMB provider.


There's a lot of compliance stuff that goes into EHRs on top of all of that. Accessibility is extremely important as well- voice recognition being a huge part of that (OpenEMR offers integration with the Microsoft EMR, but I don't believe that has decent medical support which would be a huge limiting factor).


Dragon Medical works great with the system! Not free though.


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!!!


Getting a LOT of emails from interested programmers. Woot! Please get in touch for non-programmer roles too (documentation, clinical, infra, ui, design, etc)


What is the ODB for this?


ODB?


Ol' Dirty Bastard, a former member of the Wu Tang Clan who died in 2004. Java has long had the ability to communicate with his departed spirit with its ODBC technology.


Clearly downvoted because you called a Windows tech a Java tech


Operational Database


MySQL/MariaDB and CouchDB


Are those options or do you use CouchDB for your primary DB and MySQL for your report writing with an ETL process taking data out of CouchDB every night?


MySQL for tabular data, CouchDB for documents.

Users control the backup routine. Our AWS packages make it seamless, however.


OpenEMR 5.0.1 is truly a game changing release for OpenEMR users. The features like Image viewer, Docker integration are really cool and handy. Also looking forward for more exciting features like cTAKES integration.


Archived version, since the site seems to be down.

https://archive.is/GDVO5


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: