Capability Questions

Hi @amlemmon ,

As you can imagine, you have asked many questions, it would be almost worth organising a call with various members of the community to get all the input you are requesting.

First of all OpenMRS is not a final product but a toolkit upon which OpenMRS-based products (distributions) are built. Therefore depending on the distribution (‘product’) that we are talking about items on your list may or may not be covered. In particular the UI may change a lot across distributions and allow different things. I would say that OpenMRS is very rich and allows a lot, but this doesn’t mean that there is a distribution out there that necessarily enables what OpenMRS allows. Or at least there is not one distribution that enables all of what the overall OpenMRS code base allows.

Anyhow, I will quickly provide answers to specific items that are currently on our plate and hence fresh on my mind.


There is definitely a difference between localising OpenMRS in a certain language and making it switchable across several languages. I would say that the former is a given, the latter is a lot more challenging. We are currently working on a project that requires OpenMRS/Bahmni to run both in Khmer and in English and we have achieved a complete switch but there are some caveats. Additional complications come from mixing languages using Roman and non-Roman alphabets (such as English and Russian).

In our experience as service providers and implementors of OpenMRS I would say that there is not any limits to leveraging modules. At least we never faced any limitations worth mentioning or that have become blockers in any way. The OpenMRS Core devs made a very good job at modularising the platform. However modularity brings another level of complexity that would not have existed with a single common code base, that had to be the trade off. Every module starts by depending on OpenMRS Core’s API. If you encounter a bug or a missing feature in there then you will have to work on the Core itself (or on any of the core Platform modules), which is not a problem, all of this is still open-source and open for collaborative work, of course, as it is anyway the case for all OpenMRS community projects.

We have developed Visit Documents UI for the Reference Application. It was designed to be extendable in many ways, but your exact use case should be discussed in details to understand how to get there.

This is the vast subject of national HIS, HIE and shareable & interoperable patient records. You may also be interested in OpenHIE.

Client-side caching will depend on the client UI being leveraged on. There is an Android app that acts a UI client for the Reference Application that - I believe - intends to do just that. In Bahmni, Bahmni Connect allows this to a certain extent (look at this thread of example). I would say: there is a reasonable coverage for offline features.

There is of course the reporting module, but you may be interested in this thread: ‘Evaluating Kibana for reporting and visualization’.

I think the answer is no. You may be interested in this thread specific to Bahmni: ‘Adding a patient portal’.