An amazing future for OpenMRS

I’m definitely supportive of this… this is something we need. I think I’d want to debate the “use as much of Bahmni as we can” as I think we might want to focus on some of the new designs that Greg has come up with. But I think that is more “weeds” and something we work out as we go along.

I think one key early step would be determine the size and makeup of the team we’d need to work on this, and see if we can get the commitment of resources required, either by seconded resources and/or fundraising. I don’t think the team needs to be huge, but I do think we need a core team of relatively senior people (maybe 3 to 4? I’d need to give it some thought) who can be committed to dedicating the majority of their time (90%-100%) over an extended period (6 months to a year). I think we need a strong core team that can wake up every morning and have this be their key priority if this is going to be a success.

(In the initial days of OpenMRS, PIH didn’t have a ton of systems in place, and @darius was able to focus a large chunk of his time just on OpenMRS, but now I find we are supporting numerous implementations and our time to dedicate to shared projects are limited, and I feel like other organizations are likely in a similar situation. We may all agree that we can produce more if we work together, but I want to make sure if we move forward we don’t just pay lip service to that, and when push comes to shove we stand by our commitment of resources… otherwise this initiative could easily fail).

Take care, Mark


I agree 100% with this plan.

I would also like to voice that we may need to think a bit more broadly about what a health information system is supposed to include. Historically, there has been a focus of putting widgets into OpenMRS to support feature needs. Moving forward, I would encourage us to think of OpenMRS as a suite of tools (the clinical EMR, an ETL tool, Visualization Software, Pharmacy, Radiology) which can accommodate the maturation process many implementations/counties/countries are going through in terms of there uses cases for supporting health care delivery.

On the process level, I’d recommend to evolve from being a very developer-centric based paradigm to one more centered on product managers who work with a team of devs and testers to produce products based on client needs.

From an HR perspective, perhaps as a starting point, each organization could be responsible for dedicating resources to support one “team”, a PM, a QA and 2-4 developers who would be assigned a particular feature.

Who would assign features to the team? We would need to have a higher level committee who was in charge of overall architecture and managing the teams allocated by the community groups.

This process should move in parallel. Interested organizations should begin working towards ensuring they can allocate a team to OpenMRS 3.0.

It’s not clear to me how we form the OpenMRS 3.0 Architecture committee though I’m hoping this more or less exists and perhaps just needs to be formalized.



@burke I think the best way to get organizations coalescing around roadmaps would be to have OpenMRS Inc, to provide dedicated resources, “core contributors”, to drive the features/pathways forward leaving the participating organizations to join based on needs & priorities.

The challenge implementing partners have, today more than ever is reducing budgets and more implementations to manage with those budgets.

The community can only amplify the work done, but the core “OpenMRS Inc” has to provide heavy lifting just like what Mark referenced to Darius, and the role Wyclif, Raff and Daniel have been playing.


@ssmusoke, I agree that it would be wonderful to have a team employed by openmrs inc which would be committed to core development.

However, I do think there is tremendous value in keeping directly connected to the implementations. That is, if we at AMPATH have a team that committed to Core, it is more likely that AMPATH will shift to using core. (It’s also more likely to ensure that we have a voice in the direction of core that serves our specific needs).

It may be that OpenMRS Inc could fund these teams which are employed by implementers but then seconded to openmrs inc to fulfill core work.

We need to figure a way to ensure that our goals as implementers are closely aligned with OpenMRS as a whole.


@jdick Around process, over the past few months, I’ve observed that we have a lot of good practices as well as variations that are happening across the different projects in which the community is involved. We also have our weekly project management meetings that we could look into using in a more formal way.

Since we have a few projects kicking off in the coming months (in addition to this one), I’d like to use this opportunity to explore how we can draw from and tweak what we’ve been using and come up with an easy, documented process that supports much of what you are talking about. I imagine that it would need to allow enough flexibility so that those leading or contributing to a project are able to follow their own organizational practices - while also enabling contributions from other individuals and organizations within the community who want to do so.

