GSoC 2021 : Project/Mentor Brainstorming

Thanks @mozzy

great thanks @mozzy

Thanks @mozzy,

CC : @dbryzz @lobeserge @insookwa

1 Like

Hello everyone! Here’s a project idea (originally proposed by @ibacher) for GSoC’21. Please take a look!


Hello every one,

Re-sharing this topic to get your attention on this. Please let us know your projects and ideas for GSoC 21. We have to finalize the ideas before the end of this month.



For over a dozen years of participating in GSoC, we’ve reached out the community to drum up a collection of interesting projects. I’d like to propose a slightly different approach this year. What if, instead of taking whatever ideas come to mind, we created a coordinate set of projects that together could be a substantial gift to the OpenMRS Community?

I’ve been working on a draft for Modernizing Administration functions for OpenMRS. In short, this is building a new, modern version of our administration functions. It’s not a small undertaking and would likely require at least half a dozen or more GSoC projects. Here are some of my motivations:

  • We need pragmatic ways to begin migrating countries, organizations, implementations away from using server-side rendering (JSPs and GSPs) in new development and build capacity & excitement in the way web applications are built today (client-side applications against REST APIs – most often FHIR – in medical applications). It’s 2021.
  • Nearly every distribution and implementation of OpenMRS in the world today is still using the JSP-based administration functions that were introduced over 15 years ago (commonly via the Legacy UI module).
  • The work on a new frontend framework within the Micro Frontend squad is reaching critical mass where there’s enough framework & conventions in place against which new features can be built.
  • We could produce an “Admin 3.0” module to serve up these Micro Frontend-based administration functions that could effectively be a drop-in replacement for the Legacy UI module. If we pulled it off, many implementations would choose Admin 3.0 over Legacy UI because it looks & works better and be using Micro Frontends without even realizing it.
  • One of our first project proposal for GSoC 2021 is itself administration functions (FHIR metadata administration)
  • Several of our admin features do not (yet) expose a REST API, so there would, in many cases, need to be some Java-based work to add these features. We could divide projects up by functions and have students responsible for both backend & frontend development OR we could have some projects responsible for filling in gaps in the backend (mostly Java work) and other projects focused on frontend (mostly React & TypeScript work) OR we could mix & match based on student’s interests & skills.
  • We would need to develop an extensible admin screen as the parent for administration functions with the extension point(s) and conventions necessary to make it easy for projects to add new administration features (precedent for this already exists in the existing Micro Frontends work). Ideally, we’d have this in place before GSoC begins, so students would be plugging new admin functions into it.
  • While a 100% “complete” Admin 3.0 module (i.e., at least capable of replacing the Legacy UI module) would be dependent on the success of all projects, the modular approach of admin functions would allow us to deliver any percentage of the admin functions and be well on our way (even if we have to finish up some functions post-GSoC to get it completed).
  • One of my least favorite aspects of recent years of GSoC has been the relative lack of interaction between students and reduced exposure to the community. A coordinated project like this would promote lots of knowledge sharing & teaching amongst students and provide plenty (even weekly) opportunities for community showcases.

We’d need to get buy-in from the Micro Frontends Squad. This would certainly draw a lot of attention of incoming GSoC candidates to want to help out with Micro Frontend tickets (both a curse & a blessing… but likely more of the latter).

We’d also want to get input from implementations & organizations on the relative priority/value of the various administration functions. For example, how many people are using Forms Management or HL7 management? If they only routinely use 3-4 functions from the “Advanced Administration” screens, which are they?

Thoughts? Is this madness or a bad idea? Or do you think we could pull it off?


-Burke :burke:


@burke i find it a nice idea, since we have only a month to get our projects, could this time frame be enough for as to plan these projects, we might need a number of them?

1 Like

Looks powerful @burke

The idea looks great to me . we need to break it down into smaller tasks/projects that can be accomplished with in the GSOC period. And we will need heavy in put from the MF squad members cc @mksd @mksrom @samuel34 @ruhanga @florianrappl @ivange94

1 Like

i will also bring up this during our pm call today

This sounds great! Also, for the GSoC students, it would add to their experience of working in a collaborative project.


Great idea @burke - thanks for concretely expressing this idea around a single unifying GSoC project, which I’ve heard several people endorse in past conversations.

If we decide on this route, and we start to prioritize what types of existing admin functions we tackle, we should consider how our planned strategies and approaches around Initializer and OCL might influence this. Maybe these don’t change anything (eg. we still want to allow all metadata to be created and edited via an admin UI that directly modifies the DB in real-time), but it might also be worth considering an alternative approach centered around visualizing and editing Initializer configuration files, as well as being able to do things like view whether an OpenMRS server is up-to-date with a set of Iniz configurations or not, what the differences are, and functions to apply specific or a set of those changes on demand.

Just a thought - interested in others perspectives, particularly @mksd and @mksrom.



Thanks so much @burke for outlining this in so much detail, and I still ought to go through your draft document. A couple of thoughts below.

  • Redoing the legacy admin screens? Yes.
  • As a new Admin 3.0 MF, plug and play? Yes.
  • Having GSoC teams work on well defined deliveries? Yes… but here there are caveats.

Ideally some good old functional analysis should be made to know where we are heading. As in:

  • As a data manager at Acme, I need to merge duplicate patients and correct erroneous encounters.
  • As a business analyst at Acme, I need to have a flexible tool to manage concepts
    • This connects to @mseaton’s point, this flexible tool isn’t needed at all if Acme uses OCL anyway…
  • As a client admin at Amani Hospital, I need to manage users and assign their roles, give them access to locations… etc.

