Request new repositories for OpenMRS modules

Hello OpenMRS Community,

in SolDevelo we are working on an OpenMRS distribution for our client. It has been decided to share that distribution with the community. Before that can happen, we would like to share the distribution’s module’s source code first.

I’m asking you to provide us with github repositories for the following modules:

openmrs-module-callflows - the module provides an API to handle calls with IVR and means to configure IVR service providers. It allows to configure simple call flows (as name suggests) where recipient passively listens to messages (e.g.: visit reminders) and also call flows where recipient is expected to actively interact with the system (e.g.: collecting information whether patient is adhering to the treatment, takes medication and so on).

openmrs-module-sms - the module provides an APIs to send and means to configure service providers for SMS messages (or SMS-like messages, e.g.: WhatsApp messages).

openmrs-module-messages - the module takes use of openmrs-module-sms and openmrs-module-callflows modules and provides out-of-the-box functionalities to configure call or/and messages for: adherence reporting (pill reminder), adherence feedback, visit reminder, health tips. This module can be integrated into running OpenMRS systems without any coding, although the configuration requires knowledge of an SQL and OpenMRS database schema.

openmrs-module-etl - the module provides means to configure ETL (extract, transform, load procedures) which allows pulling data from external systems to the OpenMRS application (e.g.: periodically pulling patient data into OpenMRS). This module can be integrated into running OpenMRS systems without any coding.

openmrs-module-visits - the module provides the simple functionalities which can be used to schedule the future visits.

We are going to follow with more detailed information, including user’s and technical documentation, soon. That’s going to be added to this section: Modules - Documentation - OpenMRS Wiki

The project’s Team Leader is: @kmadej

Best Regards, PiotrW

1 Like

hello @pwargulak

could this be what your looking for GitHub - openmrs/openmrs-module-messaging: Messaging Module for OpenMRS

For ETL we currently have the analytics engine though still WIP

Hope this answers some of your questions otherwise great to see this kicking off from SolDevelo

could this be of help Visit Management Module - Documentation - OpenMRS Wiki

@gcliff I may have misspoke somewhere :slight_smile: but we already did implement the modules from the top post, we just want to get the new git-repo to push the code to. I see now, that there might be some naming conflict.


Thanks for sharing @pwargulak !

Definitely worth considering moving these into OpenMRS repos, though it does look like there will be some naming conventions to figure out.

Does the code for these modules currently exist in Github under another organization if anyone wants to check them out.

Take care, Mark

Currently, the code is not available for the public and we are not able to change it.

The distribution’s abbreviation is ‘cfl’, so I’m thinking module names like: openmrs-module-cfl-sms, openmrs-module-cfl-messages for the conflicting names. Although, it might suggest that these modules are only good for our distribution, which is not true.

@pwargulak Congratulations on this milestone - and thanks for sharing with the community.

Wondering if you and your team would be interested in doing a demo of this work, either in a special session or at our next community meeting (in July/August)?

1 Like

I’d be interested in others opinions, but using a prefix (ie cfl) sounds like a good idea… to avoid having a name tied to the distro, for the 3 modules that seem to go together (callflows, sms, messages) I’m wondering if there’s a prefix we could come up with that is more descriptive and related to the functionality?

Take care, Mark

1 Like

An alternative for implementation specific modules is to share them under an implementation organization on GitHub. For example, when we (Regenstrief) created modules for Indianapolis EMS, we shared them via openmrs-indianaems. Many implementations have their own GitHub orgs.

The OpenMRS organization on GitHub is probably better for repositories that are in use by multiple different organizations or are community owned (e.g., part of the Platform or Reference Application.

Are any of these modules being used/maintained by more than one organization?

I like @jennifer’s idea of having a showcase.

1 Like

It’s a good point, @burke .

@pwargulak were you intending that these modules be community-owned and maintained going forward?

It probably makes sense, as Burke says, to host them in a (public) implementation organization repo in Github, and then potentially move them to the OpenMRS repo down the line if they get adopted elsewhere.

And I agree about a showcase…


Here is another example of an implementation organisation BandaHealth sharing their modules on GitHub: Banda Health (Formerly OpenHMIS) · GitHub

@pwargulak, am anxiously looking forward to the showcase! :slight_smile:

Our intention is that these modules will be community-owned

We also think that it will be the best solution

If it is not a problem, we prefer to move the code directly to OpenMRS repo

Regards, Kamil

FYI, anyone can create a GitHub organization for free and host public code. So, you could publish your code to a new org as easily as OpenMRS.

  • A: OpenMRS/openmrs-module-cfl-sms – a module made for “cfs” shared within the community. People might assume it’s specific to “cfl” needs, but documentation/README could indicate otherwise. Would be expected to use MPL 2.0 + HD license.

  • B: ConnectForLife/openmrs-module-sms – a module made for “Connect For Life” shared with the world (including OpenMRS community). People would assume it works for CFL, but might work elsewhere (looking at documentation for clarification).

  • C: OpenMRS/openmrs-module-sms – a foundational SMS module providing generic SMS services that could be used by any OpenMRS implementation. Would be expected to use MPL 2.0 + HD license and be in use by multiple organizations and/or within the Reference Application.

We’d like to move toward a culture where people share their code in their own repository (option B) and we try to focus the OpenMRS GitHub org on repositories on which multiple organizations are collaborating. This reduces the “gatekeeper” model and is more scaleable. Repositories are better judged on their popularity (stars/forks) and usage rather than where they are hosted on GitHub. That said, there are already nearly 300 repositories under the OpenMRS org with 40% that haven’t been updated in 2+ years, so we’re a long way away from getting away from an everything-needs-to-be-under-OpenMRS-org culture.

If you want these to be under OpenMRS org, I would go with option A (adding the ‘cfl’ namespace to avoid naming conflicts). Any /dev/2+ should be able to transfer a repository into OpenMRS org.


-Burke :burke:


We’ve decided to indeed follow option B and set up our own GitHub organization.

Regarding the showcase, I’ve decided to create a separate post on that topic.



Pawel, how are you handling content with the modules? The shared concept dictionary work we are doing with CIEL and OCL (and the OpenMRS Dictionary Manager) would be a good way.