Some of this ties into an idea that has come up a few times in recent months: having some sort of “investment roadmap” - which is really more about transparently presenting what resources are needed and allocated/assigned. From my perspective, being able to see what resources a project such as this one needs and where the gaps are would make it easier to help identify and reach out to community members who have the potential to help. I’d also expect it to show what OpenMRS Inc’s contribution to a given project is as well - whether this is a TPM, QA lead, a dev, fellows, etc.

The above is already on our growing list of community discussion topics. We planned to dive into this over the next few weeks , so I can help make sure this happens in parallel.


I would also like us to evaluate the Micro Frontends Architecture and see the extent to which it can practically shield us from a JavaScript framework or library specific solution, given the rate at which they are becoming out dated, and the fact that different groups have already invested in different technologies. For instance AMPATH has heavily invested in Angular while Andela has done so in React. Another team in Vue. Therefore, a solution where each of these developers can contribute and reuse their existing technology investment, looks like a strategy which will promote adoption.


Great proposal, Burke. Really excited to see where this goes.

I think this moment of organizing around new front-end projects is a fantastic opportunity to create process that is driven by PMs and UX designers rather than devs.

It sounds like we’re talking about investing a serious amount of developer time. I think the value of that investment would be multiplied by a serious investment in UX, so that what gets built has been professionally user-interviewed, designed, prototyped, and user-tested.


I’m still new to the OpenMRS project, but I thought it might be useful to share my thoughts as a more outside observer.

Prior to working on OpenMRS I had been spending some time with HospitalRun which spent a good deal of time focusing on a great user experiences and using modern web technologies. The project started in 2014 and modern at the time was the ember.js framework which has since fallen somewhat out of favor. If you go with React or another trendy framework I wonder if it would best to plan for a front-end “upgrade/refresh/re-write” every 4 years.

I’m personally really excited about FHIR and have been following some of the work that has been done on FHIR and the Sync 2.0 project. One strategy would be to focus on OpenMRS as a FHIR server and convert the frontend into a more generic FHIR client that is “most compatible” with the OpenMRS FHIR infrastructure, but could turn into a stand alone project. When you look at some of the SMART on FHIR initiatives, and CDS hooks; they are looking at ways to supplement a front end with plugable “apps”;.

I also think mobile needs to be in the discussion. I don’t think that every project needs to have a native mobile app, but I think there are some compelling reasons to discuss it for OpenMRS.

  1. When the internet is slow/unreliable, clinicians don’t want to have to wait screens to save / load and deal with errors. a. I know this is solved with on-site installations of OpenMRS, but we’ve been working with smaller clinics that want to use their smartphone and don’t want to deal with a on-site installations.
  2. Many clinics are supplementing their physical clinics with mobile clinics. When they go out into the community it would be useful to be able to be lookup the patient’s existing medical records.
  3. My organization runs a telemedicine consult service and when the clinician has a smartphone, then can take high resolution photos and videos. These photos and videos are very useful for remote clinicians that can help support the local clinician with a diagnosis / opinion.

In the US, we are seeing a number of mobile focused EMRs. Outside of the US, BackpackEMR is focused on low resource settings.

Back to the FHIR concept, I’ve been working on some offline concepts where one can run a local FHIR server embedded in a mobile app, then syncing back with main server when the device has internet again. This could pair nicely with what you are all doing with the Sync 2.0 project. There are projects to run a web server inside a mobile app (i-jetty on Android, and similar solutions on iOS), so that a front end app could run natively on the device and think it was talking to a full featured server.

Anyway, just some things to think about in the discussion (hope it’s helpful).


Hi Burke

Thanks for articulating this vision and leadership that is greatly needed at this time for OpenMRS. Jembi very much supports the goal of a convergence around the technical architecture of OpenMRS application framework and distributions to create a shared future that we regard as essential. We will be glad to join forces to realise your vision. We have been speaking about a similar concept for sometime with our implementation partners at Intellisoft, UCSF, ThoughtWorks, the Bahmni Coalition and CDC.

