Unique Device Identification (UDI)Glossary

Unique Device Identification (UDI)

Q: What’s the difference between DI and PI?

The Device Identifier (DI) is a fixed, catalog-level code that identifies the labeler and device model/version. Production Identifiers (PI) are variable elements such as lot/batch, serial number, expiration date, manufacture date, or software version that further specify the instance.

Q: Do all labels need both AIDC and HRI?

Yes in most cases. UDI must be presented in machine-readable form (AIDC) and Human Readable Interpretation (HRI), with limited exceptions. Both must reflect the same approved data.

Q: How does UDI relate to SSCC and EPCIS?

UDI identifies the medical device and its packages. The Serial Shipping Container Code (SSCC) identifies a logistics unit such as a pallet. EPCIS events record how UDIs are aggregated within SSCCs and how they move, enabling end-to-end traceability.

Q: What triggers a new DI?

Changes that alter the device's identity as marketed—e.g., device name/model, labeled quantity, sterilization method, or safety-relevant performance—typically require a new DI. Minor artwork changes may only require master data updates.

Q: Can software devices carry UDI?

Yes. Software as a medical device displays UDI in an 'about' or start-up screen. Major version changes may require a new DI; minor updates may change only the PI (version). Follow issuing-agency and regulator guidance.

This topic is part of the SG Systems Global regulatory & operations glossary.

Updated October 2025 • Medical Device Identification & Labeling • Quality, Regulatory, Manufacturing, Supply Chain

Unique Device Identification (UDI) is the standardized identity for medical devices. It appears on packaging (and, when required, directly on the device) in two forms—machine‑readable AIDC (e.g., barcode, DataMatrix) and Human Readable Interpretation (HRI)—and is submitted to regulator‑hosted master data repositories. In the U.S., UDI is established by 21 CFR Part 830 and the device label requirements of Part 801; in the EU it is embedded in MDR/IVDR with registration in EUDAMED. UDI makes every downstream task faster and safer: receiving and stocking in the WMS, execution in MES, vigilance and recalls, and end‑to‑end traceability.

“UDI is the device passport: one global identity that every scanner, screen, and system can trust.”

TL;DR: A UDI contains a Device Identifier (DI)—the static, catalog‑level code—and Production Identifiers (PI)—dynamic attributes like lot/batch, serial, expiration, and manufacture date. It must be printed/encoded on the label in AIDC + HRI, verified before release, and registered to the regulator’s database (e.g., GUDID/EUDAMED). Most manufacturers use GS1, HIBCC, or ICCBBA as issuing agencies. Control the DI life‑cycle under Document Control, verify barcodes in line (Label Verification), and integrate scanning across MES/WMS to power rapid recall response and DHR accuracy.

1) What UDI Covers—and What It Does Not

Covers: the unique identification of medical devices and their labeled packages, the placement and format of that identity on the label and, when applicable, on the device itself (direct part marking), and the submission of associated device master data to regulator systems. UDI supports downstream activities—inventory control, installation tracking, complaint/field action management, and post‑market surveillance.

Does not cover: UDI is not the same as serialization used in pharma distribution, and it is not a logistics code like SSCC. UDI does not replace quality system requirements (e.g., 21 CFR 820 or ISO 13485) nor does it by itself assure product authenticity—those rely on controlled processes, secure systems, and effective labeling governance.

2) Regulatory & System Anchors

The U.S. framework resides in 21 CFR 830 (system, issuing agencies, GUDID submissions) and Part 801 (labeling requirements including AIDC and HRI, placement, and direct marking for reprocessed/reusable devices). The EU MDR/IVDR regime aligns conceptually but introduces the Basic UDI‑DI, a higher‑level key that links related DIs (configurations, kits, variants) for regulatory submissions. Many other markets have converging rules; manufacturers commonly implement a global core model with regional data add‑ons, governed under change control and Data Integrity expectations.

3) Anatomy of a UDI: DI vs PI

The Device Identifier (DI) is the fixed key that identifies the labeler and specific model/version of a device as marketed. The Production Identifiers (PI) are variable elements that further specify the instance, such as lot/batch number, serial number, expiration date, manufacture date, and—where applicable—software version. If any of these appear on the label, they must be represented in the UDI. Issuing agencies define the data syntax: GS1 uses GTIN for the DI (see GS1 GTIN) with Application Identifiers for PIs; HIBCC uses the HIBC primary/secondary data structure; ICCBBA’s ISBT 128 is used for certain HCT/P and blood components. DI changes are governed—many label or design changes trigger a new DI, while routine updates may not. Treat DI assignment like part numbering: deliberate, documented, and consistent across ERP/MES/labeling.

