Hospital Inventory: Why Consumption Data Is Always Wrong

Hospital inventory software is usually specified as a stock control problem: know what you hold, reorder before it runs out, do not let anything expire. That framing is why so many implementations end up with a system nobody trusts.

The reason is that a hospital's consumption data is systematically incomplete, and it is incomplete for reasons that are entirely rational from the perspective of the people creating the gap. Understanding that is the difference between a system that improves over time and one that gets bypassed.

The scan that does not happen

In a procedure room, a nurse needs an item now. The correct process is to scan it out against a patient and a procedure. The actual process, when a patient is on the table and something is needed immediately, is to take the item.

This is not carelessness. It is a correct prioritisation of clinical need over administrative accuracy, and any system design that treats it as user error will fail. The consequence is that recorded consumption lags real consumption, unevenly, and concentrated in exactly the high-value areas — theatres, cath labs, emergency — where accuracy matters most.

Designs that reduce the gap all work by making capture cheaper rather than by insisting on compliance. Scanning at the point of restock rather than at the point of use. Weight-based or RFID-based cabinets that record removal passively. Reconciling against the procedure record afterwards, so an implant recorded in the operative note but never scanned out is flagged for correction rather than silently lost.

Par levels are a moving target

Most systems reorder against a par level — a target quantity per location. Setting those is treated as configuration, done once at implementation, and then rarely revisited.

Consumption changes constantly. A new consultant with a preference for a different suture. A seasonal shift in case mix. A supply disruption that pushed everyone to a substitute they then kept using. Par levels set at go-live are wrong within months, and the symptom is not obvious — it appears as stockouts in some places and expiry write-offs in others, which get attributed to staff behaviour rather than to configuration drift.

A system that recalculates suggested par levels from observed consumption, and surfaces the ones that have drifted furthest, addresses more real cost than most forecasting features. It is unglamorous and it is where the money is.

Expiry management is a picking problem

Expiry write-offs are usually blamed on over-ordering. Frequently the stock quantity was correct and the wrong units were picked, because the newest arrivals were at the front of the shelf.

First-expiry-first-out only happens if the system tells someone which specific unit to take, and if the physical storage makes taking that unit as easy as taking any other. Software can do the first part. The second is a storage design question, and a system that instructs staff to retrieve a specific lot from the back of a crowded shelf will be ignored in favour of whatever is reachable.

Where lot-level tracking genuinely earns its cost is recall scope. A recall on a lot number, in a system tracking which patient received which lot, is a short query. Without it, the recall covers every patient who might plausibly have received the product, which is a materially different clinical and administrative exercise.

Consignment stock breaks the ownership model

High-value implants are often held on consignment: physically in your hospital, financially the vendor's until used. Most inventory data models assume you own what you hold, and consignment violates that assumption in a way that causes persistent reconciliation problems.

Consumption of a consignment item is simultaneously a clinical event, a stock movement and the trigger for a purchase. If those three are recorded in different systems at different times, they will disagree, and the resulting disputes with vendors are recurring and expensive. Modelling ownership explicitly on the stock record — rather than inferring it from location — is the fix, and it is much easier decided at design time.

Integration determines whether any of it works

An inventory system that cannot see the surgical schedule cannot anticipate demand. One that cannot see the procedure record cannot reconcile what was used. One that does not reach the purchasing system produces reorder suggestions somebody retypes.

These integrations are where the implementation time goes, and they are usually underestimated because the interfaces exist and therefore look straightforward. The difficulty is semantic rather than technical: matching a catalogue item to a charge code to a vendor part number, when three systems have three different identifiers and no authoritative mapping. That mapping work is the project, and it is worth scoping honestly at the start.

Substitutions break the catalogue

Supply disruption is routine, and the operational response is substitution: a different manufacturer's equivalent arrives and gets used in place of the usual item. Inventory systems generally model catalogue items as distinct, unrelated records, so a substitution looks like the original stockpiling out while an unfamiliar item appears.

The consequences compound. Consumption history splits across two records, so forecasting for both is wrong. Par levels for the original keep triggering reorders for something unavailable. Reporting on usage by category undercounts, because the substitute was never mapped to the category.

Modelling equivalence explicitly — a clinical equivalence group above the catalogue item — fixes all three at once. It also gives purchasing something useful: the ability to see what was actually consumed for a clinical purpose regardless of which manufacturer supplied it that month.

Counting is a control, and it needs to be cheap

Every inventory system drifts, so every one needs physical verification. The usual approach is a full annual count, which is disruptive, expensive, and produces a single large correction that tells you nothing about when the drift happened.

Cycle counting — small, frequent counts of a rotating subset, weighted toward high-value and high-movement locations — catches drift while it is still small and identifies where it originates. It is also more likely to actually happen, because counting one shelf is a task somebody can fit into a shift.

The software requirement is modest: generate the count list, accept the result on a mobile device, record the variance rather than silently overwriting, and trend variance by location. That last part is what turns counting from an accounting exercise into a diagnostic.

What to build first

Start where value density is highest — theatres and interventional areas — rather than attempting hospital-wide coverage. Make capture passive wherever the budget allows. Reconcile against clinical records instead of trusting scan discipline. Recalculate par levels continuously. Model consignment ownership explicitly.

A system covering three high-value locations accurately is worth considerably more than one covering everywhere with data staff have learned to distrust.