Demo Script

The script below provides guidance for demonstrating openIMIS to a prospective new user (health insurer). Depending on time available for the demonstration, decide beforehand what aspects to describe through visuals and what aspects to show on the live system. Reference to Login IDs are for the demo server. To view explanation of fields and how to navigate specific pages please refer to the user manual.

The description of the system for a Health insurance implementation can be done as described below. An offline version of the demo (slides with screenshots) is provided at the end of this script.

1.Provide an overview of the data flow

                                            

Points to cover:

  • Centralized server where application resides

  • Offline application installed on computers - They are not a replacement for the online application but complements it by enabling entry of new enrolments and submission of claims for insurance staff and health facility respectively to ensure activities do not stop due to internet outages.

  • Mobile phone application - Used by enrolment agents to undertake enrolments, renewals and feedback collection and by health facility staff to undertake client identification and claims submission.

  • Data synchronization - Stored data from the offline application installed on a computer as well from the mobile phone application when used offline, can be extracted, physically transported to a location where internet is available and then uploaded to the online application.

  • Access to the system - Each person is given a user account linked to a role and a location based on which they get access to the system to undertake the tasks that they are authorized to do.



2. Describe how a scheme is constructed (configuration of registers)

                                         

Points to cover:

Either use the already created list of registers for the demonstration or create case specific registers (eg. create district or service package that is relevant to the insurer you are demonstrating to) before hand. If time permits then do so during the demonstration and create them in the order as described below (i.e. Location first and Product last). Login to the application with the provided account on the login page. You can also create your own user accounts which logs in with a familiar name and location but ensure the right roles (admin in this case) and locations allocation that you wish to demonstrate.

  • Creations of Locations - Configured to indicate geographical coverage of the scheme and allocate appropriate access to different users in the system. Currently there can be up to four sub levels defined to indicate geographical boundaries (for eg. Regional -> District -> Municipality -> Village).

  • Payers - Configured to indicate a 3rd party payer who would pay the due policy amount on behalf of an insured unit.

  • Claims administrator - The personnel responsible at a health facility who is authorized to submit claims on behalf of the health facility.

  • Enrolment Officers - The personnel (enrolment officer/agent) responsible for enroling and renewing families/enrolled units.

  • Users - Different actors involved in processing data of the insurance scheme are configured here. All users created are given a location and a role according to the function they need to perform in the system.

  • Medical Items - A list of all possible medical items covered by the scheme are configured. These form the basis of establishing facility specific price lists.

  • Medical Services - A list of all possible service packages covered by the scheme are configured. These form the basis of establishing a facility specific or facility type/group specific price lists.

  • Price Lists (Medical Service and Medical Items) - A facility specific list of medical services and items are configured. These could be a price list offered by one facility or a type of facilities (eg. all dispensaries) or a groups of facilities (eg. all government facilities). These are based on the price lists negotiated by the insurance scheme.

  • Health Facilities - A list of contracted health facilities can be configured. These include all different levels of facilities (primary, secondary or tertiary levels) as well the link to respective price lists agreed with the insurance scheme.

  • Products - A list of all insurance products on offer by the health insurer can be configured. The product includes the conditions it applies to the customer as well as to the health facility. These include different provider payment mechanisms (eg. capitation with adjusters, fee for service, service packages, etc.) and limits like ceilings per event, per individual or per family as well co payments etc. A health insurer can have one or multiple products and can offer it either in all locations or restrict them by location.





3. Describe how operations are handled structured by key processes

3.a. Enrolment Process

Points to cover:

  • Describe a standard process first which might go beyond the use of openIMIS. This helps visualize and understand where openIMIS fits in the process. If you have an idea then ideally try to tailor this to the actual process that is followed by the insurer who you are demonstrating the system to.

  • Demonstrate the use of the web application and/or the mobile application and show how a family/unit can be enrolled. This is done in the sequence of first entering the head of household, then building the family roster, then adding a Policy to the family and thereafter adding a Contribution against the policy to make the coverage active.

