UDI Database for Device Identifiers

One federal system answers the question end to end: the Global Unique Device Identification Database (GUDID), the repository every labeler must submit key device identification to for each model of medical device carrying a Unique Device Identifier in U.S. commercial distribution. Datadory delivers it as the openFDA Unique Device Identifier (GUDID) API dataset, scored 9 out of 10 against a 7.81 average across the 1,744 datasets in the catalog.

Structure matters before anything else. A UDI splits into a device identifier (DI) - the model-specific catalog identifier - and production identifiers such as lot or serial numbers; the database stores the DI attributes and flags which production identifiers apply. That makes it a master-data table rather than an event log, unlike its openFDA siblings: 175,814 510(k) notifications and 58,999 recall events describe things that happened, while these records describe things that are.

Thirty-nine documented fields structure each record, and they read like a procurement spec written by a regulator. Identity comes from brand_name, catalog_number, version_or_model_number, company_name and labeler_duns_number, with free-text device_description beside them. Commercial state is explicit rather than inferred: commercial_distribution_status, commercial_distribution_end_date, record_status, and a public_version_number/public_version_date/public_version_status trio tracking every revision.

Eight structured blocks carry the analytical weight. identifiers lists primary and previous DIs with their issuing agency (GS1 among them); gmdn_terms supplies code, name, full definition and an implantable flag; product_codes arrives enriched with device_class, regulation_number and medical_specialty_description; premarket_submissions links each model back to its 510(k), PMA or De Novo number. Handling detail includes mri_safety, storage, device_sizes, device_count_in_base_package and customer_contacts. Datadory ships the dictionary alongside the rows, so none of that has to be reverse-engineered from sample payloads.

Sample rows show how far one record reaches. An Ansell MICROFLEX XCEED XC-310 size XL nitrile examination glove resolves to primary DI 00769799310140 with is_rx false and an active distribution status. A Pioneer Surgical Fortilink-L interbody fusion cage lands as GMDN term 60762 Polymeric spinal interbody fusion cage, flagged implantable and single-use with MR Conditional labeling. CTL Medical's AL Disc Prep wedge distractor tip carries premarket_submissions K192863 - a direct line from a catalog row to its clearance.

UDI-DI is the documented join key for linking adverse events, recalls and procurement records back to master data, which turns one identifier into the spine of four other corpora:

• The openFDA Device 510(k) Clearances API holds 175,814 notifications back to 1976; GUDID's premarket_submissions array reads in that direction, tying each model to its K-number.
• The openFDA Device Recalls API adds 58,999 recall events classified since November 1, 2002, with code_info and k_numbers arrays resolving affected lots down to the models a buyer actually stocks.
• The openFDA Device Adverse Events (MAUDE) API contributes 25,711,469 reports, and since October 20, 2022 each report may carry device.udi_public, a redacted public UDI that arrives unvalidated and only on a subset of reports.
• The ClinicalTrials.gov API v2 - Studies Database supplies the evidence context: 89,921 studies matched a device-intervention query at research time, the pipeline feeding the next round of filings.

The head-to-head between the two non-event sources sits on the ClinicalTrials.gov vs GUDID comparison page. The scorecard below sums up the identifier-bearing side of the pool:

A SKU-to-master-data load runs in seven steps once the corpus arrives as typed rows:

1. Key the table on the primary DI. One row per model version means a catalog number can span several versions, so store version_or_model_number beside the DI rather than trusting catalog_number alone.
2. Match on labeler, not brand string. Join SKUs on catalog_number plus company_name or labeler_duns_number; free-typed brand strings fork into spellings that no fuzzy match survives at scale.
3. Keep previous DIs live. The identifiers block lists superseded identifiers so reissued DIs do not orphan existing catalog lines mid-quarter.
4. Gate purchasing on distribution status. commercial_distribution_status and commercial_distribution_end_date mark models that left the market - the difference between a reorderable SKU and a liability sitting in a pick face.
5. Classify without free-text guessing. GMDN terms carry code, name and definition; product codes add device_class and medical_specialty_description, so category rollups survive contact with real assortments.
6. Version-stamp every extract. Labeler revisions accumulate silently upstream, so keep successive captures and treat any stored count as a floor rather than a ceiling.
7. Build on GMDN now. FDA announced in December 2024 that Preferred Term (PT) codes will leave the database in favor of freely accessible GMDN codes, so aggregate on GMDN before the nomenclature moves under you.

Steps one through four are joins; steps five through seven are the difference between a catalog that reconciles quarterly and one that quietly rots. Both halves run inside one schema when the corpus lands already normalized.

No values, only declarations. Records state which production identifiers a label carries through five has_ flags - has_lot_or_batch_number, has_serial_number, has_expiration_date, has_manufacturing_date and has_donation_id_number - inside a set of 15 boolean labeling fields. The lot and serial values themselves never enter the database; they stay on the packaging, because the UDI rule separates static model data from unit-level traceability.

For a supply-chain build the distinction is practical. The flags tell demand planners that a model carries expiration dating before any unit arrives, while actual dates require scanning at goods receipt. Classification works the same way: is_rx, is_otc, is_single_use, is_kit, is_combination_product and is_hct_p sort items without reading descriptions, sterilization attributes cover is_sterile, prior-use status and methods, and latex labeling flags close out the allergen questions procurement asks first.

Three limits shape what the corpus supports, and all three come printed on the source documentation itself.

Declared, not audited. Attributes are submitted by labelers under the UDI rule, and the agency disclaims validation for clinical or production use - treat a record as what the labeler declared, not an independent measurement.

Master data, not traceability. Unit-level history lives outside the corpus by design, so chain-of-custody questions need scanning systems rather than identifier lookups.

All eight personas active in the Health Care Supplies slice touch the record, and the relevance spread shows which jobs lean on identifiers hardest.

E-commerce operators and developers land at relevance 3 - normalizing medical-supply listings against official master data per DI, so a storefront stops selling three spellings of one glove. Worked integration patterns sit on the developers builders use cases page.

Four personas sit at relevance 2. Data scientists resolve device identities on DI keys and GMDN terms (data scientists). Competitive-intel teams watch for new model registrations and quiet category exits - movement visible months before press releases confirm it. Market researchers count distinct models per GMDN term as an assortment-density proxy (market researchers use health care supplies data). Sales teams segment prospects by labeler portfolio breadth.

Investors and journalists-academics land at relevance 1: portfolio counts per labeler read only coarsely during diligence, and aggregate identifier counts rarely carry a narrative.

As rows, not exports you babysit. Datadory normalizes the identifier corpus - and the clearance, recall and adverse-event tables it joins onto - into typed tables keyed on the DI string and K-number, with the thirty-nine-field dictionary attached, so a single DI lookup and a five-million-row synchronization run through exactly the same pipeline.

Upstream loads move weekly, but your delivery schedule should follow the decision the data feeds, not the load calendar. A catalog-synchronization job wants scheduled refreshes so new model versions become observable history; a one-time sourcing question wants a single shaped extract. Those are separate settings, and neither requires you to track when any particular upstream load lands. Watermarking comes standard: each delivery carries its load date, because any stored total count is already a floor.

This page covers one workflow inside the 20-dataset Health Care Supplies pool - 8 primary sources plus 12 related cross-references. Start with the pillar health care supplies data guide for the full tour, then continue along the adjacent workflows: Where can I get a list of FDA-cleared medical devices? walks the clearance ledger these identifiers point back to, and fda product code lookup covers classification by device type.