The Information Should Move. Not the Patient.
What we're building at C.A.N.Tech Nepal Pvt. Ltd., and what three years of building it has taught us
A patient walks into a clinic carrying a plastic bag. Inside: an X-ray from 2019, two prescription slips in different handwriting, a lab report from a lab across town, and a registration card from a hospital that changed its system last year.
She isn't carrying her medical history. She is her medical history. If she forgets the bag, it doesn't exist.
This is normal across Nepal, and it points at the real problem which isn't that clinics lack computers. Most have them. The problem is that registration doesn't talk to the lab, the lab doesn't talk to the pharmacy, and the pharmacy doesn't talk to billing. So the patient becomes the integration layer, walking documents from one desk to the next. Everything people complain about downstream follows from that single gap. Long queues. Duplicate entry of the same name into four registers. A doctor consulting without the previous visit's results because they're in a folder on another floor. Month-end reconciliation that takes days because the numbers live in three different books.
Healthcare professionals didn't train for years to do data entry. But that's where a meaningful share of the day goes.
"Integrated" is the cheapest word in this industry
Every hospital software vendor claims it. The claim costs nothing; the plumbing costs everything. So rather than repeat it, here is what integration means concretely in our system and specifically the parts that only make sense if you're building for Nepal.
Billing that satisfies IRD, permanently. Nepali tax law requires that an issued bill can never be altered or deleted. We didn't handle that with a policy document or a code review checklist. Billing records live in a separate database where deletion is blocked by the database engine itself, enforced by triggers, with a full print and sync history against CBMS. A clinic running our system is compliant by construction rather than by discipline. That distinction matters the day someone audits you.
Bikram Sambat is not a display setting. Appointments, admissions, bills, reports, follow-up dates, all of it works in BS, because that's how the clinic thinks and how the patient thinks. Software that makes staff convert dates in their head all day is software they will quietly stop using.
One clinic's data cannot reach another's. Every record is fenced to its own clinic by the database, not by a filter clause a developer might forget to write. In production the system refuses to start at all if that enforcement is turned off. For patient data, that felt like the only defensible way to build it.
Clinics switch modules on when they're ready. Patient registration, billing, pharmacy, laboratory, wards and admissions, nursing, inventory, accounting, reporting each runs independently. A three-doctor clinic and a multi-ward hospital run the same platform; they simply don't run the same amount of it. This turned out to matter far more than we expected, for reasons further down.
One patient. One record.
The patient registers once. From that point the record moves and she doesn't.
The doctor writes the consultation digitally, and the investigations ordered appear on the lab's screen before the patient reaches the counter. Results post back into the same record. The prescription is waiting at the pharmacy. Billing assembles itself from services actually delivered rather than from slips collected at the end. Accounting sees the day's figures as they happen, not a week later. Management sees occupancy, revenue, and pending work without asking anyone to prepare a report.
No re-entry. No folder handoffs. No patient standing in a corridor holding her own file.
Built Alongside Healthcare Professionals
Technology should never be developed in isolation especially in healthcare.
Our Hospital & Clinic Management System is being refined through close collaboration with the clinics actually using it. Working alongside doctors, administrators, lab staff, pharmacists, accountants and reception teams is how we learn what a day really looks like, and it has shaped the product more than any planning session ever has.
Today the platform supports "Tulsi Multispeciality", "Swastik Samaj Dental", and other clinics across Nepal.
Each implementation teaches us something new. A multispecialty clinic has different operational needs from a dental practice; a growing clinic faces different problems from an established one. Rather than building one rigid product and asking everyone to fit it, we keep shaping the platform around workflows that already work.
Our objective is simple:
Software that suits a single doctor clinic and a multispecialty hospital equally well. Every new implementation makes it better for the next one.
The software was the easier half. This is the part most vendor blog posts leave out, and leaving it out is why they're not worth reading.
Nobody in a clinic ever tells you they've rejected your system. They log in, register the patient, print the bill and then at the end of the day someone still writes the same names into the hardbound register. The usage numbers look excellent. Nothing has actually changed.
Three things we learned the hard way:
We optimised for the month while the staff live in the minute. Our reports saved the clinic hours at month-end, but registration cost the receptionist extra seconds per patient with a queue waiting. Adoption is won or lost in those seconds, not in the demo. Patients don't trust a record they can't hold. A screen isn't proof; a stamped slip is. The elderly patient, the one flying out for work, the one seeking a second opinion they want paper, and they're right to want it. A well run digital clinic prints more than a paper one, not less. And going module by module beat every feature we shipped. We built module entitlements thinking about pricing. Their real value is that a clinic can absorb one change at a time and keep functioning while it does.
We now think "paperless" is the wrong word entirely. Zero paper was never the goal. Zero re-entry was.
What we're building toward
The connected record is the foundation, not the destination. What it makes possible is the part that's genuinely new for Nepali healthcare: operational analytics a clinic owner can act on, inventory that reorders before a stockout, appointment patterns that reveal where capacity is being wasted, and eventually clinical decision support built on real local data rather than borrowed assumptions.
None of that is possible while the information sits in registers.
We're not measuring this by how many modules a clinic has switched on. We're measuring it by whether the register in the drawer has stopped being written in. In the clinics where it has, everything else followed.
C.A.N.Tech Nepal Pvt. Ltd. builds clinic and hospital management software designed for how healthcare actually runs in Nepal.
Contact: +977-9709184575