Summer of Code 2026
Write Code. Save Lives.
OpenMRS is hoping to be a mentoring organization for Google Summer of Code™ 2026! Since 2007, we've enjoyed participating in this great program and we're extremely excited about the projects and mentorship opportunities available this year. Coding for OpenMRS is a great way to practice your coding skills and, at the same time, help benefit people in developing countries who are on the front lines of public health challenges.
If you are new to OpenMRS, we recommend starting with our Guide to the New & Curious. It will introduce you to our community, the tools and spaces we use, and help you get to know the different squads and teams working on various community projects. For a more detailed history of who we are and what we do, please see here. If you’re new to OpenMRS or wondering how to get started with your GSoC application, this video should help answer a lot of your questions:
Google Summer of Code at OpenMRS
om.rs/gsoc
Learn more about Google Summer of Code 2026:
Google Summer of Code website
Helpful Links
Community GSOC Slack Channel: #gsoc on OpenMRS Slack
GSOC Topics on the OpenMRS Forum
GSoC 2026 Program Administrators
@beryl @Jayasanka Weerasinghe
Please see GSoC Admin Guidelines for more information, or Org Admin Tips and Program Rules.
Project Ideas for GSoC 2026
Talk Thread for Idea collection:
Brainstorming GSoC 2026 Project Ideas Guide: Defining a Project Ideas List
Defining a Project (Ideas List) | Google Summer of Code Guides
The following ideas are not fully finalized, and their requirements may change or they may be removed. Most of these projects didn’t make it into last year’s GSoC list, but that doesn’t mean they should be forgotten. If you’re passionate about any of them, you’re very welcome to start exploring and working on them with the community.
Project Name & Expected Outcome | Rating and Size
| Project Description | Skills (Required / Preferred) | Primary Mentor | Backup Mentor |
|
|---|---|---|---|---|---|---|
Large | In the scope of the project would be (depending on the progress we make using other contribution channels):
| Java, Hibernate | @Rafal Korytkowski |
|
| |
Medium | We have an appointments calendar that is meant to give an overview of appointments. Unfortunately, it is currently less useful than it should be. A few things we need to address: the ability to drill-down into, e.g., monthly, weekly, and daily views; the ability to see all appointments, not just the number per service, instead of changing screens when clicking on a day or service, the app should likely display a modal; the calendar view should not be hard-coded around the Gregorian calendar, but support the various calendars from the @internationalized/date package. | React | TBA |
|
| |
Medium | We have a service queues app in O3, which is functional, but needs some attention, both to the frontend design and to the backend APIs that are used to populate it. The goal here would be to fix various UI issues and improve the overall performance and reliability of the queue module. The Service Queues view is incredibly useful for managing outpatient clinics, allowing users to track who is waiting for service, how long they’ve been waiting for etc. | React, Java | @Ian Bacher |
|
| |
Forms Migration Tool: Help HTML Form users switch to using O3 React Forms | Medium |
|
|
|
|
|
Dynamic EHR: Custom Home screen (and other screens) based on User roles, locations and other values. (doc)
| Medium | We would like to show UI elements on the O3 home page and other pages that are most relevant to the user. Currently, there is ability to do so based on User privilege. However, this is limiting and not general enough. We would like to define what to show based on other values, such as Location, currenting displayed Visit / Encounter, etc… More generally, this can be solved by having a way to write custom logic (in the form of a reduced set of JavaScript expressions) to define whether an Extension should be shown. There is actually something (what?) similar in O2 already. We should be able to inject dynamic variable
| React |
|
|
|
Archiving voided data (Definitely a priority - either GSOC 2026 or anyone who’s interested in meantime) | Large | Voiding in OpenMRS is a form of soft-deleting. We basically set a binary column to | Java | @dkayiwa |
|
|
Patient Visit Summary Printing | Medium |
| Java, Hibernate, Spring
| @Wikum Weerakutti |
|
|
Integrate O3 with the Authentication module | Medium | The authentication module brings a lot of cool authentication features to OpenMRS, including user-customizable authentication schemes and supports things like TOTP. However, there’s currently no functional integration with the O3 UI. I think it’s pretty solvable by ensuring that the authentication module sends what I’d term “fake redirect” responses, e.g., responses that will trigger this section of the openmrsFetch() implementation and then ensuring that we have the right stuff for the frontend to submit and validate the TOTP token with the backend. Should likely be a “medium-ish” sized project involving both Java and Typescript skills. | React, Typescript | @Jayasanka Weerasinghe |
|
|
A Native O3 Frontend for the Audit Trail. | Small | The idea: Over the last year, @wikumc has done fantastic work building a foundation with the Audit Log Web Module and is still actively refining it today. Currently, viewing these logs happens within the Legacy UI. As more implementations move to an O3-first workflow, there is a great opportunity to build upon Wikum’s work by bringing these capabilities into the modern O3 frontend. The opportunity: Since the REST API for logs is already built and available, integration into O3 can solve some minor UX hurdles. Having a modern Audit Log Dashboard in place and “Change History” views directly within the O3 Patient Chart would allow admins and clinicians to track accountability without needing to navigate back to the legacy interface. | React, Typescript | SolDevelo |
|
|
OpenMRS Password Authentication Re-work |
| OpenMRS’s password authentication system hasn’t really been updated since 2009 and still has some of the hallmarks of a password authentication system from that time—this doesn’t mean it’s broken, just that it doesn’t support things like multiple hash iterations, work-factors, etc. This could use some modernization. This would likely be just a small Java-focused project to update things or it could be a more medium-size project to rework our password authentication so that it’s built on top of Spring Security. | Java |
|
|
|
Medium | The Audit Log Module integrated Hibernate Envers into OpenMRS 2.7.0+, enabling the system to track Create, Update, and Delete (CUD) operations on data. While this provided a strong starting point for auditing, The module can record who modified patient data but does not capture several critical actions, including when users simply view patient records, security-related events such as login attempts, failures, account lockouts, or session timeouts, and important administrative activities like changes to global properties, module installations, or data exports. Therefore, the goal of this project is to evolve the Audit module from a basic change-tracking system into a comprehensive security and compliance tool by introducing read auditing and logging key system-level and administrative events. | Java / Spring |
|
|
|
Pending Project Ideas
Project Name & Expected Outcome | Rating and Size
| Project Description | Skills (Required / Preferred) | Potential mentors? |
|
|
|---|---|---|---|---|---|---|
Medium |
| React | @Anjula Samarasinghe |
|
| |
Implement Stricter Typescript configuration | small | This project aims to enforce stricter TypeScript configurations across OpenMRS repositories, ensuring developers follow best practices for strong typing. The primary goal is to eliminate the use of By implementing stricter TypeScript settings and refining type definitions, this project will enhance code maintainability, reduce runtime errors, and improve the overall developer experience. | React, Typescript |
|
|
|
Integrating Data Filter for Data Segregation / Multi-tenancy | Large | Data Filter is a powerful module that uses Hibernate’s filtering APIs to add additional where clauses to various SELECT statements. The use-case for this is to allow system-wide filters to be applied to the data added. Currently Data Filter includes a default set of filters that restrict the availability of data on patients to a set of locations a user has access to. The point of this project would be to expand on these capabilities to add things like: an administrative UI for associating users and patients with specific locations, additional rules to account for the various modules used in the O3 RefApp, templates for additional rules that may be useful (i.e., tie the ability to see obs with certain codes to certain privileges). | Java, Hibernate | @Joshua Nsereko
| @Wyclif Luyima |
|
Postgres support? |
|
This Project would enable the following as well: |
| @Wikum Weerakutti |
|
|
Better way to receive feedback from clinicians / users
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Program Timeline
Look here for more info on the full GSoC 2026 program timeline.
Done GSoC 2026 preparations: Community Brainstorming
Done January 19: Mentoring organizations can begin submitting applications to Google
Done Deadline February 03: Mentoring organization application deadline
Done February 03 - February 18: Google program administrators review organization applications
done February 19: List of accepted mentoring organizations announced
in progress February 19 - March 15: Potential GSoC contributors discuss application ideas with mentoring organizations
Upcoming March 16: GSoC contributor application period begins
Upcoming Deadline March 31: GSoC contributor application deadline: Prospective GSoC Contributors Submit their 2026 Applications (includes proposals)
Upcoming DEADLINE April 21: GSoC contributor proposal rankings due from Org Admins
Upcoming April 30: Accepted GSoC contributor projects announced
Upcoming May 01 - May 24: Community Bonding Period | GSoC contributors get to know mentors, read documentation, get up to speed to begin working on their projects
Upcoming May 25: Coding officially begins
Upcoming July 06: Mentors and GSoC contributors can begin submitting midterm evaluations (for standard 12 week coding projects)
Upcoming DEADLINE July 10: Midterm evaluation deadline (standard coding period)
Upcoming July 06 - August 16: Work Period | GSoC contributors work on their project with guidance from Mentors
Upcoming August 17 - August 24: Final week: GSoC contributors submit their final work product and their final mentor evaluation (standard coding period)
Upcoming DEADLINE August 24 - August 31: Mentors submit final GSoC contributor evaluations (standard coding period)
Upcoming August 24 - November 02: GSoC contributors with extended timelines continue coding
Upcoming DEADLINE November 02: Final date for all GSoC contributors to submit their final work product and final evaluation
Upcoming DEADLINE November 09: Final date for mentors to submit evaluations for GSoC contributor projects with extended deadlines
Guidelines
Student's guidelines
Mentor's guidelines
Mentor Guide https://google.github.io/gsocguides/mentor/
Roles and Responsibilities https://developers.google.com/open-source/gsoc/help/responsibilities
Org Admin Tips https://developers.google.com/open-source/gsoc/help/oa-tips
Defining a Project Ideas List https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
Program Rules https://summerofcode.withgoogle.com/rules
GSoC Discord Chat channel discord.gg/google-dev-community
OpenMRS resources to know
GitHub: https://github.com/openmrs
Talk Forum: https://talk.openmrs.org
Help Desk: https://help.openmrs.org
Issue Tracker (JIRA): https://issues.openmrs.org