We’ve done a lot of dreaming around the future for OpenMRS. I’d like to propose a pragmatic approach we could start now to move toward an amazing & inclusive future for OpenMRS…
Where we’ve been
In 2006, OpenMRS used Java Server Page (JSP) technology. It wasn’t particularly fun, but the community benefited from developers all writing modules within the same web framework and, as a result, it was relatively easy to share modules between implementations and we saw lots of collaboration across implementations.
Where we are today
- Groovy Serve Pages (GSPs) are not the future.
- OWA is an obsolete standard.
- React and Angular have become de facto standards for web development.
- Several groups who have built custom frontends are feeling the pain of supporting them.
- OpenMRS continues to be adopted by organizations and countries, with some choosing Bahmni, others building on the Reference Application, and others building their own bespoke frontends.
- Funders want to be able to fund solutions that can be shared widely across implementations & across countries.
- The Bahmni distribution has been successful and helped many, but, because of its approach of configuration over customization, does not meet the requirements for many others.
- We can’t afford to rewrite our entire application.
- Switching to Bahmni – as it exists today – isn’t a viable option for many implementations.
- While Bahmni started under ThoughtWorks, all rights to the software have been donated to the OpenMRS Community, so licensing/copyright issues shouldn’t be a barrier.
Where do we go from here
Collaboration happens when there’s a shared need. The good news is we have plenty of shared need right now in the community; we just need to take advantage of it. This is where the real work begins.
I would propose that we find at least 2-3 organizations with a shared need who are willing to work together on addressing that need through a shared solution that lays the foundation for a web application framework that is both customizable and built using today’s best practice web application development. This doesn’t mean building a brand new Reference Application de novo; rather, solving a specific problem using an extensible and customizable approach that can run either within or alongside (without being dependent on) the Reference Application or Bahmni.
- Get at least 2-3 groups with development resources who are trying to solve the same problem to commit toward collaboration and focus community efforts/resources on making that collaboration successful. This is how OpenMRS was born, so we know it can work.
- Solve a specific problem in a general way – e.g., instead of building an EMR framework, focus on building a usable point of care solution with an approach that serve as a foundation for a new Reference Application.
- Use as much of Bahmni as we can. Either refactor Bahmni to be customizable or harvest heavily.
- Ensure there’s a migration path for both Bahmni and non-Bahmni sites to use the new solution – e.g., be able to run against the Platform alongside Bahmni or the Reference Application.
- Approach the problem with today’s best practice development approach, which will lower the learning curve for new OpenMRS developers and greatly increase the number of devs who can contribute.
- Bootstrap development with an expert coder
- Useful. What we build as a community /must/ be useful to and used by implementations.
- Modular. Beyond configuration, organizations need to be able to customize the application to their local needs.
- Skinnable. Implementations & distributions need to be able to adapt the branding + look & feel.
- Conventional. Using contemporary conventions for web application development increases the tools available to us, lowers the learning curve for new developers, and increases the pool of developers who can make rapid & meaningful contributions to the community.
- Reachable (Migration Path). Organizations using the Reference Application, Bahmni, or a custom frontend need to have a migration path.
Imagine if, for example, groups from countries like Kenya, Mozambique, Nigeria, and Uganda and/or organizations like PIH, Jembi, and AMPATH all needed a progressive (mobile & desktop friendly) point of care solution and agreed to invest in a shared solution. Groups using Bahmni, Reference Application-based, and custom frontends have a frank discussion on their requirements and we put an expert coder on the task of laying a foundation to meet those requirements that either adapts Bahmni or harvests code from Bahmni and leverages the vision & expertise of Greg Schmidt and Jonathan Teich to point us in the right direction. With a skeleton in place, the groups then divide & conquer the various parts of the solution with a MVP that runs against the Platform, can at least run alongside Bahmni or the Reference Application, and provides a space for custom apps ± extension points.
Our biggest opportunity is through collaboration. We can walk further if we walk together. Collaboration is hard; it takes more energy than going your own way… but the returns can be amazing. Collaboration is how OpenMRS was born and it’s our best way forward.