Brainstorming GSoC 2026 Project Ideas

Community GSoC
1

Hi everyone,

Wishing you all a Happy New Year! :tada:

Google has announced the timeline for GSoC 2026, and as we prepare to apply, it is a good time 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!

Useful Resources:

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

cc: @ibacher @dkigen @dkayiwa @veronica @jayasanka

9 Likes
2

Hi Ian Bacher, Brandon Istenes, Veronica Muthee, jayasanka— Happy New Year! :tada:

I’m Praneeth (praneeth622), an active O3 contributor with merged PRs in openmrs-esm-patient-chart . While working on those bugs, I identified some critical gaps in OpenMRS O3 that would make excellent GSoC projects. I’d love feedback on these ideas!

Idea #1: Form Engine Error Handling & Validation Improvements

The Problem I See:

  • Forms sometimes crash silently when data is missing or invalid

  • Error messages aren’t always clear to clinicians (“Field is required” without saying which field)

  • When forms fail, users lose their work

Rough Solution: Build better error handling into the form engine — better validation messages, error boundaries to prevent crashes, and maybe a way to recover partially-filled forms.

Why It Matters: Forms are critical for patient registration, observations, and orders. Making them more reliable directly improves clinician experience.

Possible Size: Medium (175h) or Large (350h) depending on scope

Idea #2: Workspace Developer Experience Improvements

The Problem I See: While working with workspaces (in the O3-4648 fix), I found some things that could be easier:

  • Understanding how launchChildWorkspace works took time

  • Debugging workspace state is hard without dev tools

  • New contributors struggle with workspace patterns

Rough Solution: Create better tools for developers working with workspaces — maybe debugging panels, better documentation, or helper hooks.

Why It Matters: Workspaces are everywhere in O3. Making them easier to work with helps all contributors.

Possible Size: Small (90h) or Medium (175h)

Idea #3: Offline Support for Order Basket

The Problem I See: The order basket only works online. If network fails, clinicians lose pending orders.

Rough Solution: Add offline queueing using IndexedDB, so orders sync when connection returns.

Why It Matters: OpenMRS targets low-connectivity environments. Orders are time-sensitive.

Possible Size: Medium (175h)

Questions:

  1. Are these problems worth solving? Or are there bigger priorities I’m missing?

  2. For Idea #1 (forms), what pain points do implementers face most?

  3. Should any of these be combined or split differently?

