After 7 years administering an OpenEMR system including a bit of hacking to customise it we are now looking for a new solution as OpenEMR no longer fulfills out needs especially with the direction the project is heading. As such I’ve been putting OpenMRS through its paces to figure it out as well as some module development for our custom needs. As such, I feel I can offer some insight into the two.
OpenEMR is a fantastically good out of the box fully functional package IFF you’re based in the US running a moderately sized facility and have little to no desire to customise/adapt it. The appointments system in particular is one of my favourite I’ve come across, even if the library doing it was officially deprecated in 2005… Sadly though I’ve found time and time again that some workflows just don’t work for us, and adapting them is next to impossible.
I’ve also found the guts of OpenEMR to be downright ugly in places, view logic mixed in with core business logic mixed in with raw SQL statements. Code documentation is unheard of, and often your left guessing completely what a function does as dynamic typing does even give you a hint there.
If you want to change anything its very unpleasant.
On the face of it, OpenEMR allows you to customise all database columns and basic form fields. Whilst this looks like a really useful feature, the column names are often hard coded into other unrelated views which will just error if you have renamed/changed a column.
To give an example, here in the UK with don’t have HIPPA, so I once attempted to replace the HIPPA consent fields with ones better suited to our use case (Data Protection Act acceptance etc). This caused chaos a few years later when the appointment reminders were introduced (although unused) as these relied on the hippa_sms column etc.
OpenEMR also has little to no automated testing that I have found, and the documentation which alludes to them is highly outdated (as is most of the documentation). This means breaking changes are very easily introduced.
By contrast OpenMRS is rather minimalist, especially the platform distribution. The reference application includes a few more features such as appointment scheduling and a basic UI, but it doesn’t concern itself with billing, stock management or any of the non clinical features you might want. Bahamni includes these, but I personally do not get on with it, YMMV.
What OpenMRS does allow you to do is pick and choose what features you want through the modules system, and if it doesn’t exist, just write your own, something I’m currently doing for appointments as the reference appointmentscheduling module doesn’t suit our needs. I will also be creating a module similar to the billing and finance systems in OpenEMR as we currently utilise those a lot.
Whatever development I’ve done so far I’ve found the API easy to work with (once I’d remembered how to Java), and test coverage is good enough that I’m assured I’m not breaking things in the process.
Although its still early days for me with OpenMRS, I also really like the data model, it’s just much more flexible than OpenEMR’s. Person attributes appear to be the ideal solution to the problem of differing demographic requirements, and having just checked those out as part of writing this post, edit permissions per attribute are very nice indeed.
So in essence it boils down to what you want and need. If OpenEMR fits your needs perfectly now and for the foreseeable, and you like the direction development is going, albeit slowly, then I can see no reason to not recommend it. On the other hand if you want the flexibility, development speed and robustness, OpenMRS is probably the better choice if you have the ability and time to put into making it work for you.
,
