Brainstorming GSoC 2025 Project Ideas

Community GSoC
1

Hi everyone,

Wishing you all a Happy New Year! :tada:

Although Google has not yet announced GSoC 2025, it’s never too early to start brainstorming project ideas. Whether you have a fully thought-out idea or just a rough concept, don’t hesitate to share it here! Even rough ideas are welcome—we can work together to refine and shape them into impactful projects.

Project Sizes:

  • Small: ~90 hours
  • Medium: ~175 hours
  • Large: ~350 hours

Additionally, if you’re interested in becoming a mentor, feel free to express your availability here! Mentors are vital in guiding contributors and making projects successful.

Useful Resources:

Looking forward to your ideas and seeing how we can make GSoC 2025 another amazing year for OpenMRS!

17 Likes
2

Hello Jayasanka,

There are a couple of e2e tests identified for automation. Do you think this could be a suitable project for GSoC?

5 Likes
3

I think this is a good idea to bring onboard @veronica

3 Likes
4

Hello Jayasanka, this is my draft proposal

OpenMRS Help Chatbot

4 Likes
6

Develop a professional system for generating and managing medical reports accessible to both doctors and patients, including online report viewing capabilities.

what about my idea?

1 Like
7

Enhancing the Usability of the OpenMRS Patient Flag Module

The OpenMRS Patient Flag Module is an essential tool for creating and managing flags to highlight important information about patients. Current module is having a significant usability challenge. The module is not user-friendly for non-technical users, creating or managing patient flags requires knowledge of SQL or Java, which makes it hard for people like doctors or nurses to use the module effectively.

Most of time doctors and nurses engaging with patients, and if they need to create flags, they often have to ask a manager ( who is having knowledge in sql or java and manage the application) to do it for them.

Proposed Solution: User Friendly Flag Creation

I propose a flag criteria generating method that simplifies flag creation, allowing non-technical users to generate patient flags without requiring SQL or Java knowledge.

I have done a detailed explanation about generating flag criteria in below talk thread,

Benefits

  1. Increased Accessibility: Enable doctors, nurses, and other non-technical users to directly interact with the Patient Flag Module
  2. Improved Clinical Workflow: Streamline the process of flag creation and management, leading to quicker decision-making and better patient outcomes.
8 Likes
8

I’d like to suggest a large project: Support for horizontal scaling of OpenMRS instances

In the scope of the project would be (depending on the progress we make using other contribution channels):

  1. Adjust codebase across core and O3 modules to use a new storage service described here.
  2. Adjust code in core and O3 modules to use distributed caching
  3. Experiment with Hibernate Search using OpenSearch as backend instead of a local Lucene index.

I’m interested in being a mentor for this one.

7 Likes
9

A large project idea - adding an interactive builder to make form translations for forms within the form builder - https://openmrs.atlassian.net/wiki/x/OAByEw, which I’ll be glad to mentor

8 Likes
10

Large project ideas:

  • Archiving voided data: Voiding in OpenMRS is a form of soft-deleting. We basically set a binary column to 1 and attempt to ignore data at various points. Voiding data is meant to mark it as invalid for one reason or another (e.g., an obs has been superceded or data was recorded against the wrong patient). This is very useful, because voided data can be easily restored, but over the long term (especially with “immutable” objects likes obs), this causes some OpenMRS tables to grow to contain far more voided data than non-voided data. To address this, we should add a mechanism to archive voided data with the possibility of restoring it.

  • Integrating Data Filter for Data Segregation / Multitenancy: 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).

Medium project ideas:

  • Service Queues: 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.

  • Appointments: Scheduling appointments is an important function of an EMR. Unfortunately, the RefApp is currently stuck on an older version of the appointments module. What we would probably want to do here is (unfortunately) fork the appointments module to get the various fixes the OpenMRS community needs, update to the latest version of the module.

  • Improved Appointments Calendar View: 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.

Given my current time commitments, I’m not sure I can commit to actually mentoring a GSoC project this year; however, I am willing to be consulted on basically anything that’s happening in GSoC.

10 Likes
11

