Registration & OPD
Patient registration, unique identifiers, department and doctor allocation, token queues and repeat-visit lookup that finds the record in one field.
OPD and IPD, billing, pharmacy, pathology, radiology, blood bank and records — built module by module, and running in production at a government medical college hospital.
Hospital software is judged at the counter. If registration takes ninety seconds instead of fifteen, the queue reaches the door and the staff go back to the register book. Every design decision I make in this domain comes back to that.
I built and continue to run the hospital management system for Darbhanga Medical College & Hospital — a government medical college hospital — along with its radiology, attendance and campus systems. It is Django and PostgreSQL, deployed with Redis caching and connection pooling, because the boring stack is the one that stays up.
Patient registration, unique identifiers, department and doctor allocation, token queues and repeat-visit lookup that finds the record in one field.
Admission, bed and ward allocation, transfers, daily charge accrual, discharge summaries and the final bill.
Rate lists, categories and concessions, part payments, refunds, daily collection registers and shift-wise reconciliation.
Drug masters, indents and issues, batch and expiry tracking, stock movement across medicine store and central store.
Test ordering, sample tracking, result entry with reference ranges, report authoring and delivery, plus a patient-facing report lookup.
Donor and unit registers, grouping, cross-matching and issue records, alongside a medical records room module for filing and retrieval.
A working session to pin down what the system has to do, who touches it and what already exists. You get a written scope, an architecture sketch and a realistic estimate before anything is committed to.
Data model, API surface and screens, agreed before the build. Designing against real data and real edge cases is what stops the rebuild three weeks in.
Working software every week against a staging URL you can open, rather than a big reveal at the end. Feedback lands while it is still cheap to act on.
Deployment, DNS and TLS, database migration, backups, monitoring and an handover walkthrough. The system goes live on infrastructure you own.
Optional retainer: security patches, feature work, performance passes and a person who already knows the codebase when something breaks.
An end-to-end hospital management system covering patient registration, OPD and IPD workflows, billing, pharmacy, pathology, radiology, blood bank and medical records — running in production on a government medical college campus.
Read the case studyYes. The HMS at Darbhanga Medical College & Hospital is live, along with separate radiology, attendance and digital signage systems on the same campus. That is production experience in a government hospital, not a pilot.
You should. Registration and billing first, then pharmacy, then diagnostics. Each module goes live and earns trust before the next one starts — attempting a whole hospital at once is how these projects fail.
Yes, and for hospitals it is often the right choice — patient data stays inside the building and the system keeps working when the internet link does not. Cloud hosting is equally supported.
Role-based access by department and designation, audit logging of record access and changes, encrypted transport, and backups tested by restoring them. Access is scoped so a pharmacy login cannot read pathology records.
Yes. Biometric attendance integration is already in production on the DMCH campus, and analyser and device integrations are handled case by case depending on the interface the hardware exposes.
Tell me what you are trying to ship. You get an approach, a timeline and a realistic estimate — usually within a working day.