GUDID stores the DI, not the PI

A UDI record built to confirm a number was submitted to FDA's Global Unique Device Identification Database once, at launch, has answered a different question than the one Subpart E of 21 CFR Part 830 actually asks. This blog has already covered the standing duty to keep a GUDID record current as one stop on a UDI's longer path past the label. What that post didn't have room for is what the record itself actually holds, what it deliberately leaves out, and the specific clock 830.320 sets for updating it — a clock that runs on the change, not the calendar, and that can expire without anything on the physical label ever looking wrong.

The database holds the DI. It was never built to hold the PI.

Part 830 splits a UDI into two components: a device identifier, the fixed portion naming a specific version or model and the labeler behind it, and a production identifier — lot, batch, serial number, or manufacture and expiration dates — that varies unit to unit. GUDID is built around the first half only. A DI record covers one version or model, submitted once and then maintained; the actual PI values stamped on any given unit never get submitted to the database at all, because a live system trying to hold a row for every lot and serial number a manufacturer ever produces isn't what Subpart E asks a labeler to build. What the DI record carries instead is a set of flags — does this device's label carry a lot number, a serial number, an expiration date — marking which PI elements exist without storing what any of them equal. A team that reads “GUDID record” as a full device history, PI values included, is imagining a system Part 830 doesn't operate.

What 830.310 actually asks the record to carry

Section 830.310 sets out the data attributes a DI record has to include, and the list runs well past a name and a number: brand name, version or model, the company that labels the device, sterilization and single-use status, prescription-versus-over-the-counter status, and a device-category code, among a long run of other attributes FDA's guidance walks through in detail. The point isn't that every field matters equally — it's that a record limited to the identifier and a generic device description hasn't met 830.310's own scope, even if the identifier itself is correctly formed and correctly submitted.

The update clock runs on the change, not on a schedule

830.320 doesn't give a labeler an annual or quarterly window to true up a DI record. When information required under 830.310 changes, the update is due no later than the date the device is first labeled with the new information — and where the changed attribute never appears on the physical label at all, the update is due within 10 business days of the change instead. That second branch is the one a compliance calendar built only around labeling deadlines tends to miss, because nothing about a device leaving the building looks different when it fires: the label hasn't changed, so nothing on the shelf signals that the database entry behind it now has.

FDA can also open the file on its own

Subpart E doesn't leave accuracy entirely to the labeler's own review cycle. Under 830.350, where FDA determines that information in a DI record appears to be incorrect, inaccurate, or misleading, it can notify the labeler directly, and the labeler then has 30 days to submit a correction or a satisfactory explanation. That review happens against a record the public can already see: AccessGUDID, built by FDA with the National Library of Medicine, is open to anyone — hospitals, researchers, competitors — without an account. A stale attribute in GUDID isn't a private filing gap sitting in a compliance folder; it's a public-facing error sitting one search away from anyone who looks, until either the labeler catches it or 830.350 forces the question.

Where this meets the file

A UDI record built around this database, not just the label, needs a field for every attribute 830.310 actually requires, a trigger tied to the change log rather than a labeling deadline so the 10-business-day path doesn't get missed, and a place to log any 830.350 notice separately from a routine self-caught correction — the same discipline this blog has already argued for keeping registration and listing as two tracked obligations instead of one, since collapsing distinct FDA filings into a single status field is how one of them quietly goes unmet. A GUDID attribute worksheet built around 830.310's own required fields and 830.320's own update triggers is previewed in the launch catalog. If your program has caught a GUDID gap this one misses, the shelf takes that correction directly.