Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 systemsystem (eg. 070707070). Start with the individuals Insurance Number (wait 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). To save time bypass the feedback selection by selecting 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 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. To save time either skip this step and end the claims process (after providing the description of this step) and if there is time then show a batch run.
  • 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.


3.d. Renewal & Feedback Process

Points to cover:

  • Generally it helps to give context of how a process flows and where the system fits in so ideally describe a process first and then demonstrate the use of openIMIS for supporting this process.
  • It takes too long to show both the web application and the phone application so the suggestion would be to show only the mobile application (but prepare it beforehand) using a household that already has a policy that is ready for renewal.
  • You could also just use slides to demonstrate this process to give time to claims process to demonstrate and cover renewal and feedback through slides.

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.
  • To save time instead of demonstrating just described the process in the same way as renewal process is described.


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 save time suggestion would be to use slides with screen shots and otherwise demonstrate the standard report (Tools → Reports)