An amazing future for OpenMRS

The most important first step

Identify at least three organizations with:

  1. A shared problem to which a separate web application could be applied
  2. At least 1-2 developers who could be directed to work on a solution
  3. A commitment to work collaboratively toward the solution (i.e., put in the extra effort approach the solution generically instead of cutting corners)

I would guess a progressive point of care solution (i.e., works well on mobile or desktop) that could be applied to NCDs or HIV would be the most likely candidate; however, it’s more important to have 3+ organizations with a shared problem than to pre-select the problem to solve.

As an example, imagine if PIH, Jembi, AMPATH, and one or more ministries (e.g., Nigeria, Kenya, Mozambique, Uganda, etc.) decided to commit 1-2 developer(s) toward collaboratively building a point of care solution that would meet their needs. In turn, the community would commit its energy (bringing leadership, a react guru, project management, additional development, etc.) toward making the effort amazingly successful. In the end, we would have a frontend to serve us for the next 4-5+ years that could not only run alongside RefApp or Bahmni, but, with a clear migration path, serve as a point of convergence for those efforts.

Additional initial steps (could be done in parallel)

  • Identify a React guru (i.e., experience in building best practice enterprise-quality frontends and expertise in ) who can help us decide on the best option(s) for modularity †, build the skeleton + some initial functionality, and run a bootcamp to get community developers productive quickly.

  • Design discussions to flesh our requirements and build a common vocabulary (as @gschmidt has proposed); however, it’s hard to proceed too far before we know what problem we are trying to solve – i.e., step #1 is having 3+ organizations committed to solving a particular problem collaboratively and this problem needs to be an actual problem they need to solve (not necessarily the problem we want to solve). That said, in meantime, the vision Greg & Jonathan are creating can both (1) drive us toward convergent design & vocabulary and (2) provide a shared “north star” for the community (i.e., where we want to be eventually).


† For example regarding modularity, is there a way to leverage HMR for production use without adding too much complexity for the developer or overhead/risk for the implementer? Or are we better off using the SDK or other tooling to automate redeployment of the frontend when modules are added/removed?

3 Likes