UDI Labeling and GUDID Submission: The Practical Workflow

Assigning a UDI-DI to a device and getting that device’s record accepted into the FDA’s Global Unique Device Identification Database (GUDID) are two different jobs. The first is a labeling decision, made once per device version. The second is a recurring data-submission workflow — account setup, a choice between two technical submission routes, a fixed set of required and conditionally-required data attributes, and a validation process that rejects a meaningful share of first-time submissions on data-quality grounds rather than on anything wrong with the physical label.

This guide covers that submission workflow specifically: what a labeler needs before submitting, how a GUDID account gets set up, the two ways records actually reach GUDID, what the data record has to contain, and the rejection patterns that most often send a submission back. For the underlying UDI-DI/UDI-PI structure, the FDA-accredited issuing agencies (GS1, HIBCC, ICCBBA), and the device-class compliance timeline, see our guide on UDI for medical devices — this page assumes that context rather than repeating it.

Before you can submit anything to GUDID

Three things have to be in place before a labeler can put a device record into GUDID:

• A UDI-DI has already been assigned. The labeler has obtained a Device Identifier from one of the FDA-accredited issuing agencies for the specific device version or model being submitted. GUDID is where that DI’s data record lives — it doesn’t assign the DI itself.
• The labeler has a DUNS number. GUDID identifies labelers by their Dun & Bradstreet D-U-N-S Number, not by name alone. A labeler without an active DUNS number cannot request a GUDID account; this is frequently the first delay smaller or newly-formed device companies run into, since a DUNS number has its own separate application and confirmation lead time outside FDA’s process entirely.
• An FDA account exists for identity verification. GUDID account requests are submitted through FDA’s industry account system, which ties the requester’s identity to the labeler DUNS number before any submission access is granted.

Setting up a GUDID account

A GUDID account is requested per labeler DUNS number, not per device or per product line — one labeler entity, one account, covering every device that labeler brings to market. Within that account, FDA distinguishes account roles: a Labeler Account Administrator who manages user access and can designate additional submitters, and one or more Data Submitters who actually enter or upload device records. A labeler may also authorize a third party — a regulatory affairs consultant or an agent — to submit on its behalf, but the underlying account and legal submission responsibility still sit with the labeler’s own DUNS registration, not the agent’s.

FDA also maintains a separate GUDID test environment, distinct from the production database, specifically for labelers submitting via the machine-to-machine route (below) to validate that their files parse and pass schema checks before anything reaches production. Skipping the test environment on a first bulk submission is one of the more avoidable ways a labeler discovers formatting problems only after a production rejection.

Two ways a record actually reaches GUDID

FDA supports two distinct submission mechanisms, and which one makes sense depends almost entirely on how many device records a labeler manages:

• The GUDID Web Interface. A browser-based form for entering one device record at a time directly into GUDID. No file format or transmission infrastructure required — a Data Submitter logs in and fills in each attribute manually. This is the practical route for labelers with a small device catalog, infrequent new submissions, or occasional single-record updates, and it’s where most first-time or low-volume labelers start.
• HL7 SPL (Structured Product Labeling) via the FDA Electronic Submissions Gateway. An XML file built to a device-specific SPL implementation guide, submitted in bulk through the same ESG infrastructure FDA uses for other electronic regulatory submissions. This route suits labelers with large or frequently-changing device catalogs, or those with existing regulatory-data systems that can generate the XML programmatically rather than re-keying records by hand.

Note the naming overlap with drug listing: FDA also uses an HL7 SPL format for prescription drug establishment registration and listing, covered in our SPL guide — but that is a separate implementation guide serving a separate regulatory system (drug listing and DailyMed, not GUDID). A device labeler building SPL files for GUDID is working against the device SPL implementation guide, not the one that guide covers; don’t assume XML built for one will validate against the other.

What a GUDID record actually has to contain

A GUDID submission is not just the DI and a device name. The record is built from a defined set of data attributes, some mandatory for every device and others conditionally required depending on the device’s own characteristics — meaning a field can be “required” for one device and correctly blank for another, based on how earlier fields in the same record were answered. The attribute set spans several categories:

• Core identity: the DI itself, labeler (company) name, brand name, version or model, and a device description.
• Device characteristic flags: boolean and coded fields such as whether the device is sterile, single-use, contains natural rubber latex, requires prescription use, is a kit, or is part of a combination product — each of which, when set, typically triggers one or more additional required fields (sterilization method if “sterile” is set, for example).
• Classification and coding: the FDA product code and, for many devices, a GMDN (Global Medical Device Nomenclature) code, plus a cross-reference to the relevant premarket submission (510(k), PMA, or De Novo number) where one exists.
• Production identifier configuration: which PI types — lot/batch, serial number, expiration date, manufacture date — actually appear on this device’s label, which determines what a downstream scanner should expect to parse off the physical unit.
• Package and sizing data: package configuration/quantity and, where clinically relevant, size attributes such as length, diameter, or gauge.

