I wanted to raise the question about what our intention is with regards to the reference application, for implementations who are looking to create their own custom distributions.
I’ve seen a number of threads recently, like this one:
and also know there are several distributions (eg. UgandaEMR, iSantePlus @craigappl) being worked on in the community that are including the reference application within their custom distribution.
My own impression was that, as a community, we were intending for the reference application to be an example distribution, one that other distributions could “fork and modify” to meet their own specific needs, or to follow as a guide (or reference), but that it was not our intention for distributions to build on top of it.
In the above thread, @ssmusoke is understandably concerned about forking from the referenceapplication module, and losing out on new features in the future. We should make sure we are clear about our intentions for the reference application module in this sense, and that we strategically do not intend on adding new features there, but rather just configuration for features that are provided by other modules (eg. coreapps or registration).
Do others have thoughts around this? I know @darius may not be around to weigh in right now, but perhaps @burke, @dkayiwa, @raff, @wyclif, @ssmusoke, or others could comment? I want to make sure we’re all on the same page with this.
@mseaton Thank you for opening this thread, for this discussion. My personal opinion would look at this in stages of adoption of OpenMRS as an EMR :
Step 1: What is OpenMRS capable of? Oh my look at demo.openrms.org then download the reference application and set it up on a local machine
Step 2: Oh my this seems to capture most of my needs, can we start entering data into it to get reports (whether research or scratching a data management pain)
Step 3: Now can you add the ability to capture this data set, and that too …
Step 4: Can you make this software look like ours (Look and feel changes) …
By Step 4, the Reference application is already setup and being used even without requiring dedicated IT or developer skills.
By demonstrating what OpenMRS is capable of, the RefApp is actually the foundation for many implementations, and with health informatics technical skills in short supply, the need to make it more configurable (by end users) who can easily add workflows and widgets without writing Java/GSP code. I think JSON is a middle ground here
In my mind, the RefApp must:
Showcase what OpenMRS can do out of the box - some implementations can install and use this out of the box
Be easy to extend/configure without having to fork
Forking is the last resort - however even this must provide ability to return to the original path of the mothership (Ref App)
Provide visibility into new features, enhancements that are help implementers, who in many cases are expert users, non-developers or have limited development budgets, meet programatic needs.
Yes @mseaton you are correct. That was the intention of the referenceapplication module.
After some time, we find an increasing number of distributions including the referenceapplication module. The question is, could it be simply because they are not aware of our intentions for this module? Or do they find themselves using 90% of what is already in this module and change only a little bit? If the latter, could it be time to revisit our original intentions to meet their needs?
I didn’t dig too deeply into the original thread that sparked Mike’s post, but, in my opinion I’d see a couple things:
We want to strive to make the “reference application” as configurable as possible for implementer without technical resources available to them–ie, customization without programming.
But, as the referenceapplication module should be just configuration (not functionality), once an implementer starts to build technical staff and make their own “distribution”, then they’d drop the reference application module in favor of their own custom distribution module. However, if this isn’t the standard way people are using the module, then, as @dkayiwa says, maybe we want to reconsider our strategy.
This is a great conversation to get started! I didn’t realize that the original intent of the reference application. I think new people to the platform follow the continuum outlined by Stephen. This was my experience in Nepal and is now the experience in Haiti. New implementers are hooked by the reference application and they progressively need to configure and develop on top of the reference application. I have to also mention that there’s an initial comparison of OpenMRS’ Reference Application against Bahmni Core to see which would better meet the needs of the implementation. The last time I did this comparison, it appeared to be too cumbersome to create new forms in Bahmni, unlike the HTMLFormEntry and UI extensions that have come about recently.
On-boarding developers to the OpenMRS platform is another task that is made easier by depending on the reference application. We started a “configuration” module in Haiti that depends on the reference application. This module changes the logo and color scheme of the Reference Application, loads in all the forms we need, adds the patient metadata that we need to collect adds a few implementation specific fragments to the patient dashboard. We’re currently tackling the best way to create reports based on the data we’re collecting in this module.
There’s a huge learning curve to setup your own fork of the reference application. My perception is that developers would have to actively maintain over a dozen repositories that are constantly changing. (Please correct me if this perception is wrong.) Given that there are so many pieces involved when you fork, it’s much easier to build off of a released version of OpenMRS. In that case, you build against stable modules and only augment where there are failures. For example, we just found that bug in htmlformentry that was fixed by Daniel. We’ll update the version of htmlformentry in our dev environments and wait for the next release. Once a new version of OpenMRS is released, we’ll test our configuration module code against the release, upgrade the dependencies and shift to it, always aiming to release a month or two after OpenMRS. (This is totally manageable with the twice per year release of OpenMRS. Bahmni releases much more frequently, I think monthly, and I don’t know if we could follow that same logic.)
It would be really interesting to learn about the human resources needs of running a fork of OpenMRS compared to creating a configuration module based on the reference application. We have experienced a shortage in high level OpenMRS developers and estimate that it takes 12 to 18 months for a senior Java Developer to be fully proficient in OpenMRS development. Right now, we have three experienced Java developers who are on this path and we dedicated many hours trying to diagnose the recent bugs when upgrading from Platform 1.11 to 2.0. We’re moving forward from light to complex configuration and reporting. The next stages will include actively contributing back bug fixes and eventually new features, which seems to be the experience of other developers in the community.
The original intention with the 2.x reference application was that:
it would be one specific opinionated and not-so-configurable distribution of OpenMRS
we would be able to devote sufficient resources for it to be complete fully functional out of the box
many implementations would just use it as-is (adding their own forms and reports)
implementations that wanted their own distribution would fork the “distribution module” (which is the referenceapplication module) but otherwise use the same underlying components (like the coreapps and emrapi modules)
Since then, (a) we definitely failed to get sufficient resources to make it fully functional out of the box, and (b) we also didn’t document the fork-and-modify workflow, seeing as how people like @craigappl didn’t know about this vision.
“Forking” is really bad in the old subversion world, but it’s the standard way of doing things in the git world. So, from a standard dev approach, “fork” shouldn’t be bad, and when you fork, it just means that you occasionally need to do a git merge upstream master.
Our original approach did not work out, and I’m fine with the idea of making the Reference Application more of a base than a complete example (more along the lines of what the Legacy UI was).
Actually I think the best solution to this would be to get rid of the configuration in Java aspect of the referenceapplication module, and take an approach like the (better) one Bahmni came up with of having instead having a config folder on disk which can start off as the default one and be progressively customized by the implementation.
I am a simple single hospital (for now) implementer trying to follow the implementation path of take the ref app and turn a few configuration knobs, add a few forms and reports and if necessary the odd module but do not add code or fork a development into a possible railway siding,
Observations to date:
Most importantly a great thank you to the community that have helped me out when my understanding of the wiki was poor or I tripped over the odd bug.
I have found the need for additional modules to be greater than expected - maybe I missed something and have made some bad choices but we (and maybe most health facilities in the developing world) need to do limited billing/insurance reporting and I find nothing in the ref app that addresses this. For form design and reporting I have taken the X route which benefits from good help and generally good documentation but the UI has a rather different feel.
In looking at billing and a couple of other modules then there seems a substantial lag on the modules being compatible with the current core. I am willing to wait a while but I am getting the feeling that some modules may have caught trains into other sidings.
Where configuration options exist eg through the global variables I have assumed that these options would be compatible with the reference app. However I have just today learned that at least 1 global variable is reset in the reference app at each restart. I am then in a nervous state of knowing what configuration is possible. Till now I had the simplistic view that if a Global Variable was editable in the ref app then editing was allowed and would be supported.
To be frank no. I spent quite a long time working with 2 other opensource EMRs and found myself either very alone or in one of my sidings and so have been keen to stick with what I thought would be the mainstream of openmrs.
@mafrica whoever needs a more comprehensive EMR that implements functionalities like the ones you are looking for, our official recommendation is bahmni. As you may have already noticed, the bahmni team is among our topmost contributors to the openmrs core platform and some core reference application modules like emrapi, webservicesrest, and more. Bahmni is used by such a good number of implementations that you will not be alone. It is very actively maintained and supported that it even has more frequent releases than our reference application. Unless you have a significant amount of developer resources to implement what is missing in the reference application, i would recommend that you try evaluate bahmni.
Thank you for the input which I respect. I will take a serious look at Bahmni. Up to this last couple of posts I guess it was my impression that my implementation approach was the intended norm for a small/medium health facility with limited IT resources - (1) start with ref app (2) customize in a limited way using the available config options(3) add a few forms and a few reports and (4) as a last resort add further (in my case billing) modules. If I was wrong in adopting this approach then I suspect the issue must be a question of degree however I remain unclear as to when I passed the degree threshold. To help future implementers it would be useful if these thresholds where stated somewhere in the wiki and perhaps if configuration options (global variables) are not intended to be changed then perhaps they should not be visible or editable.
I may be prejudging things but I think I will find that a similar approach will be needed with Bahmni with the possible exception of step 4.
@dkayiwa this is a very clear and necessary representation of technology directions. Thanks. I have to admit that as an implementer a good deal of the technology speak goes over my head. However, I wonder if there is a similar map for functional evolution.
Specifically it would seem that billing sits somewhere on the junction of technology and function.
I have begun working with the Bahmni distribution and have been very pleasantly surprised by the level of help that I have received from the ThoughtWorks folks. While I had to grapple for a couple of days with some of the external issues of implementing Vagrant of a Windows server, I am very taken with the appliance like installation of Virtual Box.
Forking the reference application means forking only