Jembi is developing and implementing both the reference app and Bahmni and envisages a place for both kinds of tool, ie a customisable platform and configurable product. Our implementation sites would like the flexibility to deploy a simple back entry system with forms interface and easy implementation consistent with current clinical workflow. They would also like a smooth and seamless upgrade to a more feature-rich system with a dynamic and real time interface supporting common healthcare functions (reception, clinical consult, lab etc), perhaps according to a defined maturity model. We envisage both kind of application co-existing within a country-level ecosystem and interfacing with a number of other functions and applications.

Our funders would like to see greater application level reuse across implementations addressing similar use cases, eg HIV/TB care with modules supporting common indicator definitions and reports as well as linkages to OpenHIE stacks, DHIS2 etc.

One of the challenges we will need to face is funding for the initial effort and future work on the architecture and application framework. Jembi’s budgets are driven by country implementations that are tightly focussed on the implementation itself. Ideally, we would attract a significant separate tranche of funding for the initial framework development, eg through Digital Square Global Goods, and then have a mechanism to budget more explicitly in implementation budgets for core support and architectural redesign. This may require some re-thinking in terms of the global approach to sustainability and maintenance of these global goods and support from implementations.

Thanks, again, for this initiative and looking forward to working with you and the OpenMRS community to realise the vision.

Kind Regards

Chris Seebregts


I’m pretty new to OpenMRS development - so please do give me some leeway when coming to formation of opinions. One of the things I noticed as a an early Developer is that OpenMRS is already too convoluted. We already have Bahmni and the Reference Application programs running in parallel. Hence I don’t think it would be prudent to run another MVP alongside Bahmni and the Ref App to just provide space for custom apps and extension points.

Since we already have the quite versatile Bahmni in our hands, why not use a stripped down version of Bahmni as a basis instead and add the required features (Custom Skinning, Modularity etc.) on top of it?

Also @k.joseph while Java is moving down the trending curve, all our controllers, modules and in fact our entire platform is based primarily on it. Won’t it be a huge headache to shift away from Java?

1 Like

we’re not planning to migrate from Java at all, all our backend (platform, rest, fhir, tools etc) remain unmoved. OpenMRS 3 may need to touch them just to support a better smooth clinical workflow … but not to rewrite them with trending technologies. The trend will always continue making it ‘a run after wind’ to always rewrite things just to catchup, i expect some new language or tool released the day this world will shutdown :wink:


Haha :stuck_out_tongue: that is true. I’ve been working with a medical devices organization on similar tools that are present in OpenMRS. I would say OpenMRS technology stack is quite at par with market standards (we use ASP Core + Angular over here). All we need to do is slowly make our stack uniform across all modules.

1 Like

I do not see Java going down any time soon. I have been constantly reading reports about the trending languages and for each year, i keep seeing Java among the top 3 or so. There is a huge number of enterprise applications out there written in Java that are not going any where any time soon. Am not a fun of jumping onto new languages that are not tested with time. Always ask yourself, are our current problems caused by Java? If it ain’t broken, don’t fix it!" :smile:


thanks @dkayiwa this is encouraging #java

Thanks @burke for your leadership in getting this started. This has spurred a great conversation and our team at PIH is fully on board with this vision.

At PIH, we have long invested in building shared, configurable modules and applications. This is core to what we need to do, as we support many different implementations in a number of countries. Sharing as much in common, while leaving room for necessary customization, is essential. Today, we are experiencing the same major shift as many others - towards a need for more point-of-care utilization and for our applications to work seamlessly and efficiently across devices (i.e. laptops, touchscreen computers, tablets, etc), so this is a very relevant and timely discussion.

We have done our best to hack in this direction over the past year or so already. Taking a cue from the community, which had started adopting React as a new standard front-end technology for OpenMRS (Andela, Bahmni, etc), the PIH team re-tooled in an effort to collaborate in this way and to build features that are “distribution-agnostic” and which meet two of PIH’s roadmap priorities - 1. lab test ordering, basic lab tracking, and lab results entry, and 2. point-of-care screening application for a combined HIV/NCD clinic. Our approach for this has been to lead the development on a shared library of UI components built in React, and to model how these can be leveraged to quickly develop new applications, putting as much functionality as possible into the common library, fittingly called openmrs-react-components.

