Brimpa Care
Hospital management software, ready to run and set up for each hospital.
- Built for
- BHOOMAA Medicare Hospital & I.C.U., Palanpur, Gujarat (18 beds, 8 ICU beds)
- Status
- Running at a hospital today. The next one can be yours, set up for your requirements and your specialty.
- Works on
- Any browser, on the hospital's own computers and phones; nothing to install
- Since
- 2025
The problem
A small hospital runs on paper and a billing counter. Patient numbers, bill numbers and discharge papers are written by hand, so a bill can be lost, a number can repeat, and nobody can say later who changed what. The hospital wanted its own system, not a seat on a national platform, and it wanted the system to keep working when the internet does not.
What it does
- Patient registration with gap-free patient codes, OPD and IPD admissions, and OT cases.
- Billing for OPD, IPD, doctor visits and OT, with bill totals owned by the database, never by application code.
- Printed documents in the hospital's own name: OPD and IPD slips, bills, case sheets, discharge summaries and billing reports, with print headers the hospital edits itself.
- Bills sent on WhatsApp, a queue display for the waiting room, and profiles with screen-level permissions.
- An audit log of every write, immutable to the application and to every person, kept for as long as the hospital's own administrator chooses.
- Account backups the hospital can export, restore and, if it ever leaves, take with it.
How it is built
Everything specific to a hospital is a setting, never a rebuild: name, logo, address, doctors, fees, charge heads, number formats, paper sizes, brand colours. Hospital number two is a set-up that takes days, with its own data from the first minute.
- Tenancy by row-level security. Every query runs as an application role that can only see the signed-in hospital's rows. The tenant comes from the session, never from the request's host header.
- Money as integer paise. No floating point anywhere near a bill. A trigger computes every total.
- Gap-free, human-facing numbers. Patient codes and bill numbers are allocated by high-water mark inside the insert's transaction, with a per-hospital unique index as the real guarantee and a retry when two inserts race. Sequences leave gaps on rollback; these do not.
- No hard deletes. Records are voided with an actor and a reason. The application's database role has no delete grant.
- Restore and purge on their own roles. A restore runs under a role that owns nothing and sits under the same row-level security; a purge needs two switches on, one in the environment and one thrown by the developer from the panel.
- Production starts closed. The server refuses to start in production until every secret, TLS setting and kill switch is set, and refuses a superuser as its application role.
- Specialty modules. Dentistry, gynaecology or orthopaedics can be added as a module enabled per hospital, each with its own tables and screens, without touching the core.
The rules are written down first
The project keeps a logic ledger, a decision log and a schema document alongside the code. A rule lives in one place and names the reason it exists, so a later bug fix cannot quietly remove it. That habit came from a project where a validation rule vanished during an unrelated fix and needed a phase of its own to restore.
What is not here yet
Product screenshots. The owner is preparing captures from a demo hospital with no real patient data; nothing from the live hospital will ever appear here.