4) Carriers, HRI & Direct Marking

Labels must present UDI in AIDC (machine‑readable) and HRI (plain text). Common carriers are linear GS1‑128 and two‑dimensional GS1 DataMatrix; HIBC supports Code 128/Code 39 and DataMatrix. Carrier choice depends on label real estate, scan distance, print method, and hospital workflows. For devices intended to be reused and reprocessed between uses, direct part marking is required (unless technically infeasible or performance would be compromised). Direct marking can be laser etch, dot peen, or durable label stock validated for cleaning/sterilization cycles. For software as a medical device, the UDI must be displayed in an “about” screen or splash screen, and versioning rules determine when the DI or PI changes. All of this is governed by your labeling SOPs and verified continuously via barcode verification and visual inspection criteria.

5) Master Data Submission: GUDID & EUDAMED

Beyond the physical label, UDI requires master data submission to regulator databases. In the U.S., the Global UDI Database (GUDID) stores attributes such as device name, DI, packaging levels, clinically relevant sizes, sterilization status, MRI safety, and direct marking indicators. In the EU, EUDAMED’s UDI/Device modules record Basic UDI‑DI linkages, certificate references, and market attributes. Submissions can be manual or automated; whichever approach you adopt, ensure that the UDI master in your PLM/ERP is the system of record, that versioning is effective‑dated, and that change control prevents orphaned or inconsistent entries. Treat submission acknowledgments, error logs, and periodic updates as controlled records under Document Control and retain them with the DHR/technical file trail.

6) Packaging Levels, Aggregation & Logistics

UDI exists at every labeled package level: unit (or unit‑of‑use), inner pack, carton, shipper. Each level gets its own DI and may carry different PI (e.g., case‑level lot/expiry only). Logistics units such as pallets are typically identified with SSCC; the SSCC is not a UDI but should carry the lower‑level UDIs via electronic aggregation events (see EPCIS). In practice, your WMS scans UDI at receipt, maintains lot/serial status, enforces FEFO for dated devices, and prints compliant labels for kitting or relabeling under QA control. Clean aggregation models accelerate Pack & Ship and support precise, surgical recalls.

7) Life‑Cycle & Change Control

UDI is a life‑cycle artifact. New products require DI assignment, label design, barcode verification, and database submission before commercial release. Post‑market, certain changes trigger a new DI (e.g., device name/model, labeled quantity, sterilization method, or performance characteristics that affect safety); others only require master data updates. EU’s Basic UDI‑DI adds a bundling key that persists across related configurations, kits, and variants. Embed DI/Basic UDI‑DI rules into your MOC so engineering changes cannot progress without UDI impact assessment, and ensure effective dating across labeling, ERP, and regulator databases to avoid field confusion or scanning failures.

8) Execution: From Printing to Scanning in MES/WMS

High‑reliability UDI programs tie label printing to controlled data, not manual entry. The label template pulls DI and PI from the master; the line system renders AIDC and HRI, drives printers, and captures verification images/scores. During manufacturing, MES binds the UDI to the DHR and enforces checks at critical steps (e.g., correct DI for the order, correct PI for date codes, prevention of label reuse). In the warehouse, handhelds and portals default to UDI scanning for receiving, put‑away, picking, cycle counting, and returns—reducing manual data entry and preventing mis‑issue. Throughout, audit trails prove who printed what, when, and on which device, forming the evidence pack for inspections and field actions.

9) Complaints, Vigilance & Recall Readiness

UDI shines when something goes wrong. A complaint with a photo of the label can instantly resolve identity, manufacturing date, and batch/serial linkages. Field safety notices and recalls become targeted rather than sweeping: use DIs to define scope and PIs to pinpoint affected units. In hospitals, scanned UDI at point of care allows inventory blocks or alerts to prevent use of affected stock. Internally, UDI ties into Recall Readiness drills and trending; externally it supports regulator expectations for rapid, accurate market notifications. The speed of trace relies on label quality, scan compliance, aggregation fidelity, and clean UDI master data.

10) Human Factors & Small Labels

UDI is for humans too. HRI must be legible: font size, contrast, symbol placement, and language conventions matter. Small syringes, implants, and leads force tough trade‑offs; 2D symbols like DataMatrix can help, but you must validate readability under real lighting and contamination conditions. Direct marking must survive cleaning and sterilization; validate legibility over the device’s expected reprocessing cycles and keep the results with the DMR/DHF/DHR chain. Exceptions should be justified and documented, not assumed. Clear, standardized HRI (e.g., GS1 AI parentheses) prevents transcription errors when scanners are unavailable.

11) Metrics That Demonstrate Control

Label verification pass rate: percentage of lots meeting AIDC quality grades on first pass.
Scan compliance: share of transactions using UDI scans rather than manual entry in MES/WMS.
Master data latency: time from change approval to GUDID/EUDAMED update and effective use on line.
Complaint identification speed: median time to positively identify DI/PI from field evidence.
Recall precision: proportion of withdrawn units that were truly affected (high precision indicates tight UDI scope definition).

These indicators show whether UDI is operationalized—not just printed—and whether the organization can act quickly and surgically when it matters most.

12) Common Pitfalls & How to Avoid Them

DI/ERP mismatches. Keep one master record; propagate to ERP, MES, WMS, labeling, and regulator databases via controlled interfaces.
Unscannable or non‑compliant barcodes. Verify every print engine and each substrate; store grades and images as part of the batch pack.
Incorrect AIs or date formats. Lock templates; never allow free‑text AIs or local date conventions that break downstream parsing.
Skipping direct part marking validation. Prove permanence and legibility through reprocessing; record results with the DMR/DHF.
Weak aggregation. Don’t confuse UDI with SSCC; use EPCIS or equivalent events to maintain parent–child linkages.
Late or inconsistent submissions. Treat GUDID/EUDAMED like a production system with release management, not a side spreadsheet task.

13) What Belongs in the UDI Master Record

Maintain a controlled record containing: issuing agency and code scheme; primary DI (and secondary DIs if used), EU Basic UDI‑DI where applicable; PI composition and rules (which elements are printed/encoded and when); all packaging levels with their DIs; label templates and approval history; barcode verification criteria and historical results; direct part marking method and validation; device master attributes required for regulator databases; submission history and acknowledgments; and the cross‑references to SKUs, routings, and bills of materials. Tie this record to the DHR so every shipped unit can be reconstructed from scan evidence, not tribal memory.

14) How This Fits with V5 by SG Systems Global

UDI Master & Governance. The V5 platform centralizes DI/PI definition with effective‑dated versions, approval workflows, and role‑based access. UDI data is a first‑class master shared to ERP, MES, WMS, and labeling under controlled interfaces, eliminating copy‑paste drift.

Labeling & Inline Verification. V5 drives label templates from the UDI master so AIDC and HRI always reflect approved data. It triggers print jobs, captures verifier grades/images, and blocks release if symbols fail policy—integrating directly with label verification and e‑signature review.

MES/WMS Execution by Scan. In V5 MES and the V5 WMS, UDI is the default key for receiving, kitting, work execution, packing, and returns. Scan interlocks prevent mis‑issue and mis‑label; FEFO and quarantine rules are enforced using PI dates and QA statuses through to Finished Goods Release.

Aggregation & Events. V5 records parent–child linkages between unit, inner, carton, and logistics units, leveraging SSCC for shippers and emitting EPCIS events for customers who consume them—so UDI stays intact from line to loading dock.

Regulatory Submissions. V5 maintains the data set required for regulator repositories and can produce validated extracts for GUDID/EUDAMED submission, with audit trails and change‑impact checks that align with ALCOA(+) expectations.

Bottom line: V5 turns UDI from a label project into an enterprise identity system—governed, scanned everywhere, and ready for audits and recalls.

15) FAQ

Q1. What’s the difference between DI and PI?
The DI is the fixed model/version identifier assigned by an issuing agency; PIs are variable elements (lot, serial, expiry, manufacture date, software version) that further specify the instance.

Q2. Do all labels need both AIDC and HRI?
Generally yes. UDI must appear in machine‑readable (AIDC) and human‑readable (HRI) form, with limited exceptions. Both forms should be generated from the same approved data to avoid mismatch.

Q3. When is direct part marking required?
For devices intended to be used more than once and reprocessed between uses, unless technically infeasible or it would adversely affect the device. Validate permanence and legibility over the expected reprocessing cycles.

Q4. How does UDI relate to SSCC and EPCIS?
UDI identifies the device and its packages; SSCC identifies the logistics unit (e.g., pallet). EPCIS events carry UDI content through the supply chain by recording which UDIs are inside which SSCCs and where they moved.

Q5. What triggers a new DI?
Changes that affect device identity as marketed—such as device name/model, labeled quantity, sterilization method, or safety‑relevant performance—typically require a new DI. Minor artwork updates usually do not. Embed rules in change control.

Q6. Can software devices carry UDI?
Yes. Software as a medical device displays UDI in an “about” or start‑up screen; major version changes may require a new DI, while minor patches may update PI (version) only—follow issuing‑agency and regulator guidance.