GUDID stores the model. Not the box.

Pull a Global Unique Device Identification Database record for a subscriber’s own catalog number and it reads like a finished answer: labeler, brand, model, GMDN term, the FDA product code, the premarket submission that cleared it. It is finished — for exactly one of the two facts a Unique Device Identifier is built to carry. The other fact was kept out of the record on purpose, and knowing which is which is the difference between confirming a device and confirming a box.

What a UDI is actually built from

FDA’s own definitions, at 21 CFR 801.3, split a Unique Device Identifier into two parts that behave nothing alike. The device identifier (DI) is, in the regulation’s own words, “a mandatory, fixed portion of a UDI that identifies the specific version or model of a device and the labeler of that device.” The production identifier (PI) is “a conditional, variable portion” that can carry a lot or batch number, a serial number, an expiration date, a manufacture date, or — for an HCT/P regulated as a device — a distinct identification code. One half of a UDI answers which catalog number, whose label. The other half answers which specific unit, made when, expiring when, part of which run. They are not two versions of the same fact, filed twice for redundancy. They are two different questions FDA decided a single identifier should be able to answer, and only one of them is the kind of fact a national database can hold still.

What actually reaches the public database

The Global Unique Device Identification Database stores the first half only. A DI record in GUDID — searchable through AccessGUDID, the public interface FDA and the National Library of Medicine maintain — carries the labeler’s name, the brand and model, the GMDN term and code, MRI safety status, the premarket submission number, and the FDA product code the device is filed under: a genuinely rich record, at exactly one level of the device. Production identifiers are never submitted as values at all. What GUDID stores instead is a set of PI flags — yes-or-no markers for whether a lot number, a serial number, an expiration date, or a manufacture date appears on that device’s own label, never the number itself. The record tells a reader that a lot number exists on the label. It does not, and structurally cannot, tell a reader which lot.

A DI record answers what this device is and who is responsible for it. It was never asked to answer whether this is the unit that failed — that fact belongs to the half of the UDI the public database doesn’t hold.

Why the missing half is usually the one in front of you

A device recall’s code-information field, or a MAUDE narrative describing a specific failure, routinely cites exactly the kind of fact GUDID was built to exclude: a lot number, a serial range, a date of manufacture. Pulling the matching DI record confirms the model — yes, this catalog number is one a subscriber’s portfolio actually includes. It cannot confirm the unit. Answering whether this is a subscriber’s own box requires the labeler’s own distribution records, matched against the PI printed on a label GUDID never received a copy of. The gap is not a search technique that needs refining, and it is not a data-quality problem some future submission will fix. It is the shape FDA built the database in, on purpose, at the level FDA decided a national public registry should operate.

The practice

Read a GUDID or AccessGUDID hit as confirmation at the model level, never the unit level, and stop there deliberately rather than by accident. FDA Radar’s own matcher runs on five join bases today — product code, CFR regulation, application number, firm, and manufacturing partner — and none of them is a UDI; per what we monitor and how often, GUDID isn’t behind any of the four feeds those bases run against in the first place. Whether a specific lot or serial number named in a recall or an adverse-event report belongs to a subscriber’s own inventory is a question only that subscriber’s own shipping and quality records can answer. This is a description of what one public database was built to hold and what it was built to leave out — regulatory intelligence and method, never a determination about any device’s own unit history.