Most hospital software in Pakistan is bought twice. The first purchase is a cheap package that handles billing and nothing else. The second, eighteen months later, is a real system — bought after the hospital has learned, expensively, which parts of its own work the first product never modelled.
This is an account of what we actually built for two hospitals, what the hard parts were, and what we would tell a hospital administrator to check before signing anything.
Where the work starts: paper that nobody trusts
At Fatima Hospital the problem was not that records were missing. It was that they existed in several places at once. Patient files sat in one register, admissions in another, billing in a third. A patient readmitted after six months arrived as a stranger. Reconciling a month of revenue meant someone walking between departments with a notebook.
Begum Noor Memorial Hospital in Chakwal had a version of the same problem at a different scale: appointments, admissions, billing and medical records each handled separately, with no single view of a patient or a day.
Neither hospital asked for “digital transformation”. Both asked for the same practical thing: one place where a patient exists once.
What a hospital system in Pakistan actually has to handle
Foreign products fail here for specific reasons, not vague ones.
Billing is not one flow. A single hospital runs cash patients, panel patients whose employer pays, insurance cases, and charity or zakat cases with partial waivers. Each has a different approval path. A product built around insurance-first billing treats the cash patient as the exception, which is backwards for most hospitals here.
OPD and IPD behave differently. Outpatient flow is high volume and fast: register, consult, pay, leave. Inpatient is slow and accumulates — bed, medicines, procedures, lab, doctor visits — and the bill is only final at discharge. Systems that model one well usually model the other badly.
Lab and pharmacy are inventory problems wearing a clinical coat. A lab test is a sample with a chain of custody and an authorising signature. A pharmacy item is stock with an expiry date and a reorder level. Both have to post to the patient bill the moment they are used, or the bill is wrong at discharge.
The front desk is the real user. The person who will use the system eight hours a day is usually not technical and is usually under time pressure with a queue in front of them. If registering a patient takes twelve clicks, the system will be worked around within a month.
What we built
Both hospitals run on EziERP, our hospital management platform, configured to how each actually works rather than to a generic template.
The core is a single patient record: one identity that admissions, OPD, IPD, lab, pharmacy and billing all write to. Everything else hangs off that.
Around it:
- Admissions and appointments — bed allocation, transfers between wards, and discharge with the bill already assembled
- OPD and IPD workflows — separate paths, shared record
- Lab — test ordering, sample tracking, result entry and authorisation before anything reaches the patient
- Pharmacy — stock, expiry, dispensing that posts straight to the patient account
- Billing — cash, panel and partial-waiver cases, with an audit trail on every adjustment
- Reporting — the daily and monthly numbers administration actually asks for
The parts that are harder than they look
Migrating the old data. Every hospital believes its existing records are cleaner than they are. Duplicate patients, inconsistent spellings of the same name, missing dates. Migration is not a technical task, it is a decision task: somebody from the hospital has to decide which record wins. Budget real time for this.
Running both systems during switchover. You cannot stop admitting patients while software changes. There is a period where paper and system run in parallel and staff resent doing both. Keeping that period short is more important than making it comfortable.
Permissions. Who can reverse a bill? Who can edit a result after authorisation? These questions are political, not technical, and they surface late if nobody asks them early.
What to check before you buy
If you are evaluating hospital software, five questions are worth more than a feature list:
- Can you watch a real hospital using it, not a demo dataset?
- Does one patient identity carry across OPD, IPD, lab, pharmacy and billing — or do modules keep separate records?
- How does it handle a panel patient with a partial waiver?
- Who migrates the existing data, and who decides the rules?
- What is the support arrangement when something breaks at 2am?
On price, hospital systems in Pakistan vary widely by scope. We keep the ranges in a separate guide: hospital management system price in Pakistan, alongside a breakdown of the requirements clinics consistently underestimate.
If you run a hospital and are weighing this
The useful first conversation is not about features. It is about the two or three things that currently go wrong most often — the bill that is short at discharge, the file nobody can find, the month-end that takes a week. Those tell us more than a requirements document.
You can see our other delivered systems in the case studies, read about the platform on our hospital management system page, or tell us what is going wrong and we will tell you what it would take to fix.