The financing pillar
CSU financing
Cameroon's universal health coverage programme is an operating financing mechanism, with beneficiary contributions and provider remuneration. CHS does not replace it. CHS is the control layer: it determines entitlement, prices care, constructs claims, adjudicates them, authorises payment and reconciles what was actually paid.
This pillar is a system in its own right. What follows describes what it does, where its responsibility stops, and the rules that settle disagreements before they arise.
The boundary, stated exactly
CHS never holds or moves money
CHS emits an authorised payment instruction and consumes a payment confirmation. Everything between those two is the authorised government, banking or mobile-money infrastructure. CHS holds no account, initiates no transfer, and takes no payment from a patient.
Why the boundary exists
Holding or moving funds would place Obosu under payment-institution regulation: licensing, prudential and anti-money-laundering obligations. That is a different company, not a different module.
Why it is the right shape anyway
A programme's disbursement already runs through its own accounting chain. A platform that tried to sit inside that chain would duplicate it, and inherit its rules. Instructing and reconciling is both the smaller job and the more useful one.
Why it is a strength
The platform can be audited without auditing Obosu's balance sheet. CHS decides and records; it does not bank.
The lifecycle, end to end
This chain is the backbone of the pillar. Every component exists to serve one link in it, and every build phase delivers a contiguous section of it.
Person and household are recorded, independently of any coverage.
Enrolment registers the person, or the household, into the programme.
Eligibility is determined from the programme's rules and the evidence held.
Programme assignment and benefit entitlement follow from eligibility.
Care is requested, and coverage is verified for this person, this service, this facility, today.
Patient contribution is calculated, and prior authorisation obtained if the package requires it.
Care is delivered and recorded clinically.
Billable events are emitted, and a claim is constructed automatically from them.
The claim is validated, then adjudicated: approved, partially approved or rejected.
A payment instruction is authorised for a settlement period and issued to the payer.
Payment is confirmed by the payer and reconciled against the instruction.
The ledger and the audit trail record every position and every transition.
Person, household and beneficiary are three different things
Conflating these is the most expensive modelling error available in this pillar. A person can exist clinically in CHS without being covered by anything.
| Entity | What it is | Lifecycle |
|---|---|---|
| Person | A human being with a CHS health identity. Exists whether or not they are covered. | Permanent. Never deleted. |
| Household | A group used for enrolment and means assessment, with a head and members. | Formed, joined, left, dissolved. |
| Household membership | A person's participation in a household, between two dates. | Effective-dated. Never overwritten. |
| Beneficiary | A person's enrolment in a specific programme, with effective dates. | Enrolled, active, suspended, lapsed. |
| Entitlement | What a beneficiary may receive under a programme at a given date. | Derived, never stored as fact. |
Programmes are configuration, not code
The platform must never contain the sentence “CSU pays seventy per cent”. It must understand what a programme is, and read the rate from a definition an administrator can change.
- Population and eligibility
- Who qualifies, on what evidence, assessed against what criteria.
- Benefits
- Which services are included, excluded, or included with conditions.
- Tariff schedule
- The reference price per service, effective-dated.
- Contribution rules
- The share borne by the patient, by service class or by category of beneficiary.
- Exemptions
- Categories who contribute nothing, and the evidence required.
- Limits and ceilings
- Per episode, per period, per beneficiary, per household.
- Authorisation rules
- Which services require prior authorisation, and from whom.
- Provider rules
- Which facility types may deliver which services under this programme.
- Effective dates
- Every one of the above is versioned and dated.
The coverage engine
One named component answers one question: can this person receive this service, at this facility, on this date, under their programme, and who pays what? The clinician never needs to understand how it arrives at the answer.
| Response | Meaning | What the clinician sees |
|---|---|---|
| Covered | Service is in the package and the beneficiary is active. | Contribution amount; authorisation not required. |
| Partially covered | Covered, with a patient share or against a ceiling. | Contribution amount, and any remaining limit. |
| Authorisation required | In the package, but the package requires prior approval. | What to request, and from whom. |
| Not covered | Excluded, or outside this facility's authorised services. | Full tariff payable, stated plainly. |
| Cannot be verified | Eligibility cannot be established right now. | The verification state, and what may proceed. |
Clinicians never write claims
A completed act of care emits an immutable billable event. The financing pillar consumes those events and constructs the claim. This is the cleanest separation of responsibility in the platform: clinical staff record healthcare, and the financing system derives financial transactions from it.
An immutable fact
A billable event is an immutable fact. A correction emits a new event referencing the original; it never edits it.
Derived, never typed
The claim is derived from events, never typed. No clinician re-enters anything for billing, and no billing clerk re-reads a clinical note to construct a line.
Visible early
This is also what makes control signals possible: patterns are visible in the event stream long before they appear in a claim.
The claim lifecycle
| State | Meaning |
|---|---|
| Generated | Constructed from billable events and priced by the coverage engine. |
| Validated | Passed structural, eligibility and control checks. |
| Submitted | Presented to the programme for a decision. |
| Adjudicated | Decided: approved, partially approved, or rejected, with a reason. |
| Payable | Approved and included in a settlement period, awaiting authorisation. |
| Paid | Covered by a payment the payer has confirmed. |
| Reconciled | Matched to a confirmed payment, with any difference explained. |
| Closed | Settled and no longer open to change without a formal reopening. |
Correction, resubmission, dispute and cancellation are transitions available from defined states, not separate lifecycles. Every transition records who, when, why, the previous value and the new value. For public money that trail is not a nice-to-have; it is the reason the system is trusted.
Payment authorisation and settlement
A claim being approved does not mean a hospital has been paid. Adjudication and settlement are separate subsystems, and conflating them hides the number facilities care about most.
The payment instruction is an artefact, not a report
- Payee
- Facility, with its settlement reference and designated payment channel.
- Period
- The settlement period the instruction covers.
- Claim set
- Itemised, with a hash so the set cannot be altered after authorisation.
- Gross approved
- Sum of adjudicated amounts in the set.
- Adjustments
- Verification outcomes, penalties, advance recovery — each with a documented reason.
- Net payable
- The amount authorised for payment. Never assume it equals gross approved.
- Authorisation
- The authorising officer, the timestamp, and any second authoriser.
- Reference
- The identifier the external rail must echo back, or reconciliation becomes guesswork.
Reconciliation is the hard part
Because CHS does not control the payment rail, money arrives imperfectly: partial payments, one transfer covering several instructions, truncated references, payments landing in the wrong period. Reconciliation is therefore a matching engine, not a report.
Exact match on the instruction reference, where the rail preserved it.
Probable match on payee, amount and period, proposed for human confirmation.
Partial match, allocating a payment across several instructions.
Unmatched, held in an exception queue owned by the reconciler role.
The three-way match
Claims approved, instruction authorised, payment confirmed. Any leg that disagrees with the other two is an exception with a named owner and a resolution. A platform that can produce that reconciliation for any period is doing its job whether or not it ever touches a single franc.
Control signals
Deterministic checks, not machine learning, and not accusations. Every signal produces review required and routes to a human.
- Duplicate claim, or the same service repeated implausibly soon.
- Clinically impossible combination of services on one episode.
- Claim for care delivered after eligibility lapsed.
- Provider claiming outside the services their facility type is authorised for.
- Quantity above a configured limit for the medicine or service.
- One person apparently treated at distant facilities at the same time.
- Repeated corrections on claims from one source.
- Activity far outside the norm for comparable facilities.
When the network is not there
Offline clinical capture is a solved problem. Offline financial commitment is not, because “covered” computed from a cached entitlement is a commitment made on data that may be weeks old.
| Verification state | Means | What may proceed |
|---|---|---|
| Verified online | Eligibility confirmed against the programme now. | Everything the package allows. |
| Verified offline | Confirmed against a cached entitlement, with its age shown. | Configurable by service class and cache age. |
| Provisional | Beneficiary asserted, entitlement not confirmable. | Clinically necessary care, per the provisional rule. |
| Unable to verify | No entitlement information available at all. | Care proceeds. Never treated as ineligible. |
Talking about financing
If you run a programme, an insurance scheme or a network of facilities and want to go through this pillar in detail, get in touch.