What's the difference from an implementer's perspective?

Hi,

As an implementer, I’d like to define the difference between LibreHealth, OpenMRS, Bahmni and OpenEMR. What are the strengths and weaknesses of each and in what scenarios is one better than the rest?

Thanks, Craig

Hi Craig,

I can speak as far as OpenMRS/LibreHealth. This represents my opinions and not the opinions of the Steering Committee as a whole. I was one of the Infrastructure team members and kept the lights on for OpenMRS.

First, Bahmni is just a distribution of OpenMRS so there is no comparison whereas LibreHealth Toolkit is the fork of OpenMRS Platform (the EMR system). What this means is that both OpenMRS and LibreHealth Toolkit will continue development and will share code bidirectionally, however the development is not unified.

Secondly, the major difference between LibreHealth and OpenMRS is how it is governed and set up. OpenMRS’ governance model is notoriously not simple, ours on the other hand is described here. No one person or organization has majority control over the project, all of the Project Leadership Committee has equal power. With OpenMRS, a large majority of power is wielded to Regenstrief, and there are clear conflicts of interest, yet no action is being taken. if you do not believe me, follow the money. Additionally, there is no accountability or transparency in OpenMRS – which is what lead most of us to leave the community and work on forming LibreHealth. I myself spent a good amount of time fighting to save the community until I just lost hope and chose to devote my energy here.

I would say that currently OpenMRS has a major strength of more people involved, whereas we are in our infancy. However, we are set up with no conflicts of interest and total transparency and accountability, which I believe is a strength that will allow us to sustain ourselves. We are not tied to any one organization and the skies, the limits. The other problem with OpenMRS is that it is treated as an academic project, not a Free Open Source Software (FOSS) project. We run things as an Open Source project.

As @r0bby points out “OpenMRS” and “LibreHealth” are communities, not specific products. But to answer your question (of course this is just my opinion, as an architect on the Bahmni team, and a cofounder of OpenMRS):

Bahmni is an EMR and Hospital System, built on top of OpenMRS, OpenERP/Odoo, OpenELIS, and dcm4chee (though all but OpenMRS are optional). Bahmni gives you a “typical facility” system out the box, without needing to do any custom development, and it’s backed by a large, professional, product team. The target implementation would be a low-resource hospital or clinic who wants an electronic system to manage their patient EMR, as well as other hospital workflows (especially if their main concern is to use the system, and not to get directly involved in software development).

OpenMRS Platform is a platform for building patient-centered medical record applications, providing Java, REST, and FHIR APIs. If you want to build your own application, and do heavy development work, this is a great place to start. (For example Buendia, the Google-MSF Ebola tablet application was built on this.) You can also assemble a complete EMR application without writing any code from the OpenMRS Platform plus various plugin modules. This has worked well for retrospective data entry use cases, though it’s hard to achieve a full point-of-care workflow this way.

OpenMRS Reference Application is a point-of-care application built on top of the OpenMRS Platform. It is not as feature-complete as Bahmni, so I would recommend Bahmni over this for most implementers. (It is also has a bunch of extensible building blocks if you do want to customize; I was the tech lead of a ThoughtWorks/Save the Children project and we quickly built an Ebola tablet system on top of this.)

I can’t personally speak to OpenEMR; from spending 2 minutes on their web demo it looks closer to a US/European hospital EHR than any of the others.

LibreHealth Toolkit is a fork of the openmrs-core codebase. Based on this other thread the intention is to make fundamental changes, and not preserve backwards-compatibility. so my advice to an implementer would be to hold off on this and see how that aspiration plays out.

1 Like

I disagree with Darius’ advice. An implementer should participate in a LibreHealth project or team, if their needs are met by LibreHealth.

In that other thread, I said who our user is. “Knowing thy user” is probably the most important commandment of information systems. Our user is the last-mile clinician and patients, whose central focus is patient care. We want to get out of the way of our users, which means that we make design choices that will focus on usability and ease of use, over flexibility. The openmrs-platform wants to be everything for everyone. Its focus is flexibility.

openmrs reference application is a “reference application” (for reference purposes) with example code that can be used by others who want to use the platform. @djazayeri himself has confessed a few times of whether it is usable and meets the need of implementers. Should its development continue to move forward. IMHO, it is good for example code, but not a product. Its server-side architectural choices have been abandoned by the openmrs developers, but since it is the latest minimum viable product, I assume many implementers are building on top of that and continuing to develop modules on an abandoned stack.

lh-toolkit is forward looking toolkit/toolbox. It is a product that can be (after the LTS 2.0) customized by a user who doesn’t need to know HTML, CSS, JS, SQL. I feel like openmrs architects want to adopt standards after they become defacto. Our objective is to contribute to the process by which a standard becomes defacto. We will also not create our own frameworks, or try to build our own standards.

librehealth-EHR is a product that has same user-target of clinicians like the toolkit, but with billing and reporting that matches government requirements. The plan is that it integrates with lh-toolkit and uses components from toolkit.

lh-radiology is a product that is a fully open-source Radiology Information System (RIS) that is usable out-of-the-box for radiology departments, from radiology ordering, scheduling, imaging, reporting etc. There is no FLOSS RIS out in the world. This product will likely use toolkit components too, along with tight integration with other components.

