Medical Inventory Barcode Scanner UI in SwiftUI

What makes medical inventory different from retail scanning?

The barcode carries more than a price, and getting an item wrong has consequences a store never faces. A medical supply or drug barcode is a GS1-standard code that encodes not just the product but the lot number and expiry date, often as a 2D GS1 DataMatrix that packs roughly 10x the data of a linear barcode, and many devices carry a Unique Device Identification (UDI) code that ties the physical item to a regulatory record. So a medical inventory scanner is not “scan, decrement count”; it is scan, parse the lot and expiry, and track this specific batch, because a recall, an expiry, or a stock-out is a patient-safety event, not a margin problem.

That reframes the whole app. The unit of inventory is not the product, it is the lot: 40 units of a drug expiring in March and 60 expiring in September are different inventory the system must treat separately, so the scanner’s job is capturing which exact batch is on the shelf, and the app’s job is acting on what that batch’s expiry and recall status mean.

How does the scanner parse a GS1 medical barcode?

Scan with VisionKit’s DataScannerViewController (or AVFoundation), but the value is in what you do after the read. A GS1 DataMatrix is not a plain number; it is a structured string of Application Identifiers, where (01) is the GTIN (the product), (17) is the expiry date, and (10) is the lot number, all in one scan. The parser splitting that apart is the actual feature:

AI code	Field	What the app does with it
(01) GTIN	Product identity	Match to the catalog item
(17) Expiry	Use-by date	Flag near-expiry, block expired
(10) Lot	Batch number	Track this batch separately; the recall unit
(21) Serial	Unique item	Per-item tracking where required

A retail scanner that reads only the GTIN and ignores the rest is the wrong tool here, because the lot and expiry are the entire point. One honest implementation note: medical barcodes are dense 2D codes in often-poor storeroom lighting, so a reliable scan needs good camera handling (a torch, a clear viewfinder) and graceful manual entry for a damaged label, the same scan-resilience discipline as any barcode scanner viewfinder, and the same gloved-warehouse ergonomics as the warehouse inventory scanner.

What does the app owe a clinician or stockroom manager?

Action on expiry and recall, because those are the failures that matter. Expiry is first-class: the inventory view sorts and flags by use-by date (first-expiry-first-out, not just first-in-first-out), near-expiry items surface for use or return before they are wasted, and an expired item scanned at the point of use triggers a clear, hard warning, never a silent decrement. Recall handling is the safety feature that justifies lot tracking: when a lot is recalled, the app can identify exactly which batches are on which shelves, because it captured the lot at scan time, which a count-only system simply cannot do.

The workflows are stockroom-shaped: receiving (scan in, capture lot and expiry, add to the batch), counting (cycle counts that reconcile shelf to system), and consumption (scan at point of use, decrement the right lot). Each is a fast, scan-driven flow because the user is standing at a shelf, often gloved, under time pressure, so big targets, audio confirmation, and minimal typing are not polish but requirements. This is genuine b2b: the regulatory and traceability requirements (lot traceability, expiry control, recall response) are why the app exists, the same compliance-is-the-product framing as other regulated builds.

What completes it?

The boring, essential parts: a per-lot stock model as the data foundation, role-aware access (who can adjust inventory), an audit trail (medical inventory adjustments need a who-and-when record), and honest sync for a stockroom with patchy Wi-Fi, where scans queue locally and reconcile rather than failing. None of this is glamorous, and all of it is the difference between a demo and a system a hospital would actually run.

The screens, the scanner with live GS1 parsing, the per-lot inventory list sorted by expiry, the receiving and counting flows, the recall view, come as a free VP0 design, so an agent builds the GS1 parser and the per-lot model onto a UI already shaped for batch tracking and expiry action rather than a retail count.

The high-throughput variant, continuous capture with deduplication across frames, is built in the pallet bulk scanner.

Key takeaways: a medical inventory scanner

• The unit is the lot, not the product: scan captures lot and expiry, because batches expire and get recalled separately.
• Parse the full GS1 barcode: GTIN (01), expiry (17), lot (10) in one DataMatrix scan; reading only the GTIN is the wrong tool.
• Expiry and recall are the point: first-expiry-first-out sorting, hard warnings on expired items, and lot-level recall identification.
• Scan flows are stockroom-shaped: big targets, audio confirmation, torch, manual fallback, for a gloved user at a shelf.
• The unglamorous parts are the product: per-lot model, audit trail, role access, and offline-queue sync make it a real system.

Frequently asked questions

How do I build a medical inventory barcode scanner in SwiftUI? Scan GS1 DataMatrix codes with VisionKit’s DataScannerViewController, parse the Application Identifiers (GTIN, expiry, lot) into a per-lot inventory model, and build expiry-sorted views with hard warnings on expired items and lot-level recall identification. A free VP0 design supplies the scanner, per-lot list, and receiving and counting screens.

Why does medical inventory need lot tracking, not just counts? Because batches differ in ways that matter for safety: 40 units expiring in March and 60 in September are different inventory, and a recall targets specific lots. Capturing the lot and expiry at scan time lets the app enforce first-expiry-first-out and identify exactly which batches are on shelves during a recall, which a count-only system cannot do.

How do I parse a GS1 medical barcode? A GS1 DataMatrix is a structured string of Application Identifiers, not a plain number: (01) is the GTIN, (17) the expiry date, (10) the lot, and (21) a serial where used. The parser that splits these apart from one scan is the core feature; a scanner reading only the GTIN ignores the lot and expiry that medical inventory depends on.

What should happen when an expired item is scanned? A clear, hard warning at the point of use, never a silent decrement: the app knows the expiry from the barcode, so scanning an expired item must block or strongly flag it. Near-expiry items should surface earlier in expiry-sorted views so they are used or returned before they are wasted.

Is a medical inventory scanner different from a retail one? Yes: retail scanning reads a product and adjusts a count, while medical inventory must capture the lot and expiry per batch, enforce expiry control, and respond to recalls, because a stock-out, expired item, or missed recall is a patient-safety event. The regulatory and traceability requirements are why the app exists.