We added Hibernate Envers for audit logging in OpenMRS 2.7.0, but right now, there’s no easy way for admin users to view or manage these logs. One idea is to build a backend module to handle this.

Here’s what it could include:

  1. Show Audit Logs: Pull and display audits for database tables.
  2. Filters: Let users filter logs by things like who made the changes, when, and what they changed.
  3. REST Endpoints: Add APIs so other systems can access the audit data.

I played around with this idea and only had time to put together a very basic UI, which you can check out here: Audit Log UI Module. Depending on how much we want to expand it, this could turn into either a medium or large project.

4 Likes
12

Some ideas from this doc,

Dynamic EHR: Custom Home screen (and other screens) based on User roles, locations and other values

By @ibacher

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 values into the expression.

Some other Idas from the same doc:

  • Extension useEffect hook

  • Better typings for passing data into extensions and simpler extension configs

  • Better way to receive feedback from clinicians / users

  • Start having reference implementations of component in ZeroHeight

  • Deduplicate requests from useCurrentPatient & useSession hook. Ticket

    • It should be possible to leverage SWR’s caching and deduplicating features in the useCurrentPatient hook. Presently, multiple requests get fired each time we load up a Patient Chart, and unnecessarily so.

  • Stricter Typescript configuration for strong typing

    • Dovetails with Chi Bong’s work on extractwhaing a types library from our Swagger backend docs.

There are also some ideas proposed in 2024 that didn’t move forward: https://openmrs.atlassian.net/wiki/spaces/RES/pages/26279023/Summer+of+Code+2024#Pending-project-ideas%3A

OpenMRS Standalone:

Replace the Standalone with something else. Very old, can’t even build in our latest releases - we disable it as the technology no longer works and is no longer supported. We now just ship the .war file and README. Suggestion to leverage Docker - something that works by double clicking and then just runs.

We never intended to use the OpenMRS Standalone version in production. But it turned out to be used in a number of places because they found it easier to use for sites that did not have support staff with advanced IT skills. We are also seeing an increasing number of people in our community who do not have lots of computer skills and just want something to download, click and run for their hospitals.

User-defined extension show / hide rules:

The idea here is to implement something like O2’s checkRequireExpression() via the configuration schema’s “Display conditions”, allowing implementations to right JS rules to determine whether a specific extension should be visible or not.

Revamping OpenMRS 3.0 FHIR Module for Enhanced Offline Data Synchronization and Interoperability

This proposal aims to overhaul the FHIR module in OpenMRS 3.0, focusing on enabling its interoperability with applications like Google’s Open Health Stack for efficient offline data collection. The project will involve a comprehensive review of the current module, identification of limitations, and subsequent enhancements to support adding, editing, and deleting patient data, visits, encounters, and observations. The goal is to facilitate robust two-way data synchronization, crucial for healthcare settings in LMICs with intermittent internet connectivity.

Next Generation Implementer Tools for OpenMRS 3

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. Project plan documented here.

Scope: technical work on the redesigned config tools for O3.

*Design is done because Ampath/@jdick graciously contributed designs and user testing, sample designs, and @bistenes gave a lot of architectural and technical input but then had to set the project aside.

O3: Search Patient Chart feature

E.g. search all of a particular patient chart for an item of interest, e.g. “IUD” or “COVID”, to find if that term/situation has ever come up for this patient. We can likely leverage this past work: GitHub - openmrs/openmrs-module-chartsearch: liquibase.xml Will need an API.

5 Likes
13

This is a nice Idea @nethmi

14

We have been trying to fix errors related to our swagger documentation and upgrading it to the latest versions of openapi (or there about) and the pull requests for that are already in place.

For this GSoC i would suggest on top of the work on going, we work towards having a tooling or coming up with one that either autogenerates our swagger document by looking at the javadocs, return types, etc. Part of the work that autogenerates our swagger documentation i have been working on just uses reflection to scan through openmrs resource handlers. Maybe we can build on top of that for the tooling we envision? The ideal is to have an openapi spec generated at compile time rather than runtime like it is at the moment to curb any errors at compile time rather than waiting to see errors or not at runtime.

For reference,

5 Likes