This has been modestly successful, but I’d say that it has not yet met our full ambitions. This is due to a host of factors, but chief among them is lack of deep expertise in React and in responsive CSS design with Bootstrap or a similar framework. This is where I believe we really need that “expert coder” that you describe to “bootstrap development”, primarily in these new technologies. It is essential that we invest in a resource that we confidently feel will get us established in the right direction and make it easier for teams to collaborate using existing code than to go their own way.

PIH will continue to invest strategically in these initiatives and the more traction and collaboration ensures, the more investment is possible. It would be great to hear more about plans to

and what we need to do to get this underway.

Best, Mke


Maybe I’m being a little overdramatic, but this thread feels like a very important moment in our community’s history to make our collaboration deeper and more powerful. This of course strengthens our public goods.

It’s very exciting!

I believe a few things are being said here:

  1. While there is always room for improvement, the focus of Burke’s vision here is less on the core platform and more on the user experience: the web application itself.
  2. Multiple organizations are interested in being a part of this activity and have weighed in here, but there’s consensus around starting small and working our way towards larger and more sophisticated.
  3. There’s a need to discuss how this effort is resourced: but the consensus seems to be around a hybrid model of combining in-kind engineering/management effort from large implementations alongside new resources working alongside those “close the the ground”.

I think there are more than enough organizations that have “raised their hands” here to get things started. Let’s not waste any time: @burke, @jennifer, @terry… how should we proceed, and how can we all help? :slight_smile:


Hi - can a design call be arranged? I’ve been working on new mockups specifically focused on a very simple and highly composable EHR application. It fits Paul’s description of something small that could grow into something larger later.

The mockups could be presented as a strawman, and act as a starting point for conversation to see how much/and how little they solve real world needs for the implementors in this thread.

In a little less than a week, this discussion underscores how much rich experience and knowledge we already have within our own community to draw from. Another reason the future holds so much promise!

Based on this discussion, I suggest that we begin by convening a small group with representatives from each interested organization. This small group that can continue this exploration and lay out what we’d like to see in a MVP that will help us achieve our goal: an extensible, customizable web application framework that supports future development by existing and new implementations. Part of this will mean:

  • identifying specific needs and priorities across countries/implementations
  • deciding what components we can and want to re-use
  • determining what components we may need to add

@gschmidt, I like your suggestion of using your new mockups as a strawman to see what most resonates with today’s implementations. Our Design Forums are currently underutilized and we can easily dedicate one of them as a space for these ongoing discussions. Can you please propose this as an initial topic in the Propose a Design Forum Topic thread and we’ll poll everyone to determine the best day/time?

Much of this will help us work out an estimate of the level of effort/resources needed and put together a strong, well-rounded team who can help get this off of the ground. From a fundraising perspective, it would be ideal to have a pipeline of "projects" ready to go that could be used to inform proposals and ongoing discussions with donors and emerging countries - perhaps helping to re-think "the global approach to sustainability and maintenance of these global goods and support from implementations," as @chris so very nicely put it.

Over the next two weeks, let’s plan on laying out an initial action plan that also includes time and space to tackle other questions that have been raised around roles and responsibilities, resource allocation, processes, and migration paths. Please feel free to chime in with any additional considerations and actions. @burke @terry



Thanks for starting this great conversation that marks another extremely important milestones in the life of OpenMRS - and its truly amazing and humbling to be part of this history making experience.

As we continue discussing details and next steps as you have suggested, I would like to offer ourselves, IntelliSOFT, as one of those 203 groups ready to participate and contribute actively on making this process work. We have and continue to invest in both Bahmni and RefApp and therefore have lots to contribute in this collaborative effort.

Very excited to be part of this, thank you and let us do this!

1 Like

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?