I figured that it is too vague and probably too broad for the audience there. So I am focusing a more technical question for this community here.
I am going to be supporting multiple OpenMRS installations, which will involve writing and customizing modules, building forms etc which has currently been done but with no version control and management so there is no way to know what is currently installed in the field and how to improve it.
What approach do I use for the following, which may be different projects (since I am an OpenMRS newbie):
Form Customization - building new forms and updating existing ones
Module development and customization - building new modules and probably customizing existing ones
Managing deployment information - How can I maintain a repo of the modules I have to install, SQL configuration scripts, and data (dictionaries and concepts) etc, so that I can routinely and reliably contribute to the installations.
Thanks in a advance for your help, and in return I promise to dedicate time to share on my experiences as I move along.
For form customization, you are most certainly going to create your own forms.
For module development and customization it depends on what you are attempting to solve, you have to say exactly what it is so that others can propose an existing module or if you have to write one from scratch.
You can actually import metadata like concepts from existing implementations if it applies to your projects, Concept sharing has been involving in OpenMRS, so there is a couple of modules that you can use to import metadata from other sources. The CIEL concept dictionary is a good start point for a set of concepts you might be able to use out of the box.
I don’t quite understand what you mean by maintaining a repo of the modules you have to install, do you mean where to host the source code for the repositories of your custom modules? If not, can you elaborate a little more please?
@wyclif I am trying to apply software development lifecycle practices to OpenMRS implementation, including version control, automation of the process of artifact building and distribution, to help roll out to many facilities but with limited manpower (actually no manpower).
I am looking at the process of building and customizing the base installation as a project, the modules to be developed and added (unknown at this time), the customizations to the base install, etc as versionable artifacts.
If you’re writing custom modules and planning to be creating custom builds of the platform, you will definitely need to put your code under version control and nearly all version control applications provide a way to cut and label releases with version numbers.
the Reporting module has the idea of “definition libraries” which create reporting definitions on the fly via java code, like this
configuration settings can be set via Java code during a “distribution module”'s activator, like this
the metadatadeploy module lets you create your system’s content/metadata via Java code in a source-control friendly fashion, like this
aside: you can extend metadatadeploy to load from csv, xml, etc, and this would be a useful contribution to the community, if you all end up doing it
Stepping back to the big picture, the best-practice approach for a standard OpenMRS distribution to follow software dev practices is to have the “distro” build recipes be done by maven. For example openmrs-distro-referenceapplication (if you look at the pom.xml file there you will see for example the versions of modules that are being assembled together).
(I should note that the Bahmni project has a significantly different take on things, since it isn’t primarily a java application, and thus isn’t based on maven.)
Sorry for the late response, I didn’t noticed I’d been @'ed.
This is a big topic, I don’t really know the best place to start…
Mainly, we use the metadatadeploy module to programmatically set up most of our metadata, with one significant exception: concepts. For concepts, we generally are still using the metadata sharing module to create packages of concepts. We hope to use OCL (the Open Concept Lab) to do this in the future. We store all our Htmlforms in version control and then deploy them programmatically on system startup.
It’s hard to step you through everything, especially since our setup has become scattered over three modules, but the best thing to do may be to look at those three modules, and specifically the started() method in their activators to step through what we do. The three modules start up in this order:
One step beyond that, we bundle up openmrs core and all the modules we use into a debian package. We provision our servers using puppet. Our main puppet script can be found here:
Hope that helps, and doesn’t give you too much to look through!
@mogoodrich when would you have a window to walk me through the workings of the PIH approach? I am interested in automatically loading concepts & HTML forms for the start, then later being able to build updates for elements like drugs etc. I am in GMT +3 and am happy to connect when its convenient for you
Sure, I can try to walk you through things as best I can… probably midday here in Boston would be best, which I guess would be like between 14:00 and 17:00 UTC? Would that work for you? What medium–Skype?
Any chance we could arrange an open “ad hoc” OpenMRS University session for this in case others are interested? We could work around the schedule to find a time that works well for @mogoodrich and @ssmusoke.
@judy OpenMRS is the recommended EMR by the Ministry of Health in Uganda for collecting HMIS information so is currently installed at high volume health facilities providing Anti-Retroviral Treatment (ART) for HIV. I am currently going through an inventory process and will provide more concrete data once that has been completed
@ssemakadde & @michael thanks for the university slot, @mogoodrich looking forward to the session. I will share the link with my colleagues in the Uganda community.