Most hospital inventory projects I have seen did not fail because the screens were ugly. They failed because the item was modeled like a retail SKU. Then the real world arrived: a case of twelve, a box of ten, an each, a lot, a serial, a UDI, an expiry, and a location that is a cabinet, a case cart, or an unlabeled drawer.
If you are building or integrating this kind of system, the data model is the product. Everything else is a view.
Start with identity. Hospitals need at least three identifiers, and they are not interchangeable. The internal item number is what purchasing and the ERP already use. The GTIN, plus the rest of the GS1 package hierarchy, is what is printed on the box. For devices, the UDI carries the device identifier plus production identifiers: lot, serial, and expiration. If you store "barcode" as a single string on the item, you cannot parse a scanned GS1 symbol into those fields, or tell a unit-of-use scan from a case scan. I have watched receiving teams "fix" this by scanning the case GTIN and incrementing the each-level quantity by one. The count stays wrong until the next physical inventory.
Units of measure have to be first-class and convertible. An item purchased by the case, stocked by the box, and used by the each needs a packaging hierarchy with a reliable conversion. Without it, PAR levels are meaningless. A PAR of six at the cabinet might mean six eaches or six boxes, and nurses will invent a workaround either way.
PAR itself is not a number on the item. It is a policy on an item at a location, with a unit, a review date, and often a different value for weekends. If you put min and max on the global item record, every satellite location will share a number that is wrong for all of them.
Expiry and lot are inventory dimensions, not optional attributes. Two boxes of the same item with different lots and dates are not the same on-hand row. Recalls, FEFO picking, and crash-cart checks all depend on that split. If on-hand is a single quantity, you will discover expired stock only when someone opens the package.
Then there is the ERP. Most hospitals already have an item master, purchase orders, and invoices in an ERP. The clinical supply tool should not invent a second master and hope the two stay aligned. Decide which system owns the item, the vendor, the unit cost, and the purchase unit of measure. A nightly file is not enough if clinicians need today's receipt in today's cabinet. Conflicts (same item, two descriptions, two units) need a queue with a human owner, not a silent overwrite.
Scan compliance is a data problem too. If a use event can be saved without a UDI or a lot when one was required, your traceability is a suggestion. Design the exception: an emergency override, a reason, and a follow-up task, not a blank field.
I keep a short list of healthcare supply chain software options nearby when a team is deciding what to build, buy, or interface to. Pharmacy, perpetual inventory, and surgical-supply tools do not share a data model. Read that as orientation, then design the item, the package, the location, and the lot before you draw a dashboard.
Get those four records right and the rest of the application has something true to display. Get them wrong and no amount of reporting will tell you what is actually on the shelf.
