I agree that sometimes it's good enough to have "Simple Xyz" as an OpenMRS
module, and sometimes you need a dedicated external system. (Also, the more
clinical the use case, the better it fits as an OpenMRS module, in my
opinion. So I'm a big fan of using OpenERP for billing/accounting, stock
management, HR, etc, while doing things like radiology as OpenMRS modules.)
I also agree that smaller facilities need to have
relatively-simpler-to-manage systems. But "how many kinds of DB are
installed" and "how many webapps in tomcat" aren't the only dimensions of
complexity. Generally speaking, the less IT support and dev capacity you
have, the more you should be using a "typical" OpenMRS distribution with as
little customization as you can manage.
The challenge for a distro like Bahmni is to let itself be installed,
managed, and supported as if it were a simple application. This is a
solvable problem, though, and generally I think that "run this VM" is
easier for the small clinic than "install OpenMRS + a variety of modules".
I'm not opposed to building simplified OpenMRS module versions of what are
often external systems. And we should definitely do what we can to help
coordinate the efforts that people are trying in these areas.
But personally I think it's a mistake to presume that "OpenMRS + lots of
modules" is going to be a simpler-to-manage solution to the problem of
"facility information system + EMR" than a distro that integrates multiple
systems, if that integrated solution is investing in making itself a