GSoC 2022 : Project Brainstorming

Hi Community , As we are approaching mid January , its a good time for the community to start brainstorming ideas/potential projects for Google Summer of Code 2022.

Following on the success of more than a decade of involvement in Google’s Summer of Code initiative, OpenMRS once again plans to apply as a mentoring organization for Google Summer of Code™ 2022 , and we are looking forward to identifying potential project ideas and mentors for GSoC 2022 as part of the organization application process. The organization application starts on February 7, 2022 , so we would like to get as many projects fleshed out by then. If you have any ideas for projects , and/or would like to volunteer as a mentor , this is the time and place to get those discussions going.

We should have a larger number of projects + mentors compared to the previous years, as this year we are likely to have many applicatants since GSOC is no longer limited to students and its now open to newcomers 18 years and older . see our GSoC Project Creation Guidelines.

Previous GSoC Projects

GSoC projects can be new modules/OpenWeb Apps/projects, involve enhancements/new features for an existing module/OpenWeb App/project, or PoC work for an idea, but should have the following attributes:

  • Must involve coding(Major part) and be OpenMRS-related ideas
  • Clear objectives and requirements
  • A minimal viable product can be completed in 6-8 weeks (allowing time for bug fixing, documentation, and getting to production).
  • Meaningful contributions to the community
  • Involvement of at least one motivated product owner (e.g., implementation) eager to use the project’s output
  • Should have some features which may give a chance for design, coding, testing, and documentation as well as analytical thinking and creativity for students.
  • Available mentors (If don’t have, we can get it later)

New Project Ideas

If you have any new ideas which are supposed to be initiated through GSoC 2022, please go ahead and arrange a Design forum for it or post it in the Talk and get the community opinion on that ideas. (You can contact any of us, and invite our community also).

Creating a GSoC 2022 Project Page

  1. Browse to unassigned projects on the wiki or have your own idea
  2. If there is already a wiki page for your project or very similar project, update that page instead of creating a duplicate. If you need to create a new project page, please choose the “Project Page” template.
  • Project name *: Foo Bar Project ← by convention, end your page title with " Project"
  • Primary mentor *: Your OpenMRS ID / TBD
  • Backup mentor *: TBD
  • Assigned to *: TBD
  • Abstract *: 4-5 paragraph(s) describing the background, purpose, motivation of the project. Make it exciting! The more interesting your project sounds, the better the applicants you will get.
  • Sample use cases *: Provide 2 - 5 sample use cases which need to be developed. It should be simple which could able to understand by a person who doesn’t have any experience with OpenMRS.
  • First Task : If you have any simple task(which can be completed with in 3 - 5 days) related to your project, mentioned that in here. It can be a JIRA issue or any PoC. You can use to evaluate the capability of the student for that project ( Optional - But good to have)
  • Project champions : name one or more product owners (who will use the output?)
  • Required Skills *: list the skills required to apply (e.g., Java, React, Angular, REST, HTML/CSS, basic SQL, etc.)
  • Objectives *: A short list of what should be accomplished during the summer
  • Extra credit : list any nice-to-have features or approaches
  • Dev Tracks * : Include GitHub URL and JIRA URL of the project
  • Resources *: include links to any wiki pages, Talk discussions, websites with related/helpful info
  1. Add page label: gsoc2022
  2. Add a link to your project page and proposed mentor below.

Here is the GSOC 2022 timeline :

  • February 7, 2022 - Organization Applications Open
  • February 21, 2022 -Application Deadline
  • March 7, 2022 - Organizations Announced
  • April 4, 2022 - April 19, 2021 - GSoC contributors Application Period
  • May 20, 2022 - GSoC contributors Projects Announced
  • May 20 - June 12, 2022 - Community Bonding
  • June 13 , 2022 - Coding Period Starts
  • November 28 ,2021 - Mentors submit final evaluations

please see the full Timeline here

cc @jennifer @grace @dev2 @dev3 @dev4 @dev5


For the Start , we can look at the Projects that werent Implemented in GSOC 2021

and also some suggestions below from @grace


Starting a list of ideas below; I’ll put up a specific message for each one so folks can “:heart:” the ones they like. But here’s the summarized list, with est. difficulty in (brackets):

Category: Frontend / OpenMRS 3

  • Enable HTML Form Entry forms in OpenMRS 3 (Medium)
  • Next Generation Implementer Tools for OpenMRS 3 (Advanced)
  • Responsiveness & Tablet-based Needs for OpenMRS 3 (Medium?)
  • Next Generation Form Builder UI for the OpenMRS Community (Medium-High?)

