Recommendations for Project Setup During Implementation

This is a follow up to my earlier post:

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):

  1. Form Customization - building new forms and updating existing ones

  2. Module development and customization - building new modules and probably customizing existing ones

  3. 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.

1 Like

Hi Stephen,

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.

I hope that I am making sense

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.

Hi @ssmusoke

The best-practice work that I know of on this front is by PIH. I’m sure the @mogoodrich can point you to the relevant github repositories, but I doubt that anyone has documented the whole approach.

Most of the things that you can configure through the OpenMRS UI can also be configured/created programmatically, and put in source control.

For example:

  • HTML forms can be defined as XML files, like this
  • 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.)

I hope this helps some.


@darius let me try this out this is very helpful.

@mogoodrich looking forward to hearing how you are approaching this at PIH

Sorry for the late response, I didn’t noticed I’d been @'ed. :smile:

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 Thanks a bunch, I will let you know how I progress with these pointers

@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

Thanks in advance

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?

Take care, Mark

@mogoodrich thank you for the offer, apologies for short notice reply, yes I can make it via Skype today (thats in about 30min) or Monday if you will be busy. My Skype ID is ssmusoke

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.

@ssemakadde what do you think?

@michael Actually I am very flexible and would not mind sharing a session, depends on @mogoodrich availability and what he suggests will work best

Sorry, I didn’t mean today, I meant sometime next week.

@michael that is a very good idea. @ssmusoke let’s do that.

Ad hoc might not even be necessary… what is the current university call schedule, and are there free slots in the near future?

1 Like

I will defer to @ssemakadde for confirmation but the general time slot is Wednesday at 14:00 UTC:

Could you tell us more about your implementation - where ? for what ? 200 sites is impressive

@ssemakadde I can do that slot on next Wednesday if that works for you.

@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.