Around 2012 the National Institute of Nuclear Medicine and Allied Sciences at BSMMU ran everything — registration, scans, reports — on software built by a foreign vendor. One day it broke. The vendor could not fix it quickly, and for several days patient services at a national institute simply stopped.
A student mentioned the problem to his teacher at Bangladesh University of Business and Technology, Mahbubul Alam, who went in and repaired it. The institute's director then asked a bigger question: could he automate the whole place?
From one room to a hundred institutions
Alam studied computer science at the University of Madras, returned in 1998, worked as an assistant programmer at Sonali Bank and a systems analyst at the Ministry of Water Resources, and completed a master's in ICT at BUET in 2005. A spell in the United States ended with him coming home to start MajedaTech Limited — three staff, one room of his own house, teaching on the side. That first job became the template. More than a hundred Bangladeshi organisations now run the company's software, with 25 permanent staff and a rotating group of part-timers.
What this software is actually solving
The product list is unglamorous — hospital information systems, ERP, accounting, inventory, HR, e-prescriptions — and it conceals three problems that make health software harder than it looks.
Identity. The hardest problem in any hospital system is knowing that the person in front of you is the same person who came last year. Without a reliable national health identifier, matching relies on name, date of birth, phone number and address — all of which change, are recorded inconsistently, and are frequently shared within a family. Get it wrong in one direction and a patient's history is invisible; get it wrong in the other and two people's records merge, which is worse. Every feature below depends on having solved this adequately.
Interoperability. A hospital is a building full of equipment from different manufacturers — analysers, imaging machines, pharmacy systems — each speaking its own dialect. Getting a result from a machine into a patient record without a human retyping it is most of the engineering, and that is the reason "we built a report app" is a smaller claim than "reports reach the patient automatically".
Uptime. Most business software can have a maintenance window. A hospital cannot. That constraint shapes everything about how the system is built and updated, and it is precisely what failed in 2012.
Why queue management is the visible win
The effect clinicians describe is about crowds. At Dhaka Medical College Hospital, automatic report delivery, e-prescriptions, diagnostic reports in a mobile app and prescription queue management let the hospital serve more patients with fewer staff. At the National Institute of Kidney Diseases and Urology, queue management brought a crushing load under control, with appointments through the app and reports delivered automatically. The National Gastroliver Institute and the National Institute of Neurosciences use the same systems.
What that actually changes is narrower than it sounds. It is not throughput in the medical sense. The doctor still sees patients at the same rate. What disappears is the queue that exists only to collect a piece of paper — the second and third visit to a counter for a report that could have been sent. Remove those and the building empties out without a single clinical process going faster. That is why queue management is the first thing hospitals notice and the easiest thing to undervalue.
Why imported systems fail here
The origin story is the argument, and the usual version of it — a foreign vendor is slow to respond — is the smaller half.
The larger half is that hospital software encodes assumptions about how a hospital works. Systems built for wealthy health systems assume scheduled appointments rather than a walk-in crowd at dawn; insurance billing rather than cash at a counter; one clinician responsible for a patient rather than a ward round; electronic ordering by a doctor who types. None of those are translation problems, and none are fixed by changing the interface language. A system whose core workflow assumes the wrong hospital will be worked around by staff until it is a data-entry chore attached to the paper process that actually runs the ward.
A local vendor's advantage is not patriotism or price. It is that its assumptions were formed in the building.
The question to ask any vendor
There is a cost to the model worth naming, because it applies to every successful local vendor and nobody raises it while things are going well.
A hospital that runs registration, records, pharmacy and billing on one company's software has placed its institutional memory inside that company's database design. If the relationship ends — a dispute, a price rise, the firm being acquired or simply ceasing to exist — the question is whether the data leaves in a form anyone else can use.
So the question to put, in writing, before signing: can we export the complete clinical record in a standard format, on demand, without the vendor's assistance? The health industry has standards for exactly this, and a vendor who supports them is making a commitment that costs them leverage. One who answers with "we will provide a database dump" is offering something only they can interpret.
It is an unglamorous clause and it matters more than any feature on the list, because the software will be replaced one day and the patient records are supposed to outlive it.