Using web application

  • Login to the application with the provided account on the login page. You can also create your own user accounts which logs in with a familiar name and location but ensure the right roles and locations allocation that you wish to demonstrate.

  • Start with addition of the head of the household/unit to be enrolled (Insurees and Policies → Add Family/Group). To reduce the demonstration time focus mainly on mandatory fields but in case specific data entry needs exist then ensure they are also covered (eg. if poverty status is captured by the insurer then cover this field). Keep track of the unique Insurance Number and the location in case you want to use the same example for subsequent processes.

  • Once household head is saved start building the rest of the family by adding one person at a time (Insurees). Depending on time decide how many members you want to add.

  • Add a policy to the family (Policies) and indicate an Enrolment date in the past to ensure the product configured was valid by this date (if not the product will not show in the drop down) and that if you use an individual from this family to demonstrate claim submission later then the claim date should be after the Start Date of the policy.

  • Add a contribution (one or multiple payments) against the policy (Contributions) and ensure the total payment matches the policy value in order to make the policy "Active".

Using mobile application

  • Login to the app as an Enrolment Officer (EO code: E00005, Login name: E00005, Password: E00005E00005)

  • Start with capturing the picture of all members of the household against their allocated individual unique insurance IDs. Start with the head of the household/unit to be enrolled (Menu → Acquire). Keep track of the unique Insurance Number of each person.

  • Capture data of each person starting with the head of the household (Menu → Enrol → +). To reduce the demonstration time focus mainly on mandatory fields but in case specific data entry needs exist then ensure they are also covered (eg. if poverty status is captured by the insurer then cover this field). Keep track of the unique Insurance Number and the location in case you want to use the same example for subsequent processes.

  • Once household head is saved start building the rest of the family by adding one person at a time ("+" symbol). Depending on time decide how many members you want to add.

  • Add a policy to the family (Policy → +) and indicate an Enrolment date in the past to ensure the product configured was valid by this date (if not the product will not show in the drop down) and that if you use an individual from this family to demonstrate claim submission later then the claim date should be after the Start Date of the policy.

  • Add a contribution (one or multiple payments) against the policy (3 vertical dots → Payment → +) and ensure the total payment matches the policy value in order to make the policy "Active".

  • Upload the enrolled family to the web application (Menu → Synchronize → Upload Enrolments) using the login credentials of the Enrolment Officer given above.



3.b. Health service utilization

Points to cover:

  • Describe a standard process first which might go beyond the use of openIMIS. This helps visualize and understand where openIMIS fits in the process. If you have an idea then ideally try to tailor this to the actual process that is followed by the insurer who you are demonstrating the system to.

  • Demonstrate the use of the web application and/or the mobile application and show how an individual with an insurance number can be inquired to establish the persons identity and eligibility.

Using web application

  • Login to the application with the provided account on the login page or the account you created.

  • Enter the individuals Insurance Number in the Search Insurance Number field (top right of the page) to get the picture and eligibility details of the individual. For demonstration use an existing case in the system (eg. 174000002).

Using mobile application

  • Login to the app as an Enrolment Officer (EO code: E00005, Login name: E00005, Password: E00005E00005)

  • Enquire (Menu → Enquire) the individual by either scanning the Insurance Number of the individual or typing it directly in the app. For demonstration use an existing case in the system (eg. 174000002).



3.c. Claims process

Points to cover:

  • Describe a standard process first which might go beyond the use of openIMIS. This helps visualize and understand where openIMIS fits in the process. If you have an idea then ideally try to tailor this to the actual process that is followed by the insurer who you are demonstrating the system to.

  • Demonstrate the use of the web application and/or the mobile application and show how a claim for an eligible person is submitted and processed in the system. Undertake the demonstration in the sequence of - entering a claim which is then passed through automatic checks in the system (as per configuration of registers),  then through a reviewer (review and/or feedback) and lastly processed as a batch of claims over a period of time.

