New feature requests prioritization



Outdated content

This page is no longer maintained and will be archived very soon. It was replaced by this one: Incubator Prioritization



Rating scale: 1-10, with 1 being low and 10 being high

S.No.

Issue queue reference

Feature requested

Summary of description

IC Prioritization

DC Prioritization

  1. Relevance for existing user organizations

2. Upcoming implementations

3. Relevance for the global good

Composite Score

Potential for local development/ funding

  1. FTE estimates vs. existing team composition

2.  Budget

3. Low hanging fruit

1

OSD - 26

Options for using internally and externally generated IDs

openIMIS currently only checks for uniqueness (as per programmed country need) of an externally generated ID number. There can be scenarios where it might be important for openIMIS to internally generate unique ID numbers or a scenario where there is a combination of both (internally and externally generated).

10

For Nepal, Tanzania, Chad

8

potentially high relevance

5

(South Africa: motivation to generate a unique health id)

(Thailand, South Korea, Taiwan use citizen number. Phillippines everybody gets a philhealth number after registering. People forget numbers.)

23

Promote idea to develop this in-country. May-be during transition of enrolment module.







2

OSD - 29

Management of illness episodes

Similar to HL7: "Episode of Care"



openIMIS currently is unable to link different claim events under an illness episode. Illness episode is an important entity to have in order to be able to offer products which have claim payments tied to illness episodes (which might consist more than one claim from the same or different facilities).

4

(Nepal and TZ not as a priority)

10

10

24

(CHAD project - product has been reviewed, such a co-payment will not be continued and hence this will not be developed in the country context)







3

OSD - 32

Progressive web application

In different country contexts at health facility level there are different systems running for different tasks and programmes/projects. Instead of providing new hardware (phones or tablets or computers) to each programme can openIMIS be developed in a way that it can run on a variety of hardware depending on what is available at the facility? This will significantly reduce the implementation costs for openIMIS and make the system hardware independent.

7

10

10

27

It has impact on implementation costs, and would be a good argument for oI in any country







4

OSD - 39

Claims management without enrolment

Can claims be entered in openIMIS without undertaking an enrolment of the individual (entering amount and policy allocation) which currently needs to happen as claims can not be entered for an individual that does not exist in openIMIS.

0

10

10

20

4







5

OSD - 45

Additional feedback to be provided on Enrolment app

Currently the openIMIS app for Enrolment officers/Agents gives counts as feedback to the user after they have undertaken their task (policies, payments and individuals, families enrolled etc.). Request was to add some additional information to give more informative feedback to the Enrolment Officer/Agent for eg. name of household head (but at the same time ensuring from a privacy point of view the additional data should be minimal).

2

2

5

9

No







6

OSD - 50

Pre - authorization process

Some schemes require that a health facility requests a pre-authorization of a treatment from the insurer before they administer it to the client in order to have the assurance that the costs will be covered. For eg. expensive treatments like certain type of heart surgeries might require a pre-authorization request to be approved by the insurer (including indication of amount to be blocked from the patients ceiling) before the hospital undertakes the surgery. Request is derived from Service Desk issue reported by users in Egypt captured in OSD - 42

0

0

0

0

At the moment, this is out of scope of openIMIS as normally benefit packages are pre defined etc. Might become relevant again when looking at formal sector.



18.11.2020: Very common feature in commercial insurance. 

Best if it is modular. 



Parameterize every service  to require this or not?



no immediate need in Nepal right now



Potential to look at some 'quick fixes' if required.







7

OSD - 51

Client Portal

Currently an insured client or a potential new client can not interact directly with openIMIS.
The different use cases for interaction with openIMIS are:

  • Viewing personal information on the platform (claims history, etc.) and indicating preferences (reminders for renewals, privacy preferences, etc.), submit claims (reimbursement)

  • Viewing eligibility in terms of benefits covered by insurance policy as well as remaining benefits when ceilings/limitations exist

  • Providing feedback to insurance scheme (whether on facilities or insurance staff

  • Viewing products on offer and potentially self registering for an insurance policy

  • Self renewing once policy is close to expiring or expired

4

7

9



20

Split out:

  1. Low hanging fruit as giving people access to data in one direction

  2. Feedback loop

  3. Self-registration







8

OSD - 57

Interoperability between openIM