Content

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: CHAT

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: NOTIFICATIONS 

TIME: 170h / 350h, 

TYPE: Core,

LEVEL: Medium, 

MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

There is currently a module that allows SMS notifications to be sent via an external Gateway. It is designed to provide information on policies (activation, expiry, etc.). However, it could be extended to provide a generic solution to also send information through emails, or other channels of communication (e.g. Whatsapp). 

Expected outcome

We would like to introduce a generic solution for sending notifications regarding openIMIS events. Notifications could be sent using two approaches: 

• Based on scheduled tasks (e..g running in Celery) 

• Based on signals sent from modules.  

 At the moment only events based on scheduled events are implemented. We should implement at least 2 types of notifications - SMS and email ones. We should also decide on logic regarding more complex use cases (could be done through configuration): 

• In case of more than one SMS Gateway attached: 

  • Deciding on which one should be used, e. g. a situation in which the load on both gateways should be the same, or case when one gateway is used when the first one failed. 

• In case of multiple types of notifications: 

  • Prioritizing one type of channel over another one? Using all assigned to a given insurer?

We could also consider extending reporting functionality. At the moment it’s possible to check how many users in a given area have notifications turned on, have phone number etc. 

Required skills 

Python3

Django Framework

Other

Depending on scope, knowledge regarding SMTP or libraries like Twilio could be useful. 

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: AUTOMATED TESTS IN SELENIUM

TIME: 350H, 

TYPE: Automation  / Testing, 

LEVEL: Medium, 

MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

Currently the frontend part of the application doesn't have any automated tests attached. We can change it by introducing additional modules with selenium tests. It’ll be a challenge since we’re using a modular approach, and executed tests would depend on modules installed on a given instance. 

Expected outcome

New module with selenium tests for core functionalities is created. We can also think about attaching selenium tests to Github Actions CI (currently CI is executing unit tests in the backend and doing static code analysis).   

Required skills 

Python3

Django Framework, Selenium

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

PROJECT: Complex claim products

TIME: 350H, 

TYPE: Core, 

LEVEL: Hard, 

MENTORS: @Dragos Dobre / @Patrick Delcroix

Description

OpenIMIS as insurance management systems works around claims, today it is possible to claim service and items such as consultation or drugs but in our modern world there is also the need to claim more complex services or products such as a pension, package of service  or a cash paiement.

In order to claim such “complexe service/product”, openIMIS needed to add a new type of claimable business item “Complex claim products” that could define parameters required to claim a specific instance using the existing calculation modules. 

Complex claim services that can have a variable value based on other parameters (from imisdb or Form) 

The first stage would be to create the modules (FE/BE) to define those bundle and to be able to add, edit and remove  “complexe service/product” in a claim

Expected outcome

• “Claim Complex product” modules

• Update of the claim module to support the “Claim Complex product”

• (nice to have) check and valuation calculation rules

Required skills 

Python3

Django Framework

Javascript

React