An amazing future for OpenMRS

Regarding the Workflows and Logic area, Similar to some comments from @akanter and @isaacholeman, I’d like to make sure we have a workstream that continues down the “modular clinical functionality” path that has been part of the discussion [really, all application functionality]. I’m hoping we can survey our application needs and collect a reasonably wide set of functional components – reports, data displays, pathway flow over time, orders, person search, etc. – and map those to our developing general website workflow and UI paradigms, further unifying the more comp sci and more application aspects of this project. What’s needed for a generic reusable functional component? How do they need to interact with each other in real workflow? This will also allow us to define a practical starter project that is well aligned with the big picture.

Along with this, we should take a look at the concept and data types used in these applications and how they inform the site and UI design.

Moving forward!


Sorry for my slow reply @akanter, I’ve been in Dakar for work and I’m catching up on emails/forums. I didn’t realize you were at Cambridge back then–that’s cool! I’m really excited about working more closely with the OpenMRS community in general, and one of the specific areas where we’re hoping to get your input is around terminology and indicator management. It sounds like figuring out how we can use OCL may be in some ways distinct and in some ways possibly very related to our ability to deploy OpenMRS in a deeply integrated way with Community Health Toolkit apps. I’m looking forward to continuing these conversations in upcoming OMRS calls.

Hi everyone, I’m a new member of the OpenMRS team and have been working with @burke, @dkayiwa, and @jdick to get up-to-speed on the current system and to discuss options and a proposal for a modular frontend.

I shared a few slides a few days ago with them that has some frontend topics to discuss and early proposal of the direction that a modular frontend could go. I will be presenting these topics on 29 April in the Design Forum called Modular Frontend Architecture for OpenMRS.

RFC Additionally, I’ve talked with Burke about potentially creating an RFC github repo for a modular frontend. RFC is an acronym for Request For Comments (see and for examples), and it is a mechanism the open source world sometimes employs for far-reaching technical decisions.

Question for the group - What does everyone think of using an RFC as a mechanism for driving collaboration and decisions for a modular frontend? If so, I would transfer the information in the slides below to a github repo and pull requests, for everyone to see and comment on. I’m new here, though, and don’t want to start out trying to change things in my first couple weeks, so if sticking to discussions here on Talk would be better, let’s do that.

Link to some slides - – these slides are meant to set to the stage for discussions, not to represent decisions that are made. I am an experienced frontend web dev and have implemented large software systems before, but do not yet have the context of OpenMRS, nor the relationships with everyone here. I do not want this to feel like an outsider coming in and making decisions without collaborating with everyone – so feel free to comment, disagree, reach out to me directly, or anything else. The purpose of the slides is to drive collaboration :slight_smile:


@joeldenning . Thanks! While I won’t be able to make your design call, I really like what I see implied in the slide deck. Specifically:

  1. javascript library agnostic framework
  2. consistent OpenMRS-driven style guide as a way of ensuring consistent look and feel
  3. core services (such as authentication, etc) provided out of the box

Do you remember iGoogle, the old Google home page that allowed for end-user-configurable page widgets inside a generic page structure?

I keep wondering if we can get to a place, where… given the high-level use case (I want to care for a patient, I want to build a patient cohort, I want to build a report, etc), whether we can have a standard set of page structures (ie, 3 boxes by 3 boxes with a top gutter for patient context), and then allow community developers to build the widgets for the boxes? :slight_smile:

This would be exceptionally powerful. Glad that you’ve taken the interest in helping us evolve the user experience within the OpenMRS community. Welcome!!

One more quick question: in your slides, you refer to the smaller UI compositions as “single-spa applications”. Do those multiple applications which might comprise an end user page view all share the same data context?

Update: we have created an openmrs-rfc-frontend github repo where we’ll be tracking and documenting decisions about the future of OpenMRS frontend. Please jump in and comment on things, propose things, etc.

To address your questions, @paul:

I keep wondering if we can get to a place, where… given the high-level use case (I want to care for a patient, I want to build a patient cohort, I want to build a report, etc), whether we can have a standard set of page structures (ie, 3 boxes by 3 boxes with a top gutter for patient context), and then allow community developers to build the widgets for the boxes?

A good question and a tough one. Here’s a link to some related discussion and ideas. Layout components can be pretty tricky to manage, but also very valuable. I think the big question is how similar/dissimilar/flexible the UI is for different distributions. A component that tries to be flexible enough for anything but opinionated enough to be useful is really hard to do well.

One more quick question: in your slides, you refer to the smaller UI compositions as “single-spa applications”. Do those multiple applications which might comprise an end user page view all share the same data context?

Could you explain how you’re using the term data context? The applications all share the same javascript runtime environment, which includes the DOM, event loop, global variables, and global events. They are not isolated from each other via iframe. However, each can have its own variables in memory that are encapsulated and not accessible to any other application. API data is usually stored inside of encapsulated variables such as those, but can be shared if needed with other applications.

Question on the rfc-frontend repo, I was thinking that maybe it makes sense to have a dedicated repo for RFCs, so that it is possible to have the thinking done in the same place across various initiatives.

Front end is the current hot topic, OCL, the different operations areas, service providers, education, training etc.

