Hospital pharmacy expiry management: the shrinkage that never appears as a loss

Why expired pharmacy stock disappears into consumption instead of showing up as a loss, and what a hospital can fix about it without buying anything.

Ask a hospital owner what their pharmacy lost to expiry last year and you will usually get a pause, then a guess, then a promise to check. That pause is the whole subject of this piece. Hospital pharmacy expiry management fails less because stock expires and more because the expiry never becomes a number anyone is accountable for. The write-off is posted to consumption or to a sundry adjustment, gross margin absorbs it, and the loss is reported as though the medicine had been sold.

The direct answer: expiry is not an event you manage on the day it happens. It is a window that opens months earlier, when a batch stops moving, and closes in stages — first when the distributor's return window lapses, then when internal transfer to another department stops being worth the paperwork, then when the strip becomes waste. Managing expiry means managing that window. Counting the waste at the end manages nothing.

Why the window closes quietly

In most hospitals nothing is broken in any one place. The loss lives in the seams between places.

• Stock is bought in aggregate and expires in batches. Purchase decisions are made on item-level stock on hand. Expiry belongs to a specific batch with a specific date. If your reorder screen shows "1,200 units" and not "400 of them expire in seven weeks," the buyer cannot see the problem they are about to make worse.
• The person who orders is not the person who dispenses. The store sets reorder levels, often once, often years ago, often copied from the last system. Consumption patterns move — a consultant leaves, a scheme changes, a protocol is revised — and the reorder level does not move with them.
• Slow movement looks like nothing until it looks like a write-off. There is rarely a report that says "this batch has not moved in 60 days and expires in 90." There is a physical count, and by then the answer is already fixed.
• The return clause is a document, not a workflow. Most distributor agreements allow returns inside a defined window before expiry. That window is known to procurement and invisible to the pharmacy counter. Nobody is tasked with the date.
• The accounting hides it. If expired stock is written off into consumption, the P&L shows a slightly worse material cost ratio, not a loss. Nothing in the month-end pack forces anyone to explain it.

The result is a form of shrinkage that behaves differently from theft. Theft eventually produces a variance someone chases. Expiry produces a rounding error in gross margin that everyone accepts.

What to fix before you buy anything

Several of these cost nothing but attention, and they work on whatever system you already run.

• Give the write-off its own line. Stop letting expired stock settle into consumption. A separate expiry write-off account, reported monthly to the same people who see claim rejections, changes behaviour faster than any software.
• Produce a near-expiry report by batch, not by item. Ninety, sixty and thirty days out. If your current system can export batch and expiry date, a spreadsheet will do it this week.
• Read your distributor contracts and diarise the return windows. One page per supplier: how many days before expiry returns are accepted, in what condition, against what documentation. Then make the ninety-day report trigger the return, not the reminder.
• Reconcile reorder levels against twelve months of actual consumption. Not the last quarter. A full year catches seasonality and catches the items that stopped moving when a doctor left.
• Make inter-department transfer easy. Stock that is dead in the main store is sometimes live in casualty or in the OT. If transferring requires three signatures, it will not happen before expiry.
• Close the paperwork loop on returns. When goods go back to a distributor, a credit note follows, and the credit note is one of the documents that sits inside the GST e-invoicing framework — the GST e-invoicing glossary published on the GST portal sets out the document types and terminology involved. Returns that are never documented correctly turn a recoverable loss into a permanent one.

Where Ospia fits

Ospia HOS is an AI-native Hospital Operating System rather than another hospital management system, and it is running hospitals in production today. Two of its twenty-one agents sit directly on this problem. The Pharmacy Expiry Watch keeps expired stock out of the dispensary and gives the pharmacy enough warning to dispense short-dated batches first. The Inventory Watch learns reorder levels from real consumption and supplier lead times, and raises orders within the hospital's approval matrix rather than around it.

The architecture matters more than the agents here. In Ospia, Pharmacy dispenses and Inventory owns stock: dispensing publishes a MedicineDispensed event and Inventory decrements by subscription. There is no nightly reconciliation between two vendors' modules to go wrong. Every event is retained permanently, so the question "when did this batch stop moving, and who saw it" has an answer months later rather than an argument.

How far the agents may act on their own is a dial the hospital holds, set per task from L0 to L4. Action risk classifies the action; autonomy maturity configures how far automation may currently go for that action at that hospital — the two are separate settings. The levels shown on our site are illustrative starting points, not fixed. Execution above L2 requires a named human, and L4 requires a policy the hospital approved. Raising or lowering a level is an audited decision with a name attached. And because Ospia runs as a complete system with no external AI configured at all, using deterministic fallbacks on assistive paths, none of this becomes a dependency for the pharmacy to keep dispensing.

We do not publish a figure for what this saves. No total-cost-of-ownership or savings percentage goes on our site until the hospitals now running on Ospia have a full cycle behind them and agree to publish it.

If you are comparing platforms for this specifically, scope is the question to ask first. We categorise Practo Ray as a clinic-first, outpatient platform, and it is a capable one in that scope — practice management for an outpatient practice is a different job from inpatient batch-level stock control across a hospital store, a satellite pharmacy, the OT and the ICU. If your problem is the former, the comparison is not close, and it does not favour us.

A reasonable first step costs nothing: run the revenue leakage calculator, which is published ungated with no email address or form submission, and see where pharmacy sits against the other places money goes missing. If it is the largest line, you have found your project. If it is not, you have saved yourself one.