Skip to content
All work

Web

HealthPro

Health Insurance TPA Platform

A bilingual TPA platform that runs the full health-insurance cycle — eligibility, claims scrubbing, pre-authorizations, benefit ledgers, provider batches and twelve reports — built Arabic-first with RTL as a design constraint, not a translation layer.

Year
2026
Scope
Web
Built with
  • React
  • Laravel
Status
Case study
Arabic name
هيلث برو — منصّة إدارة التأمين الصحي

01Overview

HealthPro runs the entire health-insurance cycle for third-party administrators, self-funded employers and insurers — from the moment a member is registered to the moment a provider is paid.

One system, the whole cycle. Policies and plans · member registration and renewals · eligibility · pre-authorizations · claims intake and adjudication · settlement · provider payment batches · chronic-care programmes · twelve operational and financial reports.

Built for Arabic, not translated into it. The interface is Arabic-first with a complete right-to-left layout, and English is a first-class equal — your finance team can work in English while your data-entry team works in Arabic, on the same screens, at the same time. Numbers, dates, currency and charts all behave correctly in both.

Precision the region actually needs. Amounts carry the Jordanian dinar's three decimals end to end — not two. A system that rounds the fils loses it permanently, and the loss compounds silently across a year of claims.

Controls that prevent leakage, not just report it.

  • Ten automated rules screen every claim before it can be saved.

  • Balances are ledgers: available = allocated − consumed − reserved — so an authorization already issued cannot be spent a second time.

  • Approval, settlement and payment are three separate permissions held by three different people.

  • Every sensitive change is recorded with its actor, its old value and its reason.

Two self-service portals that cut the phone traffic. Providers verify eligibility while the patient is still standing there, submit claims against their own contracted tariff, request authorizations and reconcile their payment batches. Members see their card, their balances, what they owe and why, and their authorizations — without calling anyone.

Ready for real operations. Dark mode, WCAG AA accessibility, background export to Excel and PDF, scheduled coverage expiry and portal closure, and a full illustrated user guide for every role.

02Highlights

What we built.

01

Claims scrubbing before the money moves

Ten automated rules run before a claim can be saved: eligibility, service date inside coverage, tariff match, duplicate detection, waiting periods, benefit limits. Review is line by line, never on the header, and rejection carries a coded CARC reason the provider can appeal against. There is no amount field anywhere — the price comes from the provider's tariff in force on the service date.

02

Pre-authorizations across three channels

Phone, written referral and online provider requests share one table and one queue, ordered by soonest due rather than newest. Approval reserves the amount from the member's balance immediately; rejection releases it and returns the form to the quota. The countdown measures a commercial commitment and reads its clock from the server, never the browser.

03

Member portal — card, balances, EOB

Members see their card at its true print size (85.6 × 54 mm), their balances per benefit, and an explanation of benefits that separates what they owe from the contractual adjustment between provider and administrator — a distinction most portals blur, showing patients an amount that was never theirs to pay.

04

Provider portal — eligibility while the patient waits

One verdict, read in a second, with **every** blocking reason rather than the first one — because a reason that hides another sends the patient away to fix something that will not be enough. The screen deliberately shows nothing else: no national ID, no address, no claim history elsewhere. The provider asks "is this covered?", not "who is this?".

05

Twelve reports, permissioned per report

Loss ratio against **earned** premium prorated by days, PMPM against member-months rather than member count, ageing, utilisation. Permission is per report type, not per screen: loss ratio belongs to finance, clinical utilisation to the medical officer. Excel and PDF export runs in the background and carries the screen's filters exactly as they are.

06

Chronic care with computed dispensing

A chronic case carries its drugs and doses, and the pack count is computed — `ceil((dose × frequency × 30) ÷ pack size)` — rather than typed. Dispensing is monthly and a month cannot be dispensed twice: the repeat is blocked by a rule, not by the officer noticing.

07

Every sensitive change is attributable

Actor, old value, new value, reason. Which is why accounts are suspended and never deleted — deletion severs the action from the person who took it. Creating an account and assigning a role are deliberately separate permissions: whoever can do both grants themselves everything in two steps.

Next projectInvestyLookWebView case study

Have a project like this
in mind?

Tell us where you are and where you want to go — a rough idea is a perfectly good place to start.