Category: OCL/Concept Management

  • Microfrontend the OCL Module and reduce backend dependencies (Medium)

Category: DevX

  • SDK Support for Building the 3.x RefApp Distro (@burke can you add a post here describing your idea?)

Category: Infrastructure

  • Migrating from OpenMRS ID to KeyCloak (@burke can you add a post here describing your idea?)

O3: Enable HTML Form Entry forms in OpenMRS 3

Note: While we want to switch gradually away from HFE in favor of an easier to use next generation form tool, HFE is still the major tool used by existing implementers, so 3.x not supporting HFE is a major adoption blocker. Basic support for HFE forms in 3.x would be a phenomenal value-add to all implementers using HFE and wanting to try out 3.x.

The main need/user story is: “As an implementation who has many, many forms created with HTML Form Entry, we want to use 3.x while still being able to use our old HFE forms, so that we don’t have to go through a very expensive and painful process of changing all our HFE forms over to match the new 3.x form schema.”

There are two low-hanging-fruit ways this might be implemented:

  1. The HFE form could open in a separate tab
  2. iframe to show HFE forms - so the user would be in the UI here, but the form showed here would be an HFE form instead of a Carbonized 3.x form (see image below) - I think this is my preferred hack, since it keeps the user within the one EMR experience:

FHIR : Working On the OpenMRS FHIR IG

@pmanko brought the up idea of completing the OpenMRS FHIR IG .

@ibacher @pmanko can we wrap up this into a GSOC project ??

1 Like

O3: Next Generation Implementer Tools for OpenMRS 3 (Advanced)

350hr project. Designs already completed. User Story: Non-tech users can set up a 3.x EMR in a friendly, no-code UI, similar to designing a website. Empowers local team members to set up and config their EMR themselves. (More detailed user stories and requirements documented here.)

Scope: technical work on the redesigned config tools for O3. *Design is done because Ampath/@jdick graciously already paid for designs and user testing, sample designs below, and @bistenes gave a lot of architectural and technical input but then had to set the project aside.)

Sample design visual:


O3: Responsiveness & Tablet-based Needs for OpenMRS 3 (Medium?)

We have a ton of designs for 3.x that show how the frontend UX should change based on screen size or device (e.g. large desktop, small laptop, or tablet). Much of this responsiveness still needs to be implemented consistently throughout the application.

Example of the difference between large desktop, vs small laptop, vs tablet:


Small Laptop:

Large Desktop:


O3: Redo/improve Next Gen Form Builder UX/UI. (Mid/Advanced)

We could continue to use existing Ampath Forms Engine but replace the Ampath Form Builder with a react based module (instead of the angular one).

The Ampath Form Builder UI is pretty easy to use and build forms quickly, but it’s buggy and could be so much better.

(Demo of the current WYSIWYG user experience of this builder here: OpenMRS WYSIWYG Form Builder Demo - YouTube)

@jdick anything you want to add to this?


OCL: Turn the Open Concept Lab Module into a 3.x App

The OCL Module is the last remaining OMOD that depends on the (effectively deprecated) OWA Module. We want to be able to remove the OWA Module from our 3.x RefApp distro, and currently it’s just the OCL Module preventing this.

@ibacher has already set the groundwork by setting up an ESM monorepo and skeleton of the work on GitHub.

This is a smaller project; 175hrs. Fine for a newer dev but needs some past React experience.


I think that’s fine as long as we can make it somehow coding focused. Some things that might be doable:

O3: Redo Legacy UI Cohort Builder. In addition to supporting all current functionality, would also like to be able to save a search history (UI there in legacy but never implemented afaik). Add ablity to update an existing cohort based on a scheduled run of a search history.

1 Like

hi @kdaud i had to tag you to thread so that you can have an eye too

1 Like

Will, do we have any GSoC project ideas in the android client repository?

@anshul We’re still in the project ideation/development phase and those ideas really come from those in the community who have a good project idea and are interested in working with a GSoC contributor. Our full list of GSoC projects will be published on our Wiki by February 21, 2022.

Until then, @anshul, if you know of community members with clear ideas for moving the Android Client project ahead in a way that has high value for our community & OpenMRS implementations, then the next three weeks is the time to start bring up the project’s objectives, identify mentors, etc. A potential next step will be to post the idea here, start a Talk thread, and/or hold a Design Forum to flesh out the project.


