We build platforms for health funds, mutual insurers and health insurance bodies in Morocco: a member portal, a healthcare provider workspace and a back office on a single architecture — entitlements, pre-authorisations, reimbursements and reporting. Entry scope as a business module from 40,000 MAD, a full platform from 120,000 to 500,000 MAD. Our reference on this business is LA MAS.

The problem a coverage body has

Three populations pull on the same data with three incompatible expectations. The member wants to know whether they are covered, for how much, and where their reimbursement stands. The healthcare provider — clinic, laboratory, pharmacy, practice — wants to check entitlements in seconds and be paid on a predictable schedule. The administrator wants to apply the exact rule of the contract without replaying it from memory on every case.

Without a shared platform, the adjustment variable is always the same: the telephone. Administrators spend their day answering questions whose answers are already in the system, and the convention’s rules end up living mainly in the memory of the people who apply them.

Why no off-the-shelf product is enough

This is the heart of the matter, and it deserves saying plainly: no packaged product available in Morocco covers a given insurer’s convention rules. Coverage rules are not parameters — they are business rules specific to each convention: ceilings per procedure and per period, differentiated co-payments, procedures subject to prior approval, waiting periods, exclusions, family ceilings, coordination between basic and complementary cover.

A general-purpose product offers to approximate that with configurable fields. What happens next is predictable: the part that does not fit the fields leaves the software and returns to a spreadsheet, then to somebody’s head. That is the moment the tool stops being auditable — and also the moment that person’s departure becomes expensive.

A custom platform is not better "in general". It does exactly what your convention says, and it does it the same way for every case.

What we build

Member portal — entitlements and cover in plain language, claim tracking, document upload, reimbursement history, downloadable certificates.
Healthcare provider workspace — entitlement checks, pre-authorisation requests, tracking of claims and payments. This is what cuts call volume fastest.
Administrator back office — claim assessment, application of convention rules, approval chains, rejection handling and rejection reasons.
Rules engine — ceilings, co-payments, prior approvals, waiting periods and exclusions, versioned: a claim remains judgeable under the rule in force on its date, which is indispensable in a dispute.
Reporting — consumption by benefit and by population, processing times, rejection rates and reasons, outstanding commitments.
Integrations — accounting, payment methods, file exchange with providers and other bodies.

Our reference: LA MAS

We designed and built the LA MAS platform, covering the complete journey: members, healthcare providers and internal administration. The case study details the roles, the entitlement mechanics and what going live changed in processing times.

Rejections, and why they cost so much

A rejected claim always comes back: the provider calls, the administrator reopens the file, the member worries. So the cost of a rejection is not the rejection — it is the number of round trips it triggers. Two mechanisms reduce it, and neither is a configuration setting:

Checking at entry. If the provider learns a prior approval is missing before submitting, the rejection never exists. That requires the convention’s rules to be queryable in real time, not applied at the end of the chain.
An explicit rejection reason. "Incomplete file" generates a phone call; "procedure subject to prior approval, request to be filed before the procedure" generates an action. The reason must be codified, not typed by hand.

The reporting that then matters: rejection rate by reason and by provider. That is the data telling you where to train, where to fix the rule, and where the problem is not yours.

Coordinating basic and complementary cover

As soon as one cover complements another, the difficulty is no longer the rule but the order: which share falls to which level of cover, in what sequence, and on what reimbursement base. Handling that by hand produces discrepancies nobody can reconstruct six months later — and claims where the member is reimbursed twice, or not at all.

We model that sequence explicitly, with the calculation trace kept for every claim: which rule was applied, in which version, and what amount it produced. It is the only way to justify a contested reimbursement without redoing the calculation from memory.

Health data: not optional

A health coverage platform processes health data, the most sensitive category under law 09-08. That means a regime of prior authorisation from the CNDP — reviewed in two months, extendable once — and not a simple declaration: a milestone to build into the delivery plan at scoping, not to discover before launch.

Technically it translates into role separation, logging of access to records, retention periods enforced per category of data, and the ability to answer an access or deletion request. We handle that within the project — see CNDP compliance.

How we work on these projects

Always with a diagnostic: mapping of roles and permissions, an inventory of integrations, a reading of the conventions to be translated into rules, a prioritised backlog and a costed scope. On this business, reading the conventions is the design work — that is where it is decided whether the platform will be exact or approximate.

Then a business module before the full platform: most often provider-side entitlement checking, because that is the point that relieves the back office immediately. Six to ten weeks, in production, with the same code growing afterwards. See business platforms and our pricing.

Who this is for, and who it is not

For a mutual insurer, an internal fund, a provident body or a coverage manager applying its own conventions, whose administrators currently compensate for the tool’s limits by hand.

Not for a broker who needs a distribution CRM: that is a different business, and a market product will do it better and cheaper. Describe your situation — we will tell you in the first conversation.

Payer-side and provider-side systems meet in the same claim. For the provider side — clinics, laboratories, patient portals — see our healthcare software development work.

Insurance & health funds