Content

PROJECT: FHIR Open Health Stack Mobile App

TIME: 350H, 

TYPE: Peripheral,

LEVEL: Hard, 

MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

openIMIS has already two mobile apps to allow users to work offline on the field. These mobile apps are integrated with the openIMIS through the GraphQL API and some components are replicated between the two apps (i.e. enquiring functionality).

The objective of this project is to develop a modular mobile application using modern frameworks (e.g. Flutter) that integrates with openIMIS through the FHIR API using the Google Open Health Stack. The access to functionalities and screens should be restricted through authorities (already part of openIMIS).

Expected outcome

A modular mobile application that allow users to use different functionalities based on their roles and authorities and that connect to openIMIS backend through FHIR.

Required skills 

Python3

• Django Framework, FHIR, developer tools: pypi

Javascript

• React, GraphQL, npm

Other

• Knowledge of modern mobile app frameworks

• Google Open Health Stack

PROJECT: openIMIS MCP (Model Context Protocol) Server

TIME: 350H, 

TYPE: Peripheral,

LEVEL: Hard, 

MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

The student would work on implementing a server for openIMIS to support Model Context Protocol to enable openIMIS to become interoperable with LLMs and AI Agents. This would empower users to perform actions and trigger workflows via AI agents using natural language which would improve the experience for end-users. The workflows include but are not limited to: querying insurees and claims, reviewing and approving claims, getting quick custom analysis on Cash transfer projects/activities, and many more - all using natural language (initially limited to English for this project).

MCP can also aid developers of the openIMIS project to connect to AI tools to streamline software delivery lifecycle and activities including code review, documentation management, testing and release monitoring and automation.

Expected outcome

A working MCP Server implementation that can be used from within different tools including ChatGPT, Claude Code, Cursor etc.. and any other tool that supports MCP.

Required skills 

Python3

• Django Framework, GraphQL, developer tools: pypi

Javascript

• React, GraphQL, npm

Other

• Knowledge of MCP (Model Context Protocol)

• Interest and knowledge in building LLM powered experiences

PROJECT: Chat module

TIME: 350H, 

TYPE: Peripheral,

LEVEL: Hard, 

MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

During the creation of the OpenIMIS AI Evaluation module, the initial approach was to use Websockets as a communication channel between AI Instance and the main OpenIMIS instance. As a result, we have the possibility to support Websockets, which could be used as a base for implementing real-time communication between users in openIMIS regarding business items or process. 

Expected outcome

While some application deployments have a dedicated supporting division, such a solution is not possible in smaller instances. By creating a dedicated chat for OpenIMIS we want to improve communication between different types of agents using the same system. We want to introduce a module that will allow real-time communication without having to rely on external systems. Everything that users may need will be in one place.  It should be possible to start a chat using IMIS business items as channel in order to enable discussion focused on this  specific business ITem, on the other end if an imis link is mentioned it would be nice to be display with a short name (using React “name/picker” element for example)

Required skills 

Python3

Django Framework, Django Channels 

Javascript

React

Other

Basics of asynchronous communication.

PROJECT: MODULE MANAGER

TIME: 350h

TYPE: Exploratory / Infrastructure

LEVEL: Hard,

MENTORS: @Dragos Dobre / @Patrick Delcroix  

Description

At the moment the only way for managing modules in OpenIMIS is through using the openimis.json file in the backend’s assembly. Idea is to create a solution that’d allow specific types of users to add or remove modules using the dedicated frontend module (solution could be similar to the one used in OpenMRS). The backend part could use functionalities created as developer tools. We might also consider creating dedicated logic for keeping track of the module dependencies (and versions compatibility). 

Expected outcome

At the moment this feature is not essential, modules are created and released at the same time, which makes them easy to manage. As the project grows, the relationships between modules will become more complex. It will most likely be a necessity to have this kind of functionality to keep track of dependencies. The initial project created in the scope of GSoC will be a great risk-free attempt to solve this issue. Even though it’s heavily related to the modular architecture of OpenIMIS – it does not require a broad knowledge of how the modules are working. As a result, we’d want to have two new OpenIMIS modules: one for both frontend and backend. 

Frontend Module

The frontend module should display information regarding available modules. Modules should be taken from official repositories, which are npm and PyPI. Information regarding module dependencies should be displayed.. At the moment modules are not storing detailed and strict information about their versions dependencies. This should be added, and updated on every release. The user should be able to add a new module or update an already installed one.

Backend Module

Once the user has selected the desired modules, the application will automatically install them into the OpenIMIS instance.  

Example:

Claim module is depending on Core, Product, Insuree, Medical, and consecutively - their dependencies. Users don’t want to install every module separately and check version compatibility.

Our manager should recognize the dependency graph for a given module and its version. If a user has Insuree Module installed in version 1.37.2 and the most recent Claim module requires Insuree in at least 2.0.0 it should be possible to either: 

• Install the previous version of claim module 

• Check if updating to a new version is possible. (This option is preferable.)

Required skills 

Python3

Django Framework, GraphQL

Javascript

React, GraphQL

Other

Good knowledge regarding packages architecture, git and package managers (NPM, PyPi).

PROJECT: EXTENDING CALCULATION RULES

TIME: 350h, 

TYPE: Exploratory / Core,

LEVEL: Hard, 

MENTORS: @Dragos Dobre / @Patrick Delcroix

Description 

Calculation rules are a solution to accommodate complex calculations that vary between IMIS implementations. Calculation rules  are defined in the backend and based on their configuration the frontend adding the required parameters in different business items screens (kind of templating using json) via the Calculation module (front end and back end).

The idea behind the extension is that the calculation rules should 

• be used in more contexts like handling the person to be covered by an insurance policy in addition to the insuree itself.  Or /and enable the claims valuation thought calculation rules

• Be able to support string and pickers (defined in other OpenIMIS FE modules) in the json parameters templates

• implement a framework that will allow easier creation of calculation rules via a web interface. 

Expected outcome

Calculation rules can: 

• Support react pickers and string parameters. 

• Use calculation for claim check

• Use calculation for claim valuation

• Use calculation for policy member definition.

• Front end to create updates calculation

Required skills 

Python3

Django Framework

Javascript

React

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.

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. 

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: FHIR Questionnaire attached to a Claim

TIME: 170H, 

TYPE: Core, 

LEVEL: Medium, 

MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

The claiming process may differ from one organisation to another but it does not add value to customise the claim object (or Claim FHIR object) per organisation because such practice would destroy the already developed interoperability between openIMIS and other systems. FHIR does provide other resources that are adapted to gather additional information in a structured way: The FHIR questionnaire.

There is already open source  questionnaire filler existing in Javascript but we need to adapt one of those solution to either interface with or  fit inside openIMIS then attached the link to the answers (FHIR questionaireResponse ) to the claim, the Questionnaire response could be saved either in a FHIR server or in openIMIS

Form attached to the claim to collect the additional information required to handle the case

Expected outcome

Claim module updated to be able to a FHIR Questionnaire definition, to render and fill the questionnaire  and to attach the QuestionnaireResponse to the claim instance. 

Required skills 

Python3

Django Framework, Django Rest Framework

Javascript

React

Standard:

FHIR