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 | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2. Upcoming implementations | 3. Relevance for the global good | Composite Score | Potential for local development/ funding |
| 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.
| 4 | 7 | 9 | 20 | Split out:
| |||
| 8 | OSD - 57 | Interoperability between openIMIS instances | In scenarios where there are more than one scheme operator in a country, offering same/different benefit packages both using openIMIS for management of their respective schemes, it becomes necessary to ensure interoperability between these instances. Health facilities for eg. can not have two apps to register claims to different servers, or clients moving from one insurance scheme to another due to their job status should not need to register/enrol a second time. | 10 | 7 | 10 | 27 | May-be Nepal? | |||
| 9 | OSD - 58 | Linking claims of a person across different facilities for the same illness episode (referal cases) | openIMIS tracks claims related to an individual using the individual's identifier. In addition to the request to have the system track claims for an individual for an illness episode (OSD - 29), could the system also track referral chains so complete treatment chain can be observed in the dataset. This feature should allow a facility to know easily whether the patient was referred (currently this has to be entered manually - Other, referral and emergency drop down selected during claim submission) and from where, ideally also see the relevant case history from the referred facility and accordingly apply co-payments etc. according to the agreed business rules. Nepal has a similar need but not clear whether they have been able to automate this or whether they have a work around for this. | 4 | 2 | 5 | 11 | Potentially in cross-border approaches | |||
| 10 | OSD - 61 | SNOMED-CT compliance | To have compliance with multilingualism features according to SNOMED-CT Terminology and Coding for terms in openIMIS backend and frontend must support required structures and functions. This is an essential requirement for international usability and should be included in new releases. | 1 | 4? | 10 (Check with Digital Square, OpenHIE, other GGs) | 15 | Not yet explored | |||
| 11 | OSD - 62 | Alternate identification mechanisms | Currently identification in openIMIS includes a manual check against pictured stored in the database on the server. Can this be modularized to be able to replace this with other identification check mechanisms like for eg. using Biometric cards which some countries might have interest in like Cameroon currently. Can openIMIS plug into different identification systems and allow identification checks to be done on the side of the server, on the side of the local application/device , split across both as well the current approach where the check is manual but information needed (picture) to make the check is stored on the server. | 2 | 2 | 5 | 9 | ||||
| 12 | OSD - 63 | Enhancing enquiry feature | Can the Enquiry function (mobile app and online/offline application) used for checking identity and eligibility of clients when they arrive at a health facility be enhanced to deal with difficult implementation settings like limited internet availability and illiterate clients. In situations of limited internet can information be retrieved through other means like USSD for eg. Can more data be shared during enquiry to allow checking the individuals family in case illiterate clients bring their family members cards as they are unable to read the details on the insurance card. | ||||||||
| 13 | OSD - 64 | Integration with a Health Facility Client Register | |||||||||
| 14 | OSD - 65 | Integration with Patient record systems | Integration with openMRS and Bahmni currently underway. See service desk for progress: Integration with openMRS, with Bahmni | N/A | N/A | N/A | |||||
| 15 | OSD-93 | Link a policy to an insuree instead of a familly so a familly can be covered by policies from 2 members | Use case: 2 parents are working in two different company , imis can’t manage that (despite Jiri’s point of view), if you add that some insurance might cover the full family when other can concern only the worker it makes any workarround useless Discussions in issue queue. | ||||||||
| 16 | OSD-108 | Creation of service cases for claiming | Currently openIMIS supports the definition (and thereafter the claiming) of individual services and items. Many insurers would like to bundle some services and items as 'cases' - for eg. a surgery case can be a combination of a few individual services (including follow-up) and the drugs required during and after the surgery. It would be good to have the option of creating such packages by selecting the already defined services and items. The health facilities can claim for this 'case'. It makes it easy to review claims as automated checks for duplicate services/items (within case, and beyond) can be done. | 7 | N/A | N/A | 7 | ||||
| 17 | OSD-111 | Standardized claims justification during review | Currently, the justification field while reviewing a service or item in each claim is allowed to be free text. This creates an issue that even the same reason might be written in different ways by different claim reviewers, and could potentially create issues for providing coherent feedback to the health facilities for the reason of changes (reject, change of quantity) of services/items. Additionally, the difference in language could also create issues for the upcoming AI module for claims adjudication. Potential features solution: Justifications changed to a drop-down menu, with the items in drop down menu defined by claim reviews team of each implementation. Additionally, an 'other' option for free text could also be provided for ad-hoc feedback. | 9 | 9 | 7 | 35 | ||||