Currently these are scattered across various documents, spreadsheets. There can be an RFC for the RFC process (I think I just went recursive on myself), but I hope this paints a good picture


Hello, I built a slide deck to help myself understand:

  1. Different ways micro frontends can be used in OpenMRS
  2. What micro frontends are

Feel free to add / comment / edit / and fix mistakes in the document.

It includes a lot of slides from blog posts and lectures on micro frontends.

1 Like

I’m a fan of RFC’s for collaborative decision making :+1: Right now I’m only involved in the frontend side of things, so wouldn’t try to talk about whether RFC would be desireable for backend or not. In general, though, I’m in favor of it.

I have created a video that shows microfrontends visually. In the design review meeting on Monday I will be going over the content in the video in more detail. Here’s the link:


1 Like

Exceptional video. Very slick custom microfrontend inspector.

Could someone share the details for today’s call?

I got this. Thanks

For those who weren’t able to join the design forum on a modular frontend framework for OpenMRS, the call has been uploaded to YouTube:

1 Like

Dear Friends,

The OpenMRS Kenya Community in conjunction with the Kenya Health Informatics Association (KeHIA) is very happy to inform you that the “OpenMRS Camp Cradle” kicks off tomorrow in Eldoret, Kenya. This area in Kenya has a sentimental meaning to the history of OpenMRS.

This hackathon is in lockstep with this vision of “An amazing future for OpenMRS” and ongoing work by the global “Micro front-ends” Squad and this. There is already great appetite for a series of follow-on “UI/UX safari hackathon” leading up to our annual implementers meeting later in the year.

Please see attached additional details about the hackathon including the guidance schedule.

We hope to have provision for remote participation and we will provide that information early tomorrow morning.

Invitation_OpenMRS Hackathon_June 2019_GENERIC.pdf (219.1 KB) OpenMRS Camp Cradle Hackathon Schedule 17th - 21st June 2019, Eldoret, Kenya.pdf (169.9 KB)


Follow the action here #OpenMRShackathon

This is very exciting. I don’t have enough technical understanding to fully get the implications for the underlying data. The front end integration is one thing… and cool, but is there any data-layer communication standards going on? Are there rules about data coding/transformation, etc?

I don’t either…I have escalated your question to the devs…

We have made amazing progress…we have a “show and tell” in about 2 hours - really exciting!!!

I just witnessed a single-spa application running inside the OpenMRS Reference Application. #OpenMRSHackathon can drop the mic! :microphone:

Kudus to all who have participated in the OpenMRS Camp Cradle hackathon!

There truly is an amazing future for OpenMRS!


We’re starting to see the real potential of our microfrontends experiment bear fruit!

It’s hard to believe that two months have passed since we first discussed the next steps for Microfrontends, formed the Microfrontend Squad, and identified a handful of product owners like Burke, JJ, Mike, and Mark - all of whom have been following and chiming in on the Microfrontend Squad’s RFCs and on the @microfrontend channel.

During that discussion, some key interests that they wanted to see come out of this initial work came out:

  • They would like see a clear path for running this side by side/co-mingling with current applications, how quickly can we integrate something new into existing frameworks,
  • There was also strong interest in leveraging/using what has already been built that can be used (ie: react components library), open to changing/improving what has already been built.

Even as answers to these initial questions have become clearer in recent weeks, other, equally important and real questions are coming up. Last week alone, at both the hackathon, in the Microfrontend RFCs, and during our Strategy and Operations call, people began asking questions like: what this will mean for the community and implementations? What about migration strategy and approach? What about styleguides? Is there a sprint I can join?

The styleguides question has already led to Monday’s Design Forum discussion on Styleguides, which will continue on Talk and the Styleguide RFC.

Truth be told, these are all important questions for us to discuss as a community - especially as the initial, exploratory work of the Microfrontend Squad begins to transform into something more concrete and within reach.

So here are some suggested next steps for us to think about taking in the coming weeks:

  1. Look at what has come out of the Microfrontend Squad’s work as well as the Kenya OpenMRS hackathon and re-visit those initial questions posed by product owners. If you are interested in attending a follow on to our initial Microfrontends: Next Steps discussion from May, please respond to this Doodle poll to indicate your availability in the coming weeks.

  2. Guided community discussions on migration implications and strategy. We have known that we’ll need to figure out a migration path. It’s also important that we recognize that migration goes beyond technology: there are considerations in a number of areas, such as implications for the underlying data as @akanter brought up, capacity/knowledge, use + useability, etc. We’d like to have a rich, community discussion on migration that spans these and any other areas of interest. If you have particular considerations or questions about any aspect of migration that you want to include in these discussions, please share!

  3. Look into setting up a UI Design group or squad to work with the microfrontend project - or even others working on OpenMRS features. Over the past several months, there have been a few discussions around this on Talk and at the hackathon. Following @jdick’s post about a new Appointments UI, @c.antwi has proposed holding a Design Forum where we can discuss what this group could do and next steps.

  4. Hackathon safari! @wanyee has been in touch with a few countries who are eager to host their own hackathons. We’re exploring the idea of holding virtual hackathons to go along with these local hackathons. We’re hoping to integrate planning for these hackathons with our ongoing planning for OMRS19.

Other ideas or suggestions?

1 Like