Google Summer of Code 2022
openIMIS: Improve openIMIS software
This page was created for your convenience. Please be aware that only the below link to the GIZ tender platform contains the most recent versions of the tender documents.
Organizer | https://openimis.atlassian.net/wiki/spaces/OP/pages/835682333 https://openimis.atlassian.net/wiki/spaces/OP/pages/835387396 |
---|---|
Type | Competition |
Weblink | |
Deadline | 2022-04-19 |
Status | Cancelled |
Projects | openIMIS: Improve openIMIS software |
Content
- 1 PROJECT: MODULE MANAGER
- 2 PROJECT: CHAT
- 3 PROJECT: NOTIFICATIONS
- 4 PROJECT: EXTENDING CALCULATION RULES
- 5 PROJECT: FHIR DEVELOPMENT
- 6 PROJECT: NEW MOBILE APPS
- 7 PROJECT: AUTOMATED TESTS IN SELENIUM
- 8 PROJECT: Simple Claim Workflow
- 9 PROJECT: FHIR Questionnaire attached to a Claim
- 10 PROJECT: Complex claim products
- 11 PROJECT: Bundle of Items and Services
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)
Set-up the project
Authenticate a user with openIMIS as backend (FHIR login)
at least once online, then local auth possible if not network
Retrieve the user preferences (language, locations, organization etc )
for offline usage
Location (Location)
HealthFacility (Organization)
Users (Practitioner ? OE and CA)
List
Product (InsurancePlan)
Pricing/limits ? TBC
items (Medications)
services (ActivityDefintion)
diagnosis (CodeSystem)
hard coded : claim type etc… CodeSytem
Saving data : Can the app use StructureDefinition ?
hold the extension (new properties etc)
hold constraints
Check insurance coverage based on insurance number
CoverageEligibility
Coverage
Enable the registration of a new insuree
Insuree : registration of a person in the system
Enable the update of an existing insuree
Insuree
Enable the enrollment of an insuree on a product (payment not included)
Enrollment into a product/policy (including payment): Contract
challenge: define the price offline (TBD)
Add beneficiary on a policy
create/update Insuree
add add the beneficiary on the contract
Register and submit new claims using items and services defined in openIMIS
claim and claimResponse (kind of async)
Challenge: high input density
manage pricelist (TBD)
items
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