UDIUnique Device Identification

Unique Device Identification (UDI) is a global system that assigns every medical device a unique, machine-readable identifier and binds that identifier to a public registry of attributes — manufacturer, model, dimensions, sterilisation, MR-compatibility, single-use vs reusable, and dozens more. It was created so that when a device is implicated in an adverse event, a recall, or a counterfeiting investigation, anyone in the supply chain — hospital, distributor, regulator, patient — can scan the device and unambiguously identify what it is and where it came from.

In the United States the rule is 21 CFR Part 830 (the UDI Rule, 2013) plus the labelling consequences in 21 CFR 801.20. In the European Union it is Articles 27–28 of MDR 2017/745 and Articles 24–25 of IVDR 2017/746. The two systems are conceptually aligned — both follow the IMDRF UDI guidance — but they use different databases (GUDID for the US, EUDAMED for the EU) and have non-identical timelines and data fields. Most exporters end up submitting to both.

A UDI is composed of two parts. The Device Identifier (DI) is the static, mandatory part — it identifies the manufacturer and the specific version or model of the device. The Production Identifier (PI) is the conditional, dynamic part — it identifies the unit or batch and varies from unit to unit.

Device Identifier (DI)

The DI is the primary key into the public registry. One DI corresponds to exactly one row in GUDID (or one Basic UDI-DI / UDI-DI pair in EUDAMED). Change a labelled attribute — change the trade name, change the package configuration, change the sterilisation method — and you need a new DI. Manufacturers obtain DIs through an FDA-accredited issuing agency: GS1 (which issues GTINs), HIBCC (which issues HIBC LIC numbers), or ICCBBA (for blood, cellular and tissue products). Most non-blood device makers use GS1.

Production Identifier (PI)

The PI is whatever lot, batch, serial number, manufacturing date or expiration date is on the label. The MDR and 21 CFR 830.20(b) require the PI to include whichever of these appear on the label. If your label shows a lot and an expiration date, both go in the PI. If your label shows a serial number, that goes in the PI. Implantable devices and software-as-a-medical-device have additional PI rules — implants require a serial number; software requires a UDI that changes when the software version changes.

21 CFR 830.20 and Annex VI of the MDR both require the UDI to appear on the device label in two forms: an Automatic Identification and Data Capture (AIDC) form — a barcode or RFID — and a Human-Readable Interpretation (HRI) — plain text a person can read. Both must contain the same information. If the AIDC contains a lot number, the HRI must show that lot number too.

The AIDC carrier is usually a GS1-128 linear barcode, a GS1 DataMatrix 2D code (the dominant choice for small labels and direct part marking), an RFID tag for high-volume scanned-in-bulk products, or a HIBC equivalent. The carrier is the manufacturer's choice as long as it conforms to the issuing-agency standard. The HRI is human-readable, must use the issuing agency's parenthesised AI format (e.g. (01)00012345678905(10)ABC123(17)260531), and must be printed legibly at point-of-use distance.

21 CFR 830.40 and MDR Article 27(4) require devices that are intended to be reprocessed (cleaned, sterilised and re-used) to carry the UDI marked permanently on the device itself — Direct Part Marking. Surgical instruments, orthopaedic trays and other reusable hardware fall into this category. The mark must be readable through the device's normal life, which usually means laser-etched or dot-peened DataMatrix codes, validated to survive the manufacturer's recommended reprocessing cycles.

DPM has its own technical standards — ISO/IEC TR 29158 (AIM DPM grading) is the de facto verification standard. The mark must be readable after a specified number of sterilisation cycles, and the manufacturer must validate that. Failed DPM verifications are a common 510(k) and Notified Body finding.

Every DI must be submitted to a registry. In the US that is GUDID — the Global Unique Device Identification Database, operated by the FDA and freely searchable at accessgudid.nlm.nih.gov. In the EU it is EUDAMED, operated by the European Commission. Submission is the manufacturer's responsibility, not the issuing agency's.

GUDID submission

GUDID accepts roughly 60 attributes per device — brand name, version/model, sizes, sterilisation status, single-use flag, latex content, MR safety status, the manufacturer's labeller DUNS number, GMDN code, etc. Submission is via HL7 SPL (Structured Product Labeling) XML, either uploaded one device at a time through the GUDID web interface, or in bulk via the GUDID ESG (Electronic Submissions Gateway). Most manufacturers use a regulatory-information-management vendor (RIM) or build their own SPL generator.

EUDAMED

EUDAMED uses a two-tier identifier — the Basic UDI-DI (one per device group, used in technical documentation and CE certificates) and the UDI-DI (one per packaging level, equivalent to the GUDID DI). It requires roughly 30 device attributes plus links to certificates, declarations of conformity, and post-market surveillance reports. EUDAMED's UDI module has been operational on a voluntary basis since late 2021 and is becoming mandatory in stages through 2026 and beyond.

UDI is fundamentally a labelling and traceability obligation, which means the manufacturing system has to do four things every time it makes a unit.

1. Print the correct UDI on the unit label, the next-higher package, and any case-level pack — with the correct AIDC carrier and the correct HRI. The label artwork is part of the DMR (21 CFR 820.181) and must be under change control.
2. Capture the printed UDI (or at minimum the PI portion — the lot or serial) on the DHR for that unit or batch, so that a future recall can trace from UDI back to the manufacturing record.
3. Verify the print before release. A label-control step (in process or at finished-goods QC) must scan the printed barcode and confirm it parses to the expected DI and PI. Unreadable or wrong UDIs are a 21 CFR 820.86 (Acceptance status) finding.
4. Reconcile the UDIs issued against the units produced. A missing serial means a unit went out without a UDI, or two units went out with the same UDI — both are recall-grade events.

The original FDA UDI rulemaking was driven by the 2011 Institute of Medicine report on medical-device safety, which found that hospitals could not reliably identify implanted devices when adverse events occurred. The system was designed so that a hospital's electronic health record could scan a UDI from a hip implant and pull the device's recall status in real time.

For the manufacturer, the practical consequence is that recall scope is decided by UDI. When the FDA's Sentinel system or an MDR/IVDR competent authority issues a recall, it names UDIs — usually a DI plus a PI range. The manufacturer must produce, within hours, a list of every customer that received units in that range. That list comes from the DHR-to-shipment trace. A manufacturer that captured only 'lot 2406A — 500 units' on the DHR cannot answer a recall scoped to serials 2406A-0250 through 2406A-0380 without recalling all 500.

The reverse direction matters too. A hospital reports an incident and gives a UDI. The manufacturer must trace from the UDI back through the DHR to the components, the materials, the operators, the equipment and the in-process test results. If that trace is broken, the post-market investigation stalls, the MDR/MDV report deadline (15 or 30 days under 21 CFR 803) gets harder to meet, and the regulator escalates.

Not every device needs a UDI. 21 CFR 801.30 lists the exceptions, including Class I devices that are non-life-sustaining and bear a UPC code, certain custom devices, devices used only in clinical investigations, and devices that are not labelled (typically because they are used solely within the manufacturer's facility). EU MDR Annex VI Part C lists analogous EU exceptions.

Software as a Medical Device (SaMD) has its own treatment. The UDI for software changes when the software version changes in a way that could affect safety or efficacy — generally with every major or minor release, not with patch releases. The UDI is carried in the software's about screen, in any displayed startup banner, and in machine-readable form via the software's API or output files.

Combination products (e.g. drug-eluting stents, prefilled syringes) carry the UDI for the device constituent. The drug constituent retains its NDC. Both identifiers appear on the label and both are traced separately.

1. GUDID record does not match the label. Brand name updated on the label but not in GUDID, or vice versa. 21 CFR 830.310 finding.
2. Label artwork edited outside change control. The DMR's approved artwork and the printed artwork diverge — 21 CFR 820.30(i) design-change finding.
3. No verification scan after print. Unreadable barcodes ship to hospitals; the first time anyone notices is when scanning fails at point-of-care.
4. PI not captured on the DHR. The manufacturer cannot scope a recall to a serial range because the DHR only holds the lot.
5. DPM mark fails after sterilisation. Reusable instruments come back unreadable after a few cycles — reprocessing-validation gap.
6. EUDAMED Basic UDI-DI and UDI-DI confused. The technical-documentation references and the labelled UDI-DI do not line up; Notified Body audit finding.
7. Same DI used for two different package configurations. The unit and the carton both labelled with the unit DI — recipient cannot tell what they ordered.

V5's medical-device profile treats UDI as a first-class object on the device record. Each device version carries its DI, the issuing agency, the GUDID/EUDAMED submission state, and the approved label artwork with the AI-encoded UDI carrier embedded. The platform does not submit to GUDID for you (that remains a regulatory-affairs decision and most teams use a dedicated RIM for it), but it produces the SPL-ready attributes and warns when label data drifts from the registry data.

• Approved UDI label artwork lives in the DMR under two-person change control. The DI and PI structure are validated against the issuing-agency rules at save time.
• Print-and-apply at the kiosk pulls the UDI carrier from the DMR snapshot bound to the work order. The barcode is generated server-side and logged.
• A mandatory scan-back step verifies the printed barcode parses to the expected DI and PI before the unit can be released.
• Each unit's UDI (or each lot's PI range) is written to the eDHR with timestamp, operator and printer.
• Reconciliation runs at WO close — units produced vs UDIs printed vs UDIs verified vs units shipped. Mismatches block the WO from closing.
• Post-market: the recall query takes a UDI or UDI range and returns the full reverse-trace (components, materials, equipment, operators, ship destinations) in seconds.