This document summarizes the features in the scope of the Claim module.

• it naturally references the current openIMIS documentation (the Web application user guide)

• provides some refinements deduced from current code readings

• lists taken hypothesis (whenever ambiguity or incomplete description was encountered) and attention points for the new claim module

The claim module supports several Business Processes, documented in Background - Joint Learning Network for UHC (claim management section).

The following table summarizes which features are in use in which Business Process:

Access rights

A claim is attached to a health facility. Besides role-based feature access control (cf. Actors and Roles here below), all claim management actions (entering, submitting,...) are limited by user’s location(s) scope: users can only access/manage claims related to his registered health facilities.

Other IT systems integration

openIMIS claim processing doesn’t include the accounting part (effective payment of the claim).

Today, the integration with the various accounting platform is performed via the database layer (either direct access or ETL flow). This integration mechanism will remain available in the early stages of the new openIMIS platform. However, to respect the new architecture principles (and allow further platform evolution/refactoring), this integration mechanism will be migrated to a (coded) batch extract or (new) API implementation. The batch extract and/or API are however not part of the initial scope of the claim module.

The new openIMIS platform provides, from the start, a FHIR-compatible API for the claims. This API is implemented in a dedicated (distinct) module. However, to ensure business logic coherence, that module relies on the services provided by the here-described claim module.

Claim state diagram

Open

The state diagram is mainly deduced from the claim processing explanation in the user guide, with some refinement/attention points:

• a claim selected for review of feedback has a ‘main’ status of ‘pending’ ('virtual': database status remains on 'submitted') and two sub-status related to the review and/or feedback flows. The ‘pending’ status is a ‘logical’ (not database-persisted) status, indicating that there is an undergoing review/feedback flow for the claim.

• a claim can be rejected by authorized users (medical reviewer, rejecting each service/item with justification) or background processing.

Note: ‘Rejected’ is a ‘final’ state for a claim (in the sense that they cannot be modified to re-enter the processing flow).

• a rejected claim can not be modified (corrected) and cannot re-enter the processing flow

• when deleting a claim:

•  

  • the actual record in the database is duplicated (technical ID changes so all exiting FKs are checked/cascaded)

  • that new record is updated with ValidityFrom and ValidityTo = now

  • the initial record (with the ‘old’ technical id) is not deleted, as a result, the claim is still in the database but not shown to user / in reports /... anymore 

• the ‘Valuated’ state is final in openIMIS. In reality, the claim lifecycle is not finished: the claim is then transferred to the accounting for payment, then paid,...

Actors and roles

Health Facilities staff

Receptionist:

• Verifies patient data and issues a (printed) claim form

Claim administrator:

• Enter claim

• Search (filter) claims

• Edit an existing claim

• Delete entered claim

• Reject (cancel) entered claim(s)

• Submit (pool of) claim(s)

Scheme administrator & district Staff

Enrolment Officer:

• Collect feedback from the patient

Clerck:

• Enter claim

• Search (filter) claims

• Edit an existing claim

• Submit claim(s)

• Delete entered claim

• Reject (cancel) entered claim(s)

Medical Officer:

• Search (filter) claims

• Review claim (incl. adapting the number and price of items/services reimbursed)

• Acting on behalf of Enrolment Officer, enter feedback on claims

• Reject (cancel) submitted claim(s)

• Delete entered claim

Accountant:

• Triggers (/schedule/monitor) claim valuation batch

• Presents claims operational report

• Record management/health insurance administrator decisions (approvals or not)

Other IT System (API calls)

• Enter/Submit claims

• Query eligibility service >> moved to Policies module

• List (query status for) claims

Claim control (overview)

The claim control feature provides a set of claim search capabilities.

It also gives access to the following features:

• Enter (new) claim

• Edit (existing) claim

• (bulk) Submit claim(s)

• (bulk) Reject claim(s)

• (bulk)Delete claim(s)

Claim Entry Features

Verify patient data

Patient data verification (membership,...) is performed by the HF receptionist, prior to any claim entry (by HF claim administrator or District clerk).

The verification extends beyond openIMIS software (identity document,...).

Within openIMIS scope, several checks are performed using other openIMIS modules (Insurees and Policies).

The only check to be performed within the claim module is dedicated to prevent (as much as possible) claim double entry. This requires the ability to search (without deleted, but including rejected) claims on insurance number, combined (or not) with:

• Location (region/district/hf)

• Visit date interval (claim with visit date from / to overlapping with indicated date interval)

This feature is however not provided in isolation: the HF receptionist access the more generic claim entry control feature (see below), with no rights to perform claim entry, modification,...

Note: The claim forms are not printed from openIMIS claim module. The receptionists receive them printed from a central printer.

Enter (new) claim

Claims can be entered by end-users or other IT systems.

End users enter the claims via the claim entry UI. Other IT systems use the (FHIR) API to enter (and submit) claim.

Both entry/submit routes make use of the same claim entry and claim submit services (implemented in this claim module).

