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
@gcliff I may have misspoke somewhere 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.
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)?
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?
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?
@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.
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.
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.
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.