# UDI at the Point of Use: How to Build a Recall-Ready Hospital Supply Chain Source: https://fleetroot.com/blog/udi-at-the-point-of-use-how-to-build-a-recall-ready-hospital-supply-chain Published: 2026-10-01 · Category: Delivery management · Author: Fleetroot Team A hospital cannot manage a recall if it only knows the product type. It must know which device was received, which lot or serial number was used, which items remain in stock,… A hospital cannot manage a recall if it only knows the product type. It must know which device was received, which lot or serial number was used, which items remain in stock, which patient received the device, and whether the item is still somewhere in the delivery flow. This is the role of Unique Device Identification, or UDI. UDI connects the manufacturer, distributor, hospital, department, clinician, patient record, and financial system. At the point of use, it stops being a label and becomes operational data. A recall-ready hospital supply chain captures UDI at receipt and at use, then uses that data to drive inventory control, patient traceability, charge capture, and delivery decisions. ## UDI-DI and UDI-PI serve different purposes A UDI has two main parts. ### UDI-DI identifies the device The UDI-DI, or Device Identifier, identifies: - The manufacturer or labeler. - The specific device model. - The device version or package configuration. It is relatively stable. It tells the hospital what the product is. ### UDI-PI identifies the production instance The UDI-PI, or Production Identifier, carries variable production data such as: - Lot or batch number. - Serial number. - Expiration date. - Manufacturing date. The UDI-DI identifies the product category. The UDI-PI identifies the exact production instance. That is why lot plus expiry capture is the point. A recall may affect one lot or one expiry range, not every unit of the model. If the hospital captures only the UDI-DI, it can identify the product but not isolate the affected stock or patient use precisely. The [FDA UDI system](https://www.fda.gov/medical-devices/unique-device-identification-system-udi-system/udi-basics) confirms that the UDI consists of a Device Identifier and applicable Production Identifiers. Hospitals should store the UDI-DI and each relevant UDI-PI component as separate fields. ## Capture UDI at receipt and point of use UDI data must enter the supply chain in more than one place. ### Capture at receipt At the receiving dock, scan each device, case, or tray according to the hospital’s control model. Record the minimum data needed to control the item later: - UDI-DI. - Lot or batch number. - Serial number, where applicable. - Expiration date. This creates the first traceability event. It tells the hospital what arrived and which production instance is now in inventory. ![Receiving specialist scanning medical device packaging with barcode and RFID-enabled inventory](https://cdn.marblism.com/QeyNZrWdJdC.webp) ### Capture at point of use The second capture point is where the device is opened or used: operating theatre, cath lab, emergency department, pharmacy, ward, or procedure room. Do not rely on the receiving transaction alone. Point-of-use capture links the device to: - The patient encounter. - The procedure. - The inventory decrement. - The charge event. The [AHRMM barcode-at-point-of-care guidance](https://www.ahrmm.org/system/files/media/file/2019/11/Barcode-at-POC-work-group-report-102019.pdf) describes barcode scanning as a method for improving supply visibility, documentation, and usage capture. The scan should create one structured event, not separate manual entries across systems. ## Feed one UDI event into every required system UDI creates value only when the data moves beyond the scanner. One scan should feed the core systems that need the event: - ERP or MMIS for inventory and purchasing. - EHR for patient and procedure documentation. - Charge capture for billing. - Recall and replenishment workflows. In practice, the clinician scans the device once, the EHR records it against the patient and procedure, the ERP decrements stock, charge capture posts it to the encounter, and the logistics or recall workflow stores the lot and expiry relationship for downstream action. This removes duplicate entry and reduces the use of spreadsheets or side databases that create inconsistent device records. ![Clinical technician scanning UDI at point of use with connected hospital systems](https://cdn.marblism.com/wfPlAZjE3a4.webp) ## Treat recall and expiry as delivery promises A healthcare delivery is not complete when a box reaches the hospital. It must reach the right department with the right device, the right lot, a valid expiry date, and a delivery window that still supports the procedure. This changes the definition of last-mile delivery in healthcare logistics. The promise is not just arrival. The promise is usable, traceable product. A hospital logistics platform should validate lot and expiry before dispatch and maintain status visibility across dispatch, transit, handoff, and use. That matters to hospital operators, healthcare distributors, and 3PL logistics companies moving medical supplies. Fleetroot’s [healthcare last-mile logistics overview](https://fleetroot.com/blog/last-mile-logistics-in-healthcare-why-every-minute-matters) provides additional context on time-sensitive healthcare delivery operations. Its [logistics solutions](https://fleetroot.com/solutions) can also support orchestration across orders, routes, drivers, and delivery events. ## Handle quarantined lots inside live delivery runs A recall can arrive after a shipment has already been picked or dispatched. The route cannot be treated as static. When a lot is quarantined, the system should: 1. Identify the affected UDI-PI records. 2. Locate the affected inventory by facility, department, vehicle, or route. 3. Stop the incomplete delivery and notify the driver and destination. 4. Replace the item and record the exception with chain of custody. Do not cancel the full delivery run unless required. Recalculate around the blocked item and keep unaffected orders moving. The same logic applies to expiry alerts: if an item becomes unusable before the procedure, the platform should create a replacement task and update the delivery promise. ![Hospital logistics coordinator managing a quarantined lot and temperature-controlled department delivery](https://cdn.marblism.com/6mZKkgK40ZS.webp) ## Build the ROI case around measurable control The business case should be based on control and financial recovery, not on feature lists. Published examples show that the impact can be material. Florida Hospital Cardiovascular Institute reported approximately **$1.7 million in annual savings** from improved tracking and demand prediction. University Health Network reported **$14 million in savings over five years** from an operating-room supply chain transformation. A Duke Health case also reported approximately **$600,000 in annual revenue recognition** through better point-of-use capture. These are implementation-specific results, not universal benchmarks. The internal model should still be simple: > Annual value = avoided expiry write-offs + recovered charges + reduced labor + avoided stockouts + lower carrying cost + recall-response savings Start with one service line, prove the data flow, then expand. ## FAQ ### What is the difference between UDI-DI and UDI-PI? UDI-DI identifies the device model, while UDI-PI identifies the specific lot, serial, and expiry details tied to that unit. ### Why are lot and expiry the critical fields? Because recalls and usability decisions often apply to a specific lot or expiry range, not to every unit of the device model. ### What should happen when a recalled lot is already in transit? The system should quarantine the item, stop or reroute the task, notify the driver and destination, and trigger a replacement with a recorded chain of custody.