Mohamed L'Amine Gherbi Full-stack developer

Enhancing the Integrity of Algeria's Social Security System: Addressing Fraudulent Activities through Blockchain Technology

A permissioned blockchain earns its place here because CNAS, providers and pharmacies must endorse each other's transactions.

(Hyperledger Fabric, Node.js, Next.js, Hyperledger Caliper)

Author
Mohamed Lamine Gherbi
Institution
University of Mohamed Khider, Biskra, Computer Science Department
Degree
Master's in Computer Science, Software Engineering and Distributed Systems (GLSD)
Session
2024-2025
Supervisors
R. Bettira, S. Lanani, L. Kahloul

Read the thesis (PDF, 2.8 MB)

01 / What it is

What it is

The thesis asks whether a permissioned blockchain can make Algeria's social security transactions harder to falsify.

It connects CNAS, healthcare providers and pharmacies to one Hyperledger Fabric channel and moves patient registration, eligibility, prescriptions and invoice settlement into chaincode. A Next.js front end gives each organisation its own section.

The prototype is a local Fabric v2.5 network: three organisation peers, one orderer, one channel and one Node.js chaincode.

Thesis cover: Enhancing the Integrity of Algeria's Social Security System, University of Mohamed Khider, Biskra, session 2024-2025.

02 / The hard part

The hard part

The fraud problem is not a missing database. CNAS, providers and pharmacies keep separate records and can act on them without the others seeing the change.

A patient's eligibility can be changed without a coverage review; a prescription can be issued without CNAS; an invoice can be settled without a matching prescription.

The hard part is making each of those actions require the right parties before it reaches the ledger, without giving one organisation unilateral write authority.

03 / The design

The design

Each organisation runs a peer on mychannel: CNASMSP, HealthcareMSP and PharmacyMSP, with one Raft orderer and TLS. The chaincode is a single Node.js contract, basic.

Endorsement is set per transaction category: patient management needs AND('CNAS.peer'); prescription issuance needs AND('Healthcare.peer','CNAS.peer'); invoice settlement needs AND('Pharmacy.peer','CNAS.peer').

The front end is Next.js with Tailwind CSS, split into CNAS, healthcare and pharmacy sections.

Three organisations

  • CNAS Registers patients and changes eligibility status.
  • Healthcare providers Issue prescriptions for existing patients.
  • Pharmacies Settle invoices against a patient and a prescription.

Nine chaincode functions

  • registerPatient Creates a patient record on the ledger.
  • updatePatient Updates specified fields on an existing patient record.
  • verifyEligibility Returns the patient's current eligibility status.
  • updateEligibility Changes a patient's eligibility status and persists the new value.
  • issuePrescription Creates a prescription for an existing patient.
  • settleInvoice Validates patient and prescription, then builds and saves an invoice.
  • getPatient Reads one patient record.
  • getPrescription Runs a range query over prescriptions.
  • getAllInvoices Runs a range query over invoices.
Network diagram: three organisation peers on one channel, an orderer and an application gateway.
Three organisations on one channel, with an orderer, an application gateway and a peer per organisation.
CNAS register screen with a member registration form and a ledger read.
The CNAS section: registering a member and reading the ledger.
Provider portal issuing a prescription for an eligible patient.
The provider portal issuing a prescription for an eligible patient.
Sequence diagram of prescription issuance, with ledger reads and endorsement by both parties.
Prescription issuance as a sequence: the contract reads the ledger, then both parties endorse.

04 / What it proves

What it proves

The Caliper run exercised three functions, registerPatient, issuePrescription and settleInvoice, at send rates from 100 to 1000 TPS (page 62). It reports 100% success with zero failures. The report records throughput tracking the offered load to about 400 TPS, then plateauing at roughly 80-100 TPS.

Average latency started at 4-8 s, maximum latency reached 10-14 s at the peak, and minimum latency stayed at 1-4 s (page 62). Page 66 records a second summary: 400-500 TPS, 24,000-30,000 transactions per minute, 4-10 s average latency and a fastest path under 4 s.

Both summaries come from the same Caliper run and are kept here as recorded. The run executed the three workflows without a transaction failure under the recorded load.

Read

Back to the work