Records also aren’t “submit once and done.” A device record has to be kept current — a labeling change, a change in an issuing agency’s data, or a device version change means the GUDID record needs a corresponding update rather than being left to drift from what’s actually on the shelf.

Why GUDID submissions get rejected

Most GUDID rejections trace back to a handful of recurring patterns, not to anything wrong with the physical device or its label:

• DI check-digit or format errors. GS1 GTIN-based DIs (and the other issuing agencies’ own formats) carry a check digit; a transposed or mistyped digit fails validation before the rest of the record is even evaluated.
• Duplicate DI. Submitting a DI that’s already registered — to this labeler or, more problematically, to a different one — is rejected outright; this usually traces back to an internal mix-up between a genuinely new device version and a change that should have been handled as an update to an existing DI instead.
• Missing conditionally-required attributes. The most common category: a characteristic flag is set (sterile, for example) without the data element that flag requires (a sterilization method), or vice versa — an inconsistency the validation logic is specifically built to catch.
• Invalid or mismatched classification codes. A GMDN code or FDA product code that doesn’t correspond to the device description, or that’s been retired/superseded since it was last used.
• Labeler/DUNS mismatch. A submission attempting to create or modify a record for a DI that belongs to a different labeler’s DUNS registration than the one submitting it.
• SPL file/schema errors, for HL7 submissions specifically. Malformed XML, an incorrect document type code, or a file that doesn’t validate against the current device SPL implementation guide version — the same class of structural rejection that affects drug-listing SPL, just against a different schema (see the SPL guide linked above for how that validation logic works in the parallel drug-listing system).

A practical submission checklist

1. Confirm the UDI-DI is already assigned by your issuing agency (GS1, HIBCC, or ICCBBA) for this exact device version.
2. Confirm your labeler DUNS number is active and matches the entity that will hold the GUDID account.
3. Request the GUDID account (or account access, if your organization already has one) and confirm your role — Account Administrator or Data Submitter.
4. Decide Web Interface vs. HL7 SPL based on catalog size and submission frequency, not just what’s technically available to you.
5. For SPL submissions, validate the file in FDA’s GUDID test environment before submitting to production.
6. Work through the attribute set device-characteristic flag by flag — sterile, single-use, latex, kit, combination product — and confirm every field that flag conditionally requires is populated and consistent.
7. Cross-check the FDA product code and GMDN code against the actual device description and current classification before submitting.
8. After acceptance, treat the record as a living document: schedule a review whenever the device’s labeling, classification, or premarket submission status changes.

Frequently asked questions

What’s the difference between UDI labeling and GUDID submission?

UDI labeling is putting the Device Identifier and Production Identifier on the physical device and its packaging, in plain-text and machine-readable form. GUDID submission is the separate step of getting that device’s data record into FDA’s database. A device can be correctly labeled and still be out of compliance if its GUDID record was never submitted, is incomplete, or was rejected and never resubmitted.

Do I need a DUNS number to submit to GUDID?

Yes. GUDID accounts are tied to the labeler’s Dun & Bradstreet D-U-N-S Number, and an account request cannot be completed without one. Obtaining a DUNS number is a separate process from anything FDA runs, so it’s worth starting well before a compliance date if your organization doesn’t already have one.

Can I submit device data to GUDID myself, or do I need to use an agent?

A labeler can submit directly through its own GUDID account — there’s no requirement to go through a third party. Many labelers, particularly smaller ones without in-house regulatory-data infrastructure, do choose to authorize a regulatory affairs consultant or agent as a Data Submitter, but the account and legal submission responsibility remain with the labeler’s own DUNS registration either way.

What happens if a GUDID submission is rejected?

A rejected submission doesn’t create a live record — the device is treated as though its data was never submitted until a corrected version is resubmitted and accepted. Because GUDID data submission is tied to a device’s compliance date, a rejection that isn’t caught and fixed promptly can leave a device technically out of compliance even though the label itself is correct.

Is GUDID submission required for every device?

Submission obligations follow the same device-class-based compliance schedule that governs UDI labeling generally, with some device-specific exceptions and alternatives FDA has granted over time. See our UDI for medical devices guide for that compliance-timeline framework, and confirm your specific device’s current status directly against FDA’s UDI guidance rather than assuming from the general class-based schedule alone.

Related CASRAI resources

• UDI for medical devices — DI/PI structure, issuing agencies, and the compliance timeline
• Structured Product Labeling (SPL) — the parallel HL7 SPL submission system used for drug establishment registration and listing
• FDA medical device classification, 510(k), and PMA pathways
• FDA 510(k) premarket notification
• 21 CFR Part 820 / QMSR subpart map — including the labeling and identification recordkeeping requirements that reference UDI