When this functional analysis is done, then it’ll be time for some UX design.
And only then the GSoC students can start bringing those screens to life by joining the MF Squad for the time of a summer… assuming the overhead can be taken on by existing members (that’s a biggish if.)

If the above proper approach is not possible then the minimal delivery should be to take an existing admin screen and “make it better” in React and bundle it in this upcoming Admin 3.0 MF. But again, what does “make better” mean, we cannot leave this up to the students to figure out.

To be discussed further obviously. I would be curious to hear from @grace, @jdick and all the usual suspects.


I went through the documentation shared by @burke and seems very interesting!

@mksd You input on this time frame also makes sense, and we don’t have that much of time left to plan and design the screens before the project inauguration (We might have one or two), and in other hands, it’s not useful if we follow a random design or existing design which is going to be deprecated soon with any kind of new designs for the UI (or Admin 3.0 MF)

In my head, I hope there is a requirement for a kind of service layer in the MF projects which are responsible for the minor business-level decisions of the screen. Some of the examples are,

  1. REST API Requests or FHIR requests
  2. Model validation and creation/alteration (Patient, Role, Person…)
  3. Common error handling

So why don’t we have a JavaScript(ES6) NPM module which holds these service layer methods, which are exposed to be used by the MF modules? So it would be a common module and attached as a dependency for the MF modules. So once we finalize the plan and designs for the screens, we just have to develop the MF modules with the help of this common NPM module to handle the screen inputs with the server.

I’m not the best person to answer this, but in my understanding those ESMs that you suggest already exist. Or at least most of it already exists.

@mksd @suthagar23 are you referring to these modules

Indeed, and more specifically openmrs-esm-api.


@burke, great timing! This is exactly where I’d like to see us going with our GSoC projects - and I’d encourage other squads to think about how they can leverage GSoC 2021 as well. @ibacher mig

It might be worth taking a look at the timeline for GSoC: and thinking about how we can leverage the different stages (project idea => project proposal => bonding => coding) to prepare a coordinated suite of GSoC projects like this to be successful. If memory serves correctly, GSoC students really tend to get involved as early as March, when they begin exploring projects and preparing their proposals. So what would successful proposals look like? Could we guide interested students in such a way that the proposals include any of the functional analysis or UX design @mksd mentioned? Would that be too much to ask?

We have been doing this work for clinical screens over the past few months, and it takes a bunch of experts + the participation of real-world sites for UX testing sessions.

On the cheap side one would maybe argue that we could lower the bar for non-clinical screens… but to the point of having it done by GSoC students? I wonder what others think.

I actually kind of forgot that they had to draft a proposal. My view was rather to shape the work to a point where they are being asked to execute on the specifications that have been laid out for them, with a scope of work that is reasonable for a team made of a handful of them.


Porting administration functions into micro frontend modules will not be a small task, but it does lend itself to a “map reduce” (i.e., parallelized) solution. It would break down into at least 12-15 or more individual projects of varying size. Can we define them in a month? It depends was bar we set (more on this below).

Agreed. These could lower the priority of porting certain functions (e.g., concept management, location management, etc.).

I wouldn’t let perfect be the enemy of the good. If we can create an admin home page that organizes administration functions to our liking and provides a convention for how new admin functions are added to it, the individual administration functions can be iterated or replaced as needed. Even if several admin functions leave room for improvement, the work of getting necessary REST API endpoints built out and having any alternative to the 15 year-old JSP pages would be a big win for the community and for accelerated adoption of micro frontends.

Much of this has been worked out by the MF Squad through work on the clinical dashboard features and more fundamental pieces like Domain Decompisition.

I agree with @mksd. We would define the projects (e.g., create scheduling management for Admin 3.0, implement global property management for Admin 3.0, etc.) with clear specifications. The draw for students would be exposure to React/TypeScript + the ECMAScript Module specification + FHIR, Java work for gaps in the REST API, the opportunity to work in close collaboration with fellow students ("it doesn’t matter which piece you’re working on, because we each succeed by all of us succeeding), and – of course – writing code & saving lives.

Students proposals, like all prior GSoC years, would give them an opportunity to outline how they will approach the task, demonstrate why they’re the right person for the job, and layout their proposed timeline/work plan.

The Address Hierarchy, Metadata Sharing, OpenMRS Atlas, several reporting enhancements, patient merging, Bootstrap of OpenMRS 2.x, and the Legacy UI module itself, so I wouldn’t underestimate their potential. The benefits from GSoC are directly related to the effort we put into it. If we do a poor job of describing the projects, don’t make them exciting, and don’t interact much with students as they’re applying, we get weaker students and less return; however, if we do a good job of describing the problem, getting students excited about it, and interacting with them during the front-end of GSoC (February & March), we can get excellent students. In fact, some of our best and most productive OpenMRS developers in the community over the years have come to use through GSoC.

That said, I would definitely make a low bar. The starting point of acceptability would be parity with what we’ve got working in micro frontends. Once there, we’ll have a set of modular functions we can improve over time and the hard work of getting everything able to work in micro frontends will have been done.


Hey everyone! I have drafted a project idea (proposed by @ibacher) for GSoC 2021. Please take a look!

GSoC 2021: Support for Extended Operations in FHIR - Projects - OpenMRS Wiki