Claim entry UI

The claim entry form allows user to enter claim details, (medical) services and (medical) items.

Some form-related verifications (mandatory fields, field lengths,...) are performed prior to enable save action.

Save action triggers the claim entry service.

Claim entry service

Beside mandatory and references checks (hf code/insuree number/service ids/item ids/... exist), the claim entry service performs the following validations:

• Claim code is provided (not necessarily unique!)

• Claim insuree is identified

• Claim main diagnosis is identified

• End date (if populated) is after start date

• At least a service or item is claimed

Invalid claims that can be saved to the database (i.e. has all mandatory fields, fields are in an appropriate format,...) are saved with status ‘Rejected’.

The service returns an error for invalid claims that can’t be saved to the database.

The service also performs (automates) the review checks (cf. user manual):

• 1: Item/Service not in the registers of medical items/services

• 2: Item/Service not in the price lists associated with the health facility

• 3: Item/Service is not covered by an active policy of the patient

• …

• 17: Item/service cannot be covered within waiting period

• 18: N/A -- not used by this service --

• 19: Maximum number of antenatal contacts exceeded

… but these checks don’t lead to claim (as a whole) rejection: only the related medical item/service is rejected.

Yet if all items and services are rejected, the claim (as a whole) is marked as rejected.

Notes:

• to perform these checks, the claim entry service relies on the eligibility service, also called from the FHIR API for claims module.

• this UI gives access to the Print claim feature (see below)

Edit claim

Claims are edited via the exact same UI as the Enter (new) claim UI, using the same validations and calling the same entry service.

Note: Only claims in ‘Entered’ status can be edited (further adaptations may occur when the claim is reviewed, feedback provided)

Print claim

A claim can be printed from the claim entering/editing UI. It makes use of the standard browser print dialog (or file to print download).

Limitations:

• There is no ‘bulk’ print of claims: printing is a ‘one by one’ feature

• There is no predefined printer (tray, print options) routing mechanism

(Bulk) Delete claim(s)

From the Claim entry control UI, (selected) claims can be deleted.

Notes:

• Claims are not really deleted (see state diagram Deleted status).

• This feature is also accessible from Claim review and feedback control UI (see below)

Reject claim(s)

From the Claim entry control UI, (selected) claims can be rejected by ejecting each of its services/items with justification.

Medical Officer can only reject claims with status submitted.

Note: when rejecting a claim, openIMIS don't (automatically) alert the beneficiary (insuree).

(Bulk) Submit claim(s)

From the Claim entry control UI, (selected) claims with status entered (only) can be submitted.

The service used to submit claims is also made available to the FHIR API for claims module.

Claim Review & Feedback Features

Claim review and feedback control (overview)

The claim review control provides:

• a set of claim search capabilities

• a “claim selection update capability”, allowing bulk modifications on (selected) claims

It also gives access to the following features:

• (Bulk) Select claim(s) for review

• (Bulk) Select claim(s) for feedback

• Review claim

• Enter claim feedback

• (Bulk) Move claim(s) to Processed status

• (Bulk) Delete claim(s)

• (Bulk) Reject claim(s)

Bulk claim modifications

Bulk claim modification is dedicated to change to flag claims for review and/or feedback. It provides a specific filter and sub-selection mechanism: claimed amount threshold, variance and, finally, random.

Review claim

The claim review page is dedicated to adjust the claim’s medical services and items quantities and rejection status (and reason).

Enter claim feedback

The claim feedback page is dedicated to provide expected feedback on identified claims.

Note: the feedback is collected by the enrolment officer, who may not have access to the system. In that case, the medical officer acts on behalf of the enrolment officer and enter the feedback he received via another channel.

(Bulk) Move claim(s) to Processed status

Claims that are not selected for review or feedback can be moved into Processed status from the claim review and feedback control UI.

(Bulk) Delete claim(s)

Same feature as from Claim entry control UI (see above)

Claim Batch (final) Valuation

The claim valuation batch is dedicated to valuate the claims, according to insurance parameters (reimbursement rates,...).

Notes:

• As described in user manual, when there is no “relative” price (according to the corresponding insurance product), the claim is immediately valuated once in Processed status. Both types of valuations are performed by a shared service (implemented in this module).

• This batch is a ‘business’ batch (as opposed to technical batches), and even though it runs via the batch platform, its triggering (scheduling,...) is managed by a business user, with a dedicated UI (cf. Batch Run control Page)

Claim operational report

The Claim operational report is a dashboard (which can be printed) dedicated to present claims decisions overview to the management of a health insurance administrator.

The dashboard presents:

• summarized amounts (claimed/adjusted/paid amounts).

• list of claims

Claim list can be filtered by:

• location (any level)

• claimed medical service/item

From the dashboard, the user can register the management decision (Reject / Approve), individually (claim by claim) or bulk (based on filtering).

Note:

This is the only (operational) report provided by the claim module. All other (analytics) reports are generated from the Reports menu entry or a BI platform.