Improving 3.x E2E Tests

Thanks for the suggestion @kdaud, I made a small draft with a set of requirements; Feel free to update this Google Doc.

Extending tests

The student should collaborate closely with the o3 team to identify new workflows and design tests.

Making tests more reliable

Current tests are less reliable because they are not very stable. Sometimes they pass, but there is still a chance that they will fail. Also, tests suddenly start to fail when there are new changes in the implementation. We need to look into ways to improve the reliability of tests.

Run tests against Pull requests

Currently, we don’t have a mechanism for running tests against Pull requests. As a result, no failures can be detected until the changes are merged and someone run the tests manually. It makes it difficult to detect root courses as well as to engage developers. We need a proper way to run these tests against the changes in pull requests.

Improve developer engagement

We do see a lack of engagement of O3 developers with E2E tests. The possible reasons might be:

  • The E2E tests are not yet a part of the current development cycle.
  • It isn’t that easy for an O3 developer to easily get started with E2E tests due to lack of documentation.
  • It is a bit hard to work with the local environment.

We need to find solutions to the above while identifying other ways to make things easier for developers.

Apart from that, we do have some set of challenges as well:

  • Making local test runs repeatable despite data mutations
  • Handling metadata of the dockerized DB
  • Syncing local setup with the latest development version of O3
  • Running tests against an unmerged version
  • Fixing the screen recording feature. It’s not recording properly for a few weeks.

cc: @christine


hi @slubwama i remember you talking about some missing resources in FHIR,do you think this is some thing we can add to GSOC this year?

we are happy to receive more project ideas for GSOC 2022 from folks cc @burke

@herbert24 Yes. This is something that can be explored to add more value to the fhir2 module. @ibacher what do you think.


@slubwama As long as we have a well-defined set of resources and at least some notion of how they should be mapped to FHIR, I’m all for it!


Adding Accessibility Testing for OpenMRS 3.0

Accessibility Testing is defined as a type of Software Testing performed to ensure that the application being tested is usable by people with disabilities like hearing, colour blindness, old age and other disadvantaged groups. It is a subset of Usability Testing.

The end goal, in both usability and accessibility, is to discover how easily people can use a website and feed that information back into improving future designs and implementations.

The importance of Accessibility Testing

  1. Cater to market for Disabled People.
  • About 20% of the population has disability issues.

  • 1 in 10 people have a severe disability

  • 1 in 2 people over 65 have reduced capabilities

  • Disabilities include blindness, deaf, handicapped, or any disorders in the body.

  • A software product can cater to this big market if it’s made disabled-friendly. Accessibility issues in software can be resolved if Accessibility Testing is made part of the normal software testing life cycle.

  1. Abide by Accessibility Legislations
  • Government agencies all over the world have come out with legalizations, which requires that IT products be accessible to disabled people.

  • Following are the legal acts by various governments –

  • United States: Americans with Disabilities Act – 1990

  • United Kingdom: Disability Discrimination Act – 1995

  • Australia: Disability Discrimination Act – 1992

  • Ireland: Disability Act of 2005

  • Accessibility Testing is important to ensure legal compliance.

  1. Avoid Potential Law Suits
  • In the past, Fortune 500 companies have been sued because their products were not disabled-friendly. Here are a few prominent cases

  • National Federation for the Blind (NFB) vs Amazon (2007)

  • Sexton and NFB vs Target (2007)

  • NFB Vs AOL settlement (1999)

  • It’s best to create products that support the disabled and avoid potential lawsuits.

Accessibility Testing with jest-axe

OpenMRS 3.0 uses Jest to run the unit tests. Because of that, we can use Jest aXe to test our React components’ accessibility tests.

Jest aXe

Custom Jest matcher for aXe for testing accessibility

Accessibility (a11y) of applications is much easier to get right if worked in from the start, rather than retroactively going back to try and fix. While the GDS Accessibility team found that only ~30% of issues are found by automated testing it can help to establish a baseline with virtually no effort to include and run.

It cannot and does not guarantee what we build is accessible, as it can only statically analyse code, but it provides a great start.


Adding Accessibility Testing OMRS 3.0 will increase usability and accessibility.

As you can see it’s straightforward to add jest-axe to integrate aXe automated accessibility testing.

jest, jest-dom, and jest-axe work smoothly together to form a versatile testing toolkit for testing React components from a functional user perspective.

I will keep adding my findings to this. Feel free to update this google doc

Thank you!