Besides the projects that create their products, we also have teams. For a user (implementers, clinician or patient), we have a support system through teams. Education and university, Diversity and inclusion, documentation are teams that will provide cross-cutting support to the projects. So from an implementers perspective, if you are implementing a product to train your students, the Education team will provide support with training, capacity building. If you have fewer women (only one among the many target groups) in your implementation, the diversity team will provide support through programs that help bring more women.

That is how from an implementer’s perspective LibreHealth is different.

1 Like

Hi Everyone,

Thanks for your detailed responses. I hope this message reflects the situation in a neutral way.

I recognize the communities of LibreHealth and OpenMRS. As an implementer, governance of these communities hasn’t come into play in my work. The core challenges I’m trying to meet are to scope the existing project needs, apply a technical solution and find appropriate development talent to address these needs. It is definitely challenging to find a developer with OpenMRS experience who is not already 100% allocated to a project. As I look across Bahmni, LibreHealth and OpenMRS, I see a number of products. I see the OpenMRS focus on delivering a world class medical record system, Bahmni expanding on that scope to deliver a typical hospital package and LibreHealth expanding on the OpenMRS scope to deliver independent packages that interact (lh-toolkit, lh-EHR and lh-radiology), focused on delivering care in remote places.

Tangentially, I see a number of distributions on the OpenMRS page that include products that were built on top of the OpenMRS platform. I also see a number of projects that are applying the platform in the cloud to manage data across geographic regions such as SharedHealth, OpenSHR and OpenSRP. This is all evidence that the core platform has real world value in numerous applications.

From this thread, Bahmni’s position is clear. Bahmni is a product that is maintained by a professional, global software development firm. They have a monthly release cycle that aggregates all of the features across their projects. The scope of Bahmni is currently aimed at supporting multiple, integrated systems that meet the core needs of hospitals across the globe. I see that a number of organizations have adopted Bahmni in their context, including Partners in Health, who have historically been a major contributor in OpenMRS. It appears that this scope is expanding beyond the clinic to health infrastructure (Health Information Exchange) in the SharedHealth.io workflows.

OpenMRS, as a community also appears clear to me. It’s a group of volunteers who all work together to deliver common workflows, software and solutions in their independent areas. Each team independently develops the features for their roadmap and shares the generic pieces with the community. Core to this community is a global distributed workforce in project based implementations with diversified funding. The OpenMRS community, as a whole, is delivering projects within and beyond the clinic at varying scales with the EMR platform as the common link. I don’t feel that the OpenMRS platform wants to be everything to everyone, I think that the platform is the result of the distribution of the community and funding. For example, OpenMRS was chosen as the platform of choice for the OpenSHR because the data model was appropriate, it was open source and it was cheaper to apply OpenMRS to the solution than to build it from scratch.

I just finished listening to the webinar on LibreHealth. It sounds like LibreHealth is a fork of the OpenMRS community with a different governance structure, simplification of the technology and focus on delivering a product for the last-mile clinician. The LibreHealth Toolkit is the fork of OpenMRS core, not to be confused with the LibreHealth EHR, which is a fork of the PHP application OpenEMR. There appears to be a drive toward simplifying the front end application so it can be more quickly adapted by implementers using HTML, CSS and JavaScript.

Here are some more questions:

  • Does LibreHealth have a single product team with whom an implementing organization can contract?

  • What are the criteria for establishing that LibreHealth products have accomplished the goals of delivering a simplified platform using HTML, JavaScript, CSS and SQL? What are the current barriers to entry that you’re trying to improve?

  • Given the last mile focus, will LibreHealth focus on transforming their product to appliance-model computing as has been done with Baobab Health Trust, which is built with OpenMRS?

  • What is the model operating environment (hr, power/internet, clinic size, and tech) for each of the LibreHealth products?

  • What is the vision for LibreHealth at national scale? Will LibreHealth focus outside the clinic?

  • How will the governance structure impact product(s) vision differently than what is being done in OpenMRS?

Sincerely, Craig

1 Like

This is the challenge that we are addressing with LibreHealth. When you say, OpenMRS, is it the platform? community? reference app? distributions? The platform is an empty shell and clearly not a medical record system by itself. Can you really have one vision for all the very many different products that community members are building? How is attribution for all that work done in a fair way? How do you make all the work visible?

The complexity of deployment, development (ref app development stack is already discarded), the proprietary and chatty REST services and lack usability testing are barriers that we are trying to improve.

We have discussed the multi-tenancy model, among others. I dont think we have clarity on this and the community will decide through the forums. My personal opinion is that we should make it simple to install (docker, deb, msi) on multiple platforms.

We dont have a consensus on this yet… The toolkit components will likely be mobile-first and as low-powered as possible. We are setting up testing of the toolkit for performance, at the API, as well as the UI level.

My first point on this post was the effect that lack of governance has on a product. Each project and the products that they release have their own decision making team, led by the maintainer. This is a successful model in multiple FOSS projects. You see from many Linux distros, that each product has its own vision because they are not “one-size fits all”. OpenMRS seems to be that one-size fits all, which we have seen frankly doesn’t work in healthcare…