This document summarizes the features in the scope of the 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:


JLN Process - Claims processing

JLN Process - Claims status inquiry

JLN Process - Claims dispute and appeals

JLN Process - Claims adjustment and voids

Claim control (overview)

x

x



Verify patient data

x




Enter (new) claim

x




Edit claim

x




Print claim

x




(Bulk) Delete claim(s)

x




(Bulk) Reject claim(s)

x




(Bulk) Submit claim(s)

x




Claim review and feedback control (overview)

x




Bulk claim modifications

x




Review claim

x




Enter claim feedback

x




(Bluk)Move claim(s) to Processed status

x




(Bulk) Delete claim(s)

x




(Bulk) Reject claim(s)

x




Claim (final) Batch Valuation 

x




Claim operational report

x









NOT COVERED STEPS


Flag for fraud and abuse

Note: there are some checks which lead to a direct rejection of a claim between enter and checked status, some of rejection criteria could be seen as fraud/abuse detection


Update beneficiary

Note: beneficiary details are modifiable after enrolment and activation of a policy. In openIMIS  beneficiary update and claim management are 2 isolated processes


Claims status sent to provider, beneficiary and other appropriate authorities

Note: Reports are generated for Health Facilities (but not beneficiaries), there are also reports per products ... and products are per location (region/district)

Explanation of Benefits sent to provider and/or beneficiary

Timeliness of claims processing & First-time claim pass rate

Note: could be calculated from DB (DB maintains a complete timestamped history of each claim processing)




Is this business process covered in current openIMIS at all ??




Is this business process covered in current openIMIS at all ??


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

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

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

Actors and roles

Health Facilities staff

Receptionist:

Claim administrator:


Scheme administrator & district Staff

Enrolment Officer:

Clerck:

Medical Officer:

Accountant:


Other IT System (API calls)


Claim control (overview)

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

It also gives access to the following features:

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:

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:

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):

… 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:

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:

(Bulk) Delete claim(s)

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

Notes:

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:

It also gives access to the following features:

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:

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:

Claim list can be filtered by:


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.