olivhealth
Olivhealth, hospital management, reimagined.
Inventory and stores

One stock engine for every store you run

Pharmacy, blood bank, surgical items and the general store — different fields, different rules, the same reliable ledger underneath.

Hospitals rarely have one inventory. They have a pharmacy that cares about expiry, a blood bank that cares about blood group and donation date, a surgical store that cares about serial numbers, and a general store that cares about none of it. Buying four systems is how stock control dies. OlivHealth runs one engine where each kind of store declares its own fields as configuration, so you can add a new kind of inventory from the screen rather than waiting for a release.

Each store needs different information
Every inventory kind declares its own custom fields as data. A blood bank captures group and donation date; the surgical store captures serials; neither forces the other into its shape.
Adding a new store means a development request
A new kind of inventory is created from the UI with its own taxonomy and fields. No migration, no deployment, no waiting.
Stock counts cannot be explained
Every movement — receipt, reservation, dispense, return, adjustment — is an immutable ledger entry, so a discrepancy has a trail instead of a theory.
Expiry and dead stock surface too late
Batches carry their own expiry and pricing, so slow movers and near-expiry are visible while you can still do something about them.

Configurable inventory kinds

Pharmacy, blood bank, surgical, general store or something you invent — each with its own fields, defined as configuration.

Managed taxonomy

Categories, types, brands and vendors are structured records, so reporting and reorder work off real data.

Products, variants, batches

The generic item, the sellable SKU and the physical batch are separate layers, which is what makes expiry and pricing behave correctly.

Reservations and dispensing

Reserve stock against a visit and dispense it, with concurrency-safe quantity changes that cannot go negative.

GST and non-GST invoicing

Tax lives on the product, so both taxable and exempt movements produce the right document.

Per-hospital separation

Each hospital in the group keeps its own stock, its own stores and its own numbering, with nothing bleeding across.

ABDM — included as standard

Go live ABDM-enabled from day one

Every practice we onboard goes live ABDM-enabled — create and verify a patient’s ABHA at registration, and let their records follow them across the health system on their consent. It’s part of onboarding, not a separate project or an extra module to buy.

Best fit for
Hospital storesBlood banksSurgical inventoriesMulti-store hospitals

Frequently asked questions

Is this different from the pharmacy module?

It is the same engine. Pharmacy is one kind of inventory on it. If a pharmacy is all you need, start there; if you also run a blood bank or a surgical store, they sit on the same foundation instead of in a second product.

Can I define fields specific to my store?

Yes. Each inventory kind declares its own custom fields, and the screens render whatever that kind defines.

Do multiple hospitals share stock?

No, and that is deliberate. Stock is scoped to the hospital that holds it, so a group can run several units without one unit’s shelf appearing on another’s screen.

Is there an audit trail?

Yes. Movements are append-only, so the history of a batch can be read back rather than inferred.

See it on your own workflow

A quick, no-pressure walkthrough over WhatsApp or a call.

Book a demo →