An amazing future for OpenMRS

Development
, ,
1

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.

In 2014, we introduced OpenMRS 2.0, using Groovy Server Page (GSP) technology to address the downsides of JSP-based web development. As it turned out, this was taking place just as new Javascript libraries (React and Angular), were beginning to gain momentum. We later added support for Mozilla’s Open Web App (OWA) standard to provide at least some mechanism for introducing Javascript web apps into OpenMRS, but it’s not an elegant solution. Rather than migrating from OpenMRS 1.x to 2.0, some groups chose to use these newer Javascript libraries for their frontend (e.g., Bahmni was built with AngularJS and moved to React, AMPATH built a point of care solution using AngularJS and moved to Angular 2+). As implementations began using different frontend technologies, it’s been more challenging to share modules or collaborate on solutions.

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.

Assumptions

  • 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

Requirements

  • 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.

Next Steps

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.

24 Likes
2

i highly agree that this 3 or more fold union would take us to such an amazing future for OpenMRS which we all treasure ATM despite the elaborated history.

I am only challenged by the fact that technology is the most dynamic thing i have had to deal with, we can only almost solve problems for a few years to come probably advantageous to our future employment until we retire prior to our code. Stable technologies that have been around for decades like java are moving down the trending curve whereas recent ones like react are attracting more interest, this will probably only last until some new alluring code machinery shows up sooner or later. Would we then still seek for a similar collaboration to catchup with the common interests in technology! Do we need to be worried about the tech choice more than the acceptable solution!

Can’t wait to be a part of such a collaboration :slight_smile:

4 Likes
3

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

7 Likes
4

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.

Thoughts?

5 Likes
5

@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.

3 Likes
6

@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.

3 Likes
7

@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.

2 Likes
8

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.

5 Likes
9

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.

5 Likes
10

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).

6 Likes
11

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

4 Likes
12

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
13

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:

2 Likes
14

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
15

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:

9 Likes
16

thanks @dkayiwa this is encouraging #java

17

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

4 Likes
18

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:

4 Likes
19

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.

20

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

3 Likes