This document summarizes the features in 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 Valuation Batch Processings | x | |||
| Claim operational report | x | |||
| NOT COVERED STEPS | Aggregate, merge and batch claims data Flag for fraud and abuse Update beneficiary(note: beneficiary = patient?) Claims status sent to provider, beneficiary and other appropriate authorities Explanation of Benefits sent to provider and/or beneficiary Timeliness of claims processing First time claim pass rate | Is this business process covered in current openIMIS at all ?? Batch processing for valuations. Not flagged as fraud, but services & items are rejected if they don't meet certain pre-defined conditions (defined during defining services/items) Once claims are submitted, immediate feedback is provided in terms of services/items rejected, claims processed etc. Detailed status can be viewed via reports. Can be done via Feedback app. Needs human intervention to go to beneficiary to ask questions. No - planning on adding these to analytics module (HISP India) | Is this business process covered in current openIMIS at all ?? |
A claim is attached to a location (HF). Besides role-based feature access control (cfr. 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 locations.
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 early stages of the new openIMIS platform. However, to respect the new architecture principles (and allow further platform evolution/refactorings), 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 will provide, 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.
The state diagram is mainly deduced from the claim processing explanation in the user guide, with some refinement/attention points:
Note: ‘Rejected’ can be a ‘final’ state for a claim (in the sense that they will never be modified to re-enter the processing flow).
These states are however not visible from (tracked by) openIMIS. It is up to the accounting system to retrieve (and keep track of) the claims to be paid and there is no feedback from these systems to openIMIS. Any problem during the payment (erroneous bank account, ...) must be managed from the external system.
Health Facilities staff
Receptionist:
Claim administrator:
Scheme administrator & district Staff
Enrolment Officer:
Clerck:
Medical Officer:
Accountant:
Other IT System (API calls)
The claim control feature provides a set of claim search capabilities.
It also gives access to the following features:
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 (non 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.
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).
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.
Beside mandatory and references checks (hf code/chfid/service ids/item ids/... exist), the claim entry service performs the following validations:
Invalid claims that can be saved to 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 (cfr. user manual):
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’ or ‘Rzjected’ status can be edited (further adaptations may occur when claim is reviewed)
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:
From the Claim entry control UI, (selected) claims can be deleted.
Notes:
From the Claim entry control UI, (selected) claims can be rejected.
Notes:
Medical Officer can only reject claims with status submitted.
Note: when rejecting a claim, openIMIS don't (automatically) alert the beneficiary (insuree).
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.
The claim review control provides:
It also gives access to the following features:
Bulk claim modification is dedicated to change to flag claims for review and/or feedback. It provides specific filter and sub-selection mechanism: claimed amount threshold, variance and , finally, random.
The claim review page is dedicated to adjust the claim’s medical services and items quantities and rejection status.
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 act on behalf of the enrolment officer and enter the feedback he received via another chanel.
Claims that are not selected for review or feedback can be moved into Processed status from the claim review and feedback control UI.
Same feature as from Claim entry control UI (see above)
Same feature as from Claim entry control UI (see above)
The claim valuation batch is dedicated to valuate the claims, according to insurance parameters (reimbursement rates,...).
Notes:
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 a BI platform.