Seeding Your Equipment Registry from the FDA AccessGUDID Database

A New Contract, a Blank Registry

A regional ISO just signed its fourth hospital client. The handoff folder from the outgoing vendor has three different spreadsheets, none of which agree on model numbers. Serial numbers are missing on a dozen infusion pumps. Someone has to build a clean equipment registry before the first PM cycle starts, and the client wants it inside two weeks.

This is the moment most shops reach for whatever paperwork the outgoing vendor left behind and start typing. There is a faster starting point: the FDA's public device database. Every device carrying a Unique Device Identifier has a corresponding record in it, and that record includes manufacturer name, brand name, model identifiers, and device description — fields that would otherwise have to be copied by hand off a label or a faded asset tag.

This article walks through using the FDA AccessGUDID equipment registry data source directly: what it is, how to pull records manually for a handful of devices, how to pull records in bulk for a full site seed, and — just as important — what it does not give you, so nobody builds a registry assuming the database does more than it does.

What This Guide Is — and Isn't

This is a documentation aid, not legal, regulatory, or accreditation advice. Nothing here substitutes for reading current CMS Conditions of Participation guidance, Joint Commission standards, or AAMI recommended practices directly, and the compliance obligation for your registry stays with your organization, not with any software or article.

The scope here is equipment service records only. Nothing in this workflow touches patient health information, connects to an EHR, or pulls device telemetry. An equipment registry seeded this way holds facilities and asset data — make, model, identifiers, location, maintenance history — and nothing clinical.

What AccessGUDID Actually Is (and Isn't)

GUDID — the Global Unique Device Identification Database — is administered by the FDA as a reference catalog covering every device that carries a UDI. AccessGUDID is the public-facing portal, built in partnership with the National Library of Medicine, that makes that catalog searchable and downloadable without needing FDA credentials.

Labelers submit device records to GUDID under 21 CFR Part 830, either through manual web entry or HL7 Structured Product Labeling bulk upload, depending on how many devices a given manufacturer maintains. That means the quality and completeness of any one record depends on how that manufacturer filed it — AccessGUDID reflects what's been submitted, not an FDA-verified physical inspection of your specific unit.

Practically, that means a search in the FDA AccessGUDID equipment registry source will usually return: manufacturer name, brand name, model number or catalog number, device description, and the GMDN or product code categorization associated with the device type. If you need help mapping those device-type codes into a usable registry schema, the walkthrough on GMDN classification for medical devices covers that step in more detail.

It will not return: the serial number of the specific unit sitting in your client's imaging suite, that unit's install date, its current location, its PM interval, or any history of service performed on it. Those fields live in your registry, not in the FDA's.

Manual Lookup: Searching Device by Device

For a small addition — a handful of new units, a single new client site with twenty pieces of equipment — searching AccessGUDID one device at a time is often the fastest path.

A typical manual lookup follows this sequence:

1. Find the UDI label on the device, or on its original packaging if the physical label has worn off. Most UDIs appear as both a barcode and human-readable text.
2. Search the AccessGUDID portal using the Device Identifier (DI) portion of that UDI, which stays constant across the device's production run — the Production Identifier (PI) portion encodes lot or serial detail and is not what you search on.
3. Confirm the returned record matches the device in front of you by checking brand name and model against the physical unit, since database entries are sourced from manufacturer submissions and occasional mismatches happen.
4. Copy the manufacturer, model, and device description fields into your registry, then add the fields AccessGUDID can't supply: serial number, asset tag, physical location, assigned technician, and PM schedule.

This is slow at scale but reliable for small batches, and it's a reasonable way to learn the data model before committing to a bulk pull. If your team is still deciding on a registry structure, the medical equipment inventory template walks through which fields a registry actually needs before you start populating it from any source.

Bulk Seeding: The AccessGUDID Download Mechanism

When the job is seeding dozens or hundreds of records at once — a new client site, a merger of two shops' equipment lists, a registry rebuild — manual lookup stops being practical. AccessGUDID has a bulk option built for exactly this.

AccessGUDID allows users to download the full GUDID dataset at once, without an account, which is the mechanism behind seeding a local equipment library rather than looking up devices one at a time. In practice this means downloading a structured data file covering the full device catalog, then filtering it down to the manufacturers and device types relevant to your shop's equipment mix before importing anything.

A workable bulk-seed sequence looks like this:

• Pull the current bulk dataset from the AccessGUDID download page.
• Filter to the manufacturers your shop actually services — most ISOs cover a recognizable short list of brands across infusion, patient monitoring, and imaging accessory equipment, so this step cuts an enormous dataset down fast.
• Cross-reference the filtered list against your actual walkthrough count at the client site, not the other way around — the database tells you what a device is, not which of them are physically present at a given facility.
• Export the matched subset into a CSV structured to your registry's columns.
• Import that CSV into your working registry, then manually append the site-specific fields: serial number, location, in-service date, PM frequency, and assigned tech.

That last step is where most of the real work still happens. The database shortens data entry; it doesn't replace the walkthrough. If your import process needs a concrete column structure to map into, the CSV import template for equipment inventory lays out a field-by-field format designed for exactly this kind of bulk load, and the asset register guide covers how to structure the registry once records are in.

The Gaps You Still Have to Fill

It's worth stating plainly what AccessGUDID will not do for your registry, because assuming otherwise creates bad records.

No serial numbers. The database identifies device models and production batches, not the specific unit on your client's floor. Serial numbers come from the physical asset, every time.

No location or ownership data. GUDID has no concept of which hospital owns a given unit or where it sits inside that hospital. That's registry-side information your team has to capture directly.

No service or calibration history. A device record in AccessGUDID tells you what the device is. It says nothing about when it was last calibrated, what its PM interval should be, or whether it has an open work order. That history accrues inside your own system from the day you take the device on.

No guarantee of currency for every record. Because submissions come from manufacturers under 21 CFR Part 830 through varying methods, record completeness varies by manufacturer and device line. Treat every pulled record as a starting point to verify against the physical label, not a final answer.

Keeping the Registry Current After the Initial Seed

Seeding a registry from AccessGUDID is a one-time or periodic bulk operation, not a live sync. New equipment purchased after your seed date won't appear automatically; retired equipment won't disappear from your records just because it's gone from the floor. Both of those updates stay a manual or workflow-driven process inside your registry going forward.

That's also where the gap between "a spreadsheet seeded once" and "a registry that stays accurate" tends to show up. A static CSV doesn't flag a device that's six months overdue for its next PM, and it doesn't produce a client-ready export when a surveyor asks for proof of current equipment status. A working registry needs both the initial data and an ongoing mechanism for new intake, retirement, and per-client reporting.

If your shop is past the spreadsheet-seeding stage and needs that ongoing structure — a registry that tracks PM due dates, ties service history to each asset, and produces a per-client export on demand — a short trial is the fastest way to see whether that structure fits how your team actually works. You can also start from a ready-built structure rather than a blank sheet: the Equipment Inventory & Asset Registry Builder CSV import template gives you the column schema this article's bulk-seed process assumes, pre-formatted for direct import.

Either way, the FDA's public device database solves the "what is this device" problem efficiently. The "is this device compliant and on schedule" problem still belongs to your registry, your PM calendar, and your documentation — built and maintained after the seed, not instead of it.