An EDI (Electronic Data Interchange) feature to load encrypted claims files sent by providers.

Claims received thru this platform will be instantly processed (and awarded per inbuilt rules) unless otherwise indicated for human intervention.

EDI file decryption is done with a password chosen by the provider.

A simple claim-capturing interface with controls to minimize user capturing errors.

Amount to award is calculated and allocated by the system, shortfalling if benefits are no longer available.

Claims can be automatically rejected for different duplication scenarios.

User is given limited options to change the benefit allocation from a sub-list of applicable benefits, but the system automatically selects the most appropriate one.

ICD-10 codes are pre-loaded into the system and the user can pick one for each claim line and for the whole claim (diagnosis).

Modifiers are built into the system to automatically determine the maximum payable amount.

Member reimbursement claims capturing.

Member Pre-authorization and Member treatment pre-funding.

Grey – awaiting capturer verification.

The system uses the table above for mapping and thus determining what status the member is in at a specific date. This is also dependant on the status of the principal member.A member is changed to another plan by capturing a ‘Joined’ event to the new plan.The system automatically calculates the waiting period depending on whether late-joiner or regular-joiner.

Amber – on hold pending human adjudication. May have a problem detected by the system of a user.

Red – Rejected.

Green – Ok and ready for payment.

Provider’s own ref number for their own claims are captured in the system.

Printing of claim form.

Use of hash total to detect capturing errors.

Generating, emailing and printing a pre-authorization letter.

Generating, and sending a pre-authorization SMS.

A checklist is used to monitor/assess the activities around each claim (workflow).

Claim Correctly Captured.

Claim Stamped.

Clinical Data Verified.

Final Authorisation.

Adjudication & Award

Patients readmission rate:monitor the number of patients who are coming back.

Related Services' History.

History of Same Diagnosis.

Benefit Exhaustion History.

Parent Benefit Exhaustion History.

Global Limit Usage History.

An individual claim line can be flagged, and a whole claim can also be flagged. The whole claim’s flag monitors handling of the individual lines. If claim is rejected, then the individual claim lines do no access or hold benefits.

Clinical data can be captured, even though it is generally not included on standard paper claim forms, including:

Date/time of admission and discharge.

Next of kin in the case of an accident.

Per-claim audit trail: For every claim, the system records and shows the trail of users who changed it, including the date/time and location (computer) used

1. Dates treated/received/captured/paid.
2. Payment Batch.
3. EDI File
4. Fund
5. Paid only
6. Unpaid only
7. Current Member's History
8. Current Provider's Claims
9. Current Member AND Provider
10. This Whole Family

Payment Flags: Pay - All OK, Pay - On Hold, Awaiting User Decision and Rejected.

Capturing accuracy: Hash Total Mismatch, Capturing Checked and Capturing Not Checked.

Current user’s own claims: Captured by me, My UnChecked Claims and Capturing Not Checked.

Other navigator features: Bulk deletion, Bulk movement to a different provider and Bulk setting of payment decision and Searching for a specific claim by system assigned number or provider’s reference.

Data Capturing Session (Capturing by Batch) – this speeds up capturing of a batch as the common details of the entire batch are entered only once and automatically set for each new claim in that session.

Each computer can be optimised either in favour of claims or membership.

Shortfalls and rejection reasons are edited using this feature.

This feature enables you to maintain an up-to-date list of banks and their branches, along with the branch codes.

Each bank’s Electronic Data Interchange method is also indicated, the system has some methods already inbuilt, namely Paynet and Stanbic files.

The bank accounts used to pay providers are set up using this feature.

Account currency is also set using this feature.

This feature starts the claims payment process. The first step is batching of the individual claims per recipient (member or provider). The first batching process produces a payment amount.

Claims are first isolated by fund.

System can filter out recipients who don’t have banking details configured yet.

Each payment is assigned a reference number (‘Payment Ref #’).

This feature provides the final payments processing steps. It is used after a Bulk Payment Run.

Payments are grouped and locked together to form a BATCH.

A Batch is printed for final authorization, and the same batch is also authorized within the system.

When a user authorizes a batch, the system records the user ID and time

The system has been designed to cater for multiple authorisation points, up to 5 users.

The system allows the user to determine how many payments to batch because the user is aware of funds availability in the bank account.

Payments are processed one fund at a time (not mixed)

Payments can be filtered by

Date of run

Provider's Payments only

Reimbursements only

Run but not Exported to Bank

Not yet Queued for Authorisation

Queued but Not yet Authorised

Authorised

Batch can be exported to Paynet or Stanbic file formats.

Checksum is calculated and included in the file, for file integrity (preventing alteration outside the system) in the case of Paynet.

Remittance advice is generated and printed or emailed directly from within the system.

Payments are color-coded

Purple – Not even Queued for Authorisation

Amber – Pending Authorisation

Green – Authorised

This is the feature which at the core of the basic purpose of the system: benefits and claims management. It is the element which runs a standard set of tests on every claim to ensure it is eligible for benefits according to policy.

The rules to be run are categorised under

Organisation Validity

Member Validity

Beneficiary Validity

Service Provider Validity

Claim/Visit Validity

Tariff/Treatment Validity

The following tests are run each time: Organisation Validity

Is organization identified (registered with us)?

Are subs paid in treatment period?

Are funds still available?

Member Validity

Are subs Paid and up-to-date?

Does global limit still cover?

Is principal member Active?

Beneficiary Validity

Is beneficiary Active?

Is waiting period over?

Service Provider Validity

Is the discipline applicable to treatment?

Was service Provider identified?

Is service Provider on our network?

Is service provider assigned to this organisation?

Claim/Visit Validity

Is claim submitted within 3 months?

Is provider's claim number/account ref unique?

Is Service Provider Specified?

Is the disease Specified?

Tariff/Treatment Validity

Specialist treatment has referral?

Is Tariff code recognised?

Is the waiting period for this benefit over?

Where required, is authorization code present?

Is quantity valid?

Within max expected quantity contiguous?

Is treatment date in the past?

Do benefits cover this treatment?

Is treatment date before submission date?

Is this NOT a duplicate claim?

Where required, is authorization code for correct discipline?

Where required, is treatment before authorization code expiry?

Where required, is authorization code recognised?

Is treatment date after joining date?

Can this benefit's limit accommodate this treatment?

A claim is paid when it passes the above tests

This engine runs seamlessly without user activation; however, this feature configures which rules are active or not