...
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 ?? |
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 ?? |
Access rights
A claim is attached to a location (HF)health facility. 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 locationshealth facilities.
Other IT systems integration
...
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.
Claim state diagram
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’ ‘pending’ ('virtual': database status remains on 'sublitted') 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 from any state by authorized users or (medical reviewer, rejecting each service/item with justification) or background processing.
Note: ‘Rejected’ can be is a ‘final’ state for a claim (in the sense that they will never cannot be modified to re-enter the processing flow).
- a rejected claim can not be modified (corrected) and cannot re-enter the processing flow
- the deleted status has been introduced to depict the result of the ‘delete’ action, but it is a ‘logical’ status (not database-persisted). When when deleting a claim:
- the actual record in 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 (really) deleted
- 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
...
Claim administrator:
- Enter claim
- Search (filter) claims
- Edit an existing claim
- Delete entered claim
- Reject (cancel) entered claim(s)
- Submit (pool of) claim(s)
...
- Collect feedback from 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
...
Beside mandatory and references checks (hf code/chfid/service ids/item ids/... exist), the claim entry service performs the following validations:
- Claim code is unique provided (it is not enforced by databasenot necessary unique!)
- Claim insuree is identified
- Claim main diagnosis is identified
- End date (if populated) is after start date
- Claimed amount is > 0At least a service or item is claimed
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’.
...
- 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)
...
Note:
Only claims in ‘Entered’ or ‘Rzjected’ status can be edited (further adaptations may occur when 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).
...
- 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 .
Notes:
...
by ejecting each of its services/items with justification.
Medical Officer can only reject claims with status submitted.
- This feature is also accessible from Claim review and feedback control UI (see below)
- When rejecting a claim via this feature, the reject reason is either set to
- -1 (i.e. “Rejected by a medical officer”) if user has medical officer role
- 18 (i.e. “N/A”) otherwize
Note: when rejecting a claim, openIMIS don't (automatically) alert the beneficiary (insuree).
...
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.
...
Same feature as from Claim entry control UI (see above)
...
)
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,...).
...
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.