Hi community,
The OpenMRS Android Client has been valuable for extending OpenMRS functionality to mobile devices. However, it currently faces some limitations:
-
Its features are hard-coded, requiring forking and customization for each implementation.
-
Branding, workflows, and forms cannot easily be adapted without code changes.
-
This leads to fragmentation, duplicated effort, and difficult upgrades across projects.
Meanwhile, platforms like OpenSRP 2 show the value of a white-label, configurable mobile client — where implementers provide only configuration (branding, workflows, server connections), not custom code.
I’d like to propose a refactor of the OpenMRS Android Client into a white-label, configuration-driven mobile framework (OpenMRS Mobile 3.0) that implementers can adapt to their needs without forking.
Benefits
-
Plug-and-play adoption across countries and projects.
-
Easier maintenance with one shared codebase and fewer forks.
-
Consistent upgrades aligned with OpenMRS RefApp 3.x and FHIR support.
-
Rapid deployment for new programs with minimal engineering overhead.
Objectives
-
Refactor into modular core + plugins (auth, visits, encounters, forms).
-
Introduce configuration-driven setup for:
-
Server URL + authentication method (Basic, OAuth2, OpenMRS ID).
-
Enabled features (Visits, Vitals, Orders, Allergies, etc.).
-
Sync behavior (which resources to cache offline).
-
Branding (logo, theme colors, localized strings).
-
Forms (FHIR/SDC or OpenMRS XForms).
-
-
Add white-label theming support (logos, colors, app name).
-
Support extensions for custom dashboards and workflows.
-
Align with OpenMRS 3.x + FHIR APIs to ensure long-term compatibility.
I’d love to hear feedback: Would a white-label, configurable OpenMRS Mobile Client help your implementations? cc @grace @slubwama @ibacher @anon54923432 @icrc.psousa