Angular 21 single-page app
Standalone components and signals, on a custom CSS design system. No component library, which is why the product looks like itself and not like a template.
About
A hospital system built the way accountants wish software was built
erpforHospital came out of a simple observation: almost every dispute inside a hospital system is really a disagreement between two copies of the same number.
What erpforHospital is
erpforHospital is a role-based hospital management system covering the full patient journey — admission, clinical charting, diagnostics, pharmacy, billing and insurer settlement. It is a working, API-wired product rather than a prototype: the same v2.4 build that runs a ward runs the demo.
It is built India-first. Money is in rupees, tax is GST computed backwards from an inclusive MRP, and cashless claims assume the TPA workflow that hospitals here actually deal with. That is a design constraint, not a localisation layer added afterwards.
Who it's for
erpforHospital is built for small-to-mid private hospitals, nursing homes and growing hospital chains in India — the kind of operation where the same handful of people cover admissions, wards, pharmacy and the billing desk. Seven roles — administrator, doctor, nurse, front desk, billing, pharmacist and lab — each get a workspace scoped to what they do. See the day-to-day screens on the modules page, or the decisions underneath them on the features page.
Who builds it
erpforHospital is developed by Artcode Infotech, a technology services brand operated under Artcode Private Limited, working out of Manik Chowk, Chakan, Pune. Alongside this product the team builds custom web and mobile applications, enterprise systems and Odoo ERP implementations, across a stack that includes Angular, Java, Node.js and React.
For erpforHospital that background matters in one specific way: the team has shipped and maintained enough billing and inventory systems to know that the hard part is not the screens. It is keeping the numbers consistent once several people are editing them at once.
Architecture
Three layers, no surprises
Nothing exotic. The value is in the boundaries being drawn in the right places and held.
Spring Boot 3 REST API
Organised module per domain: common, config, master, rbac, patient, bed, ipd, billing, preauth, opd, pharmacy, referral, dashboard. Boundaries you can reason about.
MySQL, with money as BigDecimal
Currency never touches a floating-point type. Bills are computed rather than stored, and deletes are soft so nothing disappears from the audit trail.
Principles
Seven rules we do not bend
These are enforced in code, not written on a wall. They are also the shortest honest answer to why the billing holds up.
- The treatment engine is the single source of truth — chart, bill and ledger cannot disagree.
- Bills are computed, never stored: an invoice is derived from its inputs every time.
- Corrections post reversals; the clinical record is never rewritten.
- Money is tax-inclusive and exact, handled as BigDecimal throughout.
- Deletes are soft and issued documents freeze, so the history stays auditable.
- Admit, discharge and point-of-sale are transactional — all of it lands, or none.
- RBAC decides every view, and the API enforces it independently of the interface.
Come and poke holes in it
Bring your hardest billing case — a mid-stay TPA revision, a partial refund, a corrected charge — and we will walk it through the product.