Background: I have PRs in patient-chart (#2939, #2819) and am familiar with workspaces, forms, and orders workflows.

Happy to refine these based on feedback!

3 Likes
3

Thanks for kicking off the thread, @beryl!

I’ve gone ahead and started a wiki page here: https://om.rs/gsoc2026

I’ve also brought over the project ideas we had to leave behind last year. You can find them here: https://openmrs.atlassian.net/wiki/spaces/RES/pages/752844801/Summer+of+Code+2026#Good-Ideas-We-Had-to-Leave-Behind-Last-Year .

Might be worth reviewing to see which ones still feel relevant or promising.

And happy New Year to you too, @praneeth622! Really appreciate you bringing in those great project ideas.

6 Likes
5

Just to add some context and momentum here… Last year’s GSoC projects delivered very real impact for OpenMRS and, more importantly, for implementations.

A quick snapshot of what came out of GSoC last year:

  • :syringe: Immunization and Vaccination Tracking in O3 A clear and visual way to track immunization schedules, dose sequences, and due or overdue vaccinations directly in the patient chart, especially impactful for maternal and child health programs.
  • :blue_book: Automatic OpenAPI Documentation A build-time plugin that generates accurate OpenAPI specs directly from REST resources, eliminating API documentation drift and making integrations much easier for implementers.
  • :laptop: Modern Standalone Replacement A new cross-platform standalone runtime using Java 17 and MariaDB4j that works smoothly on Apple Silicon, Linux, and Windows, significantly lowering the barrier to getting OpenMRS running locally.
  • :high_voltage: Performance Testing Framework A scalable Gatling-based framework to simulate real user load, catch performance regressions early, and generate concrete data that implementations can use to plan infrastructure and scale safely.
  • :keyboard: Fast Data Entry improvements Integration of the React Form Engine into the Fast Data Entry app, making retrospective data entry faster, more flexible, and aligned with modern O3 workflows.
  • :hammer_and_wrench: Improved Implementer Tools Reliability and usability fixes that help non-technical administrators configure systems with more confidence and fewer support issues.
  • :detective: Audit Log Management A backend module that makes audit logs accessible and actionable, supporting troubleshooting and compliance needs in regulated healthcare environments.
  • :globe_showing_europe_africa: Translation Builder for the Form Builder A full in-UI solution for managing form translations that allows users to view, edit, search, upload, and download translations, making it much easier to support multilingual implementations.

When we reflected on these in a recent meeting, one thing stood out very clearly: the projects that worked best were the ones rooted in real implementation needs and had ongoing feedback from implementers. That collaboration is really our secret sauce.

That’s why we’re especially keen to hear from implementer organizations early this year.

If you have:

  • workflows that are painful today,
  • features you wish existed,
  • operational or scale challenges,
  • reporting, performance, or data quality gaps,
  • or ideas that would directly improve care delivery,

please post them here,even if they’re rough or half-formed.

You bring the real-world problem. The community can help shape it into a strong, impact-driven GSoC project. That’s how we keep GSoC delivering outcomes that actually move the platform forward.

Looking forward to the ideas! :heart:

P.S. @burke @paul @janflowers @ibacher @dkayiwa you have seen this play out across multiple cycles too, feel free to jump in if you want to add anything on why this kind of collaboration works well.

6

Thanks @jayasanka for bringing this out very clearly! :+1:

@kmuiruri i have seen you raise a number of feature requests for O3. Does this look like where some of that can be done when @PalladiumKenya provides mentorship to a GSoC student or two?

2 Likes
7

"100% agree with you, @dkayiwa.

@kmuiruri, a perfect example of this is the Notification feature you’re championing. It addresses workflow pain ….. clinicians not knowing when lab results are ready —and it would make a fantastic candidate for a GSoC project.

It would really be nice for PalladiumKenya to provide mentorship on this ~ from the requirements stage into development. This would improve care delivery for the users and also benefit the wider community.

2 Likes
8

@dkayiwa @veronica thanks for bring this to our attention and for the consideration, we’d be happy to be part of GSoC 2026 as @PalladiumKenya

I’m proposing 2 areas as I engage team @PalladiumKenya on other areas

  1. Service integration within clinical forms where users would be able to access variables based on program areas where a client is enrolled to. An example of a general patient seeking outpatient services who is diagnosed with HIV and enrolled to HIV program hence requiring additional variables specifically required for HIV programming.
  2. Notification feature to support care coordination and communication among practitioners within a health facility
2 Likes
9

Hi everyone,

I’d like to propose a project for GSoC 2026: A Native O3 Frontend for the Audit Trail.

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.

Mentorship: SolDevelo is happy to provide mentorship for this project to ensure the interface aligns with O3 ecosystem standards.

Useful Resources about the Audit Trail solution:

I believe this would be a high-impact way to improve clinical accountability in O3 and would love your feedback on that, thanks! :slight_smile:

CC: @alebiedzinski @pwargulak

5 Likes
10

Hi everyone,

I’d like to propose a project for GSoC 2026: A Prometheus & Grafana Metrics Module for OpenMRS.

The idea: OpenMRS deployments increasingly need better visibility into both system health and business level usage metrics (such as patient registrations, encounters, and clinic activity). While OpenMRS provides logging and basic monitoring, there is currently no standardized, Prometheus compatible way to expose aggregated business metrics or provide ready to use dashboards for implementers.

This project proposes building a dedicated OpenMRS module that exposes secure, Prometheus-compatible metrics and ships with pre built Grafana dashboards tailored for healthcare workflows. The module would focus on aggregated, non identifiable metrics and require no changes to OpenMRS core.

The opportunity: Since OpenMRS already exposes rich domain services (patients, encounters, visits, appointments), a metrics module can leverage these services to generate meaningful insights with minimal overhead. Implementers could gain realtime visibility into patient flow, clinic performance, and system usage, while developers benefit from standardized JVM and request level metrics.

Additionally, providing a simple metrics API would allow other OpenMRS modules to publish their own metrics without needing direct Prometheus knowledge, helping establish a consistent observability pattern across the ecosystem.

Feedback, suggestions are very welcome.

3 Likes
11

Hi Everyone,

I’d like to propose adding Patient Visit Summary Printing to the GSoC project list for consideration.

Rationale:

  • Requested by the Uganda team, the DRC team, and Palladium

  • Requirements are documented and ready

  • Builds on the recently completed printing support

  • Addresses real implementation needs

3 Likes
12

Because our obs table is growing to such levels that we are soon going to have real performance implications that need to be addressed, i am bring this back from last year’s GSoC ideas as was proposed by @ibacher

  • 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.
3 Likes
13

Hi everyone,

I’m exploring potential project ideas for Google Summer of Code 2026 with OpenMRS, and I’d really appreciate community feedback on the feasibility and relevance of the following idea before moving forward.

Problem I Addressed

In many real hospital environments, clinicians work in rotating shifts. While OpenMRS captures encounters, orders, and observations effectively, there doesn’t appear to be a structured way to manage clinical follow-up tasks and responsibility across shifts.

In practice, this can lead to:

  • Missed follow-ups (e.g., reviewing lab results, reassessing patients)

  • Loss of clinical context when care is handed over

  • Reliance on informal methods such as paper notes or verbal handover

I’m trying to understand whether this is a problem that OpenMRS implementations commonly face and whether it’s something worth addressing at the platform/module level.

Idea I am Proposing

Clinical Task Handover & Shift Continuity (Concept)

The idea is to introduce a lightweight, backend-focused mechanism that allows clinicians to create and track patient-linked clinical tasks, with support for continuity across shifts.

At a high level, this could include:

  • Creating clinical follow-up tasks linked to a patient and encounter

  • Assigning tasks to providers or locations (e.g., ward / department)

  • Carrying over pending tasks when shifts change

  • Tracking task status (pending, completed, overdue)

  • Basic auditability for safety and accountability

This is only a concept at this stage, and I’m intentionally keeping the scope open.

Questions for the Community

I’d really appreciate feedback on:

  • Is this a real and recurring problem in OpenMRS implementations?

  • Are there existing modules, discussions, or past efforts addressing this?

  • Would this be better modeled using existing OpenMRS concepts (e.g., orders, encounters, programs)?

  • Does this seem feasible and appropriate for a GSoC-scale project?

  • Any concerns or alternative approaches I should consider?

14

Thanks for proposing these two ideas, @kmuiruri! Could you please elaborate a bit more on them, especially around the specific problem we’re trying to solve with each?

@olewandowski brilliant idea! Since the REST endpoint and backend are already in place, this feels like a great candidate for a small-sized project.

@wikumc @dkayiwa @njiddasalifu one use case we haven’t covered yet is auditing specifically who viewed patient data and what data was accessed. This could potentially be a separate project. Would love to hear your thoughts or ideas around this.

Thanks @bawanthathilan for proposing this! I’m a bit obsessed with Prometheus myself :grinning_face_with_smiling_eyes:
@raff I know this is already on your backlog. Do you think this could be shaped into a potential GSoC project, or tweaked slightly to fit? One idea could be having a common module that allows other modules to send metrics, which then exposes them to Grafana. We’ve got some work done here but I guess pehaps it’s not yet in shape to be adopted.

@veronica thanks so much for this! it’s very well defined :heart: I’ve added it to our available project list.

@dkayiwa thanks for bringing this up. This is definitely a priority area. Let me know if you’d be interested in leading this project.

Thanks @dishakd, very thoughtful proposal! @brandon does this align with what you’re planing to working on? Would love to get your feedback here.

2 Likes
15

Thanks so much for the kind words

I’d really appreciate your feedback on this, especially regarding alignment with any ongoing or planned work.

At this stage, this is still an exploratory idea, and I’m very open to adjusting the scope or direction based on community and mentor input. Looking forward to hearing your thoughts when you have time.

1 Like
16

Hi @jayasanka thanks for following up on this. Yes, some events auditing are yet to be implemented, I am discussing with Wikum on how we can shape that into another gsoc project. I will submit it anytime soon.

1 Like
17

Hi everyone, this is another proposal for GSoC’2026

GSoC 2026 Project Proposal: Extend Audit Log Module in OpenMRS

Related Module & Work: openmrs-module-auditlogweb

1. Project Overview

During GSoC 2025, the Audit Log Web Module was developed to integrate Hibernate Envers into OpenMRS 2.7.0+. This allowed for the tracking of Create, Update, and Delete (CUD) operations. While this established a strong foundation, the current implementation only covers a fraction of the auditing requirements needed for international EMR compliance (such as HIPAA in the US or GDPR in Europe).

The goal for this year is to transition the module from a “change tracker” to a comprehensive security and compliance tool by implementing “Read” auditing and tracking critical system-level events.

2. The Problem

Currently, the module doesn’t capture some several critical actions:

  • View Access: We know who edited a patient’s record, but we don’t know who viewed it.
  • System Security: Login attempts/failures, account lockouts, and session timeouts are not logged.
  • Administrative Actions: Changes to global properties, module installations, and data exports (printing/CSV) are not captured. Just to mention a few …

3. Proposed Key Features for GSoC 2026

A. Read Operation Auditing

Implement a mechanism to log when sensitive data is accessed.

  1. Patient Dashboard Access: Log when a user views a patient’s related data/summary.
  2. REST API Access: Audit GET requests for sensitive resources (Observations, Encounters, etc…).

B. System & Security Event Tracking

Capture events outside of the Hibernate Envers scope:

  1. Authentication: User login, logout, and failed login attempts.
  2. System Lifecycle: Server startup, shutdown, and maintenance mode toggles.
  3. Data Integrity: Backups, restores, and PHI export events (printing or file downloads).

C. Advanced Reporting & Exporting

  1. Export Tools: Allow admins to export filtered logs to CSV, Excel, or JSON for legal audits.
  2. Data Retention: Implement basic log rotation or archival settings to prevent the database from growing indefinitely.

4. Technical Requirements & Skills

  • Java, Spring, Spring Events, Spring AOP & Hibernate: Deepening the use of Interceptors or Spring AOP for read-tracking.
  • OpenMRS Core: Understanding the authentication and authorization workflows.
  • REST API: Expanding the existing auditlogweb endpoints.
  • Reactjs & TypeScript: Making use of reactjs for developing the UI of the audit logging
  • Performance Tuning: Managing high-volume data writes without slowing down the UI.

5. References & Inspiration

  • PCC Audit Tool Example: PCC EHR Audit Log
  • US EHR Certification (ONC): Focuses on “Who, What, When, and Where” for every PHI access.

cc @beryl @jayasanka @wikumc @dkayiwa @ibacher @Veronica @olewandowski

3 Likes
18

Alright a couple of security-related GSoC projects:

Integrate O3 with the Authentication module

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.

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.

6 Likes
19

I think it’s a great GSoC project. In the next 2 months we are going to provide basic Grafana setup with centralized logging for OpenMRS backend and DB. Metrics such as hardware utilisation and business level metrics would be a great addition.

1 Like
20

Hi everyone! I’m very interested in the project for Horizontal Scaling of OpenMRS instances. I’ve been working closely with Rafal Korytkowski on the foundational work for this, and I’ve reached my first milestone by submitting a PR that implements the initial Storage Service.

Current Progress:

GSoC 2026 Roadmap Strategy: Based on my work with the storage service, I’m starting to map out the next phases for the GSoC timeline:

  • Storage Service Expansion: Moving beyond the core to adjust O3 modules to utilize the new storage abstraction.

  • Distributed Caching: Implementing caching mechanisms that work across multiple instances to ensure data consistency.

  • OpenSearch Migration: Transitioning from local Lucene indexes to OpenSearch for Hibernate Search to allow the search index to scale independently of the web servers.

Working on TRUNK-6488 gave me a deep look into the core’s file handling, and I’m excited to apply that to the broader scaling challenges. Looking forward to refining this proposal with @raff and the community!

1 Like
21

I think you meant health check and maintenance pages and not storage service.

Storage Service, Distributed Caching and Elastic Search instead of Lucene has all been done already.

However, there’s still more work to be done in the horizontal scaling space so I’m all in for having a GSoC project on that.