Using web application

  • Login to the application with the provided account on the login page. You can also create your own user accounts which logs in with a familiar name and location but ensure the right roles, location and health facility affiliation that you wish to demonstrate.

  • Start (Claims → Health Facility Claims) with selection of the facility for which the claim will be registered for and by whom (Claim administrator). For eg. use: Region → Ultha, District → Rapta, HF Code: RAHOS001 (Rapta District Hospital), Claim Admin Code: RHOS0011 (Rijo Lawrence)

  • Enter a claim for an individual who already has an active policy in the system. Start with the individuals Insurance Number (till you see the valid name pop up), use a unique Claim ID no. (that does not already exist in the system) and subsequently details on the treatment including dates, diagnosis, service and items provided, etc. To reduce the demonstration time focus mainly on mandatory fields (in red) but in case specific data entry needs exist then ensure they are also covered (eg. if multiple diagnosis are reported to be usually captured then cover this field). Ensure that the Visit dates are within the period when the individuals policy is Active. Keep track of the unique Insurance Number and Claim ID given to the claim in case you want to use the same example for demonstrating subsequent stages of the claims processing. Once the claim is Saved it goes into the Entered state.

  • The claim is then Submit to openIMIS (go back to Claims → Health Facility Claims → Claim No. [search the Claim No. you gave to the claim]) for undertaking the automatic check by the system as per the configuration of the product and other configuration of services and items that were done during the configuration of registers. The system after the check gives a summary and then moves the claim either to Rejected or Checked state.

  • After the automatic check a reviewer then can make an additional check for inconsistent claims (Claims → Review → Select Criteria). Select the filters for location and health facility for which the claim has to be demonstrated and set Claim Status to Checked to get the claim you moved to this state or other filters to demonstrate ways in which a reviewer can look at claims that have passed through the automatic checking of the system.

  • The list of claims can be very large and the reviewer can hence further filter out (Claim Selection Update) a sample of these claims if they wish, by setting the Criteria Details to Review select and Update based on a Random selection of say 100% (in order to choose all claims). You can also use other filters but ensure you have claims in the system that fit your filtering criteria. Alternatively claims can be manually also selected for review (Claims Found → Review column → Idle status changed to Selected for Review → Update button). The Review Status (Claims Found → Review column) of chosen claims will indicate Selected for review at which point the reviewer can review this claim in detail (Claims Found → Review button) and demonstrate whether any partial rejections (eg. changing applied quantity of a drug App. Qty.) or so are made with reasons (Justification) or the claim is accepted and review is completed (Reviewed). The claim is now reviewed by the reviewer and its status is updated to Reviewed (Claims Found → Review column).

  • The reviewer can also request a feedback at this stage (through the Enrolment Officer responsible for registering the family to which the individual belongs to) from the individual whose claim is under review by selecting the claim for feedback (Claim Selection Update → Criteria Details → Feedback select). Demonstrate the selection of claims for feedback again either using the given parameters (Random, Value or Variance) or manually select the claim for review collection (Claims Found → Feedback Column → Idle status changed to Select for Feedback → Update button). If no claim is selected for review either select selection of 0% of claims under the Random selection criteria (Claim Selection Update → Criteria Details → Feedback Select) or manually select status of claim to Not Selected (Claims Found → Feedback column → Idle changed to Not Selected).

  • After the claims are processed by the reviewer in terms of reviewing it and requesting feedback the claim can be processed further. Claims that have not gone through both the review and feedback filtering steps as mentioned above can not be processed to the next stage. So ensure the claims you want to demonstrate and move to the next stage have either gone through both filtering steps or (also to save time) bypassed from review or feedback selection by indicating a random selection of 0% which automatically update the status of the claim to Not Selected both for review and feedback collection.

  • The claim can now be moved to the Valuated state which indicates that the final evaluation of each individual claim is completed (Claims Found → Claim Status → tick box → Process).

  • If needed, demonstrate the rejected claims by selecting the filter Claim Status to Rejected (Claims → Review → Claim Details → Claim Status) and reviewing the claim (Claims Found → Review button) to understand the reason for rejection through Rejection Codes (Services → R). The explanation of the codes are provided in the User Manual here (scroll down to Rejection Reason).

  • The last stage of the claim processing is the collective or batch processing of claims (Claims → Batch Run) for a given period of time which the accounting personnel can then use to remit payments to respective health facilities. A batch is run after a period when all claims have been individually processed and taken through to the Valuated or Rejected state. Any claims submitted that are still before these two stage will not be part of the batch calculations and will automatically get shifted to the processing of the subsequent time frame. Demonstrate the processing (Batch Processing) of the batch for a location and time period that you have data for (Batch Processing → Process button).

  • Once processed the Accounts personnel can view or print batch reports (Filter for Accounts → Group By → HF → Show Claims) according to different filtering criteria and accordingly remit payments to respective health facilities. This completes the processing of claims in openIMIS.

Using mobile application

  • Mobile application is only used for claims submission and rest of the processing on the insurance scheme side is undertaking on the web application (as per the description above)

  • Demonstrate the Claims app using the facility and Claims Administrator details you wish to demonstrate. You can either create your own account or use HF Code: RAHOS001 (Rapta District Hospital), Claim Admin Code: RHOS0011 (Rijo Lawrence). Login name: RHOS0011 Password: RHOS0011

  • Start with capturing details of the facility entering the claim and then proceed to adding details of the claim like diagnosis, dates of visit, etc. For eg. enter the same date for Visit Date To & Visit Date From, but ensure that on this date the individuals policy is active.

  • At the bottom of the screen select Add Services and Add Items to add specific services or items (search with code or name and once found click Add) prescribed to the individual receiving the treatment. The quantity of the item or service can be adjusted while prices if already set will be displayed automatically and dont need to be adjusted. For eg. add Service: A1 Consultation - I unit, Item: 0176 ORAL REHYDRATION SALTS (ORS) FOR 1 LITRE POWDER - 2 Unit

  • After adding all prescribed items and services, Post the Claim so the claim is saved and ready to be uploaded to the web application.

  • To upload the claim to the web application (Menu → Synchronize → Upload Claims) using the login credentials of the Claim Administrator that you have created (if using the account given above use Claim Admin Login ID: rijo, Claim Admin Login password: rijo2019).



3.d. Renewal Process

Points to cover:

  • Describe a standard process first which might go beyond the use of openIMIS. This helps visualize and understand where openIMIS fits in the process. If you have an idea then ideally try to tailor this to the actual process that is followed by the insurer who you are demonstrating the system to.

  • Demonstrate the use of the web application and/or the mobile application and show how a renewal is triggered in the system and then followed up and completed by an enrolment officer. Undertake the demonstration in the sequence of - generating a list of renewals from the web to explain paper based process, undertaking a renewal from the web application and then using the mobile application undertake a renewal by the enrolment officer.

Using web application

  • Login to the application with the provided account on the login page. You can also create your own user accounts which logs in with a familiar name and location but ensure the right roles, location and health facility affiliation that you wish to demonstrate.

  • To demonstrate a use case you will need to have created a household before that is due for renewal in the next 14 days (this is the current period set in the system) and you will also need to login to the mobile application with the credentials of the enrolment officer responsible for the enrolment of this family. Create this case few days earlier (at least one day before you do the demonstration) as the renewal service (i.e. the check in the database for expiring policies in the given period and accordingly sending respective information to the mobile application of respective enrolment officer) is currently set to run once a day.

  • Generate the list of renewals (Tools → Policy Renewals) by selecting the appropriate location (Region, District, Municipality, Village) and Enrolment Officer for the period (Date From and Date To) you want to generate the list for (Preview).

  • Once generated demonstrate how to save (button that looks like a floppy disk) and print the list of renewals. Thereafter explain the manual process that is undertaken to get the list to the enrolment officer and subsequently how the renewal is done using the mobile application.

  • To demonstrate how a renewal is done from the web application first identify the family (Insurees and Policies → Insurees) to be renewed in the system by using the ID number (enter Insurance Number then click on Search) of any person in the family.

  • Once the family is found view the family (Insurees Found → click on Insurance Number) and select the policy that has to be renewed (Policies) and then click on R button to renew the policy by entering the Policy Details (Enrolment Date, Enrolment Officer, etc.).

  • To activate the renewed policy select the policy and then add a payment against it (as described under Enrolment process). Once the payment is completed and matches the policy value the policy will be in Active state.

Using mobile application

  • Login to the app as an Enrolment Officer for which you would like to demonstrate the renewal case for.

  • Go to the list of pending renewals (Menu → Renewal), where you will have a list of pending renewals that the enrolment officer has to follow up on.

  • Select the respective case you wish to demonstrate and renewal that family after entering the payment details.

  • Upload the renewals undertaken by the enrolment officer to the web application (Menu → Synchronize → Upload Renewals) using the login credentials of the Enrolment Officer that you have created.



4. Describe reporting possibilities

Points to cover:

  • Describe reporting possibilities from the web application as - standard reports available through the web interface of openIMIS and on demand reports available through the AR IMIS tool that is accessed say by Excel.

  • To demonstrate the standard report (Tools → Reports) choose the report you would like to generate by applying appropriate filters any report you would like to show (Preview) and subsequently save (button that looks like a floppy disk) or print it.

  • To demonstrate AR IMIS have your excel file opened on the side that is already opened a connection with AR IMIS (pivot table connected to external analysis service where AR IMIS resides) and demonstrate the cube for a fact (data) across the various dimensions available in the report.



Offline Demonstration

In case you are unable to demonstrate using the demo server due to non availability or poor connectivity to the internet. A slide deck is provided here on lines of the given demo script to demonstrate the system using slides containing screen shots.





Did you encounter a problem or do you have a suggestion?

Please contact our Service Desk



This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-sa/4.0/