Content

PROJECT: MODULE MANAGER

TIME: 350h

TYPE: Exploratory / Infrastructure

LEVEL: Hard,

MENTORS: Dragos Dobre / Damian Borowiecki  

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 / Damian Borowiecki 

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 / Damian Borowiecki

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: Patrick Delcroix / Seweryn Niedzielski

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 / Seweryn Niedzielski 

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: NEW MOBILE APPS

TIME: 350H, 

TYPE: Exploratory, 

LEVEL: Hard, 

MENTORS: Dragos Dobre / Damian Borowiecki / Kamil Malinowski

Description

OpenIMIS mobile app was created in 2013 and it can be seen in its look and feels but also in its internal architecture. Also Health IT is going toward the FHIR standard, openIMIS as a health IT system should follow.

The goal of this project would be to create a FHIR application to manage insurance that will be compatible with openIMIS but could be a basis for other insurance company system.  In that regards Google started a project called  Android-FHIR SDK that provide a FHIR application framework, meaning that the database structure is already FHIR compliant and the work required to communicate with openIMIS would be minimal as openIMIS is already FHIR compliant.

Most of the work would be on the UI/UX to fit FHIR insurance models and insurance/openIMIS business processes (the project can do one or multiple processes)  : Registration, Enrollment, Renewal, Client Portal, Claiming, Claiming Audits/feedback

User is Healthcare worker OR enrollment officer

User can be the insuree (Client Portal) - Out of scope

Expected outcome

POC that will implement of the business processes of openIMIS following the agile methodology with this product backlog ordered by priority (up to point 4 will be already a success)

1. Set-up the project

2. Authenticate a user with openIMIS as backend (FHIR login)

   1. at least once online, then local auth possible if not network

3. Retrieve the user preferences (language, locations, organization etc )

   1. for offline usage

      1. Location (Location)

      2. HealthFacility (Organization)

      3. Users (Practitioner ? OE and CA)

      4. List

         1. Product (InsurancePlan)

            1. Pricing/limits ? TBC

         2. items (Medications)

         3. services (ActivityDefintion)

         4. diagnosis (CodeSystem)

         5. hard coded : claim type etc… CodeSytem

   2. Saving data : Can the app use StructureDefinition ?

      1. hold the extension (new properties etc)

      2. hold constraints

4. Check insurance coverage based on insurance number

   1. CoverageEligibility

   2. Coverage

5. Enable the registration of a new insuree

   1. Insuree : registration of a person in the system

6. Enable the update of an existing insuree 

   1. Insuree

7. Enable the enrollment of an insuree on a product (payment not included)

   1. Enrollment into a product/policy (including payment): Contract

   2. challenge: define the price offline (TBD)

8. Add beneficiary on a policy

   1. create/update Insuree

   2. add add the beneficiary on the contract

9. Register and submit new claims using items and services defined in openIMIS

   1. claim and claimResponse (kind of async)

   2. Challenge: high input density

10. manage pricelist (TBD)

    1. items

    2. services

Required skills 

Python3

Django Framework, Django Rest Framework

Flutter

PROJECT: AUTOMATED TESTS IN SELENIUM

TIME: 350H, 

TYPE: Automation  / Testing, 

LEVEL: Medium, 

MENTORS: Damian Borowiecki / Kamil Malinowski (We could involve one of SolDevelo’s testers)

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

PROJECT: Bundle of Items and Services 

TIME: 350H, 

TYPE: Core, 

LEVEL: Hard, 

MENTORS: Dragos Dobre

Description

Add possibility to group Items and Services in a Bundle. During claiming, a bundle can be selected and via popup, the Services and Items can be selected if they have been provided to the patient. 

The first stage would be to create the modules (FE/BE) to define those bundle

Later stages (out of scope for this GSOC ) would be 

• To allow their assignation to an insurance product via “Complex claim products”

• To design checking & valuation rules for those bundle including possible conversion to standard claim item and product

• To ensure that those product are properly taken into account in the payment to health facilities

 Expected outcome

• “Bundle of Items and Services“ management module

Later stages (out of scope for this GSOC )

• Create Calculation rule to attach the “Bundle of Items and Services“ to  “Complex claim products”

• Create Calculation rule to check the “Bundle of Items and Services“ upon claim submission

• Create Calculation rule to valuate the “Bundle of Items and Services“ upon claim submission

• Update payment calculation rules to takes  “Bundle of Items and Services“ into account

Required skills 

Python3

Django Framework

Javascript

React