Solution

Built

A hospital management system that refuses at the API, not just in the menu.

One platform for patients, appointments, OPD, the consultation record, pharmacy, laboratory and billing, with tenant isolation enforced in the database and every module a switch your hospital actually controls.

The reception area of a mid-sized hospital with staff attending to patients at the counter.
All solutions

A hospital management system is the software a hospital runs its day on: registering a patient, booking and queueing them, recording the consultation, dispensing and testing, and billing all of it against one record. Nirogix does that for the outpatient journey today, on a platform built for multi-hospital scale from the first line.

What runs on it today

The outpatient journey, end to end, on one patient record. Everything below is running code you can see in a demo.

  • Patient registration with a tenant-unique UHID, and duplicate detection before a second chart is created
  • Appointments booked against a provider’s real availability, with conflict prevention
  • OPD check-in, a token queue and an arrivals board the front desk actually watches
  • The consultation record of complaints, coded diagnosis, prescription and orders, signed and correctable by amendment
  • Pharmacy dispensing against the prescription, with batch and expiry
  • Laboratory orders and results against the same visit
  • One invoice consolidating consultation, pharmacy and laboratory, printed on your letterhead
  • Admission, beds, wards and nursing charting(planned)
  • Operation theater, emergency and imaging(planned)

The part most systems leave to the menu

Two hospitals on the same platform can never see each other’s data. That is enforced by PostgreSQL row-level security, not by a filter in the application. A module a hospital has not enabled is refused by the API, not merely hidden from the sidebar. And a permission a role does not hold is refused on every request, including one typed straight into the address bar.

  • Tenant isolation enforced in the database and tested on every module
  • Module entitlement checked server-side before any business logic runs
  • Role-based access with per-user overrides that can be time-bound and expire by themselves
  • An append-only audit trail; entitlement and audit records are never deleted

Configured to your hospital, without a fork

How your hospital runs is configuration rather than a code branch: which vitals you take and where, when a consultation fee is due, what your price list looks like across departments and visit types, and your color and logo through the Portal and every printed document.

  • Your own clinical workflow, including where vitals are taken and by whom
  • A fee schedule that varies by the two dimensions a real tariff turns on
  • Tenant branding across the Portal and every print document
  • Multi-branch from the schema up, so a branch is a column rather than a second installation

How it runs

  1. 01

    Register

    The front desk registers a patient, or completes one who sent their details ahead through your QR link. Possible duplicates surface before a second chart exists.

  2. 02

    Queue

    Walk-ins and booked appointments join one queue with token numbers. Vitals are taken wherever your hospital takes them.

  3. 03

    Consult

    The doctor opens a chart that already shows past visits, bills and documents. Complaints, diagnosis, prescription and orders are recorded and signed.

  4. 04

    Dispense and test

    Pharmacy dispenses against the prescription; the laboratory works the orders raised in the consultation. Both post back to the same visit.

  5. 05

    Bill

    One invoice consolidates everything, priced from your fee schedule, printed on your letterhead, and recorded against the patient.

What this does not do

Nirogix’s inpatient is built and in verification, not yet running in a paying customer’s hospital: admission, the bed board, ward tariffs, transfers, the nursing chart and discharge exist, but there is no drawn bed map, no structured medication administration record and no auto-generated discharge summary yet, and a hospital that needs beds live this quarter should know that before a demo rather than during one. There is also no WhatsApp channel, no telemedicine, and no TPA or claims integration yet. Our ABDM work covers Milestones 1 to 4 and is verified in the sandbox; none of it is certified, and no health record has been exchanged in production.

The modules behind it

Questions we are asked

Is this suitable for a 50-bed hospital?

The outpatient half, yes, and it is running code. The inpatient half — admission, the bed board, wards, nursing charting and discharge — is built and in verification but not yet running in a paying customer’s hospital, so a 50-bed hospital would be an early inpatient partner rather than a live deployment today. We would rather tell you that now.

How is a hospital’s data kept separate from another hospital’s?

By PostgreSQL row-level security. Tenant context comes only from the authenticated session, never from anything the client sends, so a request cannot ask for another hospital’s data. It is tested in both directions on every module.

Can we enable only some modules?

Yes, and the entitlement is enforced rather than cosmetic. A module your hospital has not enabled is refused by the API, so hiding it in the menu is not what protects it.

Is it cloud or on-premise?

Cloud, and deliberately only cloud. The architecture is multi-tenant with database-enforced isolation; a single-tenant on-premise build would be a different product with a different support model. A group with a contractual isolation requirement is served by a dedicated-schema tier, which is planned.

Where is our data stored?

In India, by design: the database in an India region, with object storage set to an India jurisdiction per environment at deployment. It is an architectural decision taken ahead of any legal requirement.

Other solutions

See it running with your own workflows.

Book a walkthrough and we will map your clinic or hospital onto the platform, module by module.

Book a demoSee the modules