Code4GovTech Dedicated Mentoring Program 2026

Code4GovTech Dedicated Mentoring Program 2026

C4GT has conducted four rounds of DMP since 2022 where selected students and working professionals get an opportunity to contribute to critical tech building blocks under the guidance of a dedicated mentor. They work closely with organisations building DPGs and open source technology for a period of 3 months on problem statements that have a population scale social impact and get a stipend of Rs. 1 Lakh.

C4GT is an ecosystem initiative that nurtures the development and long-term maintenance of open-source products, particularly Digital Public Goods (DPGs), that drive population-scale social impact. By creating pathways for young talent to contribute to these products, we aim to build a stronger ecosystem together.

The openIMIS Initiative started participating in the DMP in 2025.

This page was created for your convenience. Please be aware that only the below link to the C4GT tender platform contains the most recent versions of the tender documents.

Since the openIMIS Intiative needs to be accepted as a valid partner first, this opportunity will depend on C4GT’s decision.

Content


The DMP remains a structured 3-month program designed to ensure high-quality contributions on impactful projects. To attract top-tier talent, contributors receive a stipend of INR 100,000. As per our collaborative model, 50% of this stipend (INR 50,000) is shared by the partner organization, while C4GT covers the remaining half.

DMP 2026: Timeline & Next Steps

We have mapped out the tentative 2026 timelines to align with the same days of the week as our previous cycle:

  • Project idea submission by organizations: By Feb 27

  • Project listing: By Mar 29

  • Proposal submission by contributors: By Apr 27

  • Evaluation of proposals by mentors: Apr 27 - May 19

  • Project setup & Contributor Bootcamp: May 25-29

  • Coding Period: Jun 1 - Aug 31


Topic Proposals

== to be done ==

PROJECT: FHIR DEVELOPMENT

TIME: 170H, 
TYPE: Core, 
LEVEL: Medium
MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

FHIR is the standard for communication between healthcare systems. OpenIMIS uses two types of communication: 

  • GraphQL - internally to communicate between backend and frontend

  • Rest API - Using FHIR standard to make communication with external systems possible. 

We want to improve the currently used API to make it more flexible and therefore more useful for external systems. We also can add mapping for missing resources. Real facade with

Expected outcome

For most cases filtering of data available through Rest API is not possible. To access a given resource it is necessary to provide it’s identifier. We want to add generic solutions for query filters which will allow us to filter with properties different than only identifiers or predefined case-specific variables. Support for additional resources could also be added.

Required skills 

Python3

Django Framework, Django Rest Framework

Other

Understanding the HL7 Protocol will be a nice addition. 

References


PROJECT: Migration to History model

TIME:  
TYPE:
LEVEL:  
MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

Preparation done there https://github.com/openimis/openimis-be-core_py/pull/406

  • use MODEL.filter_validity iso filter_validity, this change can be done everywhere so model migration won’t break those queries

  • openIMISModel and openIMISModelMigration are available along utils to do the data migration of the audit records in the history table

  • New model are dropping the user/date created/updated because this is managed by the history table 

Expected outcome

All models in openIMIS are extending the History or HistoryBusiness models.

Required skills 

References

  • from developer minutes #508


PROJECT: Simple Claim Workflow 

TIME: 350H, 
TYPE: Core, 
LEVEL: Medium, 
MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

Today openIMIS claiming is using the status of the business Item (the claim) to assign it to different stakeholders but this  is too limited for complexe and distributed organisations.  The idea would be to create a group of users and the possibility to assign them tasks, each task would be a business step.

Expected outcome

The expected outcome would be (each will bring add value on its own)

  • Group modules

  • Task modules

  • Ability to make fields “read only” in the task configuration (kind of masking, when a business item view is embedded in the task view)  [require task module]

  • Creating simple calculation rule to assign task to a group  [require task module and group]

Required skills 

Python3

Django Framework

Javascript

React


 


PROJECT: [Template]

TIME:  
TYPE:
LEVEL:  
MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

 

Expected outcome

Required skills 

References

  •