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
...
| 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 ?? |
...
A claim is attached to a health facility. Besides role-based feature access control (cfrcf. 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.
...
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/refactoringsrefactoring), this integration mechanism will be migrated to a (coded) batch extract or (new) api API implementation. The batch extract and/or api 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 API for the claims. This api 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’ ('virtual': database status remains on 'sublittedsubmitted') 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 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,...
...
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)
...
Claim control (overview)
The claim control feature provides a set of claim search capabilities.
...
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 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.
...
Claims can be entered by end-users or other IT systems.
End users enter the claims via the the claim entry UI. Other IT systems use the (fhirFHIR) api 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.
...
Beside mandatory and references checks (hf code/chfidinsuree number/service ids/item ids/... exist), the claim entry service performs the following validations:
- Claim code is provided (not necessary 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 also performs (automates) the review checks (cfrcf. 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
...
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 FHIR API for claims module.
- this UI gives access to the Print claim feature (see below)
...
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)
...
- There is no ‘bulk’ print of claims: printing is a ‘one by one’ feature
- There is no predified predefined printer (, tray, print options) routing mechanism
...
The service used to submit claims is also made available to the fhir api 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
...
- (Bulk) Select claim(s) for review
- (Bulk) Select claim(s) for feedback
- Review claim
- Enter claim feedback
- (BlukBulk) Move claim(s) to Processed status
- (Bulk) Delete claim(s)
- (Bulk) Reject claim(s)
...
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 act acts on behalf of the enrolment officer and enter the feedback he received via another chanelchannel.
(
...
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.
...
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 (cfrcf. Batch Run control Page)
Claim operational report
...