Most catalog problems that look like matching problems are identifier problems. A team stores a full UDI string scanned from a box, treats it as the product key, and then finds that the same model has produced four hundred different keys because every unit carried a different lot number. The fix is not a better matching algorithm. It is knowing which half of the identifier was supposed to be the key.
What a UDI Is Made Of
A unique device identifier appears on device labels and packages, and in some cases directly on the device itself, in both plain text and machine readable form. It is a single printed string, which is exactly why it gets treated as a single value. It is not one. It is a concatenation of two separately governed things.
The Device Identifier Is the Part That Stays Still
The DI identifies the labeler and the particular version or model of the device. Two units of the same model, made two years apart in different factories, carry the same DI. That property is what makes it valuable to a catalog: it is the closest thing the medical device world has to a durable product key that a buyer, a seller and a hospital system will all recognise.
It is issued under the system of one of the FDA accredited issuing agencies. GS1 is the most widely used and its identifier is a GTIN. HIBCC issues a Labeler Identification Code that the labeler combines with its own product or catalog number. ICCBBA covers blood, cellular therapy and tissue products. The three formats do not look alike, so a validation rule that only recognises one of them will silently reject the others.
- One DI per model and version. A packaging change that creates a new package configuration gets its own DI.
- The DI is the primary key in the GUDID record, and the key you can look up on AccessGUDID.
- A DI is stable across time, so it survives a catalog migration in a way an internal SKU does not.
- It is not a universal product key. Devices sold outside the systems that require a UDI may not carry one at all, so a catalog cannot treat it as mandatory.
Production Identifiers Belong to the Unit
The PI segment is where lot number, serial number, expiration date, manufacture date and, for certain devices, a distinct identification code live. These are properties of the physical thing on the shelf. They tell you nothing about what the model is and everything about which unit you are holding.
The Mistake That Creates a Thousand Phantom Products
What a GUDID Record Carries
The GUDID holds more than the identifier. A record carries descriptive and safety attributes that a catalog team will recognise, because they are the same attributes buyers ask about. The table below is a selection rather than the full element list, chosen for the fields that do real work in a commercial catalog.
| Attribute | What it is | Catalog use |
|---|---|---|
| Primary DI | The device identifier for the record | The product key. Match imports against this before anything else. |
| Brand name | The name the device is marketed under | Reconciles a supplier spreadsheet that lists a brand rather than a manufacturer. |
| Version or model number | The manufacturer's own model designation | The human readable half of identity. Buyers search this, not the DI. |
| Company name | The labeler | Not always the manufacturer people name in conversation. Worth holding both. |
| Device description | The labeler's description of the device | A starting point for content, never a finished description. |
| MRI safety status | Whether the device is MR safe, conditional or unsafe | A genuine buyer filter, and a claim that must never be guessed. |
| Contains natural rubber latex | A latex statement | A safety relevant attribute. Absence of a value is not a no. |
| Sterilization attributes | Whether it is supplied sterile and the method | Drives a filter and a real purchasing decision. |
| FDA product code | The FDA classification code for the device type | Groups a catalog into device types that map to regulatory categories. |
| Commercial distribution status | Whether it is still in commercial distribution | Flags lines that are ending, which a stale catalog will keep selling. |
How This Shapes a Seller Catalog
You are probably not a labeler. Most equipment sellers, refurbishers and distributors are not, so the submission obligation is not yours. What is yours is the consequence: your suppliers, your buyers and the hospital systems you sell into all key on these identifiers, and a catalog that cannot speak that language creates work for everyone downstream.
Store the DI as Its Own Field
Not concatenated with anything, not merged into the model column, and not reconstructed from a barcode scan at read time. Give it a column and a validation rule per issuing agency format.
Keep the Model Number Beside It
The DI is what machines match on. The version or model number is what a person types into a search box. A catalog needs both, and needs to know which is which.
Put Production Identifiers on the Unit Record
Serial number, lot and expiry describe a specific unit. If your data model has nowhere to put them, that is the gap to close before you start writing content.
Treat an Absent Attribute as Absent
A GUDID record with no latex statement is not a record that says there is no latex. Empty is not a value, and a catalog that renders empty as no is publishing a safety claim nobody made.
Where Teams Get This Wrong
- Treating the scanned string as the product key, which multiplies one model into hundreds of records.
- Assuming every device has a UDI. Older inventory, devices outside the requirement, and equipment sold in markets that do not require one will not have one.
- Assuming the labeler is the manufacturer. They are often the same company and sometimes not, and a catalog that conflates them will attribute a device to the wrong brand.
- Copying the GUDID device description straight into a product page. It is a regulatory description written for a database, not copy written for a buyer, and it is thin enough to look like a placeholder.
- Rendering a blank attribute as a negative statement. This is the single most consequential formatting decision on this list.
What GearDock Does With This
GearDock resolves each imported row to a device before it writes anything, and identifier fields are the strongest signal it has for doing that. Rows it cannot resolve confidently are grouped into an exception queue rather than guessed at. Attributes it cannot support from an attached document are reported as gaps and left out of the draft, which is why a blank latex field stays blank instead of becoming a sentence.
One Thing This Page Is Not