This document summarizes the features in 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 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.

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 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.

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’ 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 background processing.

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

• a rejected claim can be modified (corrected) and 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 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
• the ‘Approved’ 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,...

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.

Actors and roles

Health Facilities staff

Receptionist:

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

Claim administrator:

• Enter claim
• 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 patient

Clerck:

• Enter claim
• Edit an existing claim
• Submit claim(s)
• Delete entered claim
• Reject (cancel) entered claim(s)

Medical Officer:

• Review claim
• 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
• List 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 (non 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/chfid/service ids/item ids/... exist), the claim entry service performs the following validations:

• Claim code is unique (it is not enforced by database!)
• End date (if populated) is after start date
• Claimed amount is > 0

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

• 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.
• 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’ or ‘Rzjected’ status can be edited (further adaptations may occur when claim is reviewed)

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

(Bulk) Reject claim(s)

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

Notes:

• HF Claim administrator and District Clerk can only reject claims with status entered.

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

(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
• (Bluk)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 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.

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 on behalf of the enrolment officer and enter the feedback he received via another chanel.

(Bluk)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)

(Bulk) Reject claim(s)

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

Claim Valuation Batch Processings

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 business user, with a dedicated UI (cfr. 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 a BI platform.