Look closely at the label of almost any medical device, from a box of catheters to an implanted lens, and you will find a machine-readable code with a specific structure. That is a Unique Device Identifier, a UDI, and it exists to solve a problem that sounds mundane but matters enormously: being able to say, precisely and unambiguously, which device this is. When a recall hits, when an adverse event is reported, or when a hospital tracks an implant, a consistent identifier is what makes the device findable across systems.

The requirement is short and direct. 21 CFR 801.20 states the obligation in two sentences, covering both the device label and every device package.

"(1) The label of every medical device shall bear a unique device identifier (UDI) that meets the requirements of this subpart and part 830 of this chapter. (2) Every device package shall bear a UDI that meets the requirements of this subpart and part 830 of this chapter."— 21 CFR 801.20, source

The regulation points to two places: this subpart of Part 801 (the labeling rules) and Part 830 (the UDI system itself). Together they establish what a UDI must contain, who issues the coding standards, and how the data is published. The rule traces to a 2013 Federal Register final rule, cited in the regulation as 78 FR 58818, that built the U.S. UDI system and phased it in by device class over several years.

The two parts of a UDI

A UDI is not a single random string; it is structured into two components, and understanding the split is the key to the whole system. The first is the device identifier (DI): a mandatory, fixed portion that identifies the specific version or model of the device and the labeler (the company responsible for it). The DI is constant for a given device model, it does not change unit to unit. The second is the production identifier (PI): a conditional, variable portion that conveys production-specific data when present on the label, such as the lot or batch number, the serial number, the manufacturing date, or the expiration date. The PI is what distinguishes one physical unit, or one production run, from another.

The codes are not invented by each manufacturer in isolation. The FDA accredits issuing agencies that operate UDI standards, and a UDI carries the markings of whichever standard issued it. A real record from the FDA's UDI database shows the structure plainly: the 'EnVista MX60 IOL' intraocular lens from Bausch & Lomb Incorporated carries a primary device identifier '10757770515926' issued by GS1, one of the accredited issuing agencies. That single DI ties the physical lens back to a full record of the device's attributes.

GUDID: the public database behind the codes

The device-identifier half of every UDI is published. The FDA operates the Global Unique Device Identification Database, GUDID, where labelers submit the DI and a set of attributes for each device, brand name, company, model, sterility, and more. The production identifier is not stored in GUDID (lot and serial numbers are too granular and unit-specific); only the device identifier and its standing attributes are. The result is a public reference that maps any DI to a known device.

The scale is substantial. The FDA's openFDA UDI dataset, drawn from GUDID, holds more than five million device records, 5,083,948 in a recent query, each keyed to a device identifier. That volume is the payoff of the system: a single, queryable backbone for identifying medical devices across the supply chain, electronic health records, recall notices, and adverse-event reports.

For a reader, the UDI is best understood as a two-layer identity. The device identifier answers 'what kind of device is this, and who labels it,' and it is public in GUDID. The production identifier answers 'which specific unit or lot is this,' and it lives on the label rather than in the database. The requirement that both appear, on the label and the package, comes straight from 21 CFR 801.20, and it is what lets a device be tracked from the factory to the patient with a single, standardized code.

Two formats, one code, and the exceptions

A UDI must be presented in two forms at once: a plain-text version that a person can read, and an automatic-identification-and-data-capture (AIDC) version, usually a barcode, that a scanner can read. That dual presentation is what makes the identifier work both at a bedside, where a nurse may read it, and in an electronic inventory system, where a scanner captures it. The accredited issuing agencies, GS1 among them, define the encoding standards so that a scanner anywhere can parse a UDI consistently. The 'EnVista MX60 IOL' record, with its GS1-issued device identifier, is a single concrete instance of that standardized encoding in the public dataset.

The rule is not absolute, and 801.20 itself points to the carve-outs. It references exceptions in sections such as 801.30, 801.45, and 801.128(f)(2), and provides, through 801.55, a route to request an exception or an alternative where the standard placement is impractical, for instance, on devices too small to bear a legible code, or where direct marking on a reusable device would interfere with safety or performance. These exceptions are narrow and procedural; the default, stated plainly in 801.20, remains that every device label and every device package bears a UDI. Read together, the requirement and its exceptions describe a system designed to be near-universal while still bending for the genuinely impractical case, which is exactly how a database can grow past five million